导读
企业数字化向云原生演进过程面临诸多痛点，微服务框架不对立、协定多样化、语言异构，纷繁复杂的微服务技术栈，根底组件之间像一座座孤岛，各个根底组件的管制面不能互联，让用户的体验十分割裂，各种历史包袱妨碍了企业平滑过渡到云原生架构的过程。
为了帮忙企业疾速平滑转型为云原生微服务架构，腾讯通过多年的摸索与翻新，明天正式开源业界首个云原生规范的一站式微服务治理框架 Femas，通过定义一套开放式的微服务管制面标准协议，实现微服务根底组件的对立治理和调度。数据面基于多运行时的架构设计，根底能力标准化、模块化、灵便可扩大，帮忙开发者将云原生中间件生态无缝的集成到业务零碎中，实现散布式微服务运行时生命周期的一站式治理，让企业能疾速便捷构建基于云原生的大规模分布式架构。
一、背景
云原生技术通过资源的池化和秒级的弹性，给企业数字化转型带来的极大的价值和便当，升高资源老本、进步研发效率、实现疾速交付等价值越来越被业界认可。微服务作为云原生畛域中更凋谢、轻量、麻利高效的技术架构，也失去了迅猛的倒退，依据 O’Reilly 颁布的行业市场调研报告显示，寰球大概 80% 左右的企业都在应用微服务来构建业务零碎。越来越多的企业探寻云原生化的微服务架构转型，使得业务更好的上云，享受云原生的技术红利。
现实美妙，实际不易，很多企业的云原生微服务架构转型之路并不顺滑，在转型的过程中面临诸多挑战：
·技术栈不对立：微服务框架协定繁多，开发语言泛滥，框架共存保护开发成本高；
·中间件生态简单：纷繁复杂的微服务中间件生态，不足对立治理和调度，用户体验割裂；
·业务耦合：原生微服务治理能力耦合业务，降级艰难，妨碍根底能力和业务零碎的演进；
·可视化治理艰难：微服务的理念是服务拆分，但在服务拆分过程中网络拓扑可能会变得非常复杂，另外简单的中间件体系，使微服务治理体系须要站在全局的更高的视角去解决网络拓扑图里的流量治理、高可用、可观测性等问题。
针对上述挑战，企业只有通过正当的设计软件架构，能力充沛享受云带来红利。将来微服务治理的架构将沿着以下几个方向演进：
·多语言、多协定适配；
·外围治理能力标准化、模块化、可扩大；
·民主化松耦合，轻量可移植，无厂商依赖；
·治理管制面协定对立，造成业界共识规范，一套 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 形象了微服务运行时会用到的简直全副组件能力，并且提供了大量的实现。平台团队也能够通过自定义组件的实现，组装成合乎公司外部平台状况的公有微服务平台提供给公司研发应用。
2.1 微服务治理的对立
·对立概念：这里的概念由多个维度组成，比方对立物理机、虚拟机、容器等不同根底资源的概念，或者像不同企业厂商对基础设施的定义都有一套各自的业务语义，相似可用区、命名空间等。为了将上述这些不同体系维度的技术栈交融到同一套管制面，Femas 在管制面层对立了不同体系的概念，为管制面协定的标准化对立提供根底。
·对立能力：Femas 定义了微服务运行时所须要的规范能力矩阵，并将所有能力进行封装，让企业可能基于 Femas 疾速的构建一套企业级的规范微服务治理平台，能力可扩大，不便降级和保护。
·对立治理：针对不同协定框架，不同语言的微服务体系，Femas 制订了一套无关框架协定的治理规范 API 接口，让企业的异构微服务架构都能无缝集成 Femas，让多语言、多框架的微服务技术栈都能在一套平台下面对立纳管。
2.2 管制面治理协定规范的对立
·Femas 制订了一套对立的 CRD，其中包含了治理规定定义。
·同一套管制面规定协定反对多数据面，既可下发规定到 sdk/agent，也能够下发给 Sidecar。
·sdk/agent 反对管制面插件化，sdk 反对管制面的数据下发的扩大，例如默认反对 paas 平台的 http 协定下发；也能够扩大反对 k8s 的 XDS 协定下发规定。
·反对脱离管制面独自应用，SDK 反对在利用本地的 YAML 格局的规定配置。
三、性能个性
Femas 实现了对企业级的微服务架构能力矩阵的规范定义，次要蕴含四大性能个性：
3.1 注册核心治理
Femas 实现了对支流开源注册核心的治理（目前反对 Consul、Nacos、Eureka），包含集群治理，服务治理，用户在 Paas 平台配置注册核心集群，即可查看集群状态和服务列表。
在服务注册发现的底层技术中，Femas 实现了一套规范的注册发现 API 接口，用户能够间接应用 Femas 提供的 SDK 注册发现到支流的开源注册核心，可能在一套平台上实现多套注册核心集群的治理。
3.2 服务治理
Femas 的服务治理能力由 TSF 的治理能力演变而来，提供服务鉴权、API 治理、熔断降级、拜访限流、服务注册发现、服务路由、服务事件等治理能力。在 Femas 中，您能够实现：
·多协定多语言对立治理立体
·springcloud sdk 与 mesh 互访
·基于自定义和零碎标签治理
·可观测：治理事件和流量的监测
Femas 买通了 proxy 代理模式和 proxyless 模式间的服务互访，用户能够实现任何场景下的服务治理，实现云原生技术栈服务治理的对立治理。
3.3 服务可观测
在服务监控方面，提供全方位平面的监控体系，帮忙用户疾速排障。Femas 在设计之初就反对业界规范的 APM 协定，心愿将利用侧 agent 探针收集到的数据，输入到多个 backend 管控端，实现利用侧数据采集和协定的规范对立。相干技术实现计划如下：
- Metrics：实现了一套规范的业务 Metrics 指标的 API 接口，Femas 默认应用 micrometer 实现业务 Metrics 统计。
- Tracing：实现了一套规范的 tracing API 接口，SDK 侧负责制订 OpenTracing 日志标准和链路采集。因为业界可观测的统一标准 Opentelemtry 在倒退阶段，第一阶段默认应用 SkyWalking agent 采集 Tracing 信息。
用户在管制台上能够通过宏观视角和宏观视角，理解到服务调用链上的详细信息，调用链可视化数据反对可扩大，用户可依据形象的 tracing 查问接口，从其余 backend(例如 jaeger、skywalking)管控端获取可视化数据，默认反对 skywalking 的管控端。
宏观视角：依赖拓扑图查看服务之间和上下游组件（MySQL、Redis、MongoDB）间的依赖关系和调用状况。例如服务上下游调用关系、服务调用的根本 Metrics 统计、服务与中间件组件依赖关系等
宏观视角：通过调用链分析瓶颈和出错服务。提供调用链 ID、基于调用耗时、调用工夫排序，反对调用链树形展现，反对异样类型及异样堆栈展现
3.4 配置管理
Femas 实现了一套规范的配置 API 接口，配置分为治理规定、利用配置，用户实现配置的分布式治理，以及利用配置管理、配置热更新等规范能力。
·治理规定配置管理：反对通过 Paas 平台间接下发治理规定，不依赖其余三方组件，规定长久化反对 SDK 数据库 RocksDB 和外接的 Mysql 数据库。
·利用配置管理：反对任意开源配置核心对接，提供根底配置公布、监听、回滚、版本治理能力，例如配置公布反对 yaml、版本比照、配置监听、配置回滚。
3.5 分布式任务调度
实现分布式定时工作的调度和治理。用户通过控制台即可配置、治理定时调度工作，查问工作的执行记录和执行日志，配置工作超时重试机制，在保障高牢靠的同时，让用户通过简略的控制台操作即可进行工作的调度治理。
3.6 分布式事务
基于 TCC 模式提供了 AT 和 MT 两种模式的分布式事务管理性能。对于跨数据库、跨服务的分布式场景，用户能够通过控制台查看事务运行状况并进行超时事务处理，保障事务的一致性。
3.7 全链路灰度
全链路灰度基于微服务部署组的泳道设计，全链路灰度公布场景中，第一步须要划分泳道，将多个利用的某个版本划入同一泳道，在全链路灰度验证时，在泳道的入口利用做规定校验，命中流量分拨规定之后，依照各个泳道外面布局的路线做流量的全链路治理。
3.8 其余微服务运行时能力
Femas 对于运行时的能力并不设置边界，旨在帮忙用户更好的实现微服务化转型的同时，可能更简略的去运维和了解微服务。运行时能力自身会比拟割裂，咱们也心愿通过一套规范的微服务定义，以及控制台的搭配，将运行时的所有能力可能串联起来，而非独立的去应用。
将来咱们将会把上述的可观测性减少 Event，并且将治理能力比方路由、熔断等，和可观测性联合，帮忙用户对微服务中每个动作带来的影响都清晰明了。同样的，对于以后还没有波及到的诸如 state stores 的状态治理、publish&subscribe 的音讯治理、分布式锁、分布式 ID 等，咱们也将会和可观测性，以及从微服务的视角去进行联动。
3.9 与 Dapr 的区别
Dapr 作为目前一款比拟炽热的多运行时框架，Femas 和 Dapr 次要有两大不同：
·Femas 更重视能力的联合，比起每个能力独立的应用，Femas 更心愿从微服务的视角，去连贯起这部分能力。以微服务为对象，可观测为基石将利用运行时须要用到的能力可视化的展示进去，从而更好的了解和治理微服务架构。
·Dapr 自身制订了一套本人的规范，Femas 尽管也有本人的定义，然而两者最大的区别在于应用 Dapr 须要用户在业务上进行代码的改变，而 Femas 通过良好的形象，通过很轻量的形式去适配各个 RPC 框架，从而做到用户不须要改变业务代码，既能够应用多运行时带来的劣势。
四、架构设计
从以后企业遇到的痛点登程，是摸索一个新技术的最好切入点，目前，腾讯微服务平台的企业用户体量十分宏大，而且在持续增长，在帮忙企业数字化上云的过程中，遇到了很多的挑战，本着服务寰球开发者的愿景，咱们一直的思考如何用正当的架构去解决这些痛点。
4.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 调用。对立了业务层的根底能力语义，也极大减少了根底能力的可扩展性和可维护性。对于社区开发者而言，模块化的设计升高奉献代码门槛，开发者在修复某个模块的缺点时，无需关注其余模块的代码，心愿吸引更多开发者的独特参加开源建设。
4.2 微服务协定接入规范的对立
腾讯云微服务平台数据面在演进初期，在适配每个框架协定的时候，都会投入大量的老本，例如 Spring Cloud 自身版本泛滥，D 到 H 每个版 本都有变动，甚至到了的 2020 构造大变。新增 feature 须要 cherry-pick 到每个版本代码上，利用了以后版本个性的性能，则无奈复用到其余版本，类比至其余框架，Dubbo 也存在这些问题，咱们发现即便只反对 Spring Cloud 一个框架都会卷入大量的人力，更不必提其余自研框架。
因而咱们心愿自研一套框架，可能与 RPC 框架无关，做到框架外围能力代码跟下层协定代码的齐全拆散，互不影响，帮忙用户低成本地应答协定框架的版本迭代。
针对多微服务框架协定多样化的问题，Femas 将微服务生命周期形象为一下几个阶段：初始化、实例注册、服务调用的 DNS、流量出站、流量入站、服务销毁。在微服务协定的各个生命阶段做对立拦挡，实现不同协定的轻量、低成本接入。
4.3 插件化设计灵便、可扩大
腾讯外部很多私有云服务都应用了公司外部的组件，比方注册核心用的是北极星，配置核心是七彩石等等。对外交付时，外部组件因为种种原因无奈交付，所以这些我的项目须要同时保护不同的分支，一个用于保护外部组件，另一个则用于保护对外的各种组件。咱们心愿有一套框架，可能实现根底组件的灵便可替换，自在组装 Paas 平台须要的微服务组件能力矩阵，反对 Paas 平台多元化的场景。
针对 Paas 业务场景多元化的问题，Femas 将整体架构分成了三层
·组件层：微服务利用在运行过程中可能须要用到的能力形象成了一个个组件模块，所有的组件模块构建成一个插件容器池。插件容器池的两层数据结构：<interface.classType,<plugin.name,plugin.impl>>。
·平台适配层：适配层会依据用户配置的插件上下文，从插件池中抉择用户须要的组件实现。不同的适配器，会抉择不同的组件插件实现组合，来适应不同平台的需要场景。
·微服务协定扩大层：实现各个协定框架的治理插件，将 Femas 的能力在框架适合的中央中进行埋点，做到不同协定框架的轻量接入，并且能在同一套平台下面对立治理。
4.4 开箱即用的控制台
Femas 提供开箱即用的控制台，升高社区用户 POC 老本，控制台数据长久化默认反对本地嵌入式数据库 RocksDB，和外接的 mysql 数据库，存储外接形式反对控制台的程度扩大。数据长久化反对可扩大，用户可依据形象的数据操作接口，将治理数据存储到其余 K / V 数据库或关系型数据库。
五、Femas 总览
·凋谢：提供管制面微服务管控 API 接口形象封装、反对任意注册核心、APM、配置核心开源组件对接替换，防止繁多技术绑定，能适配大多数企业的根底技术栈。
·规范：定义一套微服务多运行时管控规范蕴含服务发现、服务治理、配置管理、服务调用及调用链日志埋点能力形象。
·治理：通过服务发现、治理能力形象封装实现异构语言、框架、协定对立服务发现、治理立体实现服务互访突破业务烟囱壁垒。
·接入：第一阶段提供侵入式 SDK 形式，将来提供无侵入 Sidecar/agent 接入形式，反对多语言、多框架、多协定低成本接入，升高用户迁徙及上手难度。
·轻量：用户可按需对接撑持组件如注册核心、APM、配置管理组件，各模块利用能力无厂商绑定，可增量插拔扩大能力反对容器部署，资源轻量。
·可观测：集成全局服务依赖拓扑、调用链、监控指标实现端到端利用性能剖析及高效排障能力。
Femas 和北极星
Femas 是 PolarisMesh 社区开源的另外一款子产品，PolarisMesh 对立腾讯微服务生态建设，
polaris 聚焦服务注册发现和治理核心，femas 则专一微服务运行时一站式生命周期治理，两款开源产品对标腾讯微服务畛域不同的指标和布局，生态互联。Femas 作为北极星的上游产品，标准化 API 同样实用于北极星，Femas 的治理 CRD 协定可能齐全兼容北极星，默认反对北极星的服务注册发现和治理核心。
Femas 开源布局
展望未来趋势
腾讯云微服务治理目前有两种状态，别离是 proxy 代理模式和 proxyless 模式。
治理数据面能力下沉通常会面临 JVMTI Agent 与 Envoy 两种技术栈的抉择。比照 JVMTI Agent 与 Service Mesh。
·JVMTI Agent 是基于 Java 原生的技术，可维护性较好，无侵入，没有额定运维老本，同时还具备高 SLA、高性能的长处。但毛病是 premain 会缩短启动工夫，且无奈跨语言，仍须要跟业务过程一起编译上线。
·Service Mesh 的长处是反对跨语言，而且没有业务侧的代码兼容性问题，可能疾速迭代，独立降级。但毛病是独立容器，CPU 耗费较大，问题追踪也绝对艰难，性能提早高于 agent，须要额定保护老本。
从以后微服务治理的发展趋势来看，治理管制面趋于协定对立，造成业界共识规范，一套 CRD 治理标准协议，下发多套治理数据面。而数据面，则展现出生态的多元化，例如多语言的 proxyless，跨语言的 Envoy 代理，JVMTI agent 等技术各施所长，独特推动业务的疾速倒退，减速企业数字化转型。
Femas 开源 RoadMap
后续 Femas 的开源打算：
·开源外围 SDK
·开源开箱即用的可视化 paas 平台
·制订的微服务治理的 CRD 协定，对立管制面治理协定规范
·持续补充微服务运行时能力
·目前 femas 曾经实现的运行时能力有：注册核心治理、服务治理、服务可观测、配置管理，其余运行时能力仍待欠缺。
·TSF 接来下会欠缺监控能力，并反哺到开源社区。
·全链路灰度、分布式事务、分布式工作、分布式锁等运行时能力目前尚未正式对外开放，如果社区需要反响强烈，则会思考对外开放。
·多语言 SDK 反对，go sdk 的反对
·治理能力无侵入，字节码加强和 Proxy 两种形式
·欠缺我的项目文档
·帮忙社区开发者在企业落地
Femas 开源版本来自腾讯 TSF 的局部生产代码，咱们曾经将外围主体局部提交到社区。腾讯开源激励打算激励开发者参加奉献，社区开发对代码或者文档的每一个 issue 探讨或者 PR 咱们都会踊跃驳回，参与者将取得：
·退出腾讯开源我的项目贡献者名单，并展示在腾讯开源官网
·写入具体我的项目的 CONTRIBUTING.md
·腾讯开源贡献者证书（电子版 & 纸质）
·成为线下技术大会 / 沙龙特邀嘉宾
·Q 币及纪念品
GitHub 地址：https://github.com/polarismes…