梦见钱被盗随着业务的发展，服务越来越多，如何协调线上运行的各个服务，保障服务的SLA，对服务架构和运维人员是一个很大的挑战。随着业务规模的不断扩大，小服务资源浪费等问题逐渐，需要能够基于服务调用的性能KPI数据进行容量管理，合理分配各个服务的资源占用，提高机器的利用率。线上业务发生故障时，需要对故障业务做服务降级、流量控制、流量迁移等，快速恢复业务。着开发团队的不断扩大，服务的上线越来越随意，甚至发生功能相同、服务名不同的服务同时上线。上线容易下线难，为了规范服务的上线和下线，在服务发布前，需要走服务预发布流程，由架构师或者项目经理对需要上线的服务做发布审核，审核通过的才能够上线。为了满足服务线下管控、保障线上高效运行，需要有一个统一的服务治理框架对服务进行统一、有效管控，保障服务的高效、健康运行。 大部分服务化框架的服务属性通过XML配置或者Java注解的方式进行定义，以服务端流量控制为例： 无论采用注解还是XML配置的方式，如果需要在运行态动态修改服务提供者的流控阈值，都需要在本地修改配置或者修改源码，重新打包部署并升级应用。无法实现在线、配置化的修改和动态生效。由于诸如流控阈值、服务的超时时间等无法预测出最优值，需要修改之后上线验证，根据服务运行效果决定是否再做调整，因此经常需要反复调整，采用修改源码-重新打包部署-应用升级的方式进行服务治理，效率低下。因此，在技术上需要一个服务治理框架，提供Web Portal，微服务运维或者治理人员通过在线配置化的方式修改服务提供者或者消费者的属性，可以实时动态生效。 以IBM为首的SOA解决方案提供商推出的针对企业IT系统的服务治理框架，它主要聚焦在对企业IT系统中异构服务的质量管理、服务发布审批流程管理和服务建模、开发、测试以及运行的全生命周期管理。第二代以分布式服务框架为中心的服务治理：随着电商和移动互联网的快速发展，基于电商平台的统一分布式服务框架的全新服务治理诞生，它聚焦于对内部同构服务的线上治理，保障线上服务的运行质量。相比于传统IT架构的服务治理，由于服务的开发模式、部署规模、组网类型、业务特点等差异巨大，因此服务治理的重点也从线下转移到了线上服务质量保障。 第三代以云化为核心的云端微服务治理架构：2013年至今，随着云计算和微服务架构的发展，以AWS为首的基于微服务架构 云服务化的云端服务治理体系诞生，它的核心是服务微自治，利用云调度的弹性和敏捷，逐渐消除人工治理。微服务架构可以实现服务一定程度的自治，例如服务打包、部署、升级和扩容。通过云计算的弹性伸缩、单点故障迁移、服务健康度管理和自动容量规划等措施，结合微服务治理，逐步实现微服务的自治。 第一代SOA Service GovernanceSOA Governance的定位：面向企业IT系统异构服务的治理和服务生命周期管理，它治理的服务通常是SOA服务。传统的SOA Governance包含四部分内容：1.服务建模：验证功能需求与业务需求，发现和评估当前服务，服务建模和性能需求，开发治理规划。2.服务组装：创建服务更新计划，创建和修改服务以满足所有业务需求，根据治理策略评估服务，批准组装完成。3.服务部署：确保服务的质量，措施包括功能测试、性能测试和满足度测试，批准服务部署。4.服务管理：在整个生命周期内管理和服务，服务注册表中的服务，根据服务质量等级协议（SLA）服务的性能KPI数据进行服务质量管理。SOA Governance 工作原理图如下所示： 传统SOA Governance的主要缺点如下：1.分布式服务框架的发展，内部服务框架需要统一，服务治理也需要适应新的架构，能够由表及里，对服务进行细粒度的管控。2.微服务架构的发展和业务规模的扩大，导致服务规模量变引起质变，服务治理的特点和难点也随之发生变化。3.缺少服务运行时动态治理能力，面对突发的流量高峰和业务冲击，传统的服务治理在响应速度、故障快速恢复等方面存在不足，无法更敏捷应对业务需求。 分布式服务框架的服务治理定位：面向互联网业务的服务治理，聚焦在对内部采用统一服务框架服务化的业务运行态、细粒度的敏捷治理体系。 治理的对象：基于统一分布式服务框架开发的业务服务，与协议本身无关，治理的可以是SOA服务，也可以是基于内部服务框架私有协议开发的各种服务。 治理策略：针对互联网业务的特点，例如突发的流量高峰、网络延时、机房故障等，重点针对大规模跨机房的海量服务进行运行态治理，保障线上服务的高SLA，满足用户的体验。常用的治理策略包括服务的限流降级、服务迁入迁出、服务动态由和灰度发布等。分布式服务框架典型的服务治理体系如下所示： 全公司统一服务化开发，统一简单化服务框架（Coral Service）,统一运行平台，快速高效服务开发；所有后端应用服务化，系统由多项服务化组件构成。 防止业务服务架构腐化：通过服务注册中心对服务强弱依赖进行分析，结合运行时服务调用链关系分析，梳理不合理的依赖和调用径，优化服务化架构，防止代码腐化。快速故障定界定位：通过Flume等分布式日志采集框架，实时收集服务调用链日志、服务性能KPI数据、服务接口日志、运行日志等，实时汇总和在线分析，集中存储和展示，实现故障的自动发现、自动分析和在线条件检索，方便运维人员、研发人员进行实时故障诊断。 微服务治理Portal是微服务治理的门户，它提供服务治理操作界面，供系统运维人员或者测试人员对线上运行的微服务进行动态治理，以保障服务的SLA。 点击查看，可以查看微服务的状态，以及各种性能指标。点击治理，弹出选择菜单，可以对选择的微服务进行相关的治理操作。 服务治理元数据：服务治理元数据主要包括服务治理实体对象，包括服务模型、应用模型、治理组织模型、用户权限模型、数据展示模型等。元数据模型通过Data Mapper和模型扩展，向上层界面屏蔽底层服务框架的数据模型，实现展示层和服务框架的解耦，元数据也可以用于展示界面的定制扩展；服务治理接口：服务治理Portal调用服务治理接口，实现服务治理。例如服务降级接口、服务流控接口、服务由权重调整接口、服务迁移接口等。服务接口与具体的协议无关，它通常基于分布式服务框架自身实现，可以是Restful接口，也可以是内部的私有协议； 线上服务治理包含多种策略，例如：流量控制、服务降级、优先级调度等。微服务启动的时候，将XML或者注解的服务提供者或者消费者属性注册到服务注册中心，由运维人员通过服务治理Portal进行在线修改，注册中心通知服务提供者和消费者刷新内存，动态生效。 当资源成为瓶颈时，服务框架需要对消费者做限流，启动流控机制。流量控制有多种策略，比较常用的有：针对访问速率的静态流控、针对资源占用的动态流控、针对消费者并发连接数的连接控制和针对并行访问数的并发控制。 静态流控：主要针对客户端访问速率进行控制，它通常根据服务质量等级协定（SLA）中约定的QPS做全局流量控制，例如订单服务的静态流控阈值为100 QPS，则无论集群有多少个订单服务实例，它们总的处理速率之和不能超过100 QPS。 它的最终目标是为了保命，并不是对流量或者访问速度做精确控制。当系统负载压力非常大时，系统进入过负载状态，可能是CPU、内存资源已经过载，也可能是应用进程内部的资源几乎耗尽，如果继续全量处理业务，可能会导致长时间的Full GC、消息严重积压或者应用进程宕机，最终将压力转移到集群其它节点，引起级联故障。触发动态流控的因子是资源，资源又分为系统资源和应用资源两大类，根据不同的资源负载情况，动态流控又分为多个级别，每个级别流控系数都不同，也就是被掉的消息比例不同。每个级别都有相应的流控阈值，这个阈值通常支持在线动态调整。 大促或者业务高峰时，为了核心服务的SLA，往往需要停掉一些不太重要的业务，例如商品评论、论坛或者粉丝积分等。 通过服务治理的服务降级功能，即可以满足上述两种场景的需求。服务降级主要包括屏蔽降级和容错降级两种策略： 它的处理流程如下所示：第1步：运维人员以管理员身份登录服务治理控制台，管理员具备服务治理的全套权限。 第7步：服务消费者接收到屏蔽降级事件通知之后，获取相关内容，更新本地缓存的服务订阅信息。当发起远程服务调用时，需要与屏蔽降级策略做匹配，如果匹配成功，则执行屏蔽降级逻辑，不发起远程服务调用。 第8步：服务提供者集群接收到屏蔽降级事件通知之后，获取相关内容，更新本地的服务发布缓存信息，将对应的服务降级属性修改为屏蔽降级。 当非核心服务不可用时，可以对故障服务做业务逻辑放通，以保障核心服务的运行。容错降级的工作原理如下所示： 服务在发布的时候，可以指定服务的优先级，如果用户没有指定，采用默认优先级策略，它的配置如下所示： 服务的优先级可以采用传统的低、中、高配置策略，每个级别的执行比例可以灵活配置，如下所示： 服务发布通过扩展priority属性的方式指定优先级，服务提供者将优先级属性注册到服务注册中心并通知消费者，由消费者缓存服务的优先级，根据不同的优先级策略进行调度。服务治理Portal通过动态修改注册中心指定服务priority属性的方式，实现运行态动态调整微服务的优先级。 负载均衡策略是服务治理的重要特性，分布式服务框架通常会提供多种负载均衡策略，同时支持用户扩展负载均衡策略。常用的由策略包括： 消费者根据配置的由策略选择某个目标地址之后，发起远程服务调用，在此期间如果发生了远程服务调用异常，则需要服务框架进行集群容错，重新进行选和调用。集群容错是系统自动执行的，上层用户并不需要关心底层的服务调用过程。集群容错和由策略的关系如下所示： Failover策略:服务调用失败自动切换策略指的是当发生RPC调用异常时，重新选，查找下一个可用的服务提供者。通常可以配置失败切换的最大次数和间隔周期，以防止E2E服务调用时延过大。 Failback策略：在很多业务场景中，消费者需要能够获取到服务调用失败的具体信息，通过对失败错误码等异常信息的判断，决定后续的执行策略，例如非幂等性的服务调用。 Failcache策略:Failcache策略是失败自动恢复的一种，在实际项目中它的应用场景如下：- 服务有状态由，必须定点发送到指定的服务提供者。当发生链中断、流控等服务暂时不可用时，服务框架将消息临时缓存起来，等待周期T，重新发送，直到服务提供者能够正常处理该消息。- 对时延要求不的服务。系统服务调用失败，通常是链暂时不可用、服务流控、GC挂住服务提供者进程等，这种失败不是永久性的失败，它的恢复是可预期的。如果消费者对服务调用时延不，可以考虑采用自动恢复模式，即先缓存，再等待，最后重试。-通知类服务。例如通知粉丝积分增长、记录接口日志等，对服务调用的实时性要求不高，可以自动恢复带来的时延增加。 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B来。灰度发布可以整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以其影响度。 调用分组管理：可以对服务按照业务领域、部署的DC信息、服务提供商等角度对微服务进行群组化管理，同群组之间的微服务可以调用，跨群组的微服务需要进行审批和授权，以实现不同分组之间的微服务隔离。不同分组之间可以有同名同接口的微服务的不同实现，分组信息也是服务由的一个因子。 相对于平台产品，业务服务的升级和修改非常频繁，传统依靠Java DOC进行接口说明和传递的方式，往往会因为缺乏文档建设或API DOC没有及时刷新，导致消费者拿到的接口定义说明不准确。相比于没有文档，拿到过时、错误的API DOC文档对使用者的危害更大。为了解决这个问题，需要建立服务文档中心，方便线上运维人员查看和多团队之间的协作，它的工作原理如下： 当团队规模扩大之后，会划分成平台基线组、业务定制组等不同研发团队，一些团队甚至跨多地协同开发和运维。服务的上线和下线必须要严格管控起来，一旦不合格的服务上线并被消费者消息，再想下线就非常困难了。 对于需要下线的服务管控也很重要，有些服务虽然调用频次不高，业务量也不大。但是如果贸然下线，很有可能导致依赖它的消费者业务调用失败，这会违反服务的SLA协定，给服务提供商造成损失。 除了以上介绍的常用服务治理措施，线.业务的梳理、服务划分原则和方；2.服务跨团队协作流程、准则、工具和方；3.服务的接口兼容性原则和规范；4.其它...线下服务治理依团队和业务不同，需求也不同，需要业务团队和服务框架团队长期梳理、实践和优化，才能够提升线下服务治理的效率，它的建设是个长期过程，并非一蹴而就。 微服务弹性伸缩基于PaaS云化平台或者Docker容器服务，可以实现基于负载的微服务弹性伸缩。基于PaaS平台部署微服务架构示例如下： 基于云的动态资源调度，可以实现微服务的弹性伸缩：基于CPU、内存、磁盘、网络带宽等资源占用率的弹性伸缩策略。当VM或者容器的资源占用达到设置的阈值之后，自动执行扩容策略，动态创建微服务的运行，部署并运行新的微服务实例。基于业务指标的弹性伸缩策略。例如微服务的平均时延、吞吐量、成功率等。通过对微服务的性能指标进行分布式采集、汇总和计算，判断业务指标是否达到伸缩阈值，如果达到，则自动触发微服务的伸缩流程，执行弹性伸缩。用户自定义的弹性伸缩策略。可以对基于资源占用率的伸缩策略和基于业务指标的伸缩策略做组合，实现更复杂的弹性伸缩。基于云平台的微服务弹性伸缩流程如下所示： 微服务上线运行之后，利用云平台的ALM服务，可以对微服务进行上下线、升级、回滚等生命周期管理操作： 基于云平台提供的微服务生命周期管理服务，可以实现海量微服务的高效部署、升级和管理，而不需要关心物理基础设施的准备和安装，以及资源规划等，极大的提升了微服务的上线运行效率，降低了微服务的管理成本。 在微服务治理发展的同时，云化和容器化也正在进行，结合云平台的敏捷性和弹性资源调度，微服务治理将逐步由人工治理向自动化治理演进。微服务治理总体结构图如下所示： Q1：请问在实际使用时，前端网关有什么来源框架，还有分布式系统，有推荐吗？A1: 前端网关，开源的有WSO2，基于Java语言的，GO语言的有Tyk。Q2:能展开讲一下优先级调度么 A1：分布式系统打印 埋点日志比较简单，但是复杂的是后端的大数据分析。采集可以基于FLume等，后端的分析可以基于HBase Spark 3、混合模式；4、业务自定义扩容策略，这种场景通常是级联扩容，也就是应用依赖的服务也需要同时做扩容，例如缓存、MQ等。但是，不是所有的PaaS都支持策略4。 A4: 不知道你讲的传统系统是不是指的非云系统。非云应用转到云化服务有几点设计考虑：1、服务化；2、利用云的动态性，例如弹性伸缩等；3、统一配置，使用云化的统一配置服务。 A5：包括前端的URL地址，MQ服务端的URL等，云化之后，MQ等服务也是一种云化服务，例如AWS的S3服务。在我们的实践中，原来的本地配置都统一放到了配置服务上，它是基于ZK的云化统一配置服务，地址都是从注册中心读取的，而不是本地配置。这样，就可以支持动态发现。 A6：几种场景考量：1、如果服务看中的是标准化、性，对性能要求不是特别苛刻。则采用 Restful JSON的方式；2、如果是内部各模块之间的服务化调用，对性能、时延要求非常高，则采用二进制 私有协议的方式，例如可以参考或者选择ProtocolBuf、Thrift等。通常而言，服务跟协议是解耦的，也就是说某个服务，可以同时发布成多种协议。
|