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

企业数字化向云原生演进过程面临诸多痛点，微服务框架不统一、协议多样化、语言异构，纷繁复杂的微服务技术栈，基础组件之间像一座座孤岛，各个基础组件的控制面不能互联，让用户的体验非常割裂，各种历史包袱阻碍了企业平滑过渡到云原生架构的进程。

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

数据面基于多运行时的架构设计，基础能力标准化、模块化、灵活可扩展，帮助开发者将云原生中间件生态无缝的集成到业务系统中，实现分布式微服务运行时生命周期的一站式管理，让企业能快速便捷构建基于云原生的大规模分布式架构。

一

背景

云原生技术通过资源的池化和秒级的弹性，给企业数字化转型带来的极大的价值和便利，降低资源成本、提高研发效率、实现快速交付等价值越来越被业界认可。微服务作为云原生领域中更开放、轻量、敏捷高效的技术架构，也得到了迅猛的发展，根据 O’Reilly 公布的行业市场调研报告显示，全球大约 80% 左右的企业都在使用微服务来构建业务系统。越来越多的企业探寻云原生化的微服务架构转型，使得业务更好的上云，享受云原生的技术红利。

O’Reilly 微服务市场行业调研报告

理想美好，实践不易，很多企业的云原生微服务架构转型之路并不顺滑，在转型的过程中面临诸多挑战：

• 技术栈不统一：微服务框架协议繁多，开发语言众多，框架共存维护开发成本高；
  

• 中间件生态复杂：纷繁复杂的微服务中间件生态，缺乏统一管理和调度，用户体验割裂；

• 业务耦合：原生微服务治理能力耦合业务，升级困难，阻碍基础能力和业务系统的演进；
  

• 可视化管理困难：微服务的理念是服务拆分，但在服务拆分过程中网络拓扑可能会变得非常复杂，另外复杂的中间件体系，使微服务治理体系需要站在全局的更高的视角去解决网络拓扑图里的流量治理、高可用、可观测性等问题。

针对上述挑战，企业只有通过合理的设计软件架构，才能充分享受云带来红利。未来微服务治理的架构将沿着以下几个方向演进：

• 多语言、多协议适配；
  

• 核心治理能力标准化、模块化、可扩展；
  

• 民主化松耦合，轻量可移植，无厂商依赖；
  

• 治理控制面协议统一，形成业界共识标准，一套 CRD（Custom Resource Definition）治理标准协议，下发多套治理数据面；
  

• 数据面生态的多元化，例如多语言的proxyless模式，JVMTI agent，跨语言的proxy 代理模式等；
  

• 数据面能力下沉，全面兼容开源生态；

在调研了当下主流社区的技术方案和用户需求后，我们发现以 Envoy 为代表的 proxy 代理模式虽然对业务方透明，但是对维护者带来的是性能延迟、以及高昂的额外学习和运维成本，企业自建微服务落地相对困难。相比之下，proxyLess 的Mesh 方式更贴近开源社区用户。

在此基础上，我们经过技术探索和创新，在遵循面向分布式设计、面向配置、高 SLA、可观测性、安全性等云原生架构设计原则下，推出 proxyLess 模式的多运行时微服务标准框架 Femas，通过定义一套开放式的微服务管控标准，帮助开发者快速接入并理解微服务架构，帮助用户实现异构系统微服务的统一管理。

二

Femas 简介

随着越来越多的企业投身数字化上云的浪潮，腾讯云微服务平台 TSF 历经多年磨砺，支撑了腾讯内部智慧零售、财付通、王者荣耀等核心业务系统，及第七次人口普查、某四大行及国内头部保险等政务、金融头部客户海量业务的构建与发展，Femas 作为腾讯云 TSF 的开源产品形态，正式对社区开发者开放 TSF 在生产环境中的部分核心源代码，开源框架聚焦微服务运行时，提供给多框架统一服务发现、南北及东西流量治理、服务可观测、配置管理等一站式微服务管控能力，解决企业微服务架构转型中异构框架复用难、激增流量管控难、排障恢复耗时长等核心问题。

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

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

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

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

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

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

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

1

微服务管理的统一

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

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

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

2

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

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

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

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

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

三

Femas 功能特性

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

1

注册中心管理

Femas 实现了对主流开源注册中心的管理（目前支持 Consul、Nacos、Eureka），包括集群管理，服务管理，用户在 Paas 平台配置注册中心集群，即可查看集群状态和服务列表。

在服务注册发现的底层技术中，Femas 实现了一套标准的注册发现API接口，用户可以直接使用Femas提供的 SDK 注册发现到主流的开源注册中心，能够在一套平台上实现多套注册中心集群的管理。

Femas 控制台：多套注册中心集群的管理

2

服务治理

Femas 的服务治理能力由 TSF 的治理能力演化而来，提供服务鉴权、API 管理、熔断降级、访问限流、服务注册发现、服务路由、服务事件等治理能力。在 Femas 中，您可以实现：

• 多协议多语言统一治理平面

• springcloud sdk 与 mesh 互访

• 基于自定义和系统标签治理

• 可观测：治理事件和流量的监测

Femas 打通了 proxy 代理模式和 proxyless 模式间的服务互访，用户可以实现任何场景下的服务治理，实现云原生技术栈服务治理的统一管理。

Femas 控制台：服务治理中心

3

服务可观测

在服务监控方面，提供全方位立体的监控体系，帮助用户快速排障。Femas 在设计之初就支持业界标准的 APM 协议，希望将应用侧 agent 探针收集到的数据，输出到多个 backend 管控端，实现应用侧数据采集和协议的标准统一。相关技术实现方案如下：

1. Metrics：实现了一套标准的业务 Metrics 指标的 API 接口，Femas 默认使用 micrometer 实现业务 Metrics 统计。

2. Tracing：实现了一套标准的tracing API 接口，SDK 侧负责制定OpenTracing 日志规范和链路采集。由于业界可观测的统一标准Opentelemtry 在发展阶段，第一阶段默认使用 SkyWalking agent 采集 Tracing 信息。

用户在控制台上可以通过宏观视角和微观视角，了解到服务调用链上的详细信息，调用链可视化数据支持可扩展，用户可根据抽象的 tracing 查询接口，从其他 backend(例如 jaeger、skywalking)管控端获取可视化数据，默认支持 skywalking 的管控端。

宏观视角：依赖拓扑图查看服务之间和上下游组件（MySQL、Redis、MongoDB）间的依赖关系和调用情况。例如服务上下游调用关系、服务调用的基本 Metrics 统计、服务与中间件组件依赖关系等

微观视角：通过调用链分析瓶颈和出错服务。提供调用链 ID、基于调用耗时、调用时间排序，支持调用链树形展示，支持异常类型及异常堆栈展示

4

配置管理

Femas 实现了一套标准的配置API接口，配置分为治理规则、应用配置，用户实现配置的分布式管理，以及应用配置管理、配置热更新等标准能力。

• 治理规则配置管理：支持通过 Paas 平台直接下发治理规则，不依赖其他三方组件，规则持久化支持 SDK 数据库 RocksDB 和外接的 Mysql 数据库。

• 应用配置管理：支持任意开源配置中心对接，提供基础配置发布、监听、回滚、版本管理能力，例如配置发布支持 yaml、版本对比、配置监听、配置回滚。

5

分布式任务调度

实现分布式定时任务的调度和管理。用户通过控制台即可配置、管理定时调度任务，查询任务的执行记录和执行日志，配置任务超时重试机制，在保证高可靠的同时，让用户通过简单的控制台操作即可进行任务的调度管理。

6

分布式事务

基于 TCC 模式提供了 AT 和 MT 两种模式的分布式事务管理功能。对于跨数据库、跨服务的分布式场景，用户可以通过控制台查看事务运行情况并进行超时事务处理，保证事务的一致性。

模式	特点
AT 模式	依赖数据库；对开发者友好，开发者无须编写 confirm 和 cancel 方法
MT 模式	不依赖数据库，更加灵活。在特殊场景下，用户可自定义优化和特殊功能的实现。

7

全链路灰度

全链路灰度基于微服务部署组的泳道设计，全链路灰度发布场景中，第一步需要划分泳道，将多个应用的某个版本划入同一泳道，在全链路灰度验证时，在泳道的入口应用做规则校验，命中流量分拨规则之后，按照各个泳道里面规划的路线做流量的全链路治理。

8

其他微服务运行时能力

Femas 对于运行时的能力并不设置边界，旨在帮助用户更好的实现微服务化转型的同时，能够更简单的去运维和理解微服务。运行时能力本身会比较割裂，我们也希望通过一套标准的微服务定义，以及控制台的搭配，将运行时的所有能力能够串联起来，而非独立的去使用。

未来我们将会把上述的可观测性增加 Event，并且将治理能力比如路由、熔断等，和可观测性结合，帮助用户对微服务中每个动作带来的影响都清晰明了。同样的，对于当前还没有涉及到的诸如 state stores 的状态管理、publish&subscribe 的消息管理、分布式锁、分布式 ID 等，我们也将会和可观测性，以及从微服务的视角去进行联动。

9

与Dapr的区别

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

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

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

四

Femas 架构设计

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

1

标准化、模块化

微服务的中间件生态非常的复杂，每个能力领域都有多个厂商提供的组件，缺乏统一的业界共识标准，例如注册发现有北极星 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 调用

2

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

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

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

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

3

插件化设计灵活、可扩展

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

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

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

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

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

4

开箱即用的控制台

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

五

Femas 总览

• 开放：提供控制面微服务管控 API 接口抽象封装、支持任意注册中心、APM、配置中心开源组件对接替换，避免单一技术绑定，能适配大多数企业的基础技术栈。

• 标准：定义一套微服务多运行时管控标准包含服务发现、服务治理、配置管理、服务调用及调用链日志埋点能力抽象。

• 治理：通过服务发现、治理能力抽象封装实现异构语言、框架、协议统一服务发现、治理平面实现服务互访打破业务烟囱壁垒。

• 接入：第一阶段提供侵入式 SDK 方式，未来提供无侵入 Sidecar/agent 接入方式，支持多语言、多框架、多协议低成本接入，降低用户迁移及上手难度。

• 轻量：用户可按需对接支撑组件如注册中心、APM、配置管理组件，各模块应用能力无厂商绑定，可增量插拔扩展能力支持容器部署，资源轻量。

• 可观测：集成全局服务依赖拓扑、调用链、监控指标实现端到端应用性能分析及高效排障能力。

1

Femas 和北极星

Femas 是 PolarisMesh 社区开源的另外一款子产品，PolarisMesh 统一腾讯微服务生态建设。

polaris 聚焦服务注册发现和治理中心，femas 则专注微服务运行时一站式生命周期管理，两款开源产品对标腾讯微服务领域不同的目标和规划，生态互联。Femas 作为北极星的下游产品，标准化 API 同样适用于北极星，Femas 的治理 CRD 协议能够完全兼容北极星，默认支持北极星的服务注册发现和治理中心。

2

Femas 开源规划

展望未来趋势

腾讯云微服务治理目前有两种形态，分别是 proxy 代理模式和 proxyless 模式。

治理数据面能力下沉通常会面临 JVMTI Agent 与 Envoy 两种技术栈的选择。对比 JVMTI Agent 与 Service Mesh。

• JVMTI Agent 是基于 Java 原生的技术，可维护性较好，无侵入，没有额外运维成本，同时还具备高SLA、高性能的优点。但缺点是 premain 会延长启动时间，且无法跨语言，仍需要跟业务进程一起编译上线。

• Service Mesh 的优点是支持跨语言，而且没有业务侧的代码兼容性问题，能够快速迭代，独立升级。但缺点是独立容器，CPU 消耗较大，问题追踪也相对困难，性能延迟高于 agent，需要额外维护成本。

从当前微服务治理的发展趋势来看，治理控制面趋于协议统一，形成业界共识标准，一套 CRD 治理标准协议，下发多套治理数据面。而数据面，则展现出生态的多元化，例如多语言的 proxyless，跨语言的 Envoy 代理，JVMTI agent 等技术各施所长，共同推动业务的快速发展，加速企业数字化转型。

3

Femas 开源 RoadMap

后续 Femas 的开源计划：

• 开源核心 SDK

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

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

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

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

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

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

• 多语言 SDK 支持，go sdk 的支持

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

• 完善项目文档

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

Femas 开源版本来自腾讯 TSF 的部分生产代码，我们已经将核心主体部分提交到社区。腾讯开源激励计划鼓励开发者参与贡献，社区开发对代码或者文档的每一个 issue 讨论或者 PR 我们都会积极采纳，参与者将获得：

• 加入腾讯开源项目贡献者名单，并展现在腾讯开源官网

• 写入具体项目的 CONTRIBUTING.md

• 腾讯开源贡献者证书（电子版&纸质）

• 成为线下技术大会/沙龙特邀嘉宾

• Q 币及纪念品

GitHub 地址：
https://github.com/polarismesh/femas

加「中间件小Q妹」好友，进入 Femas 技术讨论群交流

---

腾源会是腾讯云成立的汇聚开源项目、开源爱好者、开源领导者的开放社区，致力于帮助开源项目健康成长、开源爱好者能交流协助、开源领导者能发挥领袖价值，让全球开源生态变得更加繁荣。

欢迎关注「腾源会」公众号，期待你的「在看」哦～