文章图片
找到分布式问题的本质之后 ， 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平台多元化的场景 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。