参考
微服务与单体应用的关系
微服务与单体应用的区别类似于个人开发者和开发公司的区别。以一个Web项目为例进行解释：
单体应用--个人开发者
个人开发者往往一个人完成UI设计、数据库设计、前端开发、后端开发等一系列的工作。而单体应用也是如此，在一个项目中完成所有的功能模块。
微服务--开发公司
开发公司则有严密的组织架构和分工。
开发部下的每个小组都有明确的岗位和分工：项目经理负责进行项目评估、组建团队，将项目工作分解到各个开发小组，并定期更新项目进度，及时发现滞后的开发模块，调整人员分工赶工以确保项目按计划完成。每个开发小组的具体工作由组长分解到各个小组成员。管理部负责制定工作规范，开发部各岗位根据规范开展工作。人事部负责管理公司员工的入职和离职，更新公司通讯录；并统计各位员工的工作绩效，对绩效差的员工做思想工作或者辞退。
这就等同于一个微服务架构的项目，有处理具体业务逻辑的微服务，也有负责路由的统一入口；有提供微服务注册信息的服务发现，又有负责请求分发的负载均衡器；有负责监控请求链路信息的链路追踪器，又有负责解决服务雪崩的断路器。俨然是一个有明确分工和角色的组织。
一个简单的项目交给个人开发者来做往往费用更低并且开发周期更短，一个复杂的项目则需要交给开发公司才能可靠地开发。这也就体现了单体应用与微服务应用之间的关系：单体应用适合简单项目或项目初期使用，可以快速的迭代升级。但是随着项目功能越来越丰富，单体应用越来越臃肿，各个模块耦合度越来越高，最终牵一发而动全身，系统的可用性和扩展性无法保证。于是顺其自然地将不同的模块拆分为不同的项目，每个项目都进行独立的开发、部署和扩展，项目的架构则由单体应用演变成微服务架构。最终实现了各模块的解耦，提升了系统的可用性和扩展性。但是随之而来的是开发复杂度和运维工作量的增长，就像运营一个公司有房租、水电费等成本。
SpringCloud介绍
SpringCloud为开发人员提供了快速构建分布式系统的常用工具，包括配置管理、服务发现、服务熔断、智能路由、总线、鉴权等。SpringCloud基于SpringBoot实现微服务架构，它是Java项目从单体应用架构向微服务架构变迁的主流选择之一。本系列文章所用服务发现、服务熔断、负载均衡、路由等组件选用的是Spring Cloud Netflix下的。下面继续结合生活场景介绍SpringCloud中部分组件的含义：
服务发现 Eureka---公司通讯录
服务发现是微服务架构中一个关键的原则，Eureka提供了服务注册和服务发现的功能，并且各注册中心之间会互相拷贝所注册的微服务的信息，这一机制增强了Eureka对网络分区的容错能力。
Eureka就像开发公司的人事部，人事部维护了公司的通讯录，通过通讯录可以找到每一名员工的联系方式。正如人员在入职和离职时，人事部会更新公司的通讯录一样；当服务上线或者下线时，Eureka都会进行服务的注册和注销的操作。
微服务应用--小组成员
微服务应用是单体应用中各个模块拆分之后形成的一个个单独的项目，各项目之间通过HTTP API的方式进行调用。
微服务应用是整个架构中从事具体业务流程处理的模块，就像开发部各小组的成员，从事具体的设计、开发、测试、运维等工作，不像领导只安排工作不做工作。
断路器Hystrix--员工绩效考核制度
断路器是为了解决服务雪崩而设计的。如果没有引入断路器，当某个微服务出现故障时，可能会造成服务调用请求的阻塞，导致该请求的线程资源被占用。在高并发情况下，越来越多的请求阻塞，最终导致整个系统的线程资源耗尽，服务瘫痪。引入断路器后，断路器通过监测微服务，在微服务出现故障的次数超过阈值后（hystrix默认阈值为5秒内20个故障），断路器将“打开回路”，执行错误回调，不再将请求转发到故障服务，从而避免服务雪崩的发生。
断路器的作用就像公司的绩效考核制度，如果项目成员在工作中出现较大的失误，那么他的绩效会被扣除。如果该员工接二连三的出错，那么领导将会找他谈心，该员工要么端正工作态度，要么走人，避免公司业务进一步受到影响。
断路器监控Hystrix Dashboard和Turbine--员工绩效考核表
断路器会记录每一次微服务请求的结果，Hystrix Dashboard和Turbine可以高效地展示断路器的实时状态。只是Dashboard每次只能展示一个断路器的状态，而Turbine可以同时展示多个断路器的状态，从而反应整个系统的运行状况。
断路器监控就像员工绩效考核表，员工的每一项工作都记录在考核表中，哪些工作干的好加分，哪些干的差扣分都一目了然。Hystrix Dashboard就是单个员工的考核表，而Turbine就是多个员工考核表的汇总，通过所有员工的绩效情况可以获知整个公司的运营情况。
客户端负载均衡器Ribbon--小组组长的工作安排机制
Ribbon是位于客户端的负载均衡器，一个微服务通常对应多个不同的微服务实例，在用户请求这些微服务时，Ribbon会根据负载均衡规则，将请求转发给对应的微服务实例进行处理。负载均衡机制提升了系统的并发处理能力和可用性。
负载均衡器Ribbon的行为就像开发部小组组长的工作安排机制。每个岗位都至少有两名员工，小组长会在这些员工之间安排工作，这样小组可以同时做多个工作（并发处理能力），并且当某个员工请假时，有其他员工可以安排工作，避免小组工作的搁置（高可用性）。
路由/网关Zuul--项目经理的工作安排机制
Zuul是基于JVM的路由器，也是服务端的负载均衡器。它是微服务请求的入口，Zuul将特定URL的请求转发给对应的微服务进行处理。
路由/网关Zuul的行为就像开发部项目经理的工作安排机制。项目经理会根据工作的性质，将特定的工作安排给对应的小组。比如原型设计类的工作，安排给产品组来做；业务逻辑代码编写工作，安排给后端组来做；项目部署类的工作，安排给运维组来做。项目方面的工作，开发部门都交由项目经理来安排，而不会直接将工作安排给下面的小组。
统一配置Config--管理部的开发规范
统一配置中心ConfigServer可以从本地，或网上仓库读取配置文件；并为微服务架构中的各个组件Config Client提供了以HTTP API的方式读取配置文件的功能。当项目在开发、测试、生产环境中切换时，无需重新打包部署项目，只需要在配置中心修改配置即可，降低了运维方面的工作量。
统一配置就像管理部下发的各种开发规范，不同的小组有着不同的规范，小组成员都按照各自的规范各司其职。随着公司的发展，组织结构的优化，各种开发规范也在不断的完善。这就如同项目迭代更新过程中，参数配置不断完善，项目的性能不断提高。
链路追踪Sleuth--工作进度统计
Sleuth是Spring Cloud中分布式链路追踪解决方案，它大量借鉴了Dapper、Zipkin等项目。它可以在用户无感知的情况下搜集微服务的调用数据，记录微服务调用都经过了哪些组件、每个环节的耗时等信息。方便开发人员进行性能评估，找到系统的瓶颈。链路调用的基本单位是Span，每一次请求或者响应都对应了一个Span，每个Span都由一个64位的字符串标识；而一次微服务的完整调用过程称为Trace，Trace也是由一个64位的字符串标识，且Trace中包含的Span组合呈树状结构。
链路追踪Sleuth就像项目经理的工作进度统计，通过工作进度统计可以清楚地看到哪个模块的开发进度滞后，作为下一步人员调配和工作安排的依据，以确保项目能按计划完工。
微服务架构图：
取自SpringCloud官网的微服务架构图
随时随地看视频
