导读
企业数字化向云原生演进过程面临诸多痛点,微服务框架不统一、协议多样化、语言异构,纷繁复杂的微服务技术栈,基础组件之间像一座座孤岛,各个基础组件的控制面不能互联,让用户的体验非常割裂,各种历史包袱阻碍了企业平滑过渡到云原生架构的进程。
为了帮助企业快速平滑转型为云原生微服务架构,腾讯经过多年的探索与创新,今天正式开源业界首个云原生标准的一站式微服务管理框架Femas,通过定义一套开放式的微服务控制面标准协议,实现微服务基础组件的统一管理和调度。数据面基于多运行时的架构设计,基础能力标准化、模块化、灵活可扩展,帮助开发者将云原生中间件生态无缝的集成到业务系统中,实现分布式微服务运行时生命周期的一站式管理,让企业能快速便捷构建基于云原生的大规模分布式架构。
一、背景
云原生技术通过资源的池化和秒级的弹性,给企业数字化转型带来的极大的价值和便利,降低资源成本、提高研发效率、实现快速交付等价值越来越被业界认可。微服务作为云原生领域中更开放、轻量、敏捷高效的技术架构,也得到了迅猛的发展,根据O’Reilly公布的行业市场调研报告显示,全球大约80%左右的企业都在使用微服务来构建业务系统。越来越多的企业探寻云原生化的微服务架构转型,使得业务更好的上云,享受云原生的技术红利。
O’Reilly微服务市场行业调研报告
理想美好,实践不易,很多企业的云原生微服务架构转型之路并不顺滑,在转型的过程中面临诸多挑战:
针对上述挑战,企业只有通过合理的设计软件架构,才能充分享受云带来红利。未来微服务治理的架构将沿着以下几个方向演进:
在调研了当下主流社区的技术方案和用户需求后,我们发现以Envoy为代表的proxy代理模式虽然对业务方透明,但是对维护者带来的是性能延迟、以及高昂的额外学习和运维成本,企业自建微服务落地相对困难。相比之下,proxyLess的Mesh方式更贴近开源社区用户。
在此基础上,我们经过技术探索和创新,在遵循面向分布式设计、面向配置、高 SLA、可观测性、安全性等云原生架构设计原则下,推出proxyLess模式的多运行时微服务标准框架Femas,通过定义一套开放式的微服务管控标准,帮助开发者快速接入并理解微服务架构,帮助用户实现异构系统微服务的统一管理。
二、Femas简介
随着越来越多的企业投身数字化上云的浪潮,腾讯云微服务平台TSF历经多年磨砺,支撑了腾讯内部智慧零售、财付通、王者荣耀等核心业务系统,及第七次人口普查、某四大行及国内头部保险等政务、金融头部客户海量业务的构建与发展,Femas 作为腾讯云 TSF 的开源产品形态,正式对社区开发者开放TSF在生产环境中的部分核心源代码,开源框架聚焦微服务运行时,提供给多框架统一服务发现、南北及东西流量治理、服务可观测、配置管理等一站式微服务管控能力,解决企业微服务架构转型中异构框架复用难、激增流量管控难、排障恢复耗时长等核心问题。
Femas从控制面和数据面两个角度,定义了一套适合当前社区主流技术栈的微服务治理方案,方便企业在不变更基础设施的情况下,落地整套企业级的微服务解决方案。
数据面:Femas运用Multi-runtime的架构设计,将微服务底层的核心能力标准化、模块化,将微服务领域割裂的基础组件通过合理的架构组装在一起,来满足多元化的微服务场景,轻量化、可移植、低成本、无云厂商绑定。
控制面:Femas提供统一的控制面标准协议,以及一套包含了治理、资源等微服务概念的CRD定义,同时也支持多数据面下发。
Femas帮助不同的用户群体过渡到微服务架构:
2.1 微服务管理的统一
2.2 控制面治理协议标准的统一
三、功能特性
Femas能力概览
Femas完成了对企业级的微服务架构能力矩阵的标准定义,主要包含四大功能特性:
3.1 注册中心管理
Femas实现了对主流开源注册中心的管理(目前支持Consul、Nacos、Eureka),包括集群管理,服务管理,用户在Paas平台配置注册中心集群,即可查看集群状态和服务列表。
在服务注册发现的底层技术中,Femas实现了一套标准的注册发现API接口,用户可以直接使用Femas提供的SDK注册发现到主流的开源注册中心,能够在一套平台上实现多套注册中心集群的管理。
Femas控制台:多套注册中心集群的管理
3.2 服务治理
Femas的服务治理能力由TSF的治理能力演化而来,提供服务鉴权、API管理、熔断降级、访问限流、服务注册发现、服务路由、服务事件等治理能力。在Femas中,您可以实现:
Femas打通了proxy代理模式和proxyless模式间的服务互访,用户可以实现任何场景下的服务治理,实现云原生技术栈服务治理的统一管理。
Femas控制台:服务治理中心
3.3 服务可观测
在服务监控方面,提供全方位立体的监控体系,帮助用户快速排障。Femas在设计之初就支持业界标准的APM协议,希望将应用侧agent探针收集到的数据,输出到多个backend管控端,实现应用侧数据采集和协议的标准统一。相关技术实现方案如下:
用户在控制台上可以通过宏观视角和微观视角,了解到服务调用链上的详细信息,调用链可视化数据支持可扩展,用户可根据抽象的tracing查询接口,从其他backend(例如jaeger、skywalking)管控端获取可视化数据,默认支持skywalking的管控端。
宏观视角:依赖拓扑图查看服务之间和上下游组件(MySQL、Redis、MongoDB)间的依赖关系和调用情况。例如服务上下游调用关系、服务调用的基本Metrics统计、服务与中间件组件依赖关系等
微观视角:通过调用链分析瓶颈和出错服务。提供调用链ID、基于调用耗时、调用时间排序,支持调用链树形展示,支持异常类型及异常堆栈展示
3.4 配置管理
Femas实现了一套标准的配置API接口,配置分为治理规则、应用配置,用户实现配置的分布式管理,以及应用配置管理、配置热更新等标准能力。
3.5 分布式任务调度
实现分布式定时任务的调度和管理。用户通过控制台即可配置、管理定时调度任务,查询任务的执行记录和执行日志,配置任务超时重试机制,在保证高可靠的同时,让用户通过简单的控制台操作即可进行任务的调度管理。
3.6 分布式事务
基于 TCC 模式提供了 AT 和 MT 两种模式的分布式事务管理功能。对于跨数据库、跨服务的分布式场景,用户可以通过控制台查看事务运行情况并进行超时事务处理,保证事务的一致性。
3.7 全链路灰度
全链路灰度基于微服务部署组的泳道设计,全链路灰度发布场景中,第一步需要划分泳道,将多个应用的某个版本划入同一泳道,在全链路灰度验证时,在泳道的入口应用做规则校验,命中流量分拨规则之后,按照各个泳道里面规划的路线做流量的全链路治理。
3.8 其他微服务运行时能力
Femas对于运行时的能力并不设置边界,旨在帮助用户更好的实现微服务化转型的同时,能够更简单的去运维和理解微服务。运行时能力本身会比较割裂,我们也希望通过一套标准的微服务定义,以及控制台的搭配,将运行时的所有能力能够串联起来,而非独立的去使用。
未来我们将会把上述的可观测性增加Event,并且将治理能力比如路由、熔断等,和可观测性结合,帮助用户对微服务中每个动作带来的影响都清晰明了。同样的,对于当前还没有涉及到的诸如state stores的状态管理、publish&subscribe的消息管理、分布式锁、分布式ID等,我们也将会和可观测性,以及从微服务的视角去进行联动。
3.9 与Dapr的区别
Dapr作为目前一款比较火热的多运行时框架,Femas和Dapr主要有两大不同:
四、架构设计
从当前企业遇到的痛点出发,是探索一个新技术的最好切入点,目前,腾讯微服务平台的企业用户体量非常庞大,而且在持续增长,在帮助企业数字化上云的过程中,遇到了很多的挑战,本着服务全球开发者的愿景,我们不断的思考如何用合理的架构去解决这些痛点。
4.1 标准化、模块化
微服务的中间件生态非常的复杂,每个能力领域都有多个厂商提供的组件,缺乏统一的业界共识标准,例如注册发现有北极星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调用
4.2 微服务协议接入标准的统一
腾讯云微服务平台数据面在演进初期,在适配每个框架协议的时候,都会投入大量的成本,例如Spring Cloud本身版本众多,D到H每个版 本都有变化,甚至到了的2020结构大变。新增feature需要cherry-pick到每个版本代码上,利用了当前版本特性的功能,则无法复用到其他版本,类比至其他框架,Dubbo也存在这些问题,我们发现即使只支持Spring Cloud一个框架都会卷入大量的人力,更不用提其他自研框架。
因此我们希望自研一套框架,能够与RPC框架无关,做到框架核心能力代码跟上层协议代码的完全分离,互不影响,帮助用户低成本地应对协议框架的版本迭代。
针对多微服务框架协议多样化的问题,Femas将微服务生命周期抽象为一下几个阶段:初始化、实例注册、服务调用的DNS、流量出站、流量入站、服务销毁。在微服务协议的各个生命阶段做统一拦截,实现不同协议的轻量、低成本接入。
4.3 插件化设计灵活、可扩展
腾讯内部很多公有云服务都使用了公司内部的组件,比如注册中心用的是北极星,配置中心是七彩石等等。对外交付时,内部组件由于种种原因无法交付,所以这些项目需要同时维护不同的分支,一个用于维护内部组件,另一个则用于维护对外的各种组件。我们希望有一套框架,能够实现基础组件的灵活可替换,自由组装Paas平台需要的微服务组件能力矩阵,支持Paas平台多元化的场景。
针对Paas业务场景多元化的问题,Femas 将整体架构分成了三层:
4.4 开箱即用的控制台
Femas提供开箱即用的控制台,降低社区用户POC成本,控制台数据持久化默认支持本地嵌入式数据库RocksDB,和外接的mysql数据库,存储外接方式支持控制台的水平扩展。数据持久化支持可扩展,用户可根据抽象的数据操作接口,将治理数据存储到其他K/V数据库或关系型数据库。
五、Femas总览
Femas和北极星
Femas是PolarisMesh社区开源的另外一款子产品,PolarisMesh统一腾讯微服务生态建设。
polaris聚焦服务注册发现和治理中心,femas则专注微服务运行时一站式生命周期管理,两款开源产品对标腾讯微服务领域不同的目标和规划,生态互联。Femas作为北极星的下游产品,标准化API同样适用于北极星,Femas的治理CRD协议能够完全兼容北极星,默认支持北极星的服务注册发现和治理中心。
Femas开源规划
展望未来趋势
腾讯云微服务治理目前有两种形态,分别是proxy代理模式和proxyless模式。
治理数据面能力下沉通常会面临 JVMTI Agent 与Envoy两种技术栈的选择。对比 JVMTI Agent 与 Service Mesh。
从当前微服务治理的发展趋势来看,治理控制面趋于协议统一,形成业界共识标准,一套CRD治理标准协议,下发多套治理数据面。而数据面,则展现出生态的多元化,例如多语言的proxyless,跨语言的Envoy代理,JVMTI agent等技术各施所长,共同推动业务的快速发展,加速企业数字化转型。
Femas开源RoadMap
后续Femas的开源计划:
Femas开源版本来自腾讯TSF的部分生产代码,我们已经将核心主体部分提交到社区。腾讯开源激励计划鼓励开发者参与贡献,社区开发对代码或者文档的每一个issue讨论或者PR我们都会积极采纳,参与者将获得:
GitHub地址:https://github.com/polarismesh/femas