【服务治理】服务治理漫谈

【服务治理】服务治理漫谈

0. 前言

本文是服务治理领域专题的第一篇，并不希望也无法大包大揽将所有的点都覆盖到，更意在从一些更贴近我们实际工作的角度来进行更抽象层次的剖析，更多分享的是我认为重要或者有意思的一些方法论和逻辑推演过程。这能给我们后续无论是业务应用还是基础技术领域的服务治理提供一些参考。

1. 什么是服务治理

在一切的最开始，我们先来问自己一个问题，什么叫做服务治理？网上有很多关于服务治理的定义，维基百科也有着对应的定义。林林总总，有宏观的也有细节的。而在本文中，我尝试为其进行另一个维度上的简单定义：

服务治理，即以组织、业务和系统三者为核心要素建立连接，在此基础上实现服务系统的正向打通和逆向反馈。

1.1 三要素

• 组织
  组织即人。服务不可能独自存在，我们在进行治理的过程中，往往过度重视面向业务的用户体验，而会忽视掉在这个技术生态上另外一个非常重要的服务对象—技术人员。大家往往更专注于如何设计出一个高性能高可扩展的系统，而冷落了技术人员在这之中的诉求。一个良好的服务治理的判断标准，即要在服务好普通用户的同时，也需要让在这生态之上的技术同学得到归属感。
• 业务
  业务即产品。毋庸置疑，技术是为业务服务的。空谈技术本身没有意义。所以我们需要保持对业务敏锐的洞察力和前瞻意识，这样才能设计出一个演化式的合理服务架构。比如业务流量很低且还处于快速试错阶段，而你却上了一整套的高并发的解决方案，这就本末倒置了。大部分技术同学天然会有“秀技术肌肉”的冲动，这是正常的，但作为架构师，需要合理控制组织的欲望，结合业务实际进行处理，才能达到一个良好的服务治理的状态。
• 系统
  系统层面上，也即我们最常谈及服务治理时候会关注的点。如何做一个可靠、高性能、自动化、可扩展且能够快速迭代的系统出来响应业务的需求呢？良好的服务治理要求我们能够结合组织和业务实际，进行系统层面的控制。这样也是下列章节中会重点提及的内容。

如上图所示，三要素之间会相互影响，良好的服务治理能够让三者相互促进优化迭代，不合理的服务治理将导致三者相互拉扯、冲突，乃至降低士气和效率并影响最后的公司产出。所以服务治理，从来就不单纯只是系统、技术的问题，也涵盖着人和事情的要素。

1.2 系统层面的正向打通和逆向反馈

在系统层面的服务治理的范畴，相关的介绍有很多，比如业内享有盛誉的阿里开源框架 Dubbo（目前已入 Apache）中的相关图表的呈现：

可以看出在一个复杂的网络拓扑场景中，我们需要对这个服务网进行各种各样的治理，来确保这个网在技术层面能够尽可能地维持健康和有效。但如何去归纳我们到底需要什么样的服务治理呢？如下图所示：

在系统层面，我们认为：

服务治理其实是由流量的正向打通和逆向反馈所构成的一个环

正向打通，即如何将流量打通，这也是对于一个服务本身最基本的要求。我们于是需要思考：

1. 如何做跨服务通讯，Rest 还是 Rpc ？序列化用 json 还是 pb ？能支持什么协议？是否支持多协议转换？
2. 如何做服务注册/发现，用 Eureka、Zookeeper、etcd、Consul、Nacos？
3. 如何做负载均衡，用软负载，还是硬负载？负载算法用 RR、Random、一致性哈希？
4. 如何做路由筛选，捞一百个，还是 IDC 优先，还是类似 Envoy 这样的防恐慌机制或者干脆来个类似 Dubbo 的脚本花活？
5. 如何做授权鉴权，是否需要 TLS，是否需要黑白名单，是否要验签，用什么加密算法，机器如何互信？
   ……

逆向反馈，则是代表我们如何基于各种基于流量进来后观察到的数据，来进行系统性地决策（一般是负反馈）我们的服务网需要做哪些事情才能让整张网持续处于健康状态。于是，我们思考，

1. 如何扛住流量洪峰，削峰、限流？怎么限流？信号量、令牌桶、漏桶、固定窗口计数、滑动窗口计数、线程隔离？
2. 如何正确处理异常，及时熔断？一键降级？级联决策关闭入口？
3. 如何让系统可观察，监控、报警、分布式链路追踪？选择 Cat、Zabbix、Falcon、Prometheus、Zipkin、Skywalking？
4. 如何提升资源效率，采用容器，Kvm？Docker？Swarm？K8s？Mesos？Openstack？
5. 如何定义一个服务的健康度，SLA？RTO？RPO？健康度量模型？
   ……

2. 服务治理的发展史

我们都知道，服务的发展是由单块应用，服务水平分层，服务纵向切割，乃至后续微服务思想的兴起，**“两个星期”重构法则和“两张披萨”**团队等眼花缭乱的服务拆分方法论充塞你的耳目。这都是些常见的论调，但不是本章节阐述的重点。本章节更关注的是服务治理发展拆分过程中，所必然要面对的一个核心问题—“服务拆分后，之间如何产生联系？”也即：

如何形成复杂服务节点的网络？

限于篇幅，我们来简单回顾下针对该问题的几个重要思潮。

2.1 Server Proxy

我姑且称之为集中式代理阶段。该阶段也是最朴素的解决方案，多采用集中式的单点服务集群来承担较多服务治理的功能。比如集中式部署 Lvs、Nginx、Haproxy、Tengine、Mycat、Atlas、Codis等等，就是最常见的方式。这种方式的优势在于便于功能的集中维护，且语言无关，上手成本低，所以其实在大中小公司特别是创业公司里面拥有大量受众。但其带来的问题也很明显