漫谈微服务架构：什么是Spring Cloud，为何要选择Spring Cloud

 

 

 

spring cloud是基于spring boot的，因此还在使用springmvc的同学要先了解spring boot。先上一段官话，spring cloud是一个基于spring boot实现的云应用开发工具，它为基于jvm的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发框架。

spring cloud并没有重复制造*，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过spring boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

 

spring cloud全家桶

上面的图是spring cloud的全家桶，包罗万象，犹如水电，涉及到开发的方方页面。

spring cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。

首先是核心服务治理的组件（服务注册与发现）spring cloud eureka

eureka是netflix开源的一款提供服务注册和发现的产品，eureka就是一个服务中心，将所有的可以提供的服务都注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。如下图：

 

 

当然服务中心这么重要的组件一但挂掉将会影响全部服务，因此需要搭建eureka集群来保持高可用性，生产中建议最少两台。随着系统的流量不断增加，需要根据情况来扩展某个服务，eureka内部已经提供均衡负载的功能，只需要增加相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办？eureka内容有一个心跳检测机制，如果某个实例在规定的时间内没有进行通讯则会自动被剔除掉，避免了某个实例挂掉而影响服务。

因此使用了eureka就自动具有了注册中心、负载均衡、故障转移的功能。

当然还有另外一个实现组件spring cloud consul，这里不做多介绍。

随着微服务不断的增多，每个微服务都有自己对应的配置文件。在研发过程中有测试环境、uat环境、生产环境，因此每个微服务又对应至少三个不同环境的配置文件。这么多的配置文件，如果需要修改某个公共服务的配置信息，如：缓存、数据库等，难免会产生混乱，这个时候就需要引入spring cloud另外一个组件：spring cloud config。

spring cloud config

spring cloud config是一个解决分布式系统的配置管理方案。它包含了client和server两个部分，其实就是server端将所有的配置文件服务化，需要配置文件的服务实例去config server获取对应的数据。将所有的配置文件统一整理，避免了配置文件碎片化。

如果服务运行期间改变配置文件，服务是不会得到最新的配置信息，需要解决这个问题就需要引入refresh。可以在服务的运行期间重新加载配置文件，当所有的配置文件都存储在配置中心的时候，配置中心就成为了一个非常重要的组件。如果配置中心出现问题将会导致灾难性的后果，因此在生产中建议对配置中心做集群，来支持配置中心高可用性。

hystrix

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。

如下图所示：a作为服务提供者，b为a的服务消费者，c和d是b的服务消费者。a不可用引起了b的不可用，并将不可用像滚雪球一样放大到c和d时，雪崩效应就形成了。

 

 

在这种情况下就需要整个服务机构具有故障隔离的功能，避免某一个服务挂掉影响全局。在spring cloud 中hystrix组件就扮演这个角色。

hystrix会在某个服务连续调用n次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。

hystrix dashboard和turbine

当熔断发生的时候需要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得非常重要。熔断的监控现在有两款工具：hystrix-dashboard和turbine。

hystrix-dashboard是一款针对hystrix进行实时监控的工具，通过hystrix dashboard我们可以直观地看到各hystrix command的请求响应时间, 请求成功率等数据。但是只使用hystrix dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到hystrix dashboard上, 这个工具就是turbine. 监控的效果图如下：

 

 

spring cloud bus消息总线

refresh方案虽然可以解决单个微服务运行期间重载配置信息的问题，但是在真正的实践生产中，可能会有n多的服务需要更新配置，如果每次依靠手动refresh将是一个巨大的工作量，这时候spring cloud提出了另外一个解决方案：spring cloud bus

spring cloud bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。spring cloud bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展，也可以用来建立一个或多个应用之间的通信频道。目前唯一实现的方式是用amqp消息代理作为通道。

spring cloud bus是轻量级的通讯组件，也可以用在其它类似的场景中。有了spring cloud bus之后，当我们改变配置文件提交到版本库中时，会自动的触发对应实例的refresh，具体的工作流程如下：

 

 

服务网关

在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入api gateway作为轻量级网关，同时api gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。 

 

 

spring cloud体系中支持api gateway落地的技术就是zuul。spring cloud zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。zuul是netflix出品的一个基于jvm路由和服务端的负载均衡器。它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。使用zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。

链路跟踪

随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。因此分布式的链路跟踪就变的非常重要，spring cloud也给出了具体的解决方案：spring cloud sleuth和zipkin

 

 

spring cloud sleuth为服务之间调用提供链路追踪。通过sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。分布式链路跟踪需要sleuth+zipkin结合来实现，当然实现链路追踪的还有三方开源方案，如果zipkin实现的功能非常简单，图形化能力也不强，所以可以试试其它的方案，如pinpoint较成熟的框架等。说到这里顺便给大家推荐一个架构学习交流圈。交流学习企鹅圈号：519752913 里面会分享一些资深架构师录制的视频录像：有spring，mybatis，netty源码分析，高并发、高性能、分布式、微服务架构的原理，jvm性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

feign

声明式远程调度组件。

ribbon

负载均衡组件

spring cloud data flow

大数据操作组件，它是spring xd的替代品，也是一个混合计算模型，可以通过命令行的方式操作数据流

spring cloud task

组件基于spring tsak，提供任务调度和任务管理的功能

以上只介绍经常用到非常重要的内容，一般的技术栈为 springcloud +gitlab+jinkins进行普通服务的开发持续集成部署ci，后面可升级用spingcloud +gitlab+jinkins+docker容器化布署，进一步升级到用 spingcloud +gitlab+jinkins+docker+k8s自动化容器编排内容，这里的难度等级就完全不一样了，而且每一个组件都涉及到很多内容，传统业务如何进行微服务的拆分下次再进行讨论。