企业微服务治理的解决思路

Posted 2023-03-29 synuwxy

背景

随着业务需求的日渐复杂以及产品迭代节奏的不断加快，业务开发部门面临着前所未有的压力。为了抢占先机，用最快的速度准确把握用户需求的变化，优化开发出来的业务产品，微服务(MicroServices)架构技术在各大企业不断生根发芽。

微服务架构可以极大的降低业务的复杂性。开发和部署相对大单体架构而言更加简单，单个微服务的功能可以更快地更改，启动和调试单个微服务的时间成本相比于单体应用也大大减少。普遍而言，微服务架构具备以下优点：

• 将业务分而治之，降低业务复杂性，让业务易于理解、修改和维护
• 模块化部署，修改代价小，迭代速度快，有很好的扩展性
• 更好的容错性，业务服务各司其职，单点故障不易影响全局

然而微服务架构并非没有代价，就如软件工程中没有真正的银弹。

原来在单体架构时，所有的逻辑都在一个服务内处理，方法和方法之间是进程内部的调度方式，然而采用微服务架构之后，服务与服务之间需要通过网络相互沟通，一个业务的实现往往是多个服务的共同作用下完成，由此带来了一系列的问题。

企业微服务化面临的挑战

复杂的网络通信提升了故障出现的概率

在微服务架构体系中，服务与服务之间需要通过网络相互沟通，意味着研发人员在原本的业务逻辑之外，还需要额外考虑网络通信相关的问题。比如服务在向其上游服务发起请求时需要对上游服务的各种意外响应做出处理，常见的有401错误，404错误，500错误，503错误等。此外还涉及到对网络延迟，网络故障等环境问题做出处理。

一旦研发人员不能妥善处理这些网络通信带来的意外情况，随着微服务数量的不断变多，故障的风险概率将会随之增大，进而影响系统的整体稳定性。

海量的微服务加大了故障排查的难度

随着业务的发展，微服务之间的沟通关系开始变得复杂，一个业务的实现往往是途径了很多个微服务，然而冗长的调用链带来的是数倍增长的排错难度。

举个例子：一个业务需要经过10个微服务的逻辑处理才能返回最终结果，某一个时间段依据用户反馈，这个业务已经无法正常运转，此时研发人员需要地毯式排查每一个经过的业务服务，才能准确的知道故障源。

故障定位一直以来都是一件麻烦事，在微服务架构下排错更是需要支付高昂的成本。

当故障出现时难以确定影响范围

虽然在微服务架构下，单点故障难以对系统造成整体上的破坏，但业务从来都不是独立完成的，各服务之间存在各式各样的依赖关系，这就导致故障出现时往往会级联影响到下游业务，甚至引发其他业务的连锁故障，此时业务最终呈现的现象往往会干扰研发人员对其故障范围的判断。

微服务架构在部署环境中的故障难以复现

微服务架构下的服务调度错综复杂，一个业务故障的产生往往与其上下游的服务有很大的关系。有时我们在本地测试一切正常，但放到环境当中运行时却会引发故障，其原因或许是部署的环境有问题，亦或许是下游服务给予了一些意外的参数，亦或许是上游服务响应的结果不符合预期，此类种种都是我们在离开了部署环境时很难预料到的变故，并且在微服务架构的掩盖下，复现故障十分困难。

总结

微服务架构是解决业务复杂度的一个很好的方法，也是目前企业实践中最常用的办法。但是由于微服务架构的复杂性，企业想要管理好基于微服务架构的应用，也需要具备更高的能力。如果微服务治理得不恰当，反而有可能适得其反，不仅不能享受到微服务架构带来的好处，反而会因为微服务带来的系统复杂性，造成开发、运维部署的复杂度增加，进⽽影响开发迭代的速度，甚至影响系统的整体稳定性。

综上所述，企业对微服务治理的需求是十分明确的，就是想知道当下环境当中，特别是在数量庞大的微服务相互沟通的过程中，到底发生了什么，当故障发生时，故障的影响范围，故障的根本原因，最后是需要解决或缓解故障对业务影响的手段。

目前主流的服务治理解决思路

以SDK为主要表现形式的研发侧解决思路

通过编码的方式，让我们的业务代码直接具备解决问题的手段，这是目前最主流的也是发展时间最长的一种解决问题的思路。

研发的思维十分纯粹且直白，既然需要服务治理的能力，那就直接将这种能力写在代码上。通过日积月累沉淀出一些好用的SDK，代码只需要引入这些SDK即可获得服务治理能力。

在这条思路上最出名的开源库是SpringCloud。作为微服务治理框架的集合，SpringCloud的核心库封装了包括服务发现、流量访问、网关路由、熔断器、链路追踪等能力。

使用SDK解决服务治理的思路优势是：研发可以完全的掌握服务治理的所有能力，能够根据实际需求进行定制化，使其更加适配企业的实际情况。并且经过经年累月的打磨，部分语言的治理框架已经比较完善，为研发后续的开发打下了坚实的基础。

缺点是：研发掌握了一切，一旦SDK内部逻辑出现故障，或者是需要升级，就必须让研发介入重新编译打包，并且由于大部分服务都接入了服务治理SDK，所以一次升级可能需要涉及到很大范围的重新部署，这样做风险很大。SDK具备语言相关的属性，虽然部分语言的治理框架相对完善，但仍有很多流行的编程语言缺少完善的治理库，如果企业内部语言较多，为了平衡各类治理框架的差异，做统一管理，就需要投入额外的开发成本。

以Sidecar为主要表现形式的运维侧解决思路

随着技术的快速发展，DevOps理念开始流行，一种以Sidecar为主要表现形式的运维侧解决思路开始出现。研发只需要关注自身的业务部分，服务治理能力通过其他工具插入到正在运行的业务服务当中。

Sidecar模式，指单独将能力封装在另一个程序当中与业务共同运行，以此来增强业务服务的能力。服务网格（Service Mesh）技术就大量的使用了Sidecar模式，其中最为著名的开源库是Istio。

使用Sidecar模式解决服务治理的思路优势是：Sidecar作为基础设施可以由运维人员完全掌控，它与编程语言无关，并且完美的规避了SDK升级带来的重新编译部署的烦恼，并且由于Sidecar完全独立于业务服务，这就赋予业务在任何时间接入和任何时间退出的权利，即插即用。

与之相对的是Sidecar模式的缺陷：Sidecar必须劫持流量才可以做到对业务服务的能力增强，这就意味着在业务调度的过程中产生了一个新的不确定因素，一旦Sidecar本身出现故障，它将影响业务的正常运转。其次，在路由中每个服务都多了一跳，这就导致Sidecar必然带来性能的损耗。

以SDK与Sidecar同时存在为主要表现形式的解决思路

在云原生理念的推动下，业界又诞生了一种新的解决思路，它融合了SDK和Sidecar这2种解决问题的想法，并且期望实现完全的云原生，这就是Dapr。

Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到今年2月正式发布 V1.0 版本。在不到一年半的时间内，Github star 数达到了1.2 万，发展势头迅猛，Dapr 这个词是是「Distributed Application runtime」的首字母缩写：dapr是一个为应用提供分布式能力的运行时。

准确来说Dapr并不单单解决服务治理问题，而是完全基于云原生理念诞生的产物，Dapr希望将一切都抽象成云资源，代码通过对云资源的依赖来实现相应的业务。为了让各种语言都有统一的实现规范，Dapr给很多流行的语言提供了SDK，又结合了Sidecar思想，将真正实现逻辑的部分都封装在Sidecar当中，此时的Sidecar就是Dapr的运行时，有多个Sidecar，那就会出现多个运行时。业务代码会先通过SDK沟通Sidecar，再历经各个Sidecar的相互作用来实现具体需求，其中就包含了服务治理能力。

这种解决问题的办法有一个重要的优势：Dapr不仅可以动态的添加包含服务治理能力在内的各项公共能力，还可以基于抽象的云资源实现对底层实现的替换，比如将MongoDB替换成Redis等。

然而这种方式的缺陷也十分明显：Dapr几乎包含了SDK模式和Sidecar模式的大多缺点，SDK如果无法匹配Sidecar的版本时同样面临着SDK升级困难问题。由于多运行时共同作用，在路由上流量每经过一个服务，可能多了不止一跳，同样面临着性能问题。由于逻辑都封装在Sidecar上，也避免不了Sidecar本身故障时无法正常访问，并且由于多运行时，当故障出现很难准确定位故障。

如何抉择

SDK的方式和企业业务最贴合，完全的自主可控，可是需要付出巨大的研发和维护代价，去实现服务治理相应的功能。

Dapr的理念十分前卫，它能提供更多的想象空间，但是如果使用Dapr结构，研发需要放弃经营已久的开发框架去适配Dapr，相当于把底层框架几乎换掉，这个代价不是大多数企业能够承受的。

从企业成本付出来看，服务网格或许是现阶段最适合的解决方案。

使用服务网格解决微服务治理问题是当下代价最小的解决方案

服务网格（Service Mesh）是Sidecar模式的代表型技术之一，是处理服务间通信的基础设施层，在实践中，服务网格通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起。作为云原生的网络基础设施，它把微服务调度中有关网络的公共能力下沉到代理，实现了在无任何代码侵入的情况下提供可观察性、流量管理和安全性等能力。

相比SDK和Dapr这种需要研发深度介入的解决问题思路，服务网格的使用代价相对最小，这取决于Sidecar模式带来的结构优势：

• 零侵入，业务无感知，不需要支付额外的研发成本。
• 语言无关，无论使用任何编程语言都可以享受统一的服务治理能力。
• 升级便利，作为独立第三方服务，服务网格的升级迭代并不会影响业务的正常运行。

服务网格即插即用的特质对于企业十分友好，特别是针对组织架构相对复杂的企业，越少的部门关联意味着越少的沟通成本，而部门之间的沟通几乎是企业成本最大的地方。

综上所述，使用服务网格解决企业微服务治理是现阶段代价最小的选择，也是最推荐的解决方案。

用友云服务治理平台 助力企业微服务架构落地

本文主要阐述使用微服务架构时，治理框架或者平台需要解决的主要问题，微服务落地实施过程中所遇到的关键问题和对应解决方案。同时，文章也介绍用友云旗下的微服务治理平台的核心功能和技术架构，以及微服务治理平台在用友云一些产品下的实践，下一步的发展计划和趋势。

用友云微服务治理平台由来

伴随互联网、云计算、大数据等技术的快速发展，越来越多的企业在信息化之后，将企业上云和数字化提上日程。软件架构的微服务方式重构、应用的自动化运维、容器化等需求强烈，催生出了众多的PaaS平台。同时，针对微服务，也涌现除了许多RPC框架和微服务治理平台，各个框架和平台都有各自的优势和自身独特的适应场景。

相比于单体应用和SOA架构，微服务的小团队开发运维、复杂度可控制、独立扩缩、可灵活组合等等优势也逐渐凸显，被广大架构师和技术人员引入和推崇。但同时也引出了配置繁杂、事务不可控等诸多问题，如何恰当的解决微服务中暴露出的各种问题，成为各微服务治理平台的重点和难点。

软件架构在微服务之前，各个服务通过RestFul接口或者RPC进行互联和调用，进行功能的服务化和解耦，诸多成熟的RPC框架被引入，例如：

RPC调用是微服务治理的基础，但单单RPC不能称为微服务，微服务的核心功能还应该包含服务注册、发现，动态和可视化配置，限流熔断，链路追踪、分析，异步调用，数据一致性处理，API网关等等。

上文中所介绍的不同厂商的框架和产品，都围绕着以上核心功能，进行了实现和融合。各个产品都有不同的复杂度和局限性，并和自身厂商的其它产品联系密切。

用友云主要面向企业级应用，在TOB领域有独特的技术特色和要求，且用友云下的微服务治理需要和自身的DevOps平台、容器云平台及数据平台进行协同和能力聚合。在借鉴和吸收其他产品的优势的同时，用友云微服务治理平台团队针对自身产品需要做了完善和适配，充分的和用友云开发者中心、数据平台、租户中心、用户中心等结合，推出了更适合自身的用友云微服务治理平台，平台具有以下鲜明的特色：

用友微服务治理平台从2015年立项以来，经过团队的不断打磨，已经发展了几个版本，推出了较为成熟的多个版本，例如2.3.1-RELEASE、3.0.1-RELEASE，并在3.5后进行了类隔离机制和插件机制的增强，推出3.5.2-RELEASE、5.0.0-RELEASE. 并在资金云、人力云、财务云、协同云等多个产品，中建、中广核、DIWORK等大型项目中得到了验证。

平台的主要功能和技术架构

（1）功能架构：

服务治理平台提供RPC调用框架、异步调用框架、服务注册发现、配置中心、元数据、一致性框架等基础中间件，并预留了插件机制的扩展，方便开发者使用和集成；也从中间件容器层面提供类隔离和组件加载机制，尽量避免和业务应用引用的三方组件版本冲突；提供统一的门户入口，可视化的管理和查看远程服务的接口信息、调用链路日志、统计信息、评价信息，动态的控制具体接口和方法的权限和流量限制；提供限流、链路追踪等组件保证服务的稳定和可用性。

同时，在外围还支持和服务网关API Link的对接，支持使用IDE进行微服务的编排和一键发布。

（2）技术架构

服务治理平的几大核心技术模块包含注册中心，元数据、控制台、配置中心、基础SDK、链路计算、限流熔断、异步调用和一致性适配组件，IUAP和DUBBOX适配组件等，大致可以分为两类：微服务SDK（middleware）和后端支撑服务。

微服务SDK：

SDK主要可分为启动和加载（helix），基础的RPC调用（iris），配置中心sdk（proteus）、限流（sentinel）、链路（yyeye）、监控（ms-monitor）、异步调用和可靠消息（eos-spring-support）、数据最终一致性（cctrans-springsupport）、IUAP上下文支持（iuap-support）、dubbox适配（dubbox-support）等。

各个组件通过核心的插件机制和类加载机制整合在一起，形成整体对外提供服务，具有两大鲜明特性：

1：支持SPI方式扩展的插件机制，灵活组合，易于扩展；

2：基于ClassLoder的类隔离机制，组件分离，避免冲突；

通过服务治理平台的SDK，业务方可以简单快速的集成微服务的能力到业务工程，达到技术架构的微服务化的目的。

后端支撑：

后端支撑较为核心的包括注册中心、元数据、控制台和链路计算、监控、配置中心、权限管控等。

·注册中心源于springcloud体系下的eureka，在其基础上增加了多租户和权限校验机制，和用友云的租户机制和验证机制有机结合；

·元数据服务记录了业务服务中暴露出的远程RPC接口和方法，为可视化的管控及数据分析打好基础；

·统一控制台提供服务治理平台的UI交互的对接，支持用户可视化的管控接口、权限、链路，查看统计信息和监控信息；

·链路计算通过队列接收调用信息，使用数据平台的存储和分析机制统一计算和管理；

·监控服务收集各个应用和实例的基础配置、权限限流配置、端口和域名信息、接入和输出列表、调用基本统计等并统一展示；

·配置中心统一存储各个应用的各种配置信息，动态管理和下发全局配置、权限配置、限流配置等；

EDAS是阿里云平台推出的分布式服务调用和管控平台，其依赖其自身云平台的配置中心、调度中心、基础资源管理、核心容器、监控中心、权限中心等服务，构建整体服务对外提供服务，功能强大但相对复杂，整体技术栈对阿里云体系的其他产品强依赖，不易专属化的实施落地。

用友云平台的微服务治理团队也对其架构进行分析和对比，借鉴其优势的同时，结合自身特点，对各个模块进行拆分，并在异步调用、多套环境支持、去容器依赖等方面进行了针对性的适配；同时在支持与开发者中心、用户中心、权限中心等服务结合方面做了扩展，支持轻量化的独立部署，为平台的专属化减轻了负担。

关键问题点和解决方案

服务治理平台的几大核心功能包含基础的RPC框架、注册中心元数据、配置中心、链路追踪、异步和一致性、限流熔断等；

服务治理平台在实现和落地微服务的几个核心功能的过程中，也遇到一些难点，这也是众多厂家和平台共同的难点。针对这些关键点，服务治理平台提出了适合自身场景的多种合理的解决方案并实现，较为关键的几点简单说明如下：

（1）类隔离机制和插件机制：

JAVA 版的SDK，在和各种业务应用整合的同时，会遇到很多三方组件版本冲突的问题，给业务整合方带来了困扰。服务治理平台自3.5 版本开始对其进行了优化，引入了类隔离机制，推出了冰山（iceberg）思想，内部自身加载其依赖的三方组件，不对外部的业务三方引用造成冲突，大大简化了集成的难度。

同时，服务治理平台各个组件使用插件（plugin）机制进行组合，为后续的扩展和能力增强打好基础。

（2）动态配置：

业务应用的微服务化拆分，使得业务工程的配置文件更加繁多和分离，微服务的权限和流量的实时控制，也需要动态的管理各项配置。所以配置中心的后端服务和前端SDK体现出更重要的作用。

服务治理平台的SDK为每个使用的客户端，内置了配置中心的SDK，其使用长轮询的方式，近实时的感知远程配置文件的变化，从而及时的响应变化。云端的操作提供RestFul接口和可视化界面，操作简单实用。

（3）异步调用数据最终一致性：

异步调用框架提供可靠消息组件，完善了队列的权限认证体系，简化了异步调用的开发方式，业务开发只需要简单配置和注解，即可完成异步操作。同时，异步事务控制台可以在云端可视化的下发命令，提供错误事务的重试机制。

服务治理平台的SDK，将eos、cc等适配组件有机结合，一体化对外提供服务：

上述几个关键点只是服务治理平台的部分问题的解决方案，还有更多的技术点，本文在这里不做更深层次的阐述。通过云平台和支持和服务治理平台团队的共同努力，我们攻克了许多难题并给出了比较合理的解决方案且落地实现，为云平台及其他产品的微服务化铺平了道路。

服务治理平台在用友云的实践和落地

微服务治理平台自推出以来，经历了多个版本的迭代和多次升级完善，目前已经相对稳定。线上支持的应用数量已达到900多个，API数量已经接近三万个。

目前，使用服务治理平台的云产品和组织包括资金云、财务云、人力云、协同云、用友审计、用友能源等，支持的大型项目包括中建、中广核、DIWORK等。感谢各个平台和产品的支持，也希望微服务治理平台在对各产品和项目的微服务拆分及落地提供更多更有效的服务。

下图为线上监控系统分析出的各个产品和模块的调用依赖图，随着各个产品和服务的接入，用友云服务间的调用层级、依赖关系会越来越清晰，我们也能从中提炼出更多的价值。

微服务治理发展趋势和展望

服务治理平台经过长时间的发展和磨练，已经在分布式服务调用、运维管控和服务治理、生命周期管理和统一控制台、数字化监控和运营、开发支持扩展和兼容等等大方面有沉淀和输出。我们也和其他成熟的产品及框架进行对比，吸收和优化，构建和完善自身的微服务能力体系。

随着产品的发展，服务治理平台也总结了自身的几个重要阶段，我们从基础的调用框架走来，加强了权限和安全的管控，加入了服务稳定性保证，这些功能已经能覆盖大部分的业务需求。

但同时，我们要把握好技术的发展趋势，站在发展的前沿。服务治理平台下一步的发展规划，包括支持服务搜索和集市、对服务编排和网关更有效的组合、服务网格、服务监控等。

各个产品和服务间的调用数据已经收集，如何更好的更充分的利用这些数据，挖掘出有价值的信息，是服务治理平台的一个重要课题，我们可以借鉴京东云的思路，从这些数据中发掘出类似知识搜索、服务评价、调用图谱等，不仅从技术上，也从业务和流程上给出有价值的分析结果。

同时，线上应用变得更多，调用关系变的更复杂后，微服务监控的重要性就更加凸显。有效和及时的监控到各个服务和实例的参数、指标，能更有针对性的进行问题问题的排查和解决。下一阶段，微服务监控也是我们需要重点、大力投入的。

我们希望构建一个统一的可视化微服务监控体系，可以从中直观的获取到各类监控信息，譬如运行时环境、全局配置、异步调用配置、一致性组件的配置等，链接、端口、域名、跃点等，还有服务接口的调入、调出列表和统计信息，调用出错的链路和堆栈信息等等。有效的服务监控必将在开发和运维的不同阶段体现出更大的作用。

能力聚合、生态链、协同发展

服务治理平台的发展并非原生和独立的，其成功推出也伴随着其他产品和技术的支撑，云平台的DevOps、容器云的发展和微服务的发展相辅相成，有机组合，数据平台的大数据存储和分析为链路追踪和分析提供了可能。

微服务治理平台、DevOps平台、容器云平台合力，成为各个云产品和服务成功上云的三把尖刀，为其底层的技术支撑提供了强有力的保障。相信三把尖刀也会在技术中台中体现出越来越重要的价值。

对内有机整合，对外需要扩展和延伸，服务治理平台和API Link、服务编排等在微服务外围合理组合，使得微服务的利用率更高、可组合性更强。

但是，我们清楚，服务治理平台的各个技术架构和数据分析机制，依赖于各个业务平台的数据，只有各个业务线的数据不断完善，整体的用友云调用链路不断完整，服务治理才更加能突出治理和协调的作用，服务的分析和评价才更能落地。

各个业务的云化和微服务化需要技术中台的有力支撑，技术平台的发展也需要各个业务的有力配合，希望服务治理平台和开发者中心能够构建出越来越稳定和完善的服务，更多的云产品和项目接入进来，构建更为完整的用友云生态。

服务治理平台，作为用友云平台下 3+2战略 （技术中台、业务中台、数据中台 + 混合云、生态链）下的技术中台核心产品，也必将展示出更强的战斗力。