【Spring】聊聊我对 Spring Cloud 微服务架构的理解

什么是 Spring cloud?

官网是这么介绍的

构建分布式系统不需要复杂和容易出错。Spring Cloud 为最常⻅的分布式系统模式提供了⼀种简单且易于接受的编程模 型，帮助开发⼈员构建有弹性的、可靠的、协调的应⽤程序。Spring Cloud 构建于 Spring Boot 之上，使得开发者很容易 ⼊⼿并快速应⽤于⽣产中。

我所理解的Spring Cloud就是微服务系统架构的⼀站式解决⽅案

构建微服务的过程中需要做如服务发现注册、配置 中⼼、消息总线、负载均衡、断路器、数据监控等操作，⽽ Spring Cloud 为我们提供了⼀套简易的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务项⽬的构建。

Spring cloud作为当下主流的微服务框架，包含了哪些组件？各组件充当了什么角色呢？

• Eureka 服务发现框架
• Ribbon 进程内负载均衡器
• Open Feign 服务调⽤映射
• Hystrix 服务降级熔断器
• Zuul 微服务⽹关
• Config 微服务统⼀配置中⼼
• Bus 消息总线

---------------------------------------------------------------------------------------------------华丽的分割线-------------------------------------------------------------------------------------------------------------------------------

Fegin(接⼝调⽤)：

微服务之间通过Rest接⼝通讯，Spring Cloud提供Feign框架来⽀持Rest的调⽤，Feign使得不同进程的Rest 接⼝调⽤得以⽤优雅的⽅式进⾏，这种优雅表现得就像同⼀个进程调⽤⼀样。

Netflix eureka(注册发现)：

微服务模式下，⼀个⼤的Web应⽤通常都被拆分为很多⽐较⼩的web应⽤(服务)，这个时候就需要有 ⼀个地⽅保存这些服务的相关信息，才能让各个⼩的应⽤彼此知道对⽅，这个时候就需要在注册中⼼进⾏注册。每个应⽤启动时 向配置的注册中⼼注册⾃⼰的信息（ip地址，端⼝号, 服务名称等信息），注册中⼼将他们保存起来，服务间相互调⽤的时候，通 过服务名称就可以到注册中⼼找到对应的服务信息，从⽽进⾏通讯。注册与发现服务为微服务之间的调⽤带来了⽅便，解决了硬 编码的问题。服务间只通过对⽅的服务id，⽽⽆需知道其ip和端⼝即可以获取对⽅⽅服务。

Ribbon(负载均衡)：

Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP客⼾端的⾏为。为Ribbon，配置服务提供 者的地址列表后，Ribbon就可基于某种负载均衡算法，⾃动地帮助服务消费者去请求。Ribbon默认为我们提供了很多的负载均 衡算法，例如轮询、随机等。当然，我们也可为Ribbon实现⾃定义的负载均衡算法。在SpringCloud中，当Ribbon与Eureka配 合使⽤时，Ribbon可⾃动从EurekaServer获取服务提供者的地址列表，并基于负载均衡算法，请求其中⼀个服务提供者的实例 （为了服务的可靠性，⼀个微服务可能部署多个实例）。 

Hystrix(熔断器)：

当服务提供者响应⾮常缓慢，那么消费者对提供者的请求就会被强制等待，直到提供者响应或超时。在⾼负载 场景下，如果不做任何处理，此类问题可能会导致服务消费者的资源耗竭甚⾄整个系统的崩溃（雪崩效应）。Hystrix正是为了防 ⽌此类问题发⽣。Hystrix是由Netflix开源的⼀个延迟和容错库，⽤于隔离访问远程系统、服务或者第三⽅库，防⽌级联失败，从 ⽽提升系统的可⽤性与容错性。Hystrix主要通过以下⼏点实现延迟和容错。 包裹请求：使⽤HystrixCommand（或HystrixObservableCommand）包裹对依赖的调⽤逻辑，每个命令在独⽴线程中执⾏。 这使⽤了设计模式中的“命令模式”。 跳闸机制：当某服务的错误率超过⼀定阈值时，Hystrix可以⾃动或者⼿动跳闸，停⽌请求该服务⼀段时间。 资源隔离：Hystrix为每个依赖都维护了⼀个⼩型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被⽴即拒 绝，⽽不是排队等候，从⽽加速失败判定。 监控：Hystrix可以近乎实时地监控运⾏指标和配置的变化，例如成功、失败、超时和被拒绝的请求等。 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执⾏回退逻辑。回退逻辑可由开发⼈员指定。

Zuul(微服务⽹关) ：

不同的微服务⼀般会有不同的⽹络地址，⽽外部客⼾端可能需要调⽤多个服务的接⼝才能完成⼀个业务需 求。例如⼀个电影购票的⼿机APP，可能调⽤多个微服务的接⼝才能完成⼀次购票的业务流程，如果让客⼾端直接与各个微服务 通信，会有以下的问题： 客⼾端会多次请求不同的微服务，增加了客⼾端的复杂性。 存在跨域请求，在⼀定场景下处理相对复杂。 认证复杂，每个服务都需要独⽴认证。 难以重构，随着项⽬的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成⼀个或者将⼀个服务拆分成多个。如果客 ⼾端直接与微服务通信，那么重构将很难实施。 某些微服务可能使⽤了对防⽕墙/浏览器不友好的协议，直接访问时会有⼀定的困难。 以上问题可借助微服务⽹关解决。微服务⽹关是介于客⼾端和服务器端之间的中间层，所有的外部请求都会先经过微服务⽹关。 使⽤微服务⽹关后，微服务⽹关将封装应⽤程序的内部结构，客⼾端只⽤跟⽹关交互，⽽⽆须直接调⽤特定微服务的接⼝。这 样，开发就可以得到简化。不仅如此，使⽤微服务⽹关还有以下优点： 易于监控。可在微服务⽹关收集监控数据并将其推送到外部系统进⾏分析。 易于认证。可在微服务⽹关上进⾏认证，然后再将请求转发到后端的微服务，⽽⽆须在每个微服务中进⾏认证。 减少了客⼾端与各个微服务之间的交互次数。

Spring cloud bus（ 统⼀配置服务）：

对于传统的单体应⽤，常使⽤配置⽂件管理所有配置。例如⼀个SpringBoot开发的单体 应⽤，可将配置内容放在application.yml⽂件中。如果需要切换环境，可设置多个Profile，并在启动应⽤时指定 spring.profiles.active={profile}。然⽽，在微服务架构中，微服务的配置管理⼀般有以下需求： 集中管理配置。⼀个使⽤微服务架构的应⽤系统可能会包含成百上千个微服务，因此集中管理配置是⾮常有必要的。 不同环境，不同配置。例如，数据源配置在不同的环境（开发、测试、预发布、⽣产等）中是不同的。 运⾏期间可动态调整。例如，可根据各个微服务的负载情况，动态调整数据源连接池⼤⼩或熔断阈值，并且在调整配置时不停⽌ 微服务。 配置修改后可⾃动更新。如配置内容发⽣变化，微服务能够⾃动更新配置。综上所述，对于微服务架构⽽⾔，⼀个通⽤的配置管 理机制是必不可少的，常⻅做法是使⽤配置服务器管理配置。Spring cloud bus利⽤Git或SVN等管理配置、采⽤Kafka或者 RabbitMQ等消息总线通知所有应⽤，从⽽实现配置的⾃动更新并且刷新所有微服务实例的配置。

Sleuth+ZipKin(跟踪服务)：

Sleuth和Zipkin结合使⽤可以通过图形化的界⾯查看微服务请求的延迟情况以及各个微服务的依赖 情况。需要注意的是Spring boot2及以上不在⽀持Zipkin的⾃定义，需要到官⽅⽹站下载ZipKin相关的jar包。 另外需要提⼀点的是Spring boot actuator， 提供了很多监控端点如/actuator/info、/actuator/health、/acutator/refresh 等，可以查看微服务的信息、健康状况、刷新配置等。