今天开始介绍了业界比较火的SpringCloud生态

SpringCloud文章系列

背景

我们登录 https://spring.io 可以看到Spring的发展计划了

可以看到现在Spring主推3个东西：SpringBoot（构造一切）、SpringCloud（协调一切）、SpringCloudDataFlow（链接一切SpringXD，类似编排与管道处理）
在整个Java生态中，从开发工具集成—大规模分布式业务处理集成—走向大数据处理，生态在逐步扩大，而且可能是仅次于Java规范标准的开发标准了

Java程序员中应该都知道并且用过Spring框架去开发项目

回顾下整个Spring的发展

Spring创始人：Rod Johnson，Spring本身是免费的，主要靠培训与付费咨询赚钱
Spring公司叫做SpringSource，2009年被VMware收购，Rod用这个钱又收购了一批公司，其中有GemStone，12年12306挂掉的时候进行了17种技术选型PK，最终选择了他们家的Pivotal GemFire 分布式解决方案，去掉小型机用x86机器耗时减少75倍以上
后来VMare与EMC等公司成立Privotal，发展大数据技术，诞生了SpringBoot、SpringCloud等技术，可以看到未来大数据领域逐步会发展起来

Spring

2004年发布了Spring，2006发布2.0，2007年发布2.5，2009年发布3.0，2013年发布4.0，2017年发布了5.0

Spring2个特性：IOC（依赖注入）与AOP（面向切面编程）
遵循Spring设计可以保持良好的设计与扩展能力，Spring里帮你实现了常用的设计模式，按照规范开发可以天然的实现解耦与扩展能力
可以快速标准的接入Java生态中的各种功能组件，因为他们都对Spring进行了支持，需要什么就加对应的依赖+bean配置+参数配置，然后注入使用
Spring的缺点：就是配置很多，接入什么组件都需要去找标准的使用配置方式粘贴过来改改，大项目要拆分出一大堆xml配置，后来虽然推出了JavaConfig方式也依然有较多配置
目前3已经停止维护，4与5在维护，5是目前的重点

SpringMVC

在Spring1.0就有SpringMVC，最初自己的MVC是基于bean配置的，2007年2.5发布时推出了注解式的SpringMVC编写，在2009年Spring推出3.x之后加入Restful支持，SpringMVC逐渐出名，后面逐步干掉了Struts1+Struts2（WebWork）

与Spring框架的浑然一体
基于注解处理请求，大多提高了开发效率，对Restful规范支持的比较好
Struts非常臃肿，SpringMVC简单，开发效率高
相比Struts安全性较高（Struts各种安全漏洞助攻SpringMVC的发展）

SpringBoot

2014年推出了SpringBoot框架，2018年推出了2.0（基于Spring5）

提升了开发效率，遵守约定大于配置的原则，遵循82原则，80%配置一般都是不需要自定义的，同时统一了依赖版本号
解决了配置多的问题，提供AutoConfig的机制自动加载默认配置，可以按照条件自动替换bean实现，自动加载新的bean功能，依赖各种Starter使得扩展功能开箱即用
web项目简化了容器如tomcat的集成，可以直接main启动，这不仅仅是因为方便，还因为一个更大的计划：基于Spring5的SpringBoot2.x版本还想用WebFlux干掉Servlet规范=。=
提供了Actuator工具，标准化监控的指标

SpringCloud

2014年推出了SpringCloud生态工具集，17年E版本与SpringBoot1.4达到最佳，F版本对应SpringBoot2.x（SpringBoot与SpringCloud双子星发展）

跟进业界流程的微服务的设计理念提供了一整套的微服务配套服务的标准抽象，提供中间件、分布式工具、监控3个分布式系统需要的能力，给大部分分布式系统的问题提供了能落地的解决方案
联合Netflix公司与业界开源实现，推出了现成的技术实现，目前的技术选型中立，也可以基于标准适配其他分布式组件
提供了各种云服务平台的集成，AWS，CloudFoundry等平台的集成

SpringCloud包含什么

SpringCloud可以说是基于SpringBoot的一套生态，定义了一些抽象层与标准，具体的实现可以是开源的方案，不单单是Spring自己实现的
所以可以看到SpringCloud每次推出版本号不是基于数字的（”大版本不兼容.新功能版本.bug修复小版本”，如3.4.12.RELEASE），而是基于名字来代表一套组件的

名字是基于伦敦的地铁站名字命名，每个大版本命名就是根据ABCDEF等字母顺序排列，后面的SRx就是第几个功能升级版本，从Finchley开始，基于SpringBoot2.x版本开发了，不过现在业界大多用的都是1.x

SpringCloud基于以下组件

中间件类：

Spring Cloud Netflix Eureka
Spring Cloud Consul
Spring Cloud Zookeeper
Spring Cloud Config
Spring Cloud Bus
Spring Cloud Netflix Zuul
Spring Cloud Gateway
Spring Cloud Task
Spring Cloud Stream
Spring Cloud Dataflow

工具类：

Spring Cloud Netflix Hystrix
Spring Cloud Cluster
Spring Cloud Security
Feigon
Ribbon

监控类：

Spring Cloud Sleuth
Spring Cloud Turbine
Spring Boot Actuator
Spring Boot Admin

云服务类：

Spring Cloud for Cloud Foundry
Spring Cloud for Amazon Web Services（AWS）

这些服务一会都会介绍下作用，在介绍之前我们要先了解下分布式系统中的问题，为什么需要这么多组件？

分布式系统的问题

分布式系统面临着很多问题要解决，那为什么一定是分布式的呢？微服务架构与SOA有啥区别？分布式系统为啥问题这么多，我们怎么解决？这里将会逐步展开说明

服务架构的演化

不同的阶段与公司的发展阶段有关，服务架构都是逐步进化而来
在架构升级的过程中中间的2种架构形态没必要去经历，针对中小型企业建议最初单体应用不能满足时直接升级到微服务架构中来，不过这需要一个拆分迁移的过程

单体应用

单体应用就是所有业务逻辑与实现都在同一个工程中

单体应用适用于企业早期，人少业务少的情况下，为了专注于业务逻辑与分工代价，一个人负责全部或者一大堆业务开发时，这种方式简单高效
但是随着企业发展，业务多样人员增多时，单体的缺点逐步暴露出来

单体应用缺点

复杂性高：难以维护，耦合，依赖多个jar
技术债务：不坏不修，所以遗留问题多，错误的调用也多了
发布频率不一样：提高风险，发布慢
扩展能力不一样：有CPU密集与IO型，耦合一起
稳定性，任何一个bug都会导致整个服务挂
阻止创新：比如Struts的无法升级SpringMVC

垂直应用

垂直应用架构就是不同的业务进行了拆分，比如理财业务、信贷业务、电商业务，但是数据库都还用一套，而且公共的模块比如用户中心、短信发送等功能都用jar来共享的方式减少重复代码

这种服务中过去就都用SSH框架或者SSM框架去开发，然后nginx配置个域名或者挂到同域不同path下就完事了

服务化架构（如SOA）

随着业务进一步发展，发现有很多公共的服务jar也无法满足了，每次升级jar都需要把依赖的服务全部重启升级，而且无法做到松耦合高内聚，jar内功能的使用情况未知
而且不止jar共享，业务线之间也需要相互调用，而且一个业务线服务为了把相对不变的服务层与变化多端的MVC逻辑拆分开希望改为远程调用
这时候引入一种合适的远程调用方式而且又能高效与适配是最好了，所以诞生了很多这种框架，如java体系的dubboRPC，Thift，WebServiceSOAP、SOA的解决方案
SOA这个就非常重了，通信方式比较麻烦，引入了ESB企业服务总线的设计，服务通信都需要走ESB，这一层还有很多业务聚合逻辑，非常复杂
dubbo相对是非常好的框架了，dubbo在2012年开源到SpringCloud火之前，很多企业使用dubbo进行了服务化改造

于是最终像用户中心、通知中心、订单中心、库存中心这类公共的服务不再是jar包，而升级为了独立部署的服务，逐步做大发展为后期的大中台小前台结构

微服务架构

其实服务化架构下已经非常的可靠了，基本满足了企业架构的要求，不过服务之间还会有很多影响，没有做到完全的独立，比如服务实例几个部署在同机器，数据库还是共用一个库
而且因为服务化架构很多服务的调用拆分没有特定的指导原则导致一些链路超级长的拆分模式如：跟进控制器-服务-数据库3层模式拆分为3个服务，一次请求就要经历至少2次RPC调用
在微服务的设计中提倡垂直业务线聚合一个业务逻辑，保持业务的服务层与数据访问层在一起，减少横向拆分，进行竖向的业务拆分，而且保持一个数据库只被一个微服务使用，做到数据库层面的隔离
除此之外部署最好也是完全隔离的，不但是一个tomcat只部署一个web网站，而且一台机器最好只部署一个服务，当然实际可以使用虚拟化技术如VM虚拟机与docker技术去隔离，docker与微服务目前是最佳搭档
在SOA中有很多中心化的设计，如ESB，服务编排各种链路上的调用a依赖b，b依赖c，c依赖d，而在微服务中希望有一个总调度改为a调用b、c、d这种模式，减少链路
同时并不提倡使用分布式事务，而是采用一些最终一致性的解决方案去正面迎击分布式问题
微服务希望调用之间的协议保持轻量，而且具备跨语言通用性，推荐使用RestfulHTTP通信

所以微服务其实更像是基于服务化架构之上教你怎么去设计服务拆分的原则，更像是一个不包含某些功能的SOA架构
所以服务化中的很多问题的解决方案，微服务是直接继承的，本质上都是分布式系统中的一些问题，所以接下来聊一下分布式系统中的问题怎么解决

微服务架构下的分布式系统问题

分布式下的应用失去了很多单体应用的优势，比如在内存中方法直接的调用变为了远程网络的调用，水平扩展后服务实例变多如何做路由如何在服务挂了的时候感知到
微服务分布式下独立多个DB如何保证事务性，外部服务如何调用内部服务呢？接下来进一步讨论

进程间通信

其实在单体普通的方法调用直接就可以区分出几种类型同样适用于网络中的场景
参考单体方法调用，网络通信按照大类分为同步、异步的方式，同时有的请求需要返回值，有的则不需要，而异步请求还存在一对多的情况，所以排列组合就有了几种模式

不同服务主机通过网络进行通信的几种模式

同步需要返回值：请求/响应模式：HTTP请求
同步不需要返回值：通知模式：dubbo oneWay模式
异步单调用需要返回值：请求/异步响应模式：nio与netty（相当于）、aio、CompletableFuture与RxJava类似的网络异步通信模式
异步单调用不需要返回值：异步通知模式
异步多调用需要返回值：发布/异步相应模式
异步多调用不需要返回值：发布/订阅模式：消息队列

基于服务开发的难度与模型的复杂度，一般开发常用到的是同步使用”请求/响应模式”与异步使用”发布/订阅模式”
在微服务中针对同步调用一般使用HTTPRestful请求服务，因为远程调用，所以这里会涉及注册发现的机制
异步一般使用消息中间件来请求服务

最终一致性

由于微服务拆分了，所以事务去掉了，改为了最终一致性，所以一般设计为事件驱动模式，所有的业务事件发生后发布订阅模式通知另一个业务，而另一个业务再通过事件回执调用方结果
如果中间业务不通则调用方要进行处理，所以出现了很多中间态的设计，而且如果是同步模型，则可能会调用失败，则需要状态位维护一致性，则消费方要可支持重试

基于”发布/订阅模式”演化出了基于事件驱动的架构模式，所有的服务间通信都使用异步消息的模式请求与响应，同时业务场景中要多出各种中间态展示给用户
比如下单服务：因为订单能不能下成功取决于最终一致性请求所有依赖服务（用户额度、库存、物流）都回执ok后才能算作成功，否则只能取消该订单，当然在下单之前会进行各种同步查询检查，只是在检查通过最终执行时需要等待所有状态位都变为有效才能算作成功
这里还会引发另一个问题：如何保证我做完业务操作后发送消息队列一定是成功的，假设中间中断了呢？一旦中断则会造成最终的数据不一致
所以一种是通过本地事务队列，还有通过事务日志与db更新日志去扫描请求队列，当然还有一种就是常用的通过db中保存状态位+补偿定时任务去做这种错误情况的处理了

注册与发现

在微服务中客户端调用服务端，最简单的模式我是可以直接写死对方的地址去调用的

但是如果服务端水平扩展了多条机器，我就要在调用端写多台了，如果调用端也有多台，而运行时服务端加减任何机器都要修改所有的请求地址就很难处理了

所以这时候需要采用一种方式避免这个问题，最终目的是客户端只要写死一个固定的地址or名字，每次请求的时候就能请求到真实的地址了
我可以在请求之前查找地址然后请求或者我请求一个代理的地址，所以服务发现有2种模式

客户端发现：就是客户端主动查询注册表然后负载均衡请求一个端，缺点是不同的端都有这个逻辑，需要依赖一个client端，如Eureka、zk
服务端发现：类似nginx，nginx来做注册表与负载请求，缺点是需要保证nginx的高可用，类似的还有consul

哪些服务可以用需要使用服务发现的技术
服务注册有2种模式

自注册，自注册就是自己启动就自己去注册注册表，缺点是这个逻辑每个端都要写，同样需要依赖一个client端，如Eureka、zk
第三方注册，类似consul，consul主动与应用心跳，然后传播给consul的注册表，缺点是需要保证consul高可用

综合2种主要看你运行的环境是否具备发现与负载能力，有的云平台本身提供了这种能力如：kubernetes，可以自注册与路由服务，则可以用第二种模式
否则发现机制与注册机制都耦合一个统一的客户端也可以接受，这个客户端可以同时做这2个事情
目前dubbo也是基于客户端发现与自注册的模式去设计的
同时客户端发现与自注册还可以结合软负载做注册表没有及时更新的重路由请求，建议在没有强大的运维能力与云平台的支持下都采用这种设计，可以减少对环境的依赖，更具通用性，同时减少了链路的长度

服务的适配与屏蔽—API网关

API网关的作用一般用于做外部系统到内部系统转换的中间层，可以提供统一的服务端的公共功能，那这个东西为什么一定要统一到一个中间层呢？

假设一个客户端要展示一个产品页面，上面有商品、用户、订单、评价、推荐等等需要集成8个微服务的接口调用
如果客户端直接调用8个服务端的微服务也可以实现，比如在nginx配置暴露同一个api.company.com/xxx/客户端发Rest调用到后端，请求8个微服务接口，但是会有几个缺点

网络请求太多，客户端需求与服务暴露粒度不匹配
技术实现不一样，有些面向二进制RPC对浏览器与防火墙不友好
关注细节，难以重构，后续合并拆分客户端无法改动

API网关：设计模式中的门面模式：网关封装内部系统的架构，并且提供 API 给各个客户端。它还可能还具备授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等功能

优点：使用 API 网关的最大优点是，它封装了应用程序的内部结构
缺点；API 网关也有一些不足。它增加了一个我们必须开发、部署和维护的高可用组件。还有一个风险是，API 网关变成了开发瓶颈，所以必须足够简单！

一般针对大型互联网公司会有多套API网关，比如针对web端、APP端，还有开放平台端，APP端可能会有额外加密通信的逻辑，开放平台端会限制外部第三方的接口调用与计费
有的API网关直接使用nginx与插件去实现，不过nginx不太适合加太多扩展功能，更适合做静态分离，而在nginx后端的API网关可以负责更多职责
所以推荐是如下的架构模式

监控

因为微服务众多，过去一次请求响应的过程会经过很多服务处理，如果一次请求失败了，如何才能知道是哪个环节出了问题呢，微服务中的监控非常重要，没有足够的监控手段执行微服务改造后问题将会难以排查

监控一般分为几种

机器状态的监控
服务状态的监控：自身依赖的状态，降级的触发
业务监控
链路追踪

分布式中主要解决链路追踪的问题
现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最为广泛的开源实现是 Twitter 的 Zipkin，为了实现平台无关、厂商无关的分布式服务跟踪，CNCF 发布了布式服务跟踪标准 Open Tracing。
国内，淘宝的“鹰眼”、京东的“Hydra”、大众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”都是这样的系统。

服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程，称为一个“trace”。每个 trace 中会调用若干个服务，为了记录调用了哪些服务，以及每次调用的消耗时间等信息，在每次调用服务时，埋入一个调用记录，称为一个“span”。这样，若干个有序的 span 就组成了一个 trace。在系统向外界提供服务的过程中，会不断地有请求和响应发生，也就会不断生成 trace，把这些带有span 的 trace 记录下来，就可以描绘出一幅系统的服务拓扑图。附带上 span 中的响应时间，以及请求成功与否等信息，就可以在发生问题的时候，找到异常的服务；根据历史数据，还可以从系统整体层面分析出哪里性能差，定位性能优化的目标。

SpringCloud组件介绍

SpringCloud里有很多组件，我简单的将其分成4类，相对独立部署的组件叫做”中间件”，嵌入到服务中的组件叫做”工具类”，与监控有关的属于”监控类”，剩余组件属于”其他”

Spring项目可以使用http://start.spring.io脚手架生成项目，非常方便

中间件

中间件基本可以概括为3类：服务注册配置管理、API网关、异步处理

服务注册配置管理：解决分布式系统中的”注册与发现”问题，同时”配置中心”作为分布式系统的一种标配与注册中心形成一对搭档
API网关：解决分布式系统中的”服务的适配与屏蔽”问题
异步处理：在前面章节中我们介绍过”进程间通信”，微服务领域之间是松耦合的，所以分布式中很多逻辑都是异步在处理，比如异步通知，定时任务与聚合计算处理

服务注册配置管理

SpringCloud组件

Spring Cloud Netflix Eureka
Spring Cloud Consul
Spring Cloud Zookeeper
Spring Cloud Config
Spring Cloud Bus

注册中心

Eureka、Consul、Zookeeper都是注册中心的解决方案

SpringCloud层提供了一个注册中心的抽象层，具体的第三方组件可以作为这层抽象层的一种具体的实现，提供了一套基于注解的注册发现功能
Eureka是SpringCloud首推的注册中心，基于客户端发现与自注册模型，对SC体系支持性最好，属于Netflix公司的开源实现，其没有实现配置中心的功能，需要额外的配置中心组建配合，可以使用SpringCloudConfig组合
1. Eureka在CAP中属于AP，牺牲了一致性，保证了可用性，所以其注册过程中只要1台注册成功就可以发现到，注册过程比较快，但是多台Eureka可能数据不一致
2. 本质上A其实也不是完全保证的，Eureka的数据是存储在内存中，重启会丢失，相对没有zk可靠
3. 目前大多用的1.x，而2.x近期Netflix公司选择了闭源，所以目前不推荐使用
Consul基于Go语言编写，基于服务端发现与第三方注册模型，基于CP，使用raft算法，比zk的paiox算法要快，在SC体系中也有不错的支持，有支持配置中心的功能
1. 不过目前跟进大厂经验，consul的节点线上部署最好不要超过3000个，所以大规模使用需要谨慎
Zookeeper是基于CP的，采用paixos算法，至少部署3台，只有超过半数机器同步成功后才认为注册成功，所以注册时间会长一些。zk支持配置存储，所以也支持配置中心功能
1. 老牌的注册中心了，起初在大数据领域诞生使用，后面dubbo的注册中心一般也使用zk
  注册中心这3种其实都是不错的选择，具体的选择一般看社区的活跃支持程度与公司运维的熟悉程度，目前比较推荐的还是使用Zookeeper作为配置中心

注册中心-使用

点我阅读

配置中心

Config是配置中心的解决方案

目前在3套注册中心中只有Eureka不具备配置中心的功能，所以可以使用SpringCloud提供的配置中心
Config与Spring中的Environment与PropertySource抽象相同，配置存储在git中
配置中心不但在服务启动时去提供配置，配置是可以进行更改的，而更改之后需要通知到所有依赖此配置的服务实例，这时候就需要SpringCloudBus来支持了
1. Bus：消息总线，通知一般要通知多台主机，所以一般是异步的，如果想通知所有的服务从哪里得知呢？当然在注册中心中可以获得，所以Bus是通过注册中心get到需要通知服务的所有实例，然后异步调用所有实例的接口
2. Bus一般目前支持RabbitMQ来实现

配置中心-使用

点我阅读

API网关

SpringCloud组件

Spring Cloud Netflix Zuul
Spring Cloud Gateway

API网关

Zuul是集成了Netflix公司的开源组件
Gateway可以说是SC的亲儿子，比起Zuul干儿子肯定会是未来的一个趋势，虽然SC技术选型中立，不过自身的实现的支持性是最好的

API网关-使用

点我阅读

异步处理

SpringCloud组件

Spring Cloud Task
Spring Cloud Stream
Spring Cloud Dataflow

定时调度

一般一个服务实例都有多个，如果要写个定时任务可以有3种方式

每个实例对等都启动，同时加一把锁保证实际只有1个在执行
只有一个实例启动时配置开启定时任务，其他实例不开启
独立调度的触发逻辑，需要调度时使用负载均衡算法去请求一个服务实例
在分布式系统中第三种才是通用做法，Task就是做定时任务（又叫短命任务）的触发逻辑的

使用点我阅读

消息中间件

使用点我阅读

大数据聚类处理

SpringCloudDataflow

工具类

SpringCloud组件：

Spring Cloud Netflix Hystrix：降级限流点我阅读
Spring Cloud Cluster：选举，锁
Spring Cloud Security：安全

监控类

SpringCloud组件：

Spring Cloud Sleuth
Spring Cloud Turbine
Spring Boot Actuator
Spring Boot Admin

监控

Sleuth是链路追踪平台点我阅读
Turbine是属于Hystrix的监控聚合平台，可以聚合在一起看所以服务的断路器状态
Actuator是SpringBoot中提供的监控Endpoint，通过访问/xxx的urlpath可以看到服务的机器、服务、依赖、日志等数据，而admin则是针对这些数据接口做一个友好的展示平台

其他

微服务的配套还是比较齐全的，包括了如何测试、如何继承各种云平台、如何连接各种第三方组件都有考虑

云服务类：

SpringCloud组件：

Spring Cloud for Cloud Foundry
Spring Cloud for Amazon Web Services（AWS）

辅助类

连接器
测试平台

除了SpringCloud其他微服务解决方案

目前国内除了SC的解决方案，国内也有基于dubbo的方案

基于Dubbo体系的微服务解决方案

17年底阿里复活了dubbo的开源维护，并且接入了apache项目中，后续还会更好的支持http协议
18年又开源了Alibaba Nacos注册发现与配置中心
不过总体上如果要搭建一套完整的微服务组件，光有dubbo的这2个组件还不够，还需要其他开源组件or自研组件配合，如果有自己的平台技术团队可以选择支持

一般开源的平台技术实现

远程调用：apache dubbo
注册中心+配置中心：alibaba nacos、zookeeper、阿波罗、自研
API网关：nginx+lua、自研
异步任务-调度中心：xxxjob、自研
异步任务-消息组件可以直接使用kafka、rabbitMQ、activeMQ的实现
异步任务-聚合处理：spark、storm、akka
工具-熔断器：alibaba Sentinel
工具-分布式锁：zookeeper、redis
工具-认证：shiro、自研
监控-机器监控：zabbix
监控-日志监控收集：ELK
监控-链路跟踪：zipkin

总结

SpringCloud是Spring目前主推的一套微服务生态的治理组件，提供了较全的解决方案，非常适合中小型企业在进行微服务改造时使用
分布式系统带来的问题有多方面，我们重点讲了进程调用、服务发现、API网关与监控主题，针对这些问题有多种解决方案，而这些解决方案在SpringCloud的组件中都有选择
SpringCloud的组件大致分为中间件、工具与监控3大类，中间件中的服务注册配置管理组件应该说是必备组件，而其他组件属于可选组件，按需引入
最后除了SC还有其他的选择，比如DUBBO，提供了微服务必须的服务注册配置管理组件，而其他可选组件则需要采用开源or自研方案，需要一定的整合能力的团队