《一遍文章让你看懂的SpringCloud、错过你会后悔》

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

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

阅读目录：

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

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 的受权验证，实现的方式有两种：

AccessTokenFilter
复制代码

咱们目前采用的是第二种方式，这两种方式都有利有弊，关键在于本身的取舍，为何采用第二种方式？目的就是发挥 Zuul 的做用，对外网关进行统一受权验证。

关于受权 Map，里面存储了全部服务接口的配置，示例配置：

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

关于 Zuul 网关，其实还有不少须要说的，后面有机会再进行针对说明。

2、 Eureka 服务治理

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

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

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

• Feign ：基于声明式，顾名思义，就是须要定义接口，就像咱们日常使用对象调用同样。
• Ribbon ：软负载，经过往 RestTemplate 中注入负载 Handler，而后经过负载算法选取调用（经过 Eureka 获取服务注册信息）。

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

3、 Config 配置中心

咱们目前配置中心使用的是 Spring Cloud Config，固然你也可使用功能更强大的 Polly（携程开源），但 Config 目前也能知足咱们的需求，存储仓库咱们如今使用的是 Git。

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

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

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

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

curl -X POST http://manager1:8180/bus/refresh
复制代码

4、Hystrix 监控

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

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

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

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

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

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 日志链路

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

7、统一格式返回

这是我本身在工做对SpringCloud，但愿对你们有所帮助一块儿共同成长进步