服务治理都要治理些什么？读了这篇文章，结合spring cloud的各种技术，感觉有所收获，有些明白了。以下是原文（ 转自：https://www.jianshu.com/p/104b27d1e943）：

 

 

一、服务治理-思路

2014年我们自我感觉技术挺好了，当我们梳理全平台依赖状况的时候出现了这样一个状况：我们的平台存在各种各样的依赖关系，没有人能理清楚这样繁杂的依赖关系，我们面临着一个新的挑战：服务治理。

 

 

 

 

我们现在的服务数量达到200+，服务实例数量600+，接口数超过3000，链路数400+，日调度数超过25亿，机房5个，各种抖动、服务之间的调度会导致我们每天出现超过10万次的调度失败。这种情况下出现了很多问题：

1、服务资源配置困难。一个业务依赖很多其他服务，运维要花很多的资源来服务配置。

2、授权密钥配置更困难，业务上线依赖着哪个系统就要去运维那边申请，运维分配一个密钥，服务访问者需要配置该密钥进行签名，服务提供方也需要新增该caller的密钥，所以密钥配置是一个非常痛苦的经历。

3、强依赖F5/或者DNS。F5做一些结点切换的时候没办法做到实时修改，比如域名，涉及DNS的过期问题；内部DNS更明显，遇到DNS过期的问题，不能实时处理一些由于链路导致的具体问题，而且很多抖动问题都是瞬间发生，但很快又恢复，根本没有时间让运维去识别故障并做节点移除。

4、级联故障，故障识别成本高。我们的那些链条过于复杂，有些四级、五级的链条，一旦哪个环节的一「点」出了问题，会出现一「片」的症状，这是比较痛苦的。

5、接口沟通成本高。HTTP协议+JSON的协议和签名方式，接口沟通成本高。

我们的解决方式是搭建服务中心，服务中心就是服务治理的总体解决思路，由服务中心解决服务发现、服务调度、服务资源、服务质量、服务监控。

二、服务治理-设计

 

 

我们的设计非常简单：

1、厘清三个节点：服务的消费者、生产者、服务中心。服务消费者和生产者之间没有任何生产节点，我们的调用还是通过原生调用，服务中心只负责后面的一些资源管理和服务的配置推送，这期间运维是相对清闲的，因为所有的接入实例都会自动注册到服务中心，无论是消费者，还是生产者都会实时接收到相关的配置变动。另外，服务消费者和服务生产者之间是没有中间节点的，自动接入的服务都是以内网IP的方式进行通信。

2、服务调度框架HTTPSF，包括权重负载均衡、自动降权、自动恢复，调度链染色，后续我们基于HTTPSF实现了RPC框架。

3、内部/外部服务，内部服务是无需资源管理的，服务实例启动时就会自动接入服务中心，同时，我们有很多的外部服务依赖，要访问各种外部渠道平台的接口，一个重点是把外部服务纳入到我们的服务框架，在外部出现问题的时候，我们能够自动做一个降权跟恢复处理，外部服务的服务信息没办法自动注册，由运维做人工录入到服务中心。

三、服务治理-协议

 

 

 

为什么用HTTP协议？在着手进行服务治理时，整个平台实际在线上已经有100+的服务，而且是用HTTP协议JSON的序列化方式，这造成我们没办法对现有的服务做一个彻底的改造，所以我们没办法使用现成的服务框架，例如淘宝的HSF服务框架来做服务化的改造，同时我们是个完全业务驱动的平台，我们也没法投入这样的成本停下业务进行服务化改造，因此我们的框架是完全兼容现有的服务在上面做的HTTPSF，基于HTTP协议做的一个调度框架，我们几乎没有投入任何的接入成本就完成了服务化，后面我们做了一个HTTPSF-RPC框架，JWS框架中也集成了RPC的服务容器，新业务组件为了更高的开发效率会优先使用RPC框架。

四、服务治理-去中心依赖

 

 

因为加入了服务中心，平台变成了一套非常复杂的分布式系统，服务中心变得非常重要，同时去中心化也就非常必要了。在服务中心出问题的时候，怎么去处理，这边会有两级容灾：第一级很简单，就是服务中心集群部署，它保证内部不出问题，目前一直保证着5个9的可用性；另外一个层面就是万一服务中心出问题了怎么办？每个服务接入都会有一个Backup文件，所有跟服务中心的交互、配置都会在本地同步一个Backup文件，一旦服务器出问题，没法做接入的时候，会读取最近一次的Backup文件，按照之前的配置结点启动程序，这是去中心依赖的设计。

五、服务治理-负载均衡

 

 

这是我们的后台页面，实际上是运维同学用的最多的页面，但其实要做的事情并不多，只要知道我们服务都接入了哪些实例，权重如何，是否开启等等，内部服务接入之后会有一个已接入状态，内网IP就会自动发布，上面account_server是我们九游的帐号服务，就可以通过内网IP来做访问。uop是UC的帐号系统，就是UC的账户开放平台提供了整个UC的帐号体系，uop相对我们平台而言就是一个外部服务。这里运维启用了4条链路，都是在做多级容灾。正常情况下绝大部分访问量都会到我们运维希望最快的链路上面去了，一旦出现了问题，他会自动切换到移动或者电信或者汕头机房的集群。这就实现了多链路容灾处理。

六、服务治理-调度依赖管理

 

 

我们在服务的依赖管理方面可以拿到很多数据，所有对外依赖的系统和接口，各个负责人都可以看到自己系统的依赖情况，我们还可以看到实时访问量的曲线波动情况，可以对系统做一些依赖管理。

我们每周会发布依赖质量情况：比如这个系统对外依赖的情况，它依赖了这么多对外系统，其实都是我们内部的系统；它的访问量占比代表依赖情况；接着就是性能情况，以及可用性情况，每周可用性是增加还是降低的，都是可以看到的；访问量有没有增大，都可以做分析。负责人可以根据这个情况来判断对外依赖的情况是否需要改善或者做一些系统优化。

七、服务治理-故障拓扑

 

 

现在我们有整个的故障拓扑，这张图是我们线上的真实情况，服务量不是很多，因为我们做了一个服务的分级处理，运维只关心核心服务，核心服务涉及到的调度都在这里。运维只关心不同级别的服务的可用性，这是比较关键的，像上图中核心服务实际上是要求可用性能够确保达到4个9，这是最真实的可用性，因为不是通过采样得到的数据，而是所有的调度数据都会进行实时的统计。

我们九游服务管理人的角色，你进去之后可以看到所有依赖你的服务跟你对外依赖的服务组成的网状故障拓扑，基于这个拓扑，我们可以做一些报警或者一些质量分析。

八、服务治理-流程审批

 

 

 

在服务治理方面有流程审批，为了使整个运维工作更加便捷。我们所有的上线会变得非常简单，只需要在后台就可以完成，因为用户注册、申请权限、然后上线申请、服务调度授权申请，都是由各个业务负责人去提交流程。这也是在打造我们的运维生态，让运维工作可以更简单，变得规范化、降低成本，毕竟维护200多个独立系统，没有规范的流程，一定会出现疏漏的问题。

我们尽量把所有涉及到的服务管理、服务治理的问题处理好，尽量让运维不需要人工操作，包括看到的各种系统展示，运维没有任何的操作概念在里面，他只要管控、处理好监控、处理好报警阀值，这是他的一些具体工作。同时，服务中心系统让运维人员更关注一些应用上的数据，包括服务的依赖，容量，和质量，运维不再局限于只是做部署，从而把运维上升到一个应用运维层面，做的这些事情都是在帮助运维打造这样一个生态。

打造运维生态

 

 

 

 

 

要做好服务治理，尤其是有运维产品的服务治理，要做的事情挺多、也挺专业的。可以看到我们有这么多内容，包括服务发现、服务调度、服务资源、服务质量，包括后面我们一直在打造的运维生态。我可能实现了一个协议，我们做了一个调度，实现了服务的交互，这些就是服务治理吗？不是的，我们要做很多事情来维护所有服务，比如确保服务注册、服务发现、接口发布都是实时感知的。

服务调度，一旦出现波动问题都是做自动降权或者自动恢复，以应对运维来不及处理异常的情况。之前很多级别的问题都是数据突然间抖动或者网络突然间抖动，但抖动的时间不长，可能是几十秒，造成依赖方阻塞，这种情况下通过服务调度做自动降权，确保不会被你依赖，保证自身的稳定；当然服务方的服务容器这块我们有统一请求队列关联和过载保护机制，共同确保我们整个平台的可用性。

服务资源包括服务、实例、接口、接口黑白名单、RPC元数据、RPC容器、调度授权、调度策略、集群管理。

还有服务质量，包括调度监控、调度链监控、依赖监控、故障拓扑、故障时间分布、质量报告、服务分级、集群监控、报警系统。我们各种调度的监控，刚才列出来的只是很少一部分，我们还有各种各样的依赖、调度链，包括故障分布时间，服务分级的一些监控、质量报告、集群监控等等。

我们做了很多工作来确保整个平台的稳定性，所做的工作基于打造运维生态，确保我们的运维能够尽量减少人工操作，尽量可以让系统自动识别、自动处理，运维从全局把控住整个依赖关系的具体情况，保证系统全局处于稳定的情况。