作家|童子龙，刘志新策篇|梦丹
企业数字化向云演进的过程面临着各种困难。微服务框架不统一，协议多种多样，语言多种多样，存在复杂的微服务技术栈。基本组件之间有岛，每个基本组件的控制平面不能相互连接。非常分裂用户的体验，各种历史负担阻碍了企业顺利过渡到云基本体系结构的过程。
为了帮助企业快速顺利地过渡到云基本微服务体系结构，腾讯经过多年的探索和创新，通过正式开源行业第一个云基本标准一站式微服务管理框架Femas(GitHub地址：)，通过正式开源行业第一个云基本标准FEMAS (GITHUB地址：)，定义了开放微服务控制平面标准协议，实现了微服务基本组件的统一管理和调度。
Femas概览
Femas微服务治理方案
Femas从控制平面和数据平面两个角度定义了适合当前社区主流技术堆栈的微服务治理方案，使企业能够在不改变基础架构的情况下落地整个企业级微服务解决方案。
数据面：Femas采用Multi-runtime的体系结构设计，对基于微服务的核心功能进行标准化和模块化，通过合理的体系结构将微服务领域分离出来的基本组件满足各种微服务方案、轻量级、可移植性、低成本、无云供应商绑定。
控制平面：Femas提供一组CRD定义，其中包括集成控制平面标准协议和治理、资源等微服务概念，并支持多个数据平面。
Femas帮助各种用户组过渡到微服务体系结构。
面向最终用户：Femas提供完整的控制台功能和与主流开源技术兼容的通用框架插件。用户只需增加对Pom的依赖，即可快速方便地使用完整的可视化微服务运行时功能。
自行研究框架小组：Femas通过插件设计开发了符合Multi-runtime标准规范的微服务API接口。这上面增加了微服务运行库的抽象层，框架团队可以通过高度封装的API接口将所有自己的研究框架连接到Femas，从而获得完整的可视化微服务运行库功能。
平台团队大象：Femas抽象了微服务运行时使用的几乎所有组件功能，并提供了多种实现。平台团队还通过定制组件的实现，组装成适合公司内部平台情况的专用微服务平台，由公司研发amp可用于d。
微服务管理的统一
集成概念：该概念由多个维度组成，这些维度集成了物理系统、虚拟机、容器等多种基本资源的概念。或者，根据多个企业供应商的基础架构定义(如可用区域、命名空间等)，有唯一的业务意义。为了将这些不同的全系统技术堆栈集成到同一个控制平面上，Femas在控制平面上统一了不同系统的概念，为控制平面协议的标准化统一奠定了基础。
集成功能：Femas定义了微服务运营所需的标准能力矩阵，封装了所有功能，使您能够快速构建基于Femas的企业级标准微服务管理平台。可扩展，易于升级和维护。
综合治理：不同的协议框架、特定于语言的微服务系统和Femas开发了独立于框架协议的治理标准API接口，使企业异构微服务体系结构能够完全集成Femas。
控制面治理协议标准的统一
FEMAS开发了一套包含治理规则定义的集成CRD。
相同的控制面规则协议集支持多个数据面，这些数据面可以作为SDK/代理或Sidecar发布规则。
SDK/代理支持控制平面插件，SDK支持控制平面的数据转发扩展，如http协议，该协议本机支持PaaS平台。支持K8s的XDS协议发布规则也可以扩展。
支持单独使用控制平面，SDK支持应用本机YAML格式的规则配置。
p3-sign.toutiaoimg.com/large/tos-cn-i-tjoges91tu/T0D9of7Dc70Gtv?_iz=31825&from=ar;x-expires=1706864728&x-signature=%2FFv0pdE%2F4dCdqdPBhgAm%2Bmpkvf0%3D&index=3" width="640" height="572"/>Femas功能概览
Femas能力概览
Femas完成了对企业级的微服务架构能力矩阵的标准定义，主要包含四大功能特性：
注册中心管理
服务治理
服务可观测
配置管理
分布式任务调度
分布式事务
全链路灰度
其他微服务运行时能力
Dapr作为目前一款比较火热的多运行时框架，Femas和Dapr主要有两大不同：
Femas更注重能力的结合，比起每个能力独立的使用，Femas更希望从微服务的视角，去连接起这部分能力。以微服务为对象，可观测为基石将应用运行时需要用到的能力可视化的展现出来，从而更好的理解和管理微服务架构。
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将整体架构分成了三层：
组件层：微服务应用在运行过程中可能需要用到的能力抽象成了一个个组件模块，所有的组件模块构建成一个插件容器池。插件容器池的两层数据结构：<in;;>。
平台适配层：适配层会根据用户配置的插件上下文，从插件池中选择用户需要的组件实现。不同的适配器，会选择不同的组件插件实现组合，来适应不同平台的需求场景。
微服务协议扩展层：实现各个协议框架的治理插件，将Femas的能力在框架合适的地方中进行埋点，做到不同协议框架的轻量接入，并且能在同一套平台上面统一管理。
开箱即用的控制台
Femas提供开箱即用的控制台，降低社区用户POC成本，控制台数据持久化默认支持本地嵌入式数据库RocksDB，和外接的MySQL数据库，存储外接方式支持控制台的水平扩展。数据持久化支持可扩展，用户可根据抽象的数据操作接口，将治理数据存储到其他K/V数据库或关系型数据库。
Femas开源RoadMap
后续Femas的开源计划：
开源核心SDK
开源开箱即用的可视化PaaS平台
制定的微服务治理的CRD协议，统一控制面治理协议标准
继续补充微服务运行时能力
- 目前femas已经完成的运行时能力有：注册中心管理、服务治理、服务可观测、配置管理，其他运行时能力仍待完善。
- TSF接来下会完善监控能力，并反哺到开源社区。
- 全链路灰度、分布式事务、分布式任务、分布式锁等运行时能力目前尚未正式对外开放，如果社区需求反响强烈，则会考虑对外开放。
多语言SDK支持，Go SDK的支持
治理能力无侵入，字节码增强和Proxy两种方式
完善项目文档
帮助社区开发者在企业落地
—END—
《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造