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

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

伴随互联网、云计算、大数据等技术的快速发展，越来越多的企业在信息化之后，将企业上云和数字化提上日程。软件架构的微服务方式重构、应用的自动化运维、容器化等需求强烈，催生出了众多的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战略 （技术中台、业务中台、数据中台 + 混合云、生态链）下的技术中台核心产品，也必将展示出更强的战斗力。