黑科技王者荣耀背后的实时大数据平台用了什么黑科技？( 七 ) |腾讯|数据|

所以我们在做的时候也考虑到。原来我们服务是一个个开发，但是没有治理，现在我们加上服务还是一个个去开发，甚至有些服务我们会把它变成一个服务，但是我们加入了这个服务的治理。
好多人在提微服务，微服务如果没有一个平台去治理的话，将会是一种灾难。所以微服务化给我们带来便利的同时，也会给我们带来一些问题，所以在我们的场景里面，微服务是非常好的，每一个接口就可以作为一个服务，这种是天然的微服务。
2、一体化服务治理设计
但是这种微服务的治理将会是我们很大的一个问题，所以我们花了很大的精力去做了一个微服务的治理系统，从项目注册的时候，他就把项目注册的微服务中心，并且把 API 注册上来，然后在服务发布的时候，发到集群里的时候，这些服务都要主动的注册到我们的名册服务，就是 Consoul 。
但注册到服务里不是作为服务路由来用的，而是到服务里后，我们在普罗米修斯这块去做它的健康检查和状态采集，只要注册上来，我立马就能感知和把状态采集过来，然后主要做实时报表和告警。
首先在服务的稳定性和健康度这块我们有一个保障，另外一个就是服务的信息注册到 Consul 里去后，我们有一个服务的网关，我们用的是 envoy ，其实内部我们还把它作为 SideCar 使用，后面会介绍。
注册完了之后， envoy 会把这个所有的负载进信息加载到这块来，它去做它服务的路由，同时我们会把整个日志上报到日志中心去，包括网关的日志也会上传到日志中心去，日志中心再去做离线的报表和实时的一些报警监控，
所以这里面我们还加了一个基于 Consul 的一个配置，就是我们包括 server 的实时控制都可以通过 Consul 去配置，配置完了后立马能够 watch 到，然后去执行。
这个是基本的服务治理，但现在我们的服务治理升级了，比这个要更好一点，基本的原理是这样。
3、南北流量+东西流量的统一管控
并且我们在这里面实现了一个对 envoy 的管控，我们说是服务治理，主要是对流量的一些治理，比如贫富负载策略，路由策略，熔断，超时控制，故障注入等等一系列。
我们是通过 Consul 的配置管理，通过它能够下发到我们的 Agent ，这个 Agent 再把这个数据能够通过 Istio 的接口和 K8s 的 API 能够下发到 envoy ，这里面就是 API GeteWay 和 SideCar 都是 envoy ，所以我们通过 Istio 对他的 XDS 的接口写入，就可以把所有的配置信息下发到这里。
这套系统能够整个去管控整个集群，南北流量和东西流量的统一管控。这套系统我们未来准备开源，现在主要是内部在使用，而且这里面我们也做了图形化的配置，所有 envoy 和 Istio 的配置我们都经过 YAML 转 Istio 再转 UI 的方式，把它图形化了，在这块能够做统一的管控。
而且我们把 Agent 开发完了之后就是多集群的支持，就是多个 K8s 集群只要加入进来，没问题可以去支持，我们管理 API GeteWay 。
还有一块是 SideCar 的管理，就是 ServiceMash 里的 SideCar 管理。我们刚才说的函数接口也好，规则接口也好，是一个 server 。
当然这里面还提到一个 chaos mesh 的功能，我们现在还在研究，我们准备在这套系统里把它实现了。
4、基于 ServiceMesh 的全链路流量分析
这是一个我们通过 ServiceMesh 做的分析，我们虽然可以宏观地看出来我们接口对 DB 的压力有多大，但实际上我们把流量导进来是我们对压力的监控是不够的，所以这种情况我们通过 ServiceMesh ，他对出口流量和进口流量的管控，然后可以把流量进行详细的统计，统计完后可以生成一个快照，这次快照和下次快照之间的数据对比，入流量有多少的时候，对下面各个流量压力有多少。