Spring Cloud 从入门到精通

小鱼儿 2022-03-08 02:34 230阅读 0赞

Spring Cloud 从入门到精通

[https://blog.csdn.net/valada/article/details/80892573][https_blog.csdn.net_valada_article_details_80892573]

服务注册与发现

服务网关

服务消费者

服务异常处理

配置中心

消息总线

服务链路追踪

分布式锁

分布式事务

Spring Cloud 系统发布

Docker 部署 Spring Cloud 集群

服务发现——Netflix Eureka

客服端负载均衡——Netflix Ribbon

断路器——Netflix Hystrix

服务网关——Netflix Zuul

分布式配置——Spring Cloud Config

从 Spring Cloud 看一个微服务框架的「五脏六腑」

[http://www.importnew.com/28514.html][http_www.importnew.com_28514.html]

从最简单、最核心的问题出发，假设服务 A 要调用服务 B，会有什么问题？

*  服务在哪？（服务治理问题）
 *  怎么调用？（服务调用问题）

这两个是最核心的问题，也是任何微服务框架首要解决的两个问题。

为了解决第一个问题 Spring Cloud 提供了 Eureka、Zookeeper、Cloud Foundry、Consul 等服务治理框架的集成。它们的工作模式是将所有的微服务注册到一个 Server 上，然后通过心跳进行服务健康监测。这样服务 A 调用 B 时可以从注册中心拿到可用的服务 B 的地址、端口进行调用。

第二个服务调用有人可能认为就是一个简单的 HTTP 或者 RPC 调用，不是什么问题。但是在分布式的场景下，服务调用需要考虑的因素会更多。比如一个服务有多个实例，此时请求进来了交给谁处理，请求的负载怎么平衡到各个实例，都是比较棘手的问题。Spring Cloud 提供了两种服务调用的方式：一种是 Ribbon + restTemplate，另一种是 Feign。

其中 Ribbon 是基于 HTTP 和 TCP 客户端的负载均衡器，restTemplate 是 Spring 提供的 Restful 远程调用的模板，两者结合就可以达到远程调用的负载均衡。

而 Feign 是一个更加声明式的 HTTP 客户端，开发者可以像调用本地方法一样调用它，完全感觉不到是远程调用，结合 Ribbon 也可以做负载均衡。

既然两个问题都得到了解决，我们就用一个例子来进一步说明一下，例子包含了微服务中最基本的三个角色（注册中心、服务提供者、服务消费者)

服务“雪崩”与断路器

由于网络等原因，服务并不能保证 100% 可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet 容器的线程资源会被消耗殆尽，导致服务瘫痪。

由于服务与服务之间存在依赖，故障会在调用链路上传播，导致整个微服务系统崩溃，这就是服务故障的“雪崩”效应。

为了解决这个问题，Spring Cloud 提供了对 Hystrix 断路器的集成，当服务调用失败的频次达到一定阈值，断路器将被开启，降级的策略可以开发者制定，一般是返回一个固定值。这样就能够避免连锁故障。

此外 Spring Cloud 还提供 Hystrix Dashboard 和 Hystrix Turbine，帮助我们进行监控和聚合监控。

服务暴露与路由网关

微服务中的服务很多，直接暴露给用户一是不安全，二是对用户不友好。因此在微服务和面向服务的架构中，通常会有一个路由网关的角色，来负责路由转发和过滤。对应到 Spring Cloud 中有 Zuul 和 Gateway 两个组件可用。

路由网关接收了所有的用户请求，有着很高的负载，因此它通常是一个集群。用户的请求会先经过一层负载均衡被发到路由网关。

服务配置与配置中心

在微服务应用中，服务数量巨多，而每个服务不同环境都有着不同的配置，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。需要注意的是此处的配置与注册中心注册的配置信息是两个概念，此处的配置是服务本身的一些配置信息

信息同步与消息总线

前一个问题讲到了每个服务都有一些配置信息，那么配置信息更新了我们该怎么办，手动一个个去更新？当然不是，Spring Cloud 提供了 Spring Cloud Bus 组件，它通过轻量消息代理连接各个分布的节点。当配置信息更新的时候，我们只要更新一个节点的配置，这个更新就会被广播到这个分布式系统中。

问题定位与链路追踪

在微服务系统中，服务之间可以相互调用，因此我们一个请求可能会一条调用链，而整个系统会存在一张调用网，其中任意一个服务调用失败或网络超时都可能导致整个请求失败。因为调用关系的复杂，这给问题的定位造成了极大的困难，这也是必须提供服务链路追踪的原因。

Spring Cloud 为我们提供了 Spring Cloud Sleuth 组件，它能够跟进一个请求到底有哪些服务参与，参与的顺序是怎样的，从而达到每个请求的步骤清晰可见。借助服务链路追踪，我们可以快速定位问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L292ZWp1cg_size_16_color_FFFFFF_t_70][]

服务治理为心脏，路由网关、消息中心、断路器、链路追踪、配置中心等为依托，构造了整个微服务框架的「五脏六腑」。

[https_blog.csdn.net_valada_article_details_80892573]: https://blog.csdn.net/valada/article/details/80892573
[http_www.importnew.com_28514.html]: http://www.importnew.com/28514.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L292ZWp1cg_size_16_color_FFFFFF_t_70]: /images/20220308/30446a1ef22e4ad8b260f77358bf11ee.png