导语
腾讯经过多年的探索与创新,今天正式开源业界首个云原生标准的一站式微服务管理框架Femas(GitHub地址:https://github.com/polarismesh/femas),通过定义一套开放式的微服务控制面标准协议,实现微服务基础组件的统一管理和调度。
作者 | 童子龙、刘智新、刘阎
编辑 | 王莹
Femas正式开源
企业数字化向云原生演进过程面临诸多痛点,微服务框架不统一、协议多样化、语言异构,纷繁复杂的微服务技术栈,基础组件之间像一座座孤岛,各个基础组件的控制面不能互联,让用户的体验非常割裂,各种历史包袱阻碍了企业平滑过渡到云原生架构的进程。
为了帮助企业快速平滑转型为云原生微服务架构,腾讯经过多年的探索与创新,正式开源业界首个云原生标准的一站式微服务管理框架Femas(GitHub地址:https://github.com/polarismesh/femas),通过定义一套开放式的微服务控制面标准协议,实现微服务基础组件的统一管理和调度。
Femas总览
Femas微服务治理方案
Femas从控制面和数据面两个角度,定义了一套适合当前社区主流技术栈的微服务治理方案,方便企业在不变更基础设施的情况下,落地整套企业级的微服务解决方案。
Femas帮助不同的用户群体过渡到微服务架构:
Femas制定了一套统一的CRD,其中包括了治理规则定义。
同一套控制面规则协议支持多数据面,既可下发规则到SDK/AGENT,也可以下发给Sidecar。
SDK/AGENT支持控制面插件化,SDK支持控制面的数据下发的扩展,例如默认支持PaaS平台的http协议下发;也可以扩展支持K8s的XDS协议下发规则。
支持脱离控制面单独使用,SDK支持在应用本地的YAML格式的规则配置。
Femas功能概览
Femas能力概览
Femas完成了对企业级的微服务架构能力矩阵的标准定义,主要包含四大功能特性:
Dapr作为目前一款比较火热的多运行时框架,Femas和Dapr主要有两大不同:
Femas架构设计
目前,腾讯微服务平台的企业用户体量非常庞大,而且在持续增长,在帮助企业数字化上云的过程中,遇到了很多的挑战,本着服务全球开发者的愿景,我们不断的思考如何用合理的架构去解决这些痛点。
微服务的中间件生态非常的复杂,每个能力领域都有多个厂商提供的组件,缺乏统一的业界共识标准,例如注册发现有北极星PolarisMesh、Consul等,消息队列有Pulsar、Kafka等,各个基础组件像一座座数据孤岛,各个基础组件的控制面无法互联让用户的体验非常割裂,业务开发需要对接、升级基础组件,无形中增加了基础架构和业务开发间的沟通协作成本,使得企业整个技术生态陷入维护成本高昂的困境,因此需要一个稳定合理的软件架构系统去管理调度这些纷繁复杂的基础设施,终结低效、割裂的用户体验。
架构方便、快速迭代升级也是云原生架构的重要价值之一,但传统中间件使得业务系统跟基础设施强耦合,设想如果基础能力需要升级,像全链路灰度、多活等需要联动全局的能力,则需要推动整个业务配合升级,其中成本可想而知,基础能力的轻量化、可移植、无厂商依赖也是个非常重要的考量目标,基础设施维护人员和业务开发人员应该各司其职,业务不应该过多关注基础设施细节,传统中间件因为自身存在的局限性,这些问题都不能很好的解决。
基于传统组件面临的种种问题,Red Hat首席架构师Bilgin Ibryam对云原生领域的微服务架构发展提出了Multi-Runtime的理念。
Runtime作为理论的出发点,Bilgin Ibryam提出现代分布式应用程序的需求分为4类,分别是生命周期(lifecycle)、网络(networking)、状态(state)和绑定(binding)。
找到分布式问题的本质之后,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将整体架构分成了三层:
开箱即用的控制台
Femas提供开箱即用的控制台,降低社区用户POC成本,控制台数据持久化默认支持本地嵌入式数据库RocksDB,和外接的MySQL数据库,存储外接方式支持控制台的水平扩展。数据持久化支持可扩展,用户可根据抽象的数据操作接口,将治理数据存储到其他K/V数据库或关系型数据库。
Femas开源RoadMap
- 目前femas已经完成的运行时能力有:注册中心管理、服务治理、服务可观测、配置管理,其他运行时能力仍待完善。
- TSF接来下会完善监控能力,并反哺到开源社区。
- 全链路灰度、分布式事务、分布式任务、分布式锁等运行时能力目前尚未正式对外开放,如果社区需求反响强烈,则会考虑对外开放。
femas技术交流群,欢迎大家扫码进群交流
往期
推荐
扫描下方二维码关注本公众号,
了解更多微服务、消息队列的相关信息!
解锁超多鹅厂周边!
戳原文,查看更多Femas的信息!
点个在看你最好看