初步理解Spring Cloud微服务架构

本文参考：

https://www.cnblogs.com/liuning8023/p/4493156.html

https://www.infoq.cn/article/china-microservice-technique/?utm_source=tuicool&utm_medium=referral

https://www.cnblogs.com/edisonchou/p/java_spring_cloud_foundation_sample_list.html

https://www.infoq.cn/article/china-microservice-technique/?utm_source=tuicool&utm_medium=referral

https://baijiahao.baidu.com/s?id=1621651597363566701&wfr=spider&for=pc

《SpringCloud与Docker微服务架构实战》周立

微服务

“微服务架构（Microservice Architecture）”它用于描述一种设计应用程序的特别方式，作为一套独立可部署的服务。微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。

在开始介绍微服务风格（microservice style）前，比较一下整体风格（monolithic style）是很有帮助的：一个完整应用程序（monolithic application）构建成一个单独的单元。企业级应用通常被构建成三个主要部分：客户端用户界面（由运行在客户机器上的浏览器的 HTML 页面、Javascript 组成）、数据库（由许多的表构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理 HTTP 请求，执行领域逻辑（domain logic），检索并更新数据库中的数据，使用适当的 HTML 视图发送给浏览器。服务端应用是完整的 ，是一个单独的的逻辑执行。任何对系统的改变都涉及到重新构建和部署一个新版本的服务端应用程序。

这样的整体服务（monolithic server）是一种构建系统很自然的方式。虽然你可以利用开发语基础特性把应用程序划分成类、函数、命名空间，但所有你处理请求的逻辑都运行在一个单独的进程中。在某些场景中，开发者可以在的笔计本上开发、测试应用，然后利用部署通道来保证经过正常测试的变更，发布到产品中。你也可以使用横向扩展，通过负载均衡将多个应用部署到多台服务器上。

整体应用程序（Monolithic applications）相当成功，但是越来越多的人感觉到有点不妥，特别是在云中部署时。变更发布周期被绑定了——只是变更应用程序的一小部分，却要求整个重新构建和部署。随着时间的推移，很难再保持一个好的模块化结构，使得一个模块的变更很难不影响到其它模块。扩展就需要整个应用程序的扩展，而不能进行部分扩展。

这导致了微服务架构风格（microservice architectural style）的出现：把应用程序构建为一套服务。事实是，服务可以独立部署和扩展，每个服务提供了一个坚实的模块边界，甚至不同的服务可以用不同的编程语言编写。它们可以被不同的团队管理。

图1 整理架构与微服务架构

Spring Cloud

Spring Cloud是一个基于Spring Boot实现的云原生应用开发工具，它为基于JVM的云原生应用开发中涉及的配置管理、服务发现、熔断器、智能路由、微代理、控制总线、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud具有如下特点：

• 约定大于配置
• 适用于各种环境
• 隐藏了组件的复杂性，并提供声明式、无XML式的配置方式
• 开箱即用，快速启动
• 组件丰富，功能齐全
• ......

Spring Cloud核心子项目

• Spring Cloud Netflix：核心组件，可以对多个Netflix OSS开源套件进行整合，包括以下几个组件：
  • Eureka：服务治理组件，包含服务注册与发现
  • Hystrix：容错管理组件，实现了熔断器
  • Ribbon：客户端负载均衡的服务调用组件
  • Feign：基于Ribbon和Hystrix的声明式服务调用组件
  • Zuul：网关组件，提供智能路由、访问过滤等功能
  • Archaius：外部化配置组件
• Spring Cloud Config：配置管理工具，实现应用配置的外部化存储，支持客户端配置信息刷新、加密/解密配置内容等。
• Spring Cloud Bus：事件、消息总线，用于传播集群中的状态变化或事件，以及触发后续的处理
• Spring Cloud Security：基于spring security的安全工具包，为我们的应用程序添加安全控制
• Spring Cloud Consul : 封装了Consul操作，Consul是一个服务发现与配置工具（与Eureka作用类似），与Docker容器可以无缝集成
• ......

下面只简单介绍下经常用的5个

1. 服务发现——Netflix Eureka
2. 客服端负载均衡——Netflix Ribbon
3. 断路器——Netflix Hystrix
4. 服务网关——Netflix Zuul
5. 分布式配置——Spring Cloud Config

Eureka

作用：实现服务治理（服务注册与发现）

简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。

组件组成：

1. Eureka服务端 : Eureka服务端用作服务注册中心。支持集群部署。

2. Eureka客户端 : Eureka客户端是一个java客户端，用来处理服务注册与发现。

服务发现组件具备三个功能：

1. 服务注册表：用来记录各个微服务的信息
2. 服务注册与服务发现
3. 服务检查：例如心跳

在4-1图中：

• 各个微服务（服务消费者和服务提供者）在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件将这些信息缓存到本地。
• 服务消费者可以从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的借口。
• 各个微服务与服务发现组件使用一定机制（例如心跳）通信。服务发现组件如长时间无法与某微服务实例通信，就会注销该实例。
• 微服务网络地址发生变更（例如实例增减或者IP端口发生变化等）时，会重新注册到服务发现组件。使用这种方式，服务消费者就无需人工修改提供者的网络地址了。

在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

4-3图是Eureka官方的架构图，描述了一个Eureka集群的工作原理。

• Application Service相当于服务提供者。
• Application Client相当于服务消费者。
• Make Remote Call理解成调用RESTful API的行为。
• us-east-1c、us-east-1d都是zone，它们都属于us-east-1这个region。

（1）region：可以简单理解为地理上的分区，比如亚洲地区，或者华北地区，再或者北京等等，没有具体大小的限制。根据项目具体的情况，可以自行合理划分region。

（2）zone：可以简单理解为region内的具体机房，比如说region划分为北京，然后北京有两个机房，就可以在此region之下划分出zone1,zone2两个zone。

部署一个高可用的Eureka Server集群的意义：

Eureka Client会定时连接Eureka Server，获取服务注册表中的信息并缓存到本地。微服务在消费远程API时总是使用本地缓存中的数据。因此一般来说即使Eureka Server发生宕机，也不会影响到服务之间的调用。但如果Eureka Server宕机时，某些微服务也出现了不可用的情况，Eureka Client中的缓存若不被更新，就可能影响到微服务的调用，甚至影响到整个应用系统的高可用性。因此，在生产环境中，通常会部署一个高可用的Eureka Sercer集群。

Eureka Server可以通过运行多个实例并相互注册的方式实现高可用部署，实力会彼此增量的同步信息，从而确保所有节点数据一致。事实上，节点之间相互注册是Eureka Server的默认行为。

Ribbon

作用：Ribbon，主要提供客户侧的软件负载均衡算法。

简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。

Ribbon有助于控制HTTP和TCP客户端的行为。为Ribbon 配置服务提供者地址列表后，RIbbon就可以基于某种负载均衡算法，自动的帮助服务者去请求。Ribbon默认提供了很多的负载均衡算法，例如轮询、随机等。我们也可以自定义。

RIbbon与Eureka配合使用，Ribbon可自动从Eureka Servcer获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例。

Hystrix

作用：断路器，保护系统，控制故障范围。

简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

Hystrix用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性和容错性，主要通过以下几点实现延迟和容错：

1. 包裹请求

2. 跳闸机制：超过一定的阈值，可以手动或自动跳闸。

3. 资源隔离：每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就会被立即拒绝，而不是排队等候，从而加速失败判定。

4. 监控：实时监控运行指标和配置的变化。

5. 回退机制：回退逻辑可由开发人员自行提供。

6. 自我修复：图7-2描述的很详细。

注意：执行回退逻辑并不代表断路器已经打开。请求失败、超时、被拒绝以及断路器打开等都会执行回退逻辑。超过阈值才会打开断路器。

Zuul

作用：api网关，路由，负载均衡等多种作用

简介：类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。

在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

它可以与Eureka、Ribbon、Hystrix等组件配合使用。Zuul的核心是一系列的过滤器，这些过滤器可以完成以下功能。

Config

作用：配置管理

简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。

这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。