Spring Cloud 微服务的那点事

在详细的了解SpringCloud中所使用的各个组件以前，咱们先了解下微服务框架的前世此生。

单体架构

在网站开发的前期，项目面临的流量相对较少，单一应用能够实现咱们所须要的功能，从而减小开发、部署和维护的难度。这种用于简单的增删改查的数据访问框架（ORM）十分的重要。

垂直应用架构

当用户访问量不断的提高，单一应用须要不断的增长服务器来应对，同时将单一的应用拆分红多个应用用来处理提高效率。这种用于加速Web前端加载的Web框架（MVC）起到了关键性的做用。

在这一阶段每每会将系统分为不一样的层级，每一个层级有对应的职责，UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。

在这一阶段咱们最常使用到的开发框架就是Spring（业务逻辑层管理POJO）+Struts（web层前置服务控制）+Hibernate（数据库层持久化）。

服务化架构

伴随着企业服务量的不断提高，MVC框架的部署致使系统的负重愈来愈多，没法知足并发的要求，系统间数据、报文的传输会出现频繁的丢失。这时候咱们须要考虑服务化的架构（SOA）。SOA表示面向服务的架构。将应用根据不一样的职责划分红不一样的模块（相似于企业划分不一样的事业部），不一样的模块使用特定的调用协议（RPC）和接口进行交互。

这样使整个系统切分红不少单个组件服务来完成请求，当流量过大时经过水平扩展相应的组件来支撑，全部的组件经过交互来知足总体的业务需求。

SOA服务化的优势是，它能够根据需求经过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。

服务层是SOA的基础，能够直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。

在这个阶段可使用WebService或者dubbo来服务治理。

微服务架构

微服务架构算是SOA架构的一种拓展，主要关注的是服务个体的独立性、拆分粒度更小。相对于SOA架构来讲，微服务拥有如下优点：

微服务强调更深层次的组件化和服务化，每一个微服务均可以拥有独立的运行空间，确保每个服务组件能够做为单独的产品进行发布。

微服务抛弃了传统SOA笨重的企业服务总线，对外发布强调使用HTTP REST API的接口发布形式。

微服务的切分粒度大。

了解了架构的发展过程，咱们来认识一下Spring Cloud。

Spring Cloud来源于Spring，利用Spring Boot进行快捷开发。因为目前Spring Cloud社区的维护和支持的人员数量众多，相信Spring Cloud会有很好的发展。并且Spring Cloud基本上都是使用了现有的开源框架进行的集成，学习的难度和部署的门槛就比较低，对于中小型企业来讲，更易于使用和落地。

Spring Cloud主要解决了什么问题？

一、对于企业级的SOA框架来讲，服务与服务间的解耦是一项巨大的难题，随着功能服务的不断增长，多服务间的相互调用频繁，调用过程就像一个杂乱无章的毛线球，很容易致使牵一发而动全身的状况，常常会因为在服务更新的过程当中，没有合理通讯，致使数据的丢失。

这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka就是解决这类问题。

Eureka

Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。

用大白话讲，Eureka就是一个服务中心，将全部的能够提供的服务都注册到它这里来管理，其它各调用者须要的时候去注册中心获取，而后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。以下图：

固然服务中心这么重要的组件一但挂掉将会影响所有服务，所以须要搭建Eureka集群来保持高可用性，生产中建议最少两台。

随着系统的流量不断增长，须要根据状况来扩展某个服务，Eureka内部已经提供均衡负载的功能，只须要增长相应的服务端实例既可。

那么在系统的运行期间某个实例挂了怎么办?Eureka内容有一个心跳检测机制，若是某个实例在规定的时间内没有进行通信则会自动被剔除掉，避免了某个实例挂掉而影响服务。

所以使用了Eureka就自动具备了注册中心、负载均衡、故障转移的功能。

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。

监控的效果图以下：

想了解具体都监控了哪些指标，以及如何监控能够参考这篇文章：熔断监控Hystrix Dashboard和Turbine

配置中心

随着微服务不断的增多，每一个微服务都有本身对应的配置文件。在研发过程当中有测试环境、UAT环境、生产环境，所以每一个微服务又对应至少三个不一样环境的配置文件。

这么多的配置文件，若是须要修改某个公共服务的配置信息，如：缓存、数据库等，不免会产生混乱，这个时候就须要引入Spring Cloud另一个组件：Spring Cloud Config。

Spring Cloud Config

Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client经过接口获取数据、并依据此数据初始化本身的应用。

其实就是Server端将全部的配置文件服务化，须要配置文件的服务实例去Config Server获取对应的数据。将全部的配置文件统一整理，避免了配置文件碎片化。

若是服务运行期间改变配置文件，服务是不会获得最新的配置信息，须要解决这个问题就须要引入Refresh。它能够在服务的运行期间从新加载配置文件。

当全部的配置文件都存储在配置中心的时候，配置中心就成为了一个很是重要的组件。

若是配置中心出现问题将会致使灾难性的后果，所以在生产中建议对配置中心作集群，来支持配置中心高可用性。

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能够很清楚的了解到一个服务请求通过了哪些服务，每一个服务处理花费了多长时间。从而让咱们能够很方便的理清各微服务间的调用关系。

Zipkin是Twitter的一个开源项目，容许开发者收集Twitter 各个服务上的监控数据，并提供查询接口。

总结

咱们从总体上来看一下Spring Cloud各个组件如何来配套使用：

从上图能够看出Spring Cloud各个组件相互配合，合做支持了一套完整的微服务架构。

其中Eureka负责服务的注册与发现，很好将各服务链接起来

Hystrix 负责监控服务之间的调用状况，连续屡次失败进行熔断保护。

Hystrix dashboard,Turbine 负责监控 Hystrix的熔断状况，并给予图形化的展现

Spring Cloud Config 提供了统一的配置中心服务

当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息

全部对外的请求和服务，咱们都经过Zuul来进行转发，起到API网关的做用

最后咱们使用Sleuth+Zipkin将全部的请求数据记录下来，方便咱们进行后续分析

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

这些功能都是以插拔的形式提供出来，方便咱们系统架构演进的过程当中，能够合理的选择须要的组件进行集成，从而在架构演进的过程当中会更加平滑、顺利。

微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推动服务端软件系统技术水平的进步。

欢迎工做一到五年的Java工程师朋友们加入Java架构开发：697579751

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！