服务治理

作者：用友汽车信息科技（上海）有限公司 刘亚洲 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容器的治理，例如容器注入、健康检查、滚动降级、资源限度等。 ...