2.1　微服务治理基础

2.1.1　服务治理由来

在单体服务时代并没有服务治理的概念，随着单个服务慢慢演变和拆分为众多微服务组成的系统，服务提供者与服务使用者之间如果没有明确的契约和规范，开发、测试和运维过程中会带来很大的沟通成本。之前线上服务遇到过的一个真实的例子，服务代码中调用地理围栏服务，这块代码平常没什么变更，大家关注也不多，线上服务调用地理围栏突然发生故障，服务使用方联系之前负责对接的人，发现早已离职，并且这个服务多年没有修改，当前处于无人维护状态，导致出问题时无法及时响应的悲剧。

服务治理就是解决服务提供者和服务使用者之间的链路通信与治理，主要包括如下几个维度的目标。

（1）服务定义和SLA

服务定义是向外界说明当前服务提供者具体提供了哪些功能和能力，具体通过什么方式来使用服务，以及服务对外承诺的服务SLA 。

（2）服务注册中心

服务使用者使用服务之前需要先知道服务提供方具体在什么地方，服务注册中心负责管理各个服务的地址信息，用于服务使用者查询。

（3）服务生命周期管理

服务生命周期管理用于对服务部署的整个生命周期进行管理，包含服务的上线和下线，服务的扩容和缩容等。

（4）服务通信和链路治理

服务通信和链路治理是服务提供方和使用方约定，为了达成SLA而采用的一些治理手段，比如超时重试、限流降级等。

（5）服务授权和通信安全

通信安全严格来说也是属于链路通信和治理的范畴，只不过由于安全特别重要，可以将这块单独提出来进行讲述。

2.1.2　服务治理的目标与愿景

服务治理整体愿景是打造可见、可控、可追溯、可预测的全系统视图，立足全局，业务优先。可见即所得，可见皆可控。虽然服务治理的立场是系统全局，但是服务治理必须做到深入业务需求，解决业务实际问题。服务治理的开展和推广是讲究策略的，需要和业务方明确服务治理的长期收益。除此以外，服务治理要能溯源系统问题，提升定位效率。服务治理还要有能力提前发现全系统中的异常，如场景单点故障、全系统容量瓶颈和不合理的容量冗余等。

服务治理的目标是提供标准化、平台化、智能化的一站式服务治理设施，支持业务的稳定运行和高效迭代。服务治理的范围贯穿服务的全生命周期。

1）标准化是服务治理一切工作的基石，服务治理在规范、工具、框架和平台各个层次上都要有统一的标准。

2）平台化是擎天柱，标准如果完全依靠人来执行，不仅效率非常低，也很难保证不会出现各种遗漏以及落地和标准不一致的现象，将标准进行平台化落地，可以保证服务治理标准可以高效、稳定执行。

3）智能化是服务治理的理想状态，属于远景目标和仰望的星空，期望所有的服务治理工作能逐步通过自动化和智能化方式推进。

4）一站式，强调服务治理的闭环体系，所有通用的可感、可控、可追溯治理均能通过闭环高效完成。

服务治理基础设施的呈现形式多样，具体包括规范、工具、框架和平台等。

稳定是服务治理的基础和底线，易用才能提高用户效率，服务治理一般只关注稳定性和效率，对性能关注比较少，具体来说稳定运行，提高业务的稳定性，是服务治理的第一目标；高效迭代，提高业务的迭代效率，是服务治理的另一目标。

从方法论的角度看，服务治理是把复杂的、重复的事情简单化，把简单的事情标准化，标准的事情流程化，流程的事情自动化。

2.1.3　服务治理的工作范畴

基于上述服务治理目标，服务治理的实际工作包括两部分： 一站式的服务治理平台、普适性的服务开发框架 。其中一站式的服务治理平台作为服务治理输出的根据地，最重要的作用是服务治理规范的固化。服务治理规范从经验到wiki、从wiki到平台的发展趋势也表明了服务治理规范是业务方和服务治理团队之间一个非常重要的桥梁。普适性的服务开发框架，是服务治理团队非常重要的一个抓手，平台能做的事情是有限的，而广泛使用的开发框架则可以完成更多的事情。普适性笔者认为是服务开发框架最重要的优点，如何和业务方结合、提升服务开发框架的普适性非常重要。

从内容上看，服务治理具体工作范围可以概括如下。

（1）系统可见

主要是服务治理平台的工作，具体包含服务静态描述，比如服务基本信息、服务等级、全局依赖拓扑、路由关系、IDL（SDK）、权限、SLA、流量控制策略等，服务治理平台需要有能力帮助我们梳理依赖层级、判定服务等级。

服务实时拓扑，具体包括全局流量拓扑、报表审计等，服务治理平台需要有能力展示实时流量状态，基于场景定位线上问题。

（2）系统可控

打通服务治理平台和服务开发框架，为其他平台输出能力，具体包括路由切换、降级预案等。

（3）系统可追溯

将问题现场进行录制，如流量录制、日志录制等方式，然后使用相应的跟踪和追溯系统，对典型场景下的常见问题进行回放和溯源，做到“一次录制，多次回放”。基于追溯和回放机制，可以解决根因定位、场景分析等问题。

（4）系统可量化、可预测

系统可预测，是指预测业务接下来一段时间的行为，比如流量、容量、安全等，同时通过各种工具和平台检测系统的潜在风险。以容量规划为例，需要能够预见和判断业务接下来一段时间的增加趋势和运营活动，判断可能的流量峰值以及对系统容量的影响；接下来通过全链路压测、单系统压测等方式探测系统可能的容量风险。

（5）立足全局、业务优先

服务治理的目的是解决业务的稳定性和效率问题，必须完全聚焦业务，从业务出发，重点解决业务当前的痛点问题。

2.1.4　服务治理闭环体系

服务治理本质上来说是解决微服务化后产生的一系列挑战，比如效率治理、稳定性治理、效果治理、性能成本治理等。这些治理举措一般作用于设计开发阶段，我们可以称之为“正向治理”，在服务上线后，可以基于运行时的各种数据，进行综合治理和反馈，从而构成一个治理闭环，如图2-1所示。

在上述服务治理闭环中，通过多维度的度量数据收集，结合静态的服务元数据信息，构成一个完整的服务治理数据集，然后基于这些数据进行综合度量和分析。根据分析结果会产生相应的控制和管控措施，分别从线上和线下两个维度进行综合治理，同时将治理结果负向反馈回来，作为进一步治理的输入。

本章接下来几节均围绕这个治理闭环展开，对服务治理进行深入剖析。 MzGSccmj5F8hga3tixUC7lbEv2yKdA280GIYpldzqB8zdU3CRS7RJSfG+s9dVlmY