SpringCloud作为微服务治理的框架，几乎兼顾了微服务治理的方方面面。之前写过一些关于SpringCloud的文章，主要是讲各种组件的使用。本文主要回答这两个问题：SpringCloud在微服务架构中做了什么？SpringCloud提供的这些功能，给微服务架构带来了什么样的便利？简单回顾一下，我们以前用互联网架构开发：传统架构发展史单体架构单体架构在小微企业中比较常见。一个典型的代表就是一个应用程序、一个数据库、一个web容器都可以运行。比如我们开发的开源软件云合集，就是一个标准的单体结构。两种情况下，你可能会选择单体架构：在企业发展初期，为了保证快速上线，采用这种方案比较简单灵活。传统企业中垂直度较高、接入压力较小的业务。这种模式下，技术要求较低，便于各级开发人员接手，也能满足客户需求。下面是单体架构的架构图：在单体架构中，技术选择非常灵活，优先满足快速上线的要求，也方便快速跟进市场。垂直结构在单一结构发展了一段时间后，公司的商业模式得到认可，交易量逐渐增加。这时候，一些公司为了应对更大的流量，就会将原有的业务拆分。例如：后台系统、前端系统、交易系统等。在这个阶段，系统往往分为不同的层次。每个级别都有相应的职责。UI层负责与用户交互，业务逻辑层负责具体的业务功能，数据库层负责与上层的数据交换和存储。下面是垂直架构的架构图：现阶段SSH（struts+spring+hibernate）是项目的关键技术。Struts负责web层的逻辑控制，Spring负责业务层管理Bean，Hibernate负责数据库操作对数据进行封装和持久化。服务架构如果公司进一步发展壮大，垂直的子系统会越来越多，系统之间的调用关系会呈指数增长。在这样的背景下，很多企业都会考虑服务的SOA。SOA全称是面向服务的体系结构，它将应用程序按照不同的职责划分为不同的模块，不同的模块通过特定的协议和接口直接交互。这样整个系统就被分成了很多单独的组件服务来完成请求。当流量过大时，通过水平扩展支持相应的组件。所有组件交互以满足整体业务需求。SOAasaservice的优势在于可以根据需求通过网络对松散耦合的粗粒度应用组件进行分发、组合和使用。服务层是SOA的基础，可以被应用直接调用，有效控制系统中与软件代理交互的人为依赖。面向服务的架构是一种松散耦合的架构。服务拆分的原则是服务内部高内聚，服务之间低耦合。下面是一个面向服务的架构图：现阶段可以使用WebService或者dubbo来进行服务管理。SOA和微服务架构的区别面向服务的架构已经可以解决大部分企业的需求，为什么还要研究微服务呢？先说说它们的区别，如下：微服务架构强调业务系统需要彻底的组件化和服务化。组件是可以独立提供服务的产品。微服务不再强调传统SOA架构中比较重的ESB企业服务总线微服务。强调每个微服务都有自己独立的运行空间，包括数据库资源。微服务架构本身来源于互联网的思想，所以组件发布的服务强调使用HTTPRestAPI，微服务切分的粒度会更小。总结：微服务架构是SOA架构思想的延伸。强调服务个体的独立性，拆分的粒度更小。为什么考虑SpringCloud考虑SpringCloud的原因如下：SpringCloud源于Spring，其质量、稳定性、持续性都可以得到保证。SpirngCloud天然支持SpringBoot，业务实现更方便。SpringCloud发展很快。2016年开始接触的时候相关组件版本是1.x，现在要发布2.x系列。SpringCloud是Java领域最适合做微服务的框架。与其他框架相比，SpringCloud对微服务周边环境的支持最大。对于中小企业来说，使用门槛相对较低。SpringCloud是微服务架构的最佳实现方案。以下是SpringCloud的核心特性：分布式/版本化配置服务注册与发现路由服务与服务间调用负载均衡断路器分布式消息这些特性由不同的组件完成，在架构的演进中发挥着重要作用。接下来我们一起来看看吧。微服务架构SpringCloud解决的第一个问题是：服务之间的解耦。很多公司在快速发展的时候，其服务成分也会相应增加。服务之间存在复杂的相互调用关系。服务A经常调用服务B，服务B调用服务C、服务D……随着服务组件的不断增多，服务之间的调用关系呈指数级增长，极端情况下增长如下图：最可能的情况是它会影响整个身体。经常会发生某个服务更新导致其他服务没有得到通知，导致上线后悲剧频发。这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。SpringCloud的核心组件Eureka解决了这类问题。EurekaEureka是一个开源的Netflix产品，提供服务注册和发现。它提供了完整的服务注册和服务发现实现。也是SpringCloud体系中最重要、最核心的组件之一。用大白话来说，Eureka就是一个服务中心，注册所有可以提供给它的服务进行管理。其他调用者需要的时候去注册中心获取，然后调用，避免了服务之间的直接通信。调用，方便后续的横向扩展，故障转移等。如下图所示：当然，服务中心这么重要的组件一旦出现故障，所有的服务都会受到影响。因此需要搭建一个Eureka集群来保持高可用。建议在生产中至少有两个。随着系统流量的不断增加，需要根据情况扩展某项服务。Eureka内部已经提供了负载均衡功能，只需要增加相应的服务器实例即可。那么在系统运行过程中实例挂掉了怎么办？Eureka有心跳检测机制。如果某个实例在指定时间内没有通信，则会自动移除，避免实例挂掉带来的影响。服务。因此，使用Eureka自动具有注册中心、负载均衡、故障转移等功能。Hystrix在微服务架构中通常会有多个服务层调用。基础服务的故障可能会引发级联故障，进而导致整个系统不可用。这种现象称为服务雪崩效应。服务雪崩效应是“服务提供者”不可用导致“服务消费者”不可用，并逐渐放大不可用的过程。如下图所示：A是服务提供者，B是A的服务消费者，C和D是B的服务消费者。A的不可用导致B的不可用，当不可用放大到C时而D就像滚雪球一样，形成雪崩效应。在这种情况下，整个服务组织就需要具备故障隔离的功能，防止某个服务的故障影响全局。Hystrix组件在SpringCloud中扮演了这个角色。当一个服务连续调用N次没有响应时，Hystrix会立即通知调用者调用失败，避免调用者继续等待，影响整体服务。Hystrix会每隔一段时间再次检查这个服务，如果服务恢复了会继续提供服务。HystrixDashboard和Turbine在发生熔断时需要快速响应解决问题，避免故障进一步扩散，因此对熔断的监控就变得非常重要。Fuse监控现在有两个工具：Hystrix-dashboard和TurbineHystrix-dashboard是一个实时监控Hystrix的工具。通过HystrixDashboard，我们可以直观的看到每条HystrixCommand的请求响应时间、请求成功率等数据。但是如果只使用HystrixDashboard的话，只能看到单个应用中的服务信息，显然是不够的。我们需要一个工具，让我们能够聚合系统中多个服务的数据，并显示在HystrixDashboard上。这个工具是涡轮。监控效果图如下：想了解监控哪些指标，如何监控，可以参考这篇文章：熔断监控HystrixDashboard和Turbine配置中心随着微服务的不断增加，每个微服务都有自己的对应的配置文件。在研发过程中，有测试环境、UAT环境、生产环境，所以每个微服务至少对应三个不同环境的配置文件。这么多的配置文件，如果需要修改一个公共服务的配置信息，比如：缓存、数据库等，难免会造成混乱。这时候就需要引入SpringCloud的另一个组件：SpringCloudConfig。SpringCloudConfigSpringCloudConfig是分布式系统的配置管理解决方案。它包括客户端和服务器两部分。服务器提供配置文件的存储，并以接口的形式提供配置文件的内容。Client通过接口获取数据，并根据这些数据初始化自己的应用。实际上，服务器端服务于所有的配置文件，配置文件的服务实例需要去ConfigServer获取相应的数据。统一组织所有配置文件，避免配置文件碎片化。如果在服务运行过程中修改了配置文件，服务将无法获取到最新的配置信息。要解决这个问题，就需要引入Refresh。它可以在服务运行期间重新加载配置文件。当所有的配置文件都存放在配置中心时，配置中心就成为一个非常重要的组件。如果配置中心出现问题，将导致灾难性的后果。因此，建议在生产中对配置中心进行集群，以支持配置中心的高可用。SpringCloudBus上的Refresh方案虽然可以解决单个微服务运行过程中配置信息过载的问题，但是在实际实践生产中，可能会有N个以上的服务需要更新配置。如果每次都依赖手动Refresh会是一个巨大的工作量，此时SpringCloud提出了另一种解决方案：SpringCloudBus。SpringCloudBus通过轻量级消息代理连接每个分布式节点。这用于广播状态更改（例如配置更改）或其他消息命令。SpringCloudBus的核心思想之一是通过分布式启动器扩展SpringBoot应用，也可以用来建立一个或多个应用之间的通信通道。目前唯一的方法是使用AMQP消息代理作为通道。SpringCloudBus是一个轻量级的通信组件，也可以用于其他类似的场景。使用SpringCloudBus，当我们更改配置文件提交到版本库时，会自动触发对应实例的Refresh。具体工作流程如下：服务网关为微服务架构模式，后端服务的实例数一般是动态的，客户端很难找到动态变化的服务的访问地址信息实例。因此，在基于微服务的项目中，为了简化前端调用逻辑，通常会引入APIGateway作为轻量级网关。同时，APIGateway中也实现了相关的鉴权逻辑，以简化内部服务之间相互调用的复杂度。SpringCloud体系中支持APIGateway的技术是Zuul。SpringCloudZuul路由是微服务架构中不可或缺的一部分，提供动态路由、监控、弹性、安全等边缘服务。Zuul是Netflix出品的JVM路由和服务器端负载均衡器。它的具体功能是服务转发，接收和转发所有内部和外部客户端的调用。使用Zuul可以作为资源的统一访问入口，同时可以在网关上进行一些权限验证等功能。链路跟踪随着服务越来越多，调用链的分析也会越来越复杂，比如服务之间的调用关系，一个请求对应的调用链，调用之间的耗时等等，监控就成了一个问题。在实际使用中，我们需要监控服务与服务之间通信的各种指标。这些数据将是我们改进系统架构的主要依据。因此，分布式链路跟踪变得非常重要，SpringCloud也提供了具体的解决方案：SpringCloudSleuth和Zipkin。SpringCloudSleuth为服务之间的调用提供链接跟踪。通过Sleuth，你可以清楚地了解一个服务请求经过了哪些服务，以及每个服务需要多长时间来处理。这样我们就可以很容易的梳理出微服务之间的调用关系。Zipkin是Twitter的一个开源项目，允许开发者收集各种Twitter服务的监控数据，并提供查询接口。综上所述，我们来看看SpringCloud的各个组件是如何搭配使用的：从上图可以看出，SpringCloud的各个组件相互配合，共同支撑着一套完整的微服务架构。其中Eureka负责服务的注册和发现，很好的连接各种服务。Hystrix负责监听服务间的调用，对连续多次失败进行熔断保护。Hystrixdashboard，Turbine负责监控Hystrix的熔断器，并进行图形化展示。SpringCloudConfig提供统一的配置中心服务。当配置文件发生变化时，SpringCloudBus负责通知各个服务获取最新的配置信息。所有对外的请求和服务我们都通过Zuul转发，Zuul充当API网关。最后我们使用Sleuth+Zipkin记录所有的请求数据，方便我们进行后续的分析。SpringCloud从设计之初就考虑了其中的大部分。互联网公司架构演进所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，这些功能以插件的形式提供，以便在进行过程中在我们的系统架构演进过程中，我们可以合理的选择需要的组件进行集成，这样架构演进的过程就会越来越顺畅。微服务架构是一种趋势。SpringCloud提供了一个标准化的、一站式的技术解决方案，可以媲美现在Servlet规范的诞生，有效提升了服务端软件系统的技术水平。张强先后在互联网金融、第三方支付公司担任Java高级工程师、架构师、技术经理、技术总监。在互联网金融工作期间，他从无到有参与了公司技术平台的建设，并组织平台进行了四次重大架构升级。目前在一家第三方支付公司担任架构师，负责支付公司大数据平台建设。
