服务治理

作者：用友汽车信息科技（上海）有限公司 刘亚洲 Java研发工程师 一、sermant架构Sermant整体架构包含Sermant Agent、Sermant Backend、Sermant Injector、动静配置核心等组件。其中Sermant Agent是提供字节码加强根底能力及各类服务治理能力的外围组件，Sermant Backend、Sermant Injector、动静配置核心为Sermant提供其余能力的配套组件。 二、java agent和bytebuddy组合应用场景比拟典型的就是skywalking、sermant、arthas、mockito。如果说java agent开了一扇门，那么bytebuddy在开的这扇门中关上了一片新的天地。 三、Sermant的入口后面咱们说AgentLauncher是java agent的入口，为什么这么说呢？ <manifestEntries> <Premain-Class>com.huaweicloud.sermant.premain.AgentLauncher</Premain-Class> <Agent-Class>com.huaweicloud.sermant.premain.AgentLauncher</Agent-Class> <Can-Redefine-Classes>true</Can-Redefine-Classes> <Can-Retransform-Classes>true</Can-Retransform-Classes></manifestEntries>答案能够从pom.xml中找到答案，这里能够看到基于Premain-Class和Agent-Class的两个类都指向了AgentLauncher这个类。因而咱们能够十分确认的必定它就是javaagent入口类。相似于java程序有一个main的执行入口，而java agent有一个本人的入口类premain。 因而能够看到它的入口执行main： /** * premain * * @param agentArgs premain启动时携带的参数 * @param instrumentation 本次启动应用的instrumentation */public static void premain(String agentArgs, Instrumentation instrumentation) { launchAgent(agentArgs, instrumentation, false);}/** * agentmain * * @param agentArgs agentmain启动时携带的参数 * @param instrumentation 本次启动应用的instrumentation */public static void agentmain(String agentArgs, Instrumentation instrumentation) { launchAgent(agentArgs, instrumentation, true);}基于premain模式的和基于agent模式，区别在于是否为isDynamic。从这里咱们能够看到这里提出了两个类值得咱们去关注：AgentCoreEntrance、CommandProcessor，也即sermant这个我的项目的两个重点类。 更多须要理解的，能够参考byte-buddy这个开源我的项目。 ...

一、前言2023年，Sermant踊跃沉闷在开源社区的各个角落，您兴许在开源峰会、在大学校园、在线上直播、在开源社区的博客中看到过咱们的身影，兴许您的我的项目曾经在生产环境上曾经接入了Sermant。如果您还不理解Sermant，当初在浏览器搜寻框输出JavaAgent和服务治理，能够看到排名靠前的都是与Sermant相干的搜寻后果，因为咱们已深耕这片畛域。 Sermant是基于Java字节码加强技术的云原生无代理服务网格，2022年底，咱们在社区正式公布了1.0版本，宣告Sermant首个稳固的正式版本的面世。咱们以非侵入式地为业务利用提供服务治理性能为出发点，建设了Sermant我的项目的雏形。从开发效率、用户敌对等角度，咱们始终在构建和优化我的项目的框架和机制。1.0版本后的Sermant曾经具备了非侵入、高性能、插件化的外围劣势，并且开源生态中曾经提供了服务注册、标签路由、流量管制等插件能力来利用于典型的服务治理场景。同样在2022年底，Sermant 官网 也正式上线，以让开发者和用户更好地理解、应用、开发Sermant为指标，详尽地提供了Sermant的疾速入门、用户使用手册、开发者指南、博客分享等内容。另外,咱们还退出了CNCF LANDSCAPE ，在云原生Service Mesh畛域占据了一席之地。 2022年底是Sermant种下的种子刚刚发芽的阶段。2023年，Sermant在技术能力构建、开源生态构建、开源可信能力构建等方面减速投入，开始横蛮成长。 二、技术能力构建在公布1.0版本之后，Sermant始终放弃了较高的我的项目活跃度。2023年，Sermant公布了1.1、1.2、1.3三个大版本和若干个补丁版本，从框架类隔离机制、动静插拔Agent和插件、动静配置对接Nacos、服务和Agent的可观测性、流量治理能力、服务可用性治理能力等方面做了大幅的更新或加强。咱们心愿通过一直地版本更新迭代，将Sermant打造成一个易用性好、兼容性强、扩展性高、性能优良的一个开源我的项目，为社区带来极致的服务治理体验。 图 – Sermant最新1.3.0版本 Release Note 2.1 可观测性能力晋升 2023年，Sermant在对本身的可观测性上失去了重要的晋升，尤其是边车自观测能力以及字节码加强的观测能力。 2.1.1 Sermant自观测能力 针对可观测性，咱们建设了对Sermant运行状态及服务治理能力状态的监控机制，用户可能更直观，更清晰的看到Sermant进行服务治理的过程，可用于疾速理解Sermant运行状态及以后已失效的服务治理能力，使服务治理有迹可循。用户通过拜访Backend，可在前端页面间接看到Sermant运行状态，服务治理能力触发的事件以及Sermant服务运行期间产生的正告、谬误等日志信息。 Sermant的自观测能力解决了JavaAgent难以运维察看的问题，对应用Sermant来进行微服务治理的用户来说很好的实现了Agent的治理。 ![上传中...]() 图 – Sermant Backend页面展现Agent上报的信息 2.1.2 字节码加强成果的观测能力 另外，因为Sermant是基于字节码加强技术来实现的，咱们在字节码加强的可观测性上也做了晋升。第一种形式属于动态配置，启动宿主利用前，能够在配置文件中开启字节码加强日志打印的开关以及输入字节码加强后的class文件，能够直观地对加强后的类进行查看。第二种形式属于动静查看字节码加强信息，咱们在Sermant启动实现后，运行官网提供的AgentLoader，并传入参数下发查问加强信息的指令command=CHECK_ENHANCEMENT，即可在日志中查看到Sermant已执行的加强信息，包含挂载了哪些插件和加强了哪些类的办法。 2.2 框架能力晋升 在框架能力方面，2023年Sermant不仅全面优化了类隔离机制，也正式反对了Agent和插件的动静热插拔能力，对于实用宽泛的配置核心Nacos也实现了反对。 2.2.1 热插拔能力 Sermant最新版本目前反对premain和agentmain两种形式启动。agentmain启动形式能够反对Agent和插件的热部署形式，在故障注入等场景中能够在服务不停机状态下能够实现屡次动静注入和移除各类故障。另外，Sermant的插件也反对动静挂载和卸载。 下图为Sermant的热插拔能力的示意图，在初始状态能够通过动静挂载Agent的能力装置字节码加强框架，而后能够通过动静挂载/卸载插件的能力在运行态增减所需服务治理能力，也能够间接将整个Agent进行卸载。 图 – Sermant的热插拔机制 2.2.2 配置核心反对Nacos 动静配置核心为Sermant动静配置服务的配套组件，动静配置服务容许Sermant从动静配置核心拉取配置以实现丰盛多样的服务治理能力。以往版本Sermant的反对的动静配置核心有Zookeeper和Kie，新版本适配了Nacos的数据模型，反对从Nacos下发配置并监听。动静配置核心在Sermant中的角色和作用能够浏览相干博客《如何利用动静配置核心在JavaAgent中实现微服务的多样化治理》。 2.2.3 更好的类隔离能力 Sermant在1.2.0版本中对此前的类隔离框架和机制做了全面的优化，不仅保障了不向宿主服务引入类抵触问题，防止在开箱即用时对宿主服务造成负面影响，同时也了保障框架与插件、插件与插件之间不会引入类抵触问题，防止插件开发者因为和其余服务治理插件产生类抵触问题而苦恼。经验屡次迭代，现在Sermant的类隔离架构已能够轻松的应答各种简单的类加载环境。更具体的类隔离机制的介绍能够参阅相干博客《Sermant类隔离架构解析——解决JavaAgent场景类抵触的实际》。 2.3 服务治理能力晋升 在插件层面，2023年咱们对现有插件做了不少优化，例如流控插件引入基于零碎规定的流控能力以及基于负载的自适应流控能力；在标签路由插件对路由规定模型进行了对立和以及减少了链路染色能力。另外，Sermant还新增了流量标签透传插件、音讯队列禁止生产插件、离群实例摘除插件等，利用于服务治理的各个典型场景。各插件的介绍能够参考官网的[](https://sermant.io/zh/document/plugin)插件使用手册。 三、客户案例Sermant起源于华为云，目前在华为云外部的泛滥云服务中失去了宽泛的利用。 在微服务引擎CSE中，基于Sermant实现了非侵入接入服务注册发现、全链路灰度等性能，实现其余云厂商到华为云的微服务搬迁。该场景下用户在不批改业务代码的前提下，实现了搬迁工作，极大地升高了开发和运维老本。 在华为云混沌工程畛域中，实现了基于Sermant的故障注入、流量录制回放等能力。这是Sermant动静热插拔能力的典型实用场景。开发和运维人员能够在利用运行的过程中利用热插拔能力将包装了不同故障模式的插件热加载至业务过程中，以测试零碎的可靠性和稳定性。动静卸载能力的反对也使得咱们能够在一次运行测试中屡次注入各种故障。 在华为云CPTS云服务中，基于Sermant框架开发的全链路压测能力构建了零业务代码侵入的性能压测一体化平台的能力。不仅实现了流量染色的标记和传递，还反对内部服务mock转发、影子库、压测流量接入的对立管制等性能，为全链路压测平台提供了外围的根底能力。 此外，不少产品也曾经实现了将现有的SDK能力向Agent能力做迁徙，为服务治理性能提供了新的非侵入一键接入的抉择。 2023年Sermant在泛滥开源生态用户的实在场景中也实现了落地。某私域电商用户基于Sermant开源框架自研了若干插件，在监控、故障演练等场景中利用于600+生产环境实例中。某网约车平台在架构优化上，引入Sermant进行革新，实现服务的主动发现和API治理能力，从零散治理到对立管控，提供对立的微服务注册和治理核心。某汽车畛域用户应用Sermant开源仓库的服务注册插件实现了200+实例以零业务代码批改的形式从A云无损迁徙到B云。将来还有一些开源生态用户将基于Sermant将SDK能力逐渐向Agent革新，将服务治理能力对立收编至One Agent。这些例子充分证明Sermant在JavaAgent服务治理畛域能无效的为企业用户缩小服务治理能力的接入老本以及微服务架构的革新老本，并且企业用户还可自定义开发插件适配本身场景，将服务治理性能的粒度细化到插件中，按需引入相互隔离。 如果您也是Sermant的生态用户，欢迎您在咱们Github仓库的 issue中注销您的应用状况，一起打造凋敝的 Sermant 社区生态。咱们不仅会为您提供疾速反对和响应，建设专属反对渠道，帮忙您更高效地施行和落地 Sermant我的项目，也会依据公司的应用状况造成丰盛的 Sermant 案例库，帮忙企业进行落地实际宣传。 四、开源社区建设4.1 线下会议和流动 2023年5月底GOTC寰球开源技术峰会上，Sermant作为新锐我的项目首次在此类开源大会流动中亮相，在现场开设了流动展台并在峰会举办期间发表了快闪演讲，吸引许多开发者在Sermant展台和演讲台下围观。尔后，Sermant越来越频繁地在参加了各个线下开源交换会议及流动。例如，在国内开源畛域有着重要影响力的凋谢原子基金会举办的OAGS凋谢原子寰球开源峰会、ICT畛域的华为开发者大会、云原生畛域的顶级国内开源会议KubeCon China、汇聚泛滥开源大咖的CosCon中国开源年会等。咱们历经中国的东南西北方向，在北京、上海、成都、东莞停办开源展台和在分论坛分享议题，面对面地和宽广开发者进行线下交换，扩充了Sermant在开源、云原生、微服务治理、服务网格畛域的生态影响力。 ...

你好，我是程序员Alan. 在正式引入微服务的各个组件之前，先通过一个面试中常见的问答来理解服务治理的全貌。 面试官：都在说微服务须要治理，那你说说什么是服务治理？为什么须要治理？能够简略介绍一下吗？ Alan: 服务治理，也就是解决多个服务节点，组成集群的时候，产生的一些简单的问题。 咱们能够把集群看作是一个微型的城市，把路线看做是组成集群的服务，把行走在路线上的车当做是流量，那么服务治理就是对于整个城市道路的治理。 如果你新建了一条街道（相当于启动了一个新的服务节点），那么就要告诉所有的车辆 （流量）有新的路线能够走了；你敞开了一条街道，你也要告诉所有车辆不要从这条路走了，这就是服务的注册和发现。 咱们在路线上装置监控，监督每条路线的流量状况，这就是服务的监控。 路线一旦呈现拥挤或者路线须要培修，那么就须要临时关闭这条路线，由城市来对立调度 车辆，走不堵的路线，这就是熔断以及引流。 路线之间犬牙交错四通八达，一旦在某条路线上呈现拥挤，然而又发现这条路线从头堵到尾，阐明事变并不是产生在这条路线上，那么就须要从整体链路上来排查事变到底处在哪个地位，这就是分布式追踪。 不同路线上的车辆有多有少，那么就须要有一个警察来疏导，在某一个工夫走哪一条路会比拟快，这就是负载平衡。 站在伟人的肩膀上SpringCloud微服务实战—码闻强

监控治理应用步骤通过引入spring-boot-starter-actuator,能够应用SpringBoot提供利用监控和治理的性能.能够通过HTTP,JMX,SSH协定来进行操作,主动失去审计,衰弱及指标信息等 引入 spring-boot-starter-actuator通过http形式拜访监控端点可进行shutdown,POST提交,此端点默认敞开1.创立SpringBoot我的项目,引入web包,devtools包(我的项目热部署),Ops下的Actuator包2.配置文件management.security.enabled=false监控和治理端点端点名形容autoconfig所有主动配置信息auditevents审计信息beans所有Bean的信息configprops所有配置属性dump线程状态信息env以后环境信息health利用健康状况info以后利用信息metrics利用的各项指标mappings利用@RequestMapping映射门路shutdown敞开以后利用(默认敞开)trace追踪信息(最新的http申请)定制端点信息定制端点通过endpoints+端点名+属性名设置 批改端点id: endpoints.beans.id=mybeans开启近程利用敞开性能: endpoints.shutdown.enable=true敞开端点: endpoints.beans.enabled=false开启所需端点: endpoints.enabled=false(敞开所有端点拜访)endpoints.beans.enabled=true定制端点拜访门路: management.context-path=/manage(定制所有端点的拜访门路)endpoints.beans.path=/bean定制端点端口号: management.port=8989敞开http端点: management.port=-1 health端点查看连贯的利用配置的健康状况(status="up"/status="down")自定义衰弱状态指示器: 创立指示器类,实现HealthIndicator接口:Health.up().build()代表衰弱,Health.down().withDetail("msg","xxx").build()代表衰弱指示器的名字格局:xxxHealthIndicator标注@Component将指示器退出容器中

OCTO是美团外部的服务治理平台，蕴含服务通信框架、命名服务、服务数据中心和用户治理平台等组件，为公司内全副服务提供了整套的服务治理计划和对立的服务治理体验。咱们在之前的几篇文章中别离从不同的角度介绍了OCTO平台的建设状况。包含： 《美团命名服务的挑战与演进》介绍了美团命名服务（MNS）从1.0到2.0演进的初衷、实现计划以及落地的成果，并介绍了命名服务作为一个技术中台组件，对业务的重要价值以及推动业务降级的一些成绩。《美团OCTO万亿级数据中心计算引擎技术解析》介绍了美团自研的 OCTO数据中心计算引擎的演进历程及架构设计，同时具体地介绍其全面晋升计算能力、吞吐能力、升高运维老本所采纳的各项技术计划。《团大规模微服务通信框架及治理体系OCTO外围组件开源》介绍了OCTO的外围组件OCTO-RPC（JAVA通信框架）、OCTO-NS（命名服务）和OCTO-Portal（用户治理平台）的开源状况。《简单环境着落地Service Mesh的挑战与实际》从更高的视角介绍了美团以后的服务治理零碎的发展史、所面临的窘境和优化思路。对Service Mesh在美团大规模简单服务场景下的落地做了深刻的剖析。本文将持续介绍OCTO零碎在Service Mesh化演进方面的工作。次要从数据面的角度，具体介绍各项技术计划的设计思路。 1 整体架构咱们先看看OCTO 2.0的整体架构，如下图所示： 基础设施是指美团现有的服务治理零碎 OCTO1.0，包含MNS、KMS（鉴权治理服务）、MCC（配置管理核心）、Rhino（熔断限流服务）等。这些零碎接入到OCTO 2.0的管制立体，防止过多重构引入的不必要老本。 OCTO 2.0管制立体摒弃了社区的Istio，齐全自研。数据立体基于开源Envoy革新。运维零碎负责数据面组件的降级、公布等运维工作。更多的整体选型及起因可参考之前团队的文章: 《美团下一代服务治理零碎 OCTO2.0 的摸索与实际》。 对OCTO 2.0中的性能，咱们分为Mesh和服务治理两个维度，上面咱们来重点看下流量劫持、无损重启、服务路由等几个常见的问题，并论述美团是如何联合现有比较完善的服务治理零碎来解决这些问题的。 2 Mesh性能2.1 流量劫持OCTO 2.0并未采纳Istio的原生计划，而是应用iptables对进出POD的流量进行劫持。次要考量了以下两个因素： iptables本身存在性能损失大、管控性差的问题： iptables在内核对于包的处理过程中定义了五个“hook point”，每个“hook point”各对应到一组规定链，outbond流量将两次穿梭协定栈并且通过这5组规定链匹配，在大并发场景下会损失转发性能。iptables全局失效，不能显式地禁止相干规定的批改，没有相干ACL机制，可管控性比拟差。在美团现有的环境下，应用iptables存在以下几个问题： HULK容器为富容器状态，业务过程和其余所有根底组件都处于同一容器中，这些组件应用了各种各样的端口，应用iptables容易造成误拦挡。美团当初存在物理机、虚拟机、容器等多个业务运行场景，基于iptables的流量劫持计划在适配这些场景时复杂度较高。鉴于上述问题，咱们最终采纳了Unix Domain Socket直连形式来实现业务过程和OCTO-Proxy之间的流量转发。 在服务消费者一方，业务过程通过轻量的Mesh SDK和OCTO-Proxy所监听的UDS地址建设连贯。在服务提供者一方，OCTO-Proxy代替业务过程监听在TCP端口上，业务过程则监听在指定的UDS地址上。 该计划的长处是Unix Domain Socket相比于iptable劫持领有更好的性能和更低的运维老本。毛病是须要Mesh SDK的反对。 2.2 服务订阅原生Envoy的CDS/EDS申请是全量服务发现模式，行将零碎中所有的服务列表都申请到数据面中。因为大规模集群中服务数量太多，真正所需的只是多数服务，所以须要革新成按需服务发现模式，仅申请须要拜访的后端服务的节点列表。 在业务过程启动后，须要通过HTTP的形式向OCTO-Proxy发动订阅申请。OCTO-Proxy将所申请的后端服务Appkey更新到XDS中，XDS再向管制面申请特定的服务资源。 为了减少整个过程中的健壮性，升高后续运维老本，咱们做了局部适配。例如，OCTO-Proxy的启动速度有可能慢于业务过程，所以在Mesh SDK中减少了申请的重试逻辑；将Mesh SDK和OCTO-Proxy之间的http申请革新成了同步申请，避免Pilot资源下发延时带来的问题；Mesh SDK的订阅信息也会保留在本地文件中，以便OCTO-Proxy热重启或者故障重启时应用。 2.3 无损热重启2.3.1 流量损失场景如何在根底组件降级过程中提供继续、不间断的服务，做到业务流量无损及业务无感知，是所有根底组件面临的一大难题。这个问题对于OCTO-Proxy这种处于流量外围链路上的组件更加重要。社区原生的Envoy本身曾经反对了热重启性能但并不彻底，在某些场景下还是不能做到齐全的流量无损。 下图别离在短连贯和长连贯两种场景下来阐明OCTO-Proxy热重启时的流量损耗问题。 对于短连贯，所有新的连贯会在新的OCTO-Proxy上创立，旧OCTO-Proxy上已有的连贯在响应到来后被动断开。旧OCTO-Proxy的所有短连贯逐步断开，这就是“Drain”（排空）的过程。连贯排空之后，旧OCTO-Proxy被动退出，新的OCTO-Proxy持续工作。整个过程中的流量，齐全无损。 对于长连贯形式，SDK和旧OCTO-Proxy维持一条长连接不断开，并继续应用该连贯发送申请。旧OCTO-Proxy过程最终退出时，该连贯被动断开，此时可能尚有局部响应未返回，导致Client端申请超时。因而，Envoy的热重启对长连贯场景的反对并不完满。 为了反对根底组件在降级过程中提供不间断的服务，业界目前次要应用的是滚动公布（Rolling Update）的形式：服务器分批进行服务，执行更新，而后从新将其投入使用，直到集群中所有实例都更新为新版本。在此过程中会被动摘掉业务流量，保障降级过程中业务流量不失落。 美团外部因为要兼容物理机、虚拟机、容器，业界云原生应用K8s滚动降级的形式不太实用，所以在现有环境下，如何保障服务治理零碎的高可用性以及业务的高可靠性是一个十分辣手的事件。 2.3.2 适配计划以后计划是把业务服务分为两种角色，即对外提供服务的Server端角色和对外发动申请的Client端角色，针对两种不同的角色采纳不同的热更新反对。 Client端OCTO-Proxy热更新：老的OCTO-Proxy在进入热重启状态后，对后续“新申请”间接返回含“热重启”标记的响应协定，Client SDK在收到含“热重启”标记的响应协定时，应被动切换新连贯并申请重试（以防止以后Client SDK持有的旧连贯因为旧OCTO-Proxy热重启流程实现后被被动敞开的问题）。这里须要留神，Client SDK须要“妥善”解决旧连贯所在链路上遗留的所有“应答”协定。 通过这种Client SDK和OCTO-Proxy间的交互配合，能够反对Client端在OCTO-Proxy降级过程中保障流量的安全性。 Server端OCTO-Proxy热更新：Server侧OCTO-Proxy在热重启开始后，即会被动向Client侧OCTO-Proxy发送ProxyRestart音讯，告诉Client侧OCTO-Proxy被动切换新连贯，防止以后Client侧OCTO-Proxy持有的旧连贯因为Server侧旧OCTO-Proxy热重启流程实现后被强制敞开的问题。Client端OCTO-Proxy在收到“被动切换新连贯”的申请后，应即时从可用连接池中移除，并“妥善”解决旧连贯所在链路上遗留的所有“应答”协定（激进起见可标记连贯不可用，并维持一段时间，比方OCTO-Proxy默认drainTime）。 2.4 数据面运维2.4.1 LEGO运维计划云原生环境中，Envoy运行在规范的K8S Pod中，通常会独立出一个Sidecar容器。能够应用K8s提供的能力来实现对Envoy Sidecar容器的治理，例如容器注入、健康检查、滚动降级、资源限度等。 ...

文章来源：http://www.liangsonghua.me作者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、JAVA高级、微服务架构 一、容错的必要性假设单体应用可用率为99.99%,即使拆分后每个微服务的可用率还是保持在99.99%，总体的可用率还是下降的。因为凡是依赖都可能会失败，凡是资源都是有限制的，另外网络并不可靠。有可能一个很不起眼的微服务模块高延迟最后导致整体服务不可用 二、容错的基本模块1、主动超时，一般设置成2秒或者5秒超时时间2、服务降级，一般会降级成直接跳转到静态CDN托底页或者提示活动太火爆，以免开天窗3、限流，一般使用令牌机制限制最大并发数4、隔离，对不同依赖进行隔离，容器CPU绑核就是一种隔离措施5、弹性熔断，错误数达到一定阀值后，开始拒绝请求，健康检查发现恢复后再次接受请求三、Hystrix主要概念Hystrix流程 想要使用Hystrix，只需要继承HystrixCommand或者HystrixObservableCommand并重写业务逻辑方法即可，区别在于HystrixCommand.run()返回一个结果或者异常，HystrixObservableCommand.construct()返回一个Observable对象 编者按：关于反应式编程可参考文章Flux反应式编程结合多线程实现任务编排 Hystrix真正执行命令逻辑是通过execute()、queue()、observe()、toObservable()的其中一种,区别在于execute是同步阻塞的，queue通过myObservable.toList().toBlocking().toFuture()实现异步非阻塞，observe是事件注册前执行，toObservable是事件注册后执行,后两者是基于发布和订阅响应式的调用 每个熔断器默认维护10个bucket,每秒一个bucket,每个bucket记录成功,失败,超时,拒绝的状态，默认错误超过50%且10秒内超过20个请求才进行中断拦截。当断路器打开时，维护一个窗口，每过一个窗口时间，会放过一个请求以探测后端服务健康状态，如果已经恢复则断路器会恢复到关闭状态 当断路器打开、线程池提交任务被拒绝、信号量获得被拒绝、执行异常、执行超时任一情况发生都会触发降级fallBack,Hystrix提供两种fallBack方式，HystrixCommand.getFallback()和HystrixObservableCommand.resumeWithFallback() 四、线程和信号量隔离 1、线程隔离，针对不同的服务依赖创建线程池2、信号量隔离，本质是一个共享锁。当信号量中有可用的许可时，线程能获取该许可(seaphore.acquire()),否则线程必须等待，直到有可用的许可为止。线程用完必须释放(seaphore.release())否则其他线程永久等待 五、Hystrix主要配置项 六、使用1、请求上下文，下面将要提到的请求缓存、请求合并都依赖请求上下文，我们可以在拦截器中进行管理 public class HystrixRequestContextServletFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HystrixRequestContext context = HystrixRequestContext.initializeContext(); try { chain.doFilter(request, response); } finally { context.shutdown(); } }}2、请求缓存，减少相同参数请求后端服务的开销，需要重写getCacheKey方法返回缓存key public class CommandUsingRequestCache extends HystrixCommand<Boolean> { private final int value; protected CommandUsingRequestCache(int value) { super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")); this.value = value; } @Override protected Boolean run() { return value == 0 || value % 2 == 0; } @Override protected String getCacheKey() { return String.valueOf(value); }}3、请求合并。请求合并在Nginx静态资源加载中也很常见,Nginx使用的是nginx-http-concat扩展模块。但是在Hystric中请求合并会导致延迟增加，所以要求两者启动执行间隔时长足够小，减少等待合并的时间，超过10ms间隔不会自动合并 ...

本文我们重点讨论如何构建一个有效的服务治理平台，话不多说，直接切入整体。构建服务治理平台基于“管理”，“度量”，“管控”三个层面统筹考虑安排。具体来讲，又可以分为六个层次来考虑问，分别是：服务管理流程体系，服务治理平台，服务治理核心架构，服务协议规范，服务支撑工具，服务运行环境。六个层面的具体关系如下图所示： 接下来我们分别来看一下每个层面的具体内容。 01 服务治理框架 当下无论对于什么样类型的服务治理核心框架，无论是开源还是自建，在功能层面相差不大，但技术实现却有所差别。但就落地实践而言，自建难度远大于依赖现有的开源项目。因此本次重点基于开源项目考虑，构建服务治理核心框架选型考虑主要涉及三个因素：开发人员知识储备，业务/应用要求，当下行业的技术趋势。目前来讲主要服务治理核心框架的选型有三个：spring-cloud框架，dubbo框架以及service mesh框架。具体框架对比，后续会有详细分析。 02 服务协议规范 服务协议规范具体而言细分服务接口，服务集成，服务模板，数据规范四个层面。 服务接口考虑接口类型以及与之相关的接口协议，例如http协议，或者rpc协议等。 服务集成重点考虑集成过程中的统一协议，通信方式。 服务模板框架主要说明开发服务需要的统一模板信息，框架信息。 数据规范需要依赖明确的命名规范以及数据请求格式规范，以方便服务治理过程中的信息处理。 03 服务支撑工具 服务治理的支撑功能可以划分为三个层次：治理支撑服务，功能支撑服务，线下支撑服务。 治理支撑服务包括服务注册/发现，流量控制，容错熔断，服务升级/回滚，链路跟踪，路由分发，超时重试，智能恢复等支撑工具集成。 功能支撑服务包括监控告警，日志服务，认证鉴权，计量计费，消息服务，负载均衡，持久化服务，网管服务等支撑工具。 线下支撑服务包括DevOps流程支撑服务，运行环境支撑。 04 服务运行环境 当下服务运行环境具体而言，包括物理运行环境，容器运行环境，mesh运行环境。服务治理平台需要支撑不同的运行环境。 05 服务治理门户 服务治理门户构建从五个层面考虑，包括数据采集，存储仓库，工具聚合，综合分析，服务门户。 服务门户以业务/应用/服务作为门户的组织方式，实现分析、管控、统计三维一体控制平台。 综合分析依赖处理后服务指标，集成数据，可视化呈现当下服务状态以及预测某一阶段服务状态。 工具聚合服务支撑工具保证服务生态的完整性，并能够管理、记录、反馈服务状态。 存储仓库存储采集的日志，性能，链路等与服务相关的数据。 数据采集是指proxy + agent通过拦截/旁路监测方式获取链路或者服务数据，并能够上报到存储仓库。 06 服务管理流程体系 最后服务治理平台应该构建在一定的服务管理流程体系之下，符合一定的服务管理流程规范。

背景应用微服务化场景下，随着服务个数的增加，服务之间的相互调用变得更加复杂，服务治理需求愈加突出，其中服务流量控制是服务治理中的重要一环。 当前常用的流量控制方案主要有基于Spring Cloud的Hystrix和阿里开源的Sentinel应用流量控制降级方案。客观而言，两个方案都是侵入式的，要求用户在应用中引入相关包，编写相关逻辑。 UAVStack作为一套智能化服务技术栈，其服务治理（UAV.ServiceGovern）模块提供了基于画像的服务注册与发现、服务访问授权及服务流量控制能力。 本文主要介绍UAVStack的无侵入式服务流量限制及降级方案。安装UAV后，通过页面配置即可用实现常用的QPS限流等。 一、限流模型 图1限流模型 UAV服务治理流量控制采用上图所示的漏斗+能力池限流模型。将应用根据UAV画像抽象出三层，分别是应用层（应用实例层）、服务组件层和URL层。每一层均可以添加多个限流策略，多个限流策略以“且”的关系存在。请求呈漏斗状依次进入URL层限流、服务组件层限流、应用层限流，只有通过三层限流后才能进入应用。 应用层（应用实例层）：应用层代表当前应用实例整体，应用层限流即限制进入当前应用的总流量。应用层限流流量为服务组件层和URL层流量上限；服务组件层：服务组件层是应用下所有服务组件的集合，包含一个或多个服务组件。可以针对每个服务组件配置不同的限流和降级策略，每个服务组件包含0个或多个URL；URL层：URL层包含所有服务URL。URL层限流即限制进入具体URL的流量。流量控制的目标不是仅仅限制QPS，还要限制对系统资源的使用。服务能力池描述当前应用或组件对外提供的服务能力的上限，该上限为池的最大容量；由于不同的请求消耗的系统资源不一样，因此每种类型的请求将会被赋予不同的权重值。重的请求消耗更多系统资源，将被赋予更大的权重值，而轻的请求赋予较小的权重值。每个请求都会根据权重值消耗服务能力池中的能力，重的请求比轻的请求消耗得服务能力多。无法从服务能力池中获取足够的服务能力时，便会触发降级策略。 二、关键技术2.1 MOF中间件劫持MOF(MonitorFramework)中间件劫持为UAV服务治理中流量控制提供基础支撑。主要提供以下几方面的支撑： 请求捕获：捕获所有进入应用容器的请求，并将请求转入限流模型处理流程，实现流量控制和请求降级；流量控制策略配置：基于MOF提供的基础能力实现流量控制策略配置、当前限流状态查询/开启/关闭等热控制。2.2 限流器和降级策略UAV服务治理默认支持两种限流器：时间段计数限流器和基于令牌桶算法的服务能力限流器。 时间段计数限流器通过原子量累计时间段内请求个数。当请求个数超过限制总数时，执行降级策略。默认的降级策略是终止请求处理流程，返回TOO_MANY_REQUEST。UAV服务治理支持开发和配置自定义的降级策略。 基于令牌桶算法的服务能力限流器会随着时间变化按恒定时间间隔(1/QPS，如果QPS=100,则间隔是10ms)向服务能力池中里补充，直至将能力池填满。出现新请求时，会根据当前请求权重值N拿走N个Token；如果没有足够的Token可取，则会阻塞或拒绝请求，从而执行拒绝策略。基于令牌桶算法的服务能力限流器也支持开发和配置自定义的降级策略。 UAV服务治理不仅支持自定义降级策略，也支持自定义限流器，满足不同用户的不同需求。 三、功能展示3.1 限流策略配置树页面根据应用画像以配置树形将应用展示为三层：应用实例层、服务组件层、URL组件层。如图2所示，应用实例层节点代表当前应用实例（仅有一个）；服务组件节点代表当前应用下的某一具体服务组件，如RS服务组件，每个服务组件下可能包含0个或多个URL节点；一个URL节点代表应用对外提供的服务的具体URL。 流量控制策略可以配置在三层中的任意节点上。配置在应用实例层节点可以限制进入整个应用的流量；配置在服务组件节点上可以控制当前服务组件下所有URL的流量；配置在URL节点上可以限制访问当前URL的流量。 图2 应用配置树 3.2 策略配置及策略下发策略配置中主要配置限流器、限流器参数、降级策略及降级策略参数。默认限流器是基于令牌桶算法的服务能力限流器，URL节点需要配置限流阈值和当前节点的请求权重值。请求超过阈值时，默认降级策略会返回TOO_MANY_REQUEST。 图3 策略配置 配置策略完成，通过策略下发按钮将策略下发至目标应用，同时展示当前实时限流状态。 图4 策略下发结果状态展示 3.3 限流效果及性能展示图5为极简应用（接收到请求后直接返回）场景下的测试结果，包括在压力不断增强的情况下应用原生吞吐量（红线）、安装UAV不启用限流的吞吐量（黑线）、安装UAV限流900QPS时应用接收到的请求量（限流900整体，蓝线）、限流900QPS时正常处理的请求量（橙线，限流900正常请求）及限流900QPS时拒绝的请求量（绿线，限流900限流请求）。 图5 应用吞吐量测试 从图5中可以看出，对比原生和安装UAV无限流情况，UAV限流对应用的吞吐量影响比较小，基本可以忽略不计。随着请求量的增加，进入应用的正常请求量（橙线）稳定在900左右，被限流的请求量随着整体请求量增加而增加，且与未被限流的请求量之和为整体请求量，表明UAV限流有效。另一方面，随着请求量的增加，在原生和无限流的情况下，应用吞吐量在1500左右达到上限；但在限流900QPS的情况下，应用请求量一直在增加，因为超出的请求被直接拒绝，没有进入应用中，从侧面体现了UAV限流对应用的保护能力。 图6为极简应用场景的测试结果，为应用在压力不断增强的情况下的平均响应时间。在原生和无限流情况下（红线和黑线），应用的平均响应时间随着压力增大而增加，最终在1300左右时大幅增加，说明应用的服务能力已经接近极限；在UAV限流900QPS的情况，正常请求（橙线）的平均响应时间即使超过1300达到2100时也基本保持稳定，被拒绝的请求的平均响应时间未见大幅变动，应用服务器的平均响应时间也基本保持稳定。UAV限流对应用实现了有效保护。 图6 应用平均响应时间测试 总结服务治理是微服务化场景下的一个重要问题。本文仅简单介绍UAV服务治理中服务端限流部分原理和功能展示。由于篇幅有限，暂不详细展开介绍。大家有兴趣可以继续关注UAVStack公众号或申请加入官方微信群，相信您一定会有所收获。 官方网站：https://uavorg.github.io/main/ 开源地址：https://github.com/uavorg UAVStack已在Github上开放源码，并提供了安装部署、架构说明和用户指南等双语文档，欢迎访问-给星-拉取~~~ 作者：曾礼 原文发布于：UAVStack智能运维