SpringCloud从入门到进阶（一）——懂生活就懂微服务

内容

　　本文经过生活中的实际场景解释单体应用和微服务应用的关系，以及SpringCloud中各组件的功能和含义。

适合人群

　　Java开发人员

说明

　　转载请说明出处：SpringCloud从入门到进阶（一）——懂生活就懂微服务

　　GitHub仓库地址：https://github.com/leo-zz/SpringCloudDemo

参考

　　Spring Cloud Netflix官方文档

微服务与单体应用的关系

　　微服务与单体应用的区别相似于我的开发者和开发公司的区别。以一个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官网的微服务架构图

本系列文章导航

SpringCloud从入门到进阶（一）——懂生活就懂微服务

SpringCloud从入门到进阶（二）——注册中心Eureka的伪分布式部署

SpringCloud从入门到进阶（三）——源码探究Eureka集群之replicas的unavailable故障

SpringCloud从入门到进阶（四）——生产环境下Eureka的彻底分布式部署

SpringCloud从入门到进阶（五）——路由接入Zuul

SpringCloud从入门到进阶（六）——使用SpringBoot搭建微服务

SpringCloud从入门到进阶（七）——断路器Hystrix及其监控工具HystrixDashborad与Turbine

SpringCloud从入门到进阶（八）——链路追踪Sleuth

SpringCloud从入门到进阶（九）——踩坑实战之Zuul下实现文件上传

待续...