Spring Cloud 微服务架构全链路实践

Dear 丶 2023-05-30 06:08 24阅读 0赞

# [Spring Cloud 微服务架构全链路实践][Spring Cloud] #

![format_png][]

阅读目录：

*  **1. 网关请求流程**
 *  **2. Eureka 服务治理**
 *  **3. Config 配置中心**
 *  **4. Hystrix 监控**
 *  **5. 服务调用链路**
 *  **6. ELK 日志链路**
 *  **7. 统一格式返回**

[Java 微服务框架选型（Dubbo 和 Spring Cloud？）][Java _Dubbo _ Spring Cloud]

目前公司使用的 Spring Cloud 整个技术组件，基本包含了上面图中所包含的，不得不说，Spring Cloud 整个生态真的很强大，使用起来也很方便有效。

后面有时间再针对每个组件进行使用解读，这篇文章主要说下 Spring Cloud 架构的链路图，顺便把自己的思路整理下来，以备查阅。

## 1. 网关请求流程 ##

![format_png 1][]

在 Spring Cloud 整个组件库中，Spring Cloud Zuul 是最容易被忽视，但也是最重要的，Spring Cloud Zuul 可以和 Eureka 注册中心集成，我们目前使用 Spring Cloud Zuul 的功能如下：

*  **Filter 过滤器**
 *  **Router 路由**
 *  **Ribbon 负载均衡**
 *  **Hystrix 熔断**
 *  **Retry 重试**

有些功能是 Spring Cloud Zuul 自带的，比如 Filter 和 Router，有些是结合 Spring Cloud 其他组件，比如 Ribbon 和 Hystrix。

这里重点介绍下 Filter 过滤器，分为四个过滤类型：

*  **pre**：Zuul 转发请求之前执行，我们目前的实现是`AccessTokenFilter`，用于 oAuth2.0 JWT 的授权验证。
 *  **route**：Zuul 路由时执行，目前项目没用到。
 *  **post**：Zuul 路由转发后执行，也就是已经请求成功了后端服务，我们目前的实现是`CustomResponseFilter`，用于统一请求格式的封装，比如 code/msg/data 等。
 *  **error**：以上过滤器发生错误时执行，我们目前的实现是`CustomErrorFilter`，用于拦截过滤器执行的出现的错误，然后统一格式封装返回，另外，error 过滤器好像并不能捕获后端服务执行出现的错误。

另外，关于 oAuth2.0 JWT 的授权验证，实现的方式有两种：

*  授权的配置在后端服务中（每个服务都需要当作 Resource Server 进行配置，需要配置公钥，接口的授权具体配置在注解中），Zuul 只做转发，并不进行授权的验证。
 *  授权的配置在 Zuul 中，也就是把 Zuul 当作 Resource Server，后端服务不需要进行任何处理，Zuul 中具体的实现就是`AccessTokenFilter`，里面的逻辑是手动解析 JWT，然后判断是否正确，以及解析出用户信息/Scope/Role，然后根据当前的请求 API，对授权 Map 中的配置进行匹配，如果匹配错误，直接抛出 401 授权错误。

我们目前采用的是第二种方式，这两种方式都有利有弊，关键在于自己的取舍，为什么采用第二种方式？目的就是发挥 Zuul 的作用，对外网关进行统一授权验证。

关于授权 Map，里面存储了所有服务接口的配置，示例配置：

private static final Map ROUTE_MAPS;
    static
    {
        ROUTE_MAPS = new HashMap<String, String>();
        ROUTE_MAPS.put("eureka-client/home", "read:ROLE_ADMIN");
        ROUTE_MAPS.put("eureka-client/user", "read:ROLE_ADMIN");
        ROUTE_MAPS.put("eureka-client/error", "read:ROLE_ADMIN");
    }

这是我们目前的配置，是一个静态的 Map，后面会存储在 Spring Cloud Config 配置中心，Zuul 启动时进行加载，利用 Spring Cloud Bus 动态刷新。

关于 Zuul 网关，其实还有很多需要说的，后面有机会再进行针对说明。

## 2. Eureka 服务治理 ##

![format_png 2][]

Eureka 遵循的是 AP 原则（服务可用性和分区容错性），是服务治理最理想的遵循 CAP 分布式原则。

Eureka 集群中的节点是彼此平级，不像 Consul 有 master/worker 之分，集群中的 Eureka 节点彼此两两注册，所以，Eureka 集群最好部署三个节点，这也是我们目前的部署方式。

另外，Eureka 的自我保护机制，可以参考[这篇文章][Link 1]。

服务之间的相互调用，负载有两种使用方式：

*  **Feign**：基于声明式，顾名思义，就是需要定义接口，就像我们平常使用对象调用一样。
 *  **Ribbon**：软负载，通过往 RestTemplate 中注入负载 Handler，然后通过负载算法选取调用（通过 Eureka 获取服务注册信息）。

我们目前打算使用 Ribbon 负载方式，为什么？看下面代码就知道了：

restTemplate.getForObject("http://eureka-client/hello", String.class);

## 3. Config 配置中心 ##

![format_png 3][]

我们目前配置中心使用的是 Spring Cloud Config，当然你也可以使用功能更强大的 Polly（携程开源），但 Config 目前也能满足我们的需求，存储仓库我们现在使用的是 Git。

Config 配置中心提供了数据加密功能，你可以使用 RSA 的加密方式，这样存储在 Git 中的配置都是密文形式，Config Client 获取加密配置的时候，Config Server 会自动进行解密返回。

配置中心的使用场景，我们目前主要是两个地方：

*  项目启动的配置信息，比如数据库的连接字符串等。
 *  业务服务的配置信息，也就是业务相关的配置。

另外，需要说明的是，默认情况下，如果 Git 中的配置更新了，Config Client 不会进行更新配置，我们目前的解决方式是，使用 Spring Cloud Bus 进行动态刷新配置（Config Server 中配置），具体的流程：

*  Git 中添加 WebHooks 脚本，比如`curl -X POST http://manager1:8180/bus/refresh`，当 Git 仓库中的配置更新后，自动执行。
 *  Config Server 中配置 Spring Cloud Bus，接受 Git 的配置刷新请求，然后利用 RabbitMQ 广播通知所有的 Config Client 订阅方，刷新配置信息。

## 4. Hystrix 监控 ##

![format_png 4][]

Hystrix 主要是用于服务熔断/降级/隔离处理，Hystrix 配置在调用方，当被调用方服务不可用时，触发 Hystrix 熔断，会执行指定的 Fallback 方法，进行特殊处理。

我之前以为，Hystrix 熔断的触发条件是服务不可用，也就是服务请求超时（比如服务挂掉了），但我自己测试了下，服务出现 500 错误，也会触发 Hystrix 熔断，而且会自动忽略 Hystrix 的超时时间设置。

我们目前使用 Hystrix，主要有两个地方：

*  **内部服务调用**：可以对某个 API 接口进行熔断处理。
 *  **Zuul 网关使用**：就是当 Zuul 路由转发调用时，但有个局限性，就是只能对服务进行熔断，并不能针对某个 API 接口熔断。

上面图中，主要画的是 Hystrix 的监控流程，我们目前主要使用 RabbitMQ 进行采集传输，turbine-server 进行数据流的聚合，hystrix-dashboard 进行图形化的展示。

## 5. 服务调用链路 ##

![format_png 5][]

服务调用链路的概念，就是当服务请求发起时，记录整个请求链路的数据，以备查询。

目前市面上，几乎所有服务调用链路的实现，理论基础都是基于 Google Dapper 的那篇论文，其中最重要的概念就是 traceId 和 spanId。

*  traceId 记录整个服务链路的 ID，由首次请求方创建，服务链路中唯一。
 *  spanId 记录当前服务块的 ID，由当前服务方创建。
 *  parentId 记录上一个请求服务的 spanId。

下面我描述下，我们目前的服务调用链路过程：

*  H5 发起请求，到 Zuul 网关，Zuul 创建全局的 traceId 和自己的 spanId，然后携带这些数据到业务服务 A，并利用 Spring Cloud Sluth 传输到 RabbitMQ。
 *  业务服务 A，接收到 Zuul 传输的 traceId 和 spanId，然后把 Zuul 的 spanId 设置成 parentId，并生成自己的 spanId，然后携带这些数据到业务服务 B，并利用 Spring Cloud Sluth 传输到 RabbitMQ。
 *  ....

上面图中，详细说明了整个服务调用链路的过程，这边再说下使用的技术栈：

*  Spring Cloud Sluth：和 SkyWalking 的探针概念比较类似，每个服务都进行配置，收集当然服务的请求数据（traceId 和 spanId），然后利用`stream-sluth`和`binder-rabbit`组件，将请求数据传输到 RabbitMQ。
 *  Spring Cloud Zipkin：主要用于请求链路的 UI 展示，Zipkin 会从 RabbitMQ 读取请求数据，然后存储到 ElasticSearch 中，然后下次显示直接从 ElasticSearch 中读取。
 *  Kibana：Kibana 也可以显示 ElasticSearch 中的请求数据，只不过不是图形化的，需要索引配置创建。

## 6. ELK 日志链路 ##

![format_png 6][]

ELK 可以参考下之前的几篇文章：

*  [ELK 架构之 Elasticsearch 和 Kibana 安装配置][ELK _ Elasticsearch _ Kibana]
 *  [ELK 架构之 Logstash 和 Filebeat 安装配置][ELK _ Logstash _ Filebeat]
 *  [ELK 架构之 Logstash 和 Filebeat 配置使用（采集过滤）][ELK _ Logstash _ Filebeat 1]
 *  [ELK 架构之 Elasticsearch、Kibana、Logstash 和 Filebeat 安装配置汇总（6.2.4 版本）][ELK _ Elasticsearch_Kibana_Logstash _ Filebeat _6.2.4]

上面图中已经很详细介绍了下 ELK 的流程，ELK 默认技术栈里是没有 Filebeat 的，Logstash 用作日志收集的时候，CPU 和内存会占用资源比较大，所以我们使用轻量化的 Filebeat 进行日志的收集，Filebeat 部署在每个业务服务所在的服务器，然后将收集到的日志数据传输到 Logstash，Logstash 可以部署两到三台服务器上，用作日志的过滤和分析工作，然后再将处理后的日志数据，传输到 ElasticSearch 存储。

## 7. 统一格式返回 ##

![format_png 7][]

关于统一格式返回，图中已经详细的说明了，如果你有更好的方案，欢迎探讨。

[Spring Cloud]: https://www.cnblogs.com/xishuai/p/spring-cloud-microservice.html
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNC80MzUxODgtMjAxODA0MTIyMTQwNDU0MjctMTc2MDgxMDgzLnBuZw?x-oss-process=image/format,png
[Java _Dubbo _ Spring Cloud]: https://www.cnblogs.com/xishuai/p/dubbo-and-spring-cloud.html
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAwMjgxNjEtMTkzMTUwNzQxLnBuZw?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAwNTYyMzktOTg0NDE4MzU5LnBuZw?x-oss-process=image/format,png
[Link 1]: https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAxMTY4MzMtMTU5NDUyMzAzMi5wbmc?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAxMzQ0NjgtMTY3MTY0MTQxOC5wbmc?x-oss-process=image/format,png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAxNTMzNTAtMTQ2NDI1NjQ2MS5wbmc?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAyMDkxNDMtNzU1NTY4NjcwLnBuZw?x-oss-process=image/format,png
[ELK _ Elasticsearch _ Kibana]: http://www.cnblogs.com/xishuai/p/elk-elasticsearch-kibana.html
[ELK _ Logstash _ Filebeat]: http://www.cnblogs.com/xishuai/p/elk-logstash-filebeat.html
[ELK _ Logstash _ Filebeat 1]: http://www.cnblogs.com/xishuai/p/spring-boot-log4j2-and-elk-logstash-filebeat.html
[ELK _ Elasticsearch_Kibana_Logstash _ Filebeat _6.2.4]: http://www.cnblogs.com/xishuai/p/elk-elasticsearch-kibana-logstash-filebeat-log4j2.html
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDM1MTg4LzIwMTgwNy80MzUxODgtMjAxODA3MDUxMzAyNTA4MDAtODkyMjA0NDI3LnBuZw?x-oss-process=image/format,png