我们目前配置中心使用的是 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 :8180/bus/refresh，当 Git 仓库中的配置更新后，自动执行。
Config Server 中配置 Spring Cloud Bus，接受 Git 的配置刷新请求，然后利用 RabbitMQ 广播通知所有的 Config Client 订阅方，刷新配置信息。
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 架构之 Elasticsearch 和 Kibana 安装配置
ELK 架构之 Logstash 和 Filebeat 安装配置
ELK 架构之 Logstash 和 Filebeat 配置使用（采集过滤）
ELK 架构之 Elasticsearch、Kibana、Logstash 和 Filebeat 安装配置汇总（6.2.4 版本）
上面图中已经很详细介绍了下 ELK 的流程，ELK 默认技术栈里是没有 Filebeat 的，Logstash 用作日志收集的时候，CPU 和内存会占用资源比较大，所以我们使用轻量化的 Filebeat 进行日志的收集，Filebeat 部署在每个业务服务所在的服务器，然后将收集到的日志数据传输到 Logstash，Logstash 可以部署两到三台服务器上，用作日志的过滤和分析工作，然后再将处理后的日志数据，传输到 ElasticSearch 存储。
7. 统一格式返回