|
摘要：随着业务的发展,规模扩大，服务越来越多，需要协调线上运行的各个服务，保障服务的SLA;基于服务调用的性能KPI数据进行容量管理，合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移等快速恢复业务。怎样的服务治理框架能满足需求？
我今天分享的主题是《微服务治理的技术演进和架构实践》 本次分享，将分为三个部分。
为什么需要服务治理？ 第一、业务需求 随着业务的发展，服务越来越多，如何协调线上运行的各个服务，保障服务的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做为全球最大的云计算解决方案提供商，在微服务云化开发和治理方面积累了非常多的经验，具体总结如下
8.服务治理是核心：服务性能KPI统计、告警、服务健康度管理、灵活的弹性伸缩策略、故障自动迁移、服务限流和服务降级等多种治理手段，保障服务高质量运行。 云端微服务治理架构设计 云端微服务治理架构设计的目标如下：
云端微服务治理架构设计云端微服务治理从架构上可以分为三层：
1. 微服务治理Portal 微服务治理Portal是微服务治理的门户，它提供服务治理操作界面，供系统运维人员或者测试人员对线上运行的微服务进行动态治理，以保障服务的SLA。 Portal框架可以基于AngularJS等Web框架进行开发，它的门户界面如下所示：可以支持同时配置多个服务注册中心集群，对不同的微服务集群进行治理。 选择某个微服务集群之后，就可以对该集群的微服务进行治理，界面示例如下： 点击查看，可以查看微服务的状态，以及各种性能指标。点击治理，弹出选择菜单，可以对选择的微服务进行相关的治理操作。 2. 微服务治理SDK 服务治理SDK层，它主要由如下几部分组成：
3. 线上服务治理 线上服务治理包含多种策略，例如：流量控制、服务降级、优先级调度等。微服务启动的时候，将XML或者注解的服务提供者或者消费者属性注册到服务注册中心，由运维人员通过服务治理Portal进行在线修改，注册中心通知服务提供者和消费者刷新内存，动态生效。 下面就这几种典型的治理策略进行说明。 第一、流量控制 当资源成为瓶颈时，服务框架需要对消费者做限流，启动流控保护机制。流量控制有多种策略，比较常用的有：针对访问速率的静态流控、针对资源占用的动态流控、针对消费者并发连接数的连接控制和针对并行访问数的并发控制。
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方式，是同步阻塞的，因此需要设置服务调用超时时间，防止对端长时间不响应导致的应用线程挂死。超时控制支持在服务端或者消费端配置，需要支持方法级超时控制。 微服务路由策略：负载均衡策略是服务治理的重要特性，分布式服务框架通常会提供多种负载均衡策略，同时支持用户扩展负载均衡策略。常用的路由策略包括：
集群容错策略：消费者根据配置的路由策略选择某个目标地址之后，发起远程服务调用，在此期间如果发生了远程服务调用异常，则需要服务框架进行集群容错，重新进行选路和调用。集群容错是系统自动执行的，上层用户并不需要关心底层的服务调用过程。集群容错和路由策略的关系如下所示：
常用的集群容错策略如下：
服务灰度发布：灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。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服务，可以对微服务进行上下线、升级、回滚等生命周期管理操作：
基于云平台提供的微服务生命周期管理服务，可以实现海量微服务的高效部署、升级和管理，而不需要关心物理基础设施的环境准备和安装，以及资源规划等，极大的提升了微服务的上线运行效率，降低了微服务的管理成本。 微服务治理全景图
微服务治理涵盖的范围非常广，很多治理手段也需要业务在实际开发中积累和沉淀，并没有统一的标准，这就是实施微服务治理的困难之处。 在微服务治理发展的同时，云化和容器化革命也正在进行，结合云平台的敏捷性和弹性资源调度，微服务治理将逐步由人工治理向自动化治理演进。 微服务治理总体结构图如下所示：
Q&A Q1：请问在实际使用时，前端网关有什么来源框架，还有分布式跟踪系统，有推荐吗？ A1: 前端网关，开源的有WSO2，基于Java语言的，GO语言的有Tyk。 Q2:能展开讲一下优先级调度么 A1：分布式跟踪系统打印 埋点日志比较简单，但是复杂的是后端的大数据分析。采集可以基于FLume等，后端的分析可以基于HBase Spark Q3:请教一下，对应用层扩容很容易，很多时候一个服务慢了，根本原因是依赖的存储 数据库 外部接口的原因，这个时候对应用层扩容解决不了问题，paas的扩容还有什么意义呢？数据库扩容 涉及数据迁移，应用层连接池更新等等 paas不能简单扩容 A3：PaaS层的扩容通常会有几种策略： 1、基于资源使用率的扩容； 2、基于服务性能指标的扩容； 3、混合模式； 4、业务自定义扩容策略，这种场景通常是级联扩容，也就是应用依赖的服务也需要同时做扩容，例如缓存、MQ等。但是，不是所有的PaaS都支持策略4。 Q4:怎样从传统的系统转化到云服务上，在系统设计及技术架构有什么需要注意点。 A4: 不知道你讲的传统系统是不是指的非云系统。非云应用转到云化服务有几点设计考虑：1、服务化；2、利用云的动态性，例如弹性伸缩等；3、统一配置，使用云化的统一配置服务。 Q5：那mq 缓存 数据库的client都要改造 支持后端自动发现了，好多中间价的client都是配置死的，有可分享的开源实现么 A5：包括前端的URL地址，MQ服务端的URL等，云化之后，MQ等服务也是一种云化服务，例如AWS的S3服务。在我们的实践中，原来的本地配置都统一放到了配置服务上，它是基于ZK的云化统一配置服务，地址都是从注册中心读取的，而不是本地配置。这样，就可以支持动态发现。 Q6：应用服务化后，涉及服务与服务之间的远程rpc，请问数据传输过程中一般采用哪种系列化方式，之间的优缺点都有哪些？还有场景 A6：几种场景考量：1、如果服务看中的是标准化、开放性，对性能要求不是特别苛刻。则建议采用 Restful JSON的方式；2、如果是内部各模块之间的服务化调用，对性能、时延要求非常高，则建议采用二进制 私有协议的方式，例如可以参考或者选择ProtocolBuf、Thrift等。通常而言，服务跟协议是解耦的，也就是说某个服务，可以同时发布成多种协议。 |
|
|
