一、应用背景
随着计算技术的进步，内存、CPU、磁盘等资源不再是稀缺的，计算机作为应用程序的载体从单服务器转变为多服务器，集中计算演化为分布式计算。原有的“巨石”应用难以适应业务的发展速度，可扩展、自适应的能力不足，程序员面对着数以万计的源代码文件抓耳挠腮（O M G!），越来越多的工程师渴望小而美、易于扩展的架构体系，微服务应运而生。自2005年首次由Peter Rodgers提出微服务概念以来，风靡一时，随着近些年的发展，已经逐步被千万企业所采用，多数为互联网企业。我于工作半年之后有幸参与到后端微服务架构迁移的产品设计和开发中，有些体会，与大家分享。
二、设计原则
- SRP（Single Responseble Principle）即单一职责原则，每一个服务提供者仅暴露自己职责范围内的接口，操作职责范围内的DB，不继承其他服务提供者的协议。简单点说，该你干的才去干，不该干的调用其他人的服务来干。
- RESTful，作为Web Service的替代者，其面向资源的特性注定是为微服务而生的，接口设计符合REST设计原则将使服务易于理解和接受。需要注意的是，灵活的使用，而不是生硬的照搬REST设计，如保持请求风格一致，GET/POST，少用DELETE/PUT（仁者见仁，智者见智）；保证同类资源前缀的一致性等。REST和RPC的优劣如表2-1。说一下可扩展性吧，RPC多以client拥有server的interface来实现通信，当接口变动后，client必须马上升级，而REST的接口协议可以不强制升级。
响应时间
用户友好程度
可扩展性
REST
***
*****
*****
RPC
*****
**
****
- 协议，也就是实体或者Bean了，作为各个服务组件共有的内容，是组件之间调用的桥梁。服务组件之间的调用通过协议进行调用，协议尽量不去彼此继承。如果说微服务是个分布式的世界，那么协议就是这个世界的法律文书（感觉很严肃的样子）。
三、架构图
关键点：
1.服务注册中心，zookeeper集群作为分布式调度中心，各个服务注册在zookeeper之上，注册内容包括服务的请求url，请求ip地址和端口，服务组件名称，注册时间等；
2.Gateway，服务网关作为系统的入口，具有服务转发、授权验证、负载均衡等作用，使用高并发框架netty实现高速转发等；
3.访问控制服务，用户首先需要获得系统授权才可以访问业务服务，授权通过token来实现；
4.业务服务1~N，是系统内具体业务组件的划分；
5.用户服务，实现用户信息的注册、修改、共享等；
6.配置中心，整个系统的配置均位于配置中心，组件通过访问配置中心获取配置参数；
7.监控系统，检测ECS、RDS、zookeeper集群等的各项状态；
8.Kafka消息队列系统，支撑其他系统。
后续会对各个子系统和子系统用到的技术跟大家简要分享。晚安。
By Will