1、概要
1.1、借助模型工具，画出对架构的理解，从历史演变开始，到目前落地的、较成熟的架构，描述出对它的理解。通过历史演变，我们知道为什么用这个架构，用这个架构有什么好处，如果我们继续延伸的时候，我们如何去实现“易插拔”的理想状态。以下文章仅仅是个人理解，难免存在错误。
1.2、纲要
单体应用的结构
单体应用的发展与需求
单体应用如何一步一步到多体应用发展。
微服务结构下的模式
微服务架构的技术选型思考
总结
2、单体应用
2.1、单体应用的图示
用户Client的请求，发送至服务器端的程序，通过服务器软件，服务器软件有Nginx、Apache、Tomcat、IIS等。这些服务器软件各有特点，根据不同的场景和服务器端程序的开发语言不一，选用不一；请求到了应用程序这里，处理用户的请求，对数据库进行CURD的访问，最后再返回给用户结果；
应用程序需要部署在大型的服务器上，DB存放在一台服务器上。
2.2、单体应用的演变
思考一下，如果，一台应用程序不够用了，或者一台DB不够了，这时候需要增加DB的服务器。那么，发过来的请求，需要转发给哪一台服务器呢？这就有了负载均衡。多台服务器应用程序，多态db，部署多个服务器软件，分布在不同地域的用户，使用负载均衡，将请求转发至离他们最近的或者最快的服务器上。那么问题来了，如果请求的时候，如果请求过多，用户一直请求，服务器应用程序却请求不了怎么办？这就需要熔断器；
陆续出现熔断器、鉴权的机制，怎么去管理呢？
这时候就是往微服务的模式转变了，这时候，就出现了注册中心，帮助开发者去管理这些熔断器、鉴权模块等。
3、微服务架构
由单体服务器慢慢演变，其实需要一个很复杂个过程，上述的过程，仅仅是一个梗概；
3.1、了解微服务模块与中间件。
首先先描述一下前后台的关系；
我们假定前端用vue.js实现，后端用Spring Cloud实现，前端的转发使用Nginx来给后端转发。
Nginx的配置文件，我们可以在/etc/nginx/nginx.conf（一般是这个配置文件，有些可能自定义的，被主配置文件引用）查看。在Nginx的配置文件里，我们可以读取前端项目所在的服务器host和端口，以及files的位置，并且，请求后端的地址也会在这里体现，这样就能够解释通了，我们的请求从浏览器发出，找到前端工程的地址，请求由Nginx反向代理到后端的项目中。
3.2、Eureka
Eureka Server:注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号；
Eureka Client:负责将这个服务的信息注册到Eureka Server中；
3.3、Feign
例如，订单模块调用积分模块，现在订单模块已经知道了积分模块的地址和端口号了。发出请求就需要借助Feign；
Feign根据指定的服务进行建立链接、构造请求、发起请求、获取响应、解析响应等；
上述的操作，Feign的一个机制：动态代理；
3.4、Ribbon
服务模块有了地址、端口、和建立连接请求的条件，如果存在多个同行服务在不同机器上，比如：
172.1.16.58:9000
172.1.16.59:9000
172.1.16.60:9000
172.1.16.61:9000
Ribbon的作用是负载均衡。每次请求的时候，会通过不同的算法均匀的将请求分发到各个服务上；
Ribbon会从Eureka Client获取到对应的服务注册表，相对应的知道了服务部署的地址和监听的端口；
Ribbon可以使用默认的轮询算法，从其中选择一台机器；
Feign就会针对Ribbon选中的这台机器，进行下一步动作；
Feign默认是带有Ribbon的依赖的，开发的时候不需要单独引入；
3.5、Hystrix
熔断机制。隔离、熔断、降级；Hystrix会生成很多小的线程池，比如订单的试一个线程池、积分是一个线程池；每个线程池中仅仅用于请求的服务；
即使积分服务挂掉，订单服务的线程池是正常的，仍旧可以工作，不会受到影响；
熔断：积分服务挂掉的话，设置时间5分钟内够来的请求直接返回；
降级：需要对某用户的积分进行操作，但是积分服务挂掉没办法进行。这时候可以设计一个专门存放故障的数据库；来记录对这个用户的积分操作是什么样子的。等积分服务恢复之后，可以手动还原回去；
3.6、Zuul
使用了一个网关，不需要关心后端有多少个微服务，只需要知道网关的地址即可。所有的请求都请过网关进行处理；
好处：可以做统一的降级、限流、认证授权等；
