李林锋，华为PaaS平台架构师，9年Java NIO通讯框架、平台中介软件架构设计和开发经验，开源框架Netty中国推广者。精通Netty、Mina、RPC框架、企业ESB总线、分散式服务框架、云端计算等技术，《Netty权威指南》、《分散式服务框架原理与实践》作者，公司总裁技术创新奖获得者.
本次分享，将分为三个部分。
为什么需要服务治理服务治理的技术演进历程云端微服务治理框架设计为什么需要服务治理？
第一、业务需求
随着业务的发展，服务越来越多，如何协调线上执行的各个服务，保障服务的SLA，对服务架构和运维人员是一个很大的挑战。随着业务规模的不断扩大，小服务资源浪费等问题逐渐显现，需要能够基于服务呼叫的效能KPI资料进行容量管理，合理分配各个服务的资源占用，提高机器的利用率。线上业务发生故障时，需要对故障业务做服务降级、流量控制、流量迁移等，快速恢复业务。
著开发团队的不断扩大，服务的上线越来越随意，甚至发生功能相同、服务名不同的服务同时上线。上线容易下线难，为了规范服务的上线和下线，在服务释出前，需要走服务预释出流程，由架构师或者专案经理对需要上线的服务做释出稽核，稽核通过的才能够上线。为了满足服务线下管控、保障线上高效执行，需要有一个统一的服务治理框架对服务进行统一、有效管控，保障服务的高效、健康执行。
第二、技术需求
大部分服务化框架的服务属性通过XML配置或者Java注解的方式进行定义，以服务端流量控制为例：
服务释出的XML档案通常会打包到服务提供者的jar包中，部署在Java Web或者Java Container容器中，储存在服务端的本地磁盘中。
无论采用注解还是XML配置的方式，如果需要在执行态动态修改服务提供者的流控阈值，都需要在本地修改配置或者修改源代码，重新打包部署并升级应用。无法实现线上、配置化的修改和动态生效。由于诸如流控阈值、服务的超时时间等无法预测出最优值，需要修改之后上线验证，根据服务执行效果决定是否再做调整，因此经常需要反复调整，采用修改源代码-重新打包部署-应用升级的方式进行服务治理，效率低下。
因此，在技术上需要一个服务治理框架，提供Web Portal，微服务运维或者治理人员通过线上配置化的方式修改服务提供者或者消费者的属性，可以实时动态生效。
服务治理的技术演进历程
第一代服务治理 SOA Governance: 以IBM为首的SOA解决方案提供商推出的针对企业IT系统的服务治理框架，它主要聚焦在对企业IT系统中异构服务的质量管理、服务释出审批流程管理和服务建模、开发、测试以及执行的全生命周期管理。
第二代以分散式服务框架为中心的服务治理：随着电商和移动互联网的快速发展，基于电商平台的统一分散式服务框架的全新服务治理理念诞生，它聚焦于对内部同构服务的线上治理，保障线上服务的执行质量。相比于传统IT架构的服务治理，由于服务的开发模式、部署规模、组网型别、业务特点等差异巨大，因此服务治理的重点也从线下转移到了线上服务质量保障。
第三代以云化为核心的云端微服务治理架构：2013年至今，随着云端计算和微服务架构的发展，以AWS为首的基于微服务架构 云服务化的云端服务治理体系诞生，它的核心理念是服务微自治，利用云排程的弹性和敏捷，逐渐消除人工治理。微服务架构可以实现服务一定程度的自治，例如服务独立打包、独立部署、独立升级和独立扩容。通过云端计算的弹性伸缩、单点故障迁移、服务健康度管理和自动容量规划等措施，结合微服务治理，逐步实现微服务的自治。
第一代 SOA Governance服务治理
第一代SOA Service GovernanceSOA Governance的定位：面向企业IT系统异构服务的治理和服务生命周期管理，它治理的服务通常是SOA服务。传统的SOA Governance包含四部分内容：
1.服务建模：验证功能需求与业务需求，发现和评估当前服务，服务建模和效能需求，开发治理规划。
2.服务组装：建立服务更新计划，建立和修改服务以满足所有业务需求，根据治理策略评估服务，批准组装完成。
3.服务部署：确保服务的质量，措施包括功能测试、效能测试和满足度测试，批准服务部署。
4.服务管理：在整个生命周期内管理和监控服务，跟踪服务登录档中的服务，根据服务质量等级协议（SLA）上报服务的效能KPI资料进行服务质量管理。
SOA Governance 工作原理图如下所示：
传统SOA Governance的主要缺点如下：
1.分散式服务框架的发展，内部服务框架需要统一，服务治理也需要适应新的架构，能够由表及里，对服务进行细粒度的管控。
2.微服务架构的发展和业务规模的扩大，导致服务规模量变引起质变，服务治理的特点和难点也随之发生变化。
3.缺少服务执行时动态治理能力，面对突发的流量高峰和业务冲击，传统的服务治理在响应速度、故障快速恢复等方面存在不足，无法更敏捷应对业务需求。
第二代分散式服务框架服务治理
分散式服务框架的服务治理定位：面向互联网业务的服务治理，聚焦在对内部采用统一服务框架服务化的业务执行态、细粒度的敏捷治理体系。
治理的物件：基于统一分散式服务框架开发的业务服务，与协议本身无关，治理的可以是SOA服务，也可以是基于内部服务框架私有协议开发的各种服务。
治理策略：针对互联网业务的特点，例如突发的流量高峰、网络延时、机房故障等，重点针对大规模跨机房的海量服务进行执行态治理，保障线上服务的高SLA，满足使用者的体验。常用的治理策略包括服务的限流降级、服务迁入迁出、服务动态路由和灰度释出等。
分散式服务框架典型的服务治理体系如下所示：
第三代云端微服务治理
随着云端计算的发展，Dev&Ops逐渐流行起来，基础设施服务化（IaaS）为大规模、批量流水线式软件交付提供了便利，AWS做为全球最大的云端计算解决方案提供商，在微服务云化开发和治理方面积累了非常多的经验，具体总结如下
全公司统一服务化开发环境，统一简单化服务框架（Coral Service）,统一执行平台，快速高效服务开发；所有后端应用服务化，系统由多项服务化元件构成。服务共享、原子化、重用。服务由小研发团队（2 Pizza Team）负责服务开发、测试、部署和治理，运维整个生命周期支撑。高度自动化和Dev&Ops支援，一键式服务部署和回退。超大规模支援：后台几十万个服务，成千上万开发者同时使用，平均每秒钟有1-2个服务部署。尝试基于Docker容器部署微服务。 8.服务治理是核心：服务效能KPI统计、告警、服务健康度管理、灵活的弹性伸缩策略、故障自动迁移、服务限流和服务降级等多种治理手段，保障服务高质量执行。
云端微服务治理架构设计
云端微服务治理架构设计的目标如下：
防止业务服务架构腐化：通过服务注册中心对服务强弱依赖进行分析，结合执行时服务呼叫链关系分析，梳理不合理的依赖和呼叫路径，优化服务化架构，防止程式码腐化。快速故障定界定位：通过Flume等分散式日志采集框架，实时收集服务呼叫链日志、服务效能KPI资料、服务界面日志、执行日志等，实时汇总和线上分析，集中储存和展示，实现故障的自动发现、自动分析和线上条件检索，方便运维人员、研发人员进行实时故障诊断。服务微管控：细粒度的执行期服务治理，包括限流降级、服务迁入迁出、服务超时控制、智慧路由、统一配置、优先级排程和流量迁移等，提供方法级治理和动态生效功能，通过一系列细粒度的治理策略，在故障发生时可以多管齐下，线上调整，快速恢复业务。服务生命周期管理：包括服务的上线审批、下线通知，服务的线上升级，以及线上和线下服务文件库的建设。灵活的资源排程：基于Docker容器，可以实现微服务的独立部署和细粒度的资源隔离。基于云端的弹性伸缩，可以实现微服务级别的按需伸缩和故障隔离。云端微服务治理架构设计云端微服务治理从架构上可以分为三层：
第一层：微服务治理展示层，它的实现为微服务治理Portal，主要面向系统运维人员或者治理人员，提供线上、配置化的治理界面。第二层：微服务治理SDK，向服务治理提供治理元资料、治理界面、以及客户端的治理类库。第三层：微服务治理服务实现层，微服务治理服务，通过服务注册中心，重新整理服务治理属性，同时通知服务提供者和消费者丛集各节点重新整理内存，使服务治理Portal下发的服务治理策略动态生效。1. 微服务治理Portal
微服务治理Portal是微服务治理的门户，它提供服务治理操作界面，供系统运维人员或者测试人员对线上执行的微服务进行动态治理，以保障服务的SLA。
Portal框架可以基于AngularJS等Web框架进行开发，它的门户界面如下所示：可以支援同时配置多个服务注册中心丛集，对不同的微服务丛集进行治理。
选择某个微服务丛集之后，就可以对该丛集的微服务进行治理，界面示例如下：
点选检视，可以检视微服务的状态，以及各种效能指标。点选治理，弹出选择选单，可以对选择的微服务进行相关的治理操作。
2. 微服务治理SDK
服务治理SDK层，它主要由如下几部分组成：
服务治理元资料：服务治理元资料主要包括服务治理实体物件，包括服务模型、应用模型、治理组织模型、使用者许可权模型、资料展示模型等。元资料模型通过Data Mapper和模型扩充套件，向上层界面遮蔽底层服务框架的资料模型，实现展示层和服务框架的解耦，元资料也可以用于展示界面的定制扩充套件；服务治理界面：服务治理Portal呼叫服务治理界面，实现服务治理。例如服务降级界面、服务流控界面、服务路由权重调整界面、服务迁移界面等。服务界面与具体的协议无关，它通常基于分散式服务框架自身实现，可以是Restful界面，也可以是内部的私有协议；服务治理客户端类库：由于服务治理服务本身通常也是基于分散式服务框架开发，因此服务治理Portal需要整合分散式服务框架的客户端类库，实现服务的自动发现和呼叫；呼叫示例：客户端SDK需要提供服务治理界面的引数说明、注意事项以及给出常用的呼叫示例，方便前端开发人员使用；整合开发指南：服务治理SDK需要提供整合开发指南，指导使用者如何在开发环境中搭建、整合和使用服务治理SDK。3. 线上服务治理
线上服务治理包含多种策略，例如：流量控制、服务降级、优先级排程等。微服务启动的时候，将XML或者注解的服务提供者或者消费者属性注册到服务注册中心，由运维人员通过服务治理Portal进行线上修改，注册中心通知服务提供者和消费者重新整理内存，动态生效。
下面就这几种典型的治理策略进行说明。
第一、流量控制
当资源成为瓶颈时，服务框架需要对消费者做限流，启动流控保护机制。流量控制有多种策略，比较常用的有：针对访问速率的静态流控、针对资源占用的动态流控、针对消费者并发连线数的连线控制和针对并行访问数的并发控制。
静态流控：主要针对客户端访问速率进行控制，它通常根据服务质量等级协定（SLA）中约定的QPS做全域性流量控制，例如订单服务的静态流控阈值为100 QPS，则无论丛集有多少个订单服务例项，它们总的处理速率之和不能超过100 QPS。动态流控：它的最终目标是为了保命，并不是对流量或者访问速度做精确控制。当系统负载压力非常大时，系统进入过负载状态，可能是CPU、内存资源已经过载，也可能是应用程序内部的资源几乎耗尽，如果继续全量处理业务，可能会导致长时间的Full GC、讯息严重积压或者应用程序宕机，最终将压力转移到丛集其它节点，引起级联故障。触发动态流控的因子是资源，资源又分为系统资源和应用资源两大类，根据不同的资源负载情况，动态流控又分为多个级别，每个级别流控系数都不同，也就是被拒绝掉的讯息比例不同。每个级别都有相应的流控阈值，这个阈值通常支援线上动态调整并发控制：针对执行绪的并发执行数进行控制，它的本质是限制对某个服务或者服务的方法过度消费，耗用过多的资源而影响其它服务的正常执行。并发控制有两种形式：针对服务提供者的全域性控制和针对服务消费者的区域性控制。连线控制：通常分散式服务框架服务提供者和消费者之间采用长连线私有协议，为了防止因为消费者连线数过多导致服务端负载压力过大，系统需要支援针对连线数进行流控。4. 服务降级
大促或者业务高峰时，为了保证核心服务的SLA，往往需要停掉一些不太重要的业务，例如商品评论、论坛或者粉丝积分等。
另外一种场景就是某些服务因为某种原因不可用，但是流程不能直接失败，需要本地Mock服务端实现，做流程放通。以图书阅读为例，如果使用者登入余额鉴权服务不能正常工作，需要做业务放通，记录消费话单，允许使用者继续阅读，而不是返回失败。
通过服务治理的服务降级功能，即可以满足上述两种场景的需求。服务降级主要包括遮蔽降级和容错降级两种策略：
遮蔽降级：当外界的触发条件达到某个临界值时，由运维人员/开发人员决策，对某类或者某个服务进行强制降级。它的处理流程如下所示：
第1步：运维人员以管理员身份登入服务治理控制台，管理员具备服务治理的全套许可权。
第2步：运维人员选择服务降级选单，在服务降级界面中选择遮蔽降级。
第3步：通过服务查询界面选择需要降级的服务，注意服务的分组和版本资讯，指定具体的降级策略：返回null、返回指定异常还是执行本地Mock界面实现。第4步：服务治理Portal通过服务注册中心客户端SDK，将遮蔽降级指令和相关资讯传送到服务注册中心。
第5、6步：服务注册中心接收到遮蔽降级讯息后，以事件的形式下分别群发给服务提供者丛集和服务消费者丛集。
第7步：服务消费者接收到遮蔽降级事件通知之后，获取相关内容，更新本地快取的服务订阅资讯。当发起远端服务呼叫时，需要与遮蔽降级策略做匹配，如果匹配成功，则执行遮蔽降级逻辑，不发起远端服务呼叫。
第8步：服务提供者丛集接收到遮蔽降级事件通知之后，获取相关内容，更新本地的服务释出快取资讯，将对应的服务降级属性修改为遮蔽降级。
第9步：操作成功之后，服务注册中心返回降级成功的应答讯息，由服务治理Portal界面展示。
第10步：运维人员查询服务提供者列表，检视服务状态。
第11步：服务注册中心返回服务状态为遮蔽降级状态。
容错降级：当非核心服务不可用时，可以对故障服务做业务逻辑放通，以保障核心服务的执行。容错降级的工作原理如下所示：
5. 服务优先级排程
当系统当前资源非常有限时，为了保证高优先级的服务能够正常执行，保障服务SLA，需要降低一些非核心服务的排程频次，释放部分资源占用，保障系统的整体执行平稳。
服务在释出的时候，可以指定服务的优先级，如果使用者没有指定，采用预设优先级策略，它的配置如下所示：
服务的优先级可以采用传统的低、中、高三级配置策略，每个级别的执行比例可以灵活配置，如下所示：
服务释出通过扩充套件priority属性的方式指定优先级，服务提供者将优先级属性注册到服务注册中心并通知消费者，由消费者快取服务的优先级，根据不同的优先级策略进行排程。服务治理Portal通过动态修改注册中心指定服务priority属性的方式，实现执行态动态调整微服务的优先级。
总结除了上面介绍的几种常用线上治理策略，比较重要的微服务治理策略还包括：
微服务超时控制：由于微服务呼叫通常使用RPC方式，是同步阻塞的，因此需要设定服务呼叫超时时间，防止对端长时间不响应导致的应用执行绪挂死。超时控制支援在服务端或者消费端配置，需要支援方法级超时控制。
微服务路由策略：负载均衡策略是服务治理的重要特性，分散式服务框架通常会提供多种负载均衡策略，同时支援使用者扩充套件负载均衡策略。常用的路由策略包括：
随机：采用随机算法进行负载均衡，通常在对等丛集组网中，随机路由算法讯息分发还是比较均匀的。轮循:按公约后的权重设定轮循比率，到达边界之后，继续绕接。服务呼叫时延：消费者快取所有服务提供者的服务呼叫时延，周期性的计算服务呼叫平均时延，然后计算每个服务提供者服务呼叫时延与平均时延的差值，根据差值大小动态调整权重，保证服务时延大的服务提供者接收更少的讯息，防止讯息堆积。一致性Hash:相同引数的请求总是发到同一个服务提供者，当某一台提供者宕机时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。粘滞连线:粘滞连线用于有状态服务，尽可能让客户端总是向同一提供者发起服务呼叫，除非该提供者宕机，再连线另一台。丛集容错策略：消费者根据配置的路由策略选择某个目标地址之后，发起远端服务呼叫，在此期间如果发生了远端服务呼叫异常，则需要服务框架进行丛集容错，重新进行选路和呼叫。丛集容错是系统自动执行的，上层使用者并不需要关心底层的服务呼叫过程。丛集容错和路由策略的关系如下所示：
常用的丛集容错策略如下：
Failover策略:服务呼叫失败自动切换策略指的是当发生RPC呼叫异常时，重新选路，查询下一个可用的服务提供者。通常可以配置失败切换的最大次数和间隔周期，以防止E2E服务呼叫时延过大。Failback策略：在很多业务场景中，消费者需要能够获取到服务呼叫失败的具体资讯，通过对失败错误码等异常资讯的判断，决定后续的执行策略，例如非幂等性的服务呼叫。Failcache策略:Failcache策略是失败自动恢复的一种，在实际专案中它的应用场景如下：- 服务有状态路由，必须定点发送到指定的服务提供者。当发生链路中断、流控等服务暂时不可用时，服务框架将讯息临时快取起来，等待周期T，重新发送，直到服务提供者能够正常处理该讯息。- 对时延要求不敏感的服务。系统服务呼叫失败，通常是链路暂时不可用、服务流控、GC挂住服务提供者程序等，这种失败不是永久性的失败，它的恢复是可预期的。如果消费者对服务呼叫时延不敏感，可以考虑采用自动恢复模式，即先快取，再等待，最后重试。-通知类服务。例如通知粉丝积分增长、记录界面日志等，对服务呼叫的实时性要求不高，可以容忍自动恢复带来的时延增加。Failfast策略：在业务高峰期，对于一些非核心的服务，希望只调用一次，失败也不再重试，为重要的核心服务节约宝贵的执行资源。此时，快速失败是个不错的选择。服务灰度释出：灰度释出是指在黑与白之间，能够平滑过渡的一种释出方式。AB test就是一种灰度释出方式，让一部使用者继续用A，一部分使用者开始用B，如果使用者对B没有什么反对意见，那么逐步扩大范围，把所有使用者都迁移到B上面来。灰度释出可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
基于微服务的多版本管理机制 灰度路由策略，即可实现基于业务规则的灰度释出。
多版本管理：服务上线之后，随着业务的发展，需要对功能进行变更，或者修复线上的BUG，服务升级之后，往往需要对服务做多版本管理。服务多版本管理是分散式服务框架的重要特性，它涉及到服务的开发、部署、线上升级和服务治理。
呼叫分组管理：可以对服务按照业务领域、部署的DC资讯、服务提供商等角度对微服务进行群组化管理，同群组之间的微服务可以自由呼叫，跨群组的微服务需要进行审批和授权，以实现不同分组之间的微服务隔离。不同分组之间可以有同名同界面的微服务的不同实现，分组资讯也是服务路由的一个因子。
全线上服务文件
相对于平台产品，业务服务的升级和修改非常频繁，传统依靠Java DOC进行界面说明和传递的方式，往往会因为缺乏文件建设或API DOC没有及时重新整理，导致消费者拿到的界面定义说明不准确。相比于没有文件，拿到过时、错误的API DOC文件对使用者的危害更大。
为了解决这个问题，需要建立服务文件中心，方便线上运维人员检视和多团队之间的协作，它的工作原理如下：
可以基于Swagger UI，构建微服务线上文件库，如下所示：
可以参考如下连结：https://github.com/swagger-api/swagger-ui
服务上线审批下线通知机制
当团队规模扩大之后，会划分成平台基线组、业务定制组等不同研发团队，一些团队甚至跨多地协同开发和运维。服务的上线和下线必须要严格管控起来，一旦不合格的服务上线并被消费者讯息，再想下线就非常困难了。
对于需要下线的服务管控也很重要，有些服务虽然呼叫频次不高，业务量也不大。但是如果贸然下线，很有可能导致依赖它的消费者业务呼叫失败，这会违反服务的SLA协定，给服务提供商造成损失。
服务的上线审批、下线通知机制需要建立完善起来，它的工作原理如下所示：
除了以上介绍的常用服务治理措施，线下服务治理还包括：1.业务的梳理、服务划分原则和方法论；2.服务跨团队协作流程、准则、工具和方法论；3.服务的界面相容性原则和规范；4.其它…线下服务治理依团队和业务不同，需求也不同，需要业务团队和服务框架团队长期梳理、实践和优化，才能够提升线下服务治理的效率，它的建设是个长期过程，并非一蹴而就。
云端自治理
微服务弹性伸缩
基于PaaS云化平台或者Docker容器服务，可以实现基于负载的微服务弹性伸缩。
基于PaaS平台部署微服务架构示例如下：
基于Docker容器部署微服务示例如下：
基于云的动态资源排程，可以实现微服务的弹性伸缩：基于CPU、内存、磁盘、网络带宽等资源占用率的弹性伸缩策略。当VM或者容器的资源占用达到设定的阈值之后，自动执行扩容策略，动态建立微服务的执行环境，部署并执行新的微服务例项。基于业务指标的弹性伸缩策略。例如微服务的平均时延、吞吐量、成功率等。
通过对微服务的效能指标进行分散式采集、汇总和计算，判断业务指标是否达到伸缩阈值，如果达到，则自动触发微服务的伸缩流程，执行弹性伸缩。使用者自定义的弹性伸缩策略。可以对基于资源占用率的伸缩策略和基于业务指标的伸缩策略做组合，实现更复杂的弹性伸缩。基于云平台的微服务弹性伸缩流程如下所示：
E2E微服务生命周期管理
利用云平台对资源的动态编排和排程，可以实现基础设施自动化。利用ALM（应用生命周期管理）可以实现微服务的E2E生命周期管理。
基于Docker容器的微服务基础设施自动化流程如下所示：
微服务上线执行之后，利用云平台的ALM服务，可以对微服务进行上下线、升级、回滚等生命周期管理操作：
基于云平台提供的微服务生命周期管理服务，可以实现海量微服务的高效部署、升级和管理，而不需要关心物理基础设施的环境准备和安装，以及资源规划等，极大的提升了微服务的上线执行效率，降低了微服务的管理成本。
微服务治理全景图
微服务治理涵盖的范围非常广，很多治理手段也需要业务在实际开发中积累和沉淀，并没有统一的标准，这就是实施微服务治理的困难之处。
在微服务治理发展的同时，云化和容器化革命也正在进行，结合云平台的敏捷性和弹性资源排程，微服务治理将逐步由人工治理向自动化治理演进。
微服务治理总体结构图如下所示：
感谢您的观看，喜欢的小伙伴可以点个赞！！！专注Java、大资料知识干货及相关领域动态分享，请多多关注哦！
