腾讯开源业界首个云原生标准的一站式微服务管理框架Femas

作家|童子龙，刘志新策篇|梦丹

企业数字化向云演进的过程面临着各种困难。微服务框架不统一，协议多种多样，语言多种多样，存在复杂的微服务技术栈。基本组件之间有岛，每个基本组件的控制平面不能相互连接。非常分裂用户的体验，各种历史负担阻碍了企业顺利过渡到云基本体系结构的过程。

为了帮助企业快速平滑转型为云原生微服务架构，腾讯经过多年的探索与创新，正式开源业界首个云原生标准的一站式微服务管理框架Femas（GitHub地址：），通过定义一套开放式的微服务控制面标准协议，实现微服务基础组件的统一管理和调度。

Femas总览

Femas微服务治理方案

Femas从控制面和数据面两个角度，定义了一套适合当前社区主流技术栈的微服务治理方案，方便企业在不变更基础设施的情况下，落地整套企业级的微服务解决方案。

• 数据面：Femas运用Multi-runtime的架构设计，将微服务底层的核心能力标准化、模块化，将微服务领域割裂的基础组件通过合理的架构组装在一起，来满足多元化的微服务场景，轻量化、可移植、低成本、无云厂商绑定。

• 控制面：Femas提供统一的控制面标准协议，以及一套包含了治理、资源等微服务概念的CRD定义，同时也支持多数据面下发。

Femas帮助不同的用户群体过渡到微服务架构：

• 面向最终用户：Femas提供了完整的控制台能力，并且提供了常见的框架插件，兼容主流开源技术，用户只需添加Pom依赖，就能方便快捷的拥有全套的可视化微服务运行时能力。

• 面向自研框架团队：Femas采用插件化设计，制定了一套符合Multi-runtime标准规范的微服务API接口，在此之上、更增加了微服务运行时的抽象层，框架团队可以通过高度封装 的API接口，将任意自研框架接入Femas，获得全套可视化的微服务运行时能力。

• 面向平台团队：Femas抽象了微服务运行时会用到的几乎全部组件能力，并且提供了大量的实现。平台团队也可以通过自定义组件的实现，组装成符合公司内部平台情况的私有微服务平台提供给公司研发使用。

微服务管理的统一

• 统一概念：这里的概念由多个维度组成，比如统一物理机、虚拟机、容器等不同基础资源的概念， 或者像不同企业厂商对基础设施的定义都有一套各自的业务语义，类似可用区、命名空间等。为了将上述这些不同体系维度的技术栈融合到同一套控制面，Femas在控制面层统一了不同体系的概念，为控制面协议的标准化统一提供基础。

• 统一能力：Femas定义了微服务运行时所需要的标准能力矩阵，并将所有能力进行封装，让企业能够基于Femas快速的构建一套企业级的标准微服务管理平台，能力可扩展，方便升级和维护。

• 统一治理：针对不同协议框架，不同语言的微服务体系，Femas制定了一套无关框架协议的治理标准API接口，让企业的异构微服务架构都能无缝集成Femas，让多语言、多框架的微服务技术栈都能在一套平台上面统一纳管。

控制面治理协议标准的统一

Femas制定了一套统一的CRD，其中包括了治理规则定义。

同一套控制面规则协议支持多数据面，既可下发规则到SDK/AGENT，也可以下发给Sidecar。

SDK/AGENT支持控制面插件化，SDK支持控制面的数据下发的扩展，例如默认支持PaaS平台的http协议下发；也可以扩展支持K8s的XDS协议下发规则。

支持脱离控制面单独使用，SDK支持在应用本地的YAML格式的规则配置。

Femas功能概览

Femas能力概览

Femas完成了对企业级的微服务架构能力矩阵的标准定义，主要包含四大功能特性：

• 注册中心管理

• 服务治理

• 服务可观测

• 配置管理

• 分布式任务调度

• 分布式事务

• 全链路灰度

• 其他微服务运行时能力

Dapr作为目前一款比较火热的多运行时框架，Femas和Dapr主要有两大不同：

1. Femas更注重能力的结合，比起每个能力独立的使用，Femas更希望从微服务的视角，去连接起这部分能力。以微服务为对象，可观测为基石将应用运行时需要用到的能力可视化的展现出来，从而更好的理解和管理微服务架构。

2. Dapr本身制定了一套自己的标准，Femas虽然也有自己的定义，但是两者最大的区别在于使用Dapr需要用户在业务上进行代码的改动，而Femas通过良好的抽象，通过很轻量的方式去适配各个RPC框架，从而做到用户不需要改动业务代码，既可以使用多运行时带来的优势。

Femas架构设计

目前，腾讯微服务平台的企业用户体量非常庞大，而且在持续增长，在帮助企业数字化上云的过程中，遇到了很多的挑战，本着服务全球开发者的愿景，我们不断的思考如何用合理的架构去解决这些痛点。

标准化、模块化

微服务的中间件生态非常的复杂，每个能力领域都有多个厂商提供的组件，缺乏统一的业界共识标准，例如注册发现有北极星PolarisMesh、Consul等，消息队列有Pulsar、Kafka等，各个基础组件像一座座数据孤岛，各个基础组件的控制面无法互联让用户的体验非常割裂，业务开发需要对接、升级基础组件，无形中增加了基础架构和业务开发间的沟通协作成本，使得企业整个技术生态陷入维护成本高昂的困境，因此需要一个稳定合理的软件架构系统去管理调度这些纷繁复杂的基础设施，终结低效、割裂的用户体验。

架构方便、快速迭代升级也是云原生架构的重要价值之一，但传统中间件使得业务系统跟基础设施强耦合，设想如果基础能力需要升级，像全链路灰度、多活等需要联动全局的能力，则需要推动整个业务配合升级，其中成本可想而知，基础能力的轻量化、可移植、无厂商依赖也是个非常重要的考量目标，基础设施维护人员和业务开发人员应该各司其职，业务不应该过多关注基础设施细节，传统中间件因为自身存在的局限性，这些问题都不能很好的解决。

基于传统组件面临的种种问题，Red Hat首席架构师Bilgin Ibryam对云原生领域的微服务架构发展提出了Multi-Runtime的理念。

Runtime作为理论的出发点，Bilgin Ibryam提出现代分布式应用程序的需求分为4类，分别是生命周期（lifecycle）、网络（networking）、状态（state）和绑定（binding）。

• 生命周期：编程语言会指定生态系统中的可用库、打包格式和运行时，自动化部署、弹性伸缩、自愈等代表了应用程序生命周期的需求。

• 网络：从更广泛的角度去掌握网络，例如DNS、流量管控。

• 状态：依赖于底层的状态的分布式能力，如缓存、服务编排和工作流、分布式单例、临时调度。

• 绑定：在跟外部系统的集成过程中，依赖度额协议转化，错误恢复等能力。

找到分布式问题的本质之后，Bilgin Ibryam接下来谈到未来云原生的趋势的构想，提出了Multi-Runtime的概念。

1.将分布式的能力抽象成多个Runtime，并将能力外移。

2.将所有能力标准化、模块化，业务系统跟中间件的交互方式转变成面向分布式能力的标准API调用。

3.将业务系统从Fat SDK的时代解放出来，业务系统无需耦合基础能力的SDK。

4.云原生基础设施跟业务系统能够独立演进，企业数字化，快速扩展、快速迭代的能力大幅提升。

Multi-Runtime推动了中间件生态的标准化和透明化下沉，实现业界基础能力API接口范式的统一。

我们也察觉到Multi-Runtime的基础能力标准化、模块化对架构演进带来的价值，无厂商绑定、可移植，推动各个微服务中间件厂商的标准化，对开源生态和内部自研的全面兼容。我们根据经验，将微服务拆分成一个个基础能力模块，对每个模块进行接口定义：

• 面向分布式能力的抽象

• 能力模块化

• 能力标准化

Femas将底层核心能力标准化、模块化，业务应用由传统面向各个基础能力的开发转变成面向分布式能力的标准化API调用。统一了业务层的基础能力语义，也极大增加了基础能力的可扩展性和可维护性。对于社区开发者而言，模块化的设计降低贡献代码门槛，开发者在修复某个模块的缺陷时，无需关注其他模块的代码，希望吸引更多开发者的共同参与开源建设。

面向分布式标准能力的API调用

微服务协议接入标准的统一

腾讯云微服务平台数据面在演进初期，在适配每个框架协议的时候，都会投入大量的成本，例如Spring Cloud本身版本众多，D到H每个版 本都有变化，甚至到了的2020结构大变。新增feature需要cherry-pick到每个版本代码上，利用了当前版本特性的功能，则无法复用到其他版本，类比至其他框架，Dubbo也存在这些问题，我们发现即使只支持Spring Cloud一个框架都会卷入大量的人力，更不用提其他自研框架。

因此我们希望自研一套框架，能够与RPC框架无关，做到框架核心能力代码跟上层协议代码的完全分离，互不影响，帮助用户低成本地应对协议框架的版本迭代。

针对多微服务框架协议多样化的问题，Femas将微服务生命周期抽象为一下几个阶段：初始化、实例注册、服务调用的DNS、流量出站、流量入站、服务销毁。在微服务协议的各个生命阶段做统一拦截，实现不同协议的轻量、低成本接入。

插件化设计灵活、可扩展

腾讯内部很多公有云服务都使用了公司内部的组件，比如注册中心用的是北极星，配置中心是七彩石等等。对外交付时，内部组件由于种种原因无法交付，所以这些项目需要同时维护不同的分支，一个用于维护内部组件，另一个则用于维护对外的各种组件。我们希望有一套框架，能够实现基础组件的灵活可替换，自由组装Paas平台需要的微服务组件能力矩阵，支持Paas平台多元化的场景。

针对Paas业务场景多元化的问题，Femas将整体架构分成了三层：

1. 组件层：微服务应用在运行过程中可能需要用到的能力抽象成了一个个组件模块，所有的组件模块构建成一个插件容器池。插件容器池的两层数据结构：<in;;>。

2. 平台适配层：适配层会根据用户配置的插件上下文，从插件池中选择用户需要的组件实现。不同的适配器，会选择不同的组件插件实现组合，来适应不同平台的需求场景。

3. 微服务协议扩展层：实现各个协议框架的治理插件，将Femas的能力在框架合适的地方中进行埋点，做到不同协议框架的轻量接入，并且能在同一套平台上面统一管理。

开箱即用的控制台

Femas提供开箱即用的控制台，降低社区用户POC成本，控制台数据持久化默认支持本地嵌入式数据库RocksDB，和外接的MySQL数据库，存储外接方式支持控制台的水平扩展。数据持久化支持可扩展，用户可根据抽象的数据操作接口，将治理数据存储到其他K/V数据库或关系型数据库。

Femas开源RoadMap

后续Femas的开源计划：

• 开源核心SDK

• 开源开箱即用的可视化PaaS平台

• 制定的微服务治理的CRD协议，统一控制面治理协议标准

• 继续补充微服务运行时能力

- 目前femas已经完成的运行时能力有：注册中心管理、服务治理、服务可观测、配置管理，其他运行时能力仍待完善。

- TSF接来下会完善监控能力，并反哺到开源社区。

- 全链路灰度、分布式事务、分布式任务、分布式锁等运行时能力目前尚未正式对外开放，如果社区需求反响强烈，则会考虑对外开放。

• 多语言SDK支持，Go SDK的支持

• 治理能力无侵入，字节码增强和Proxy两种方式

• 完善项目文档

• 帮助社区开发者在企业落地

—END—

《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造