摄影网站建设解决方案,显示网站翻页代码,网站推广策划方案大数据精准获客,小孩子做手工做游戏的网站简介#xff1a; 做过微服务开发的开发者相信对 Dubbo 都不陌生#xff0c;Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内#xff0c;Dubbo 的多语言版本在这两年呈现了良好的发展势头#xff0c;其中#xff0…简介 做过微服务开发的开发者相信对 Dubbo 都不陌生Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内Dubbo 的多语言版本在这两年呈现了良好的发展势头其中Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备其它几种主流的多语言版本在社区也有提供。 作者 | 陆龟 来源 | 阿里巴巴云原生公众号
本文整理自作者在3月20日云原生中间件 Meetup 上海站的分享。回复关键字“中间件”可以获取视频录播地址和 PPT。
就在今天Dubbo 社区刚刚发布了 3.0 的首个预览版本 - 3.0.0.preview。 https://github.com/apache/dubbo/releases/tag/3.0.0.preview
本文将和读者一起解读 Dubbo3 的首个 preview 版本一方面我们将深入分析 Dubbo3 云原生变革的核心理念另一方面我们将逐个解读 preview 版本的核心功能。
做过微服务开发的开发者相信对 Dubbo 都不陌生Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内Dubbo 的多语言版本在这两年呈现了良好的发展势头其中Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备其它几种主流的多语言版本在社区也有提供。
云原生视角的微服务变革
Dubbo 主要解决微服务开发、运行域问题它和微服务的编程、通信、流量治理等密切关联因此在探寻 Dubbo3 的云原生变革之前我们先尝试从云原生视角观察云原生基础设施带给微服务架构和实践的变革进而总结出 Dubbo 这样一个和微服务实践密切相关的框架所面临的变革与挑战。 微服务在让业务开发演进更灵活、快捷的同时也带来了一些它独有的特征和需求如微服务之后组件数量越来越多如何解决各个组件的稳定性如何快速的水平扩容等。
这些诉求尤其是运维、交付相关诉求如微服务组件的生命周期、网络、通用服务绑定、服务状态管理等并不应该是开发人员关注的重点因为它们已经完全脱离了业务逻辑开发人员更愿意专注在有业务价值组件上但这个层次的诉求却是实现微服务交付的关键能力。开发者期望由底层基础设施来提供此类能力支持而处于不同阶段发展的基础设施却不一定具备这样的能力因此在微服务软件架构和底层基础设施之间就出现了一条鸿沟我们需要有组件能填补这一鸿沟让微服务组件能更好的接入底层基础设施。 这里从一个更抽象的层面尝试用两条发展曲线演示了软件架构诉求与底层基础设施能力丰富度之间的关系。总体上两者之间的发展关系可拆分为两个阶段。
在第一个阶段软件架构这条红色的线从单体应用、到面向服务的软件架构、再到微服务架构快速演进从而也提出了上文我们讲到的对基础设施对交付的诉求这个时候基础设施层还多是以定制化的方式来满足软件架构的诉求如过往的集中化的 ESB、各个不同的 PaaS 平台等。
第二个阶段是从容器、Kubernetes 为代表的基础产品的出现开始蓝线与红线之间的增长速度被快速拉近以云原生技术为代表的底层基础设施丰富度得到了极大改善它们不再只是被动的满足微服务开发的诉求而是开始抽象更多的软件诉求到底层的基础设施将它们下沉为基础能力并开始以统一的、标准化的形式向上输出以满足微服务对交付、运维等的诉求不仅如此通过更深入的主动创新、持续的向上释放能力底层基础设施还开始反过来影响微服务的开发、接入方式如 sidecar、dapr 等模型。
Dubbo3 的云原生变革
通过上文云对原生基础设施演进给传统微服务带来变革的分析我们得出以 Dubbo 为代表的微服务开发框架应重点在以下方向突破与变革。
更多的微服务组件及能力正下沉到以 Kubernetes 为代表的基础设施层。传统微服务开发框架应剔除一些冗余机制积极的适配到基础设施层以做到能力复用微服务框架生命周期、服务治理等能力应更好地与 Kubernetes 服务编排机制融合。以 Service Mesh 为代表微服务架构给微服务开发带来的新的选择但由于 Mesh 架构本身的复杂性其距离大规模生产落地还有一段距离。我们相信基于 ServiceMesh 的体系会逐步从孵化器走向成熟期会有越来越多的企业采用 Service Mesh技术但在未来在很长一段时间内基于服务框架的传统微服务体系还将是主流长期仍将占据半壁江山。
我们不妨回想一下在云原生基础设施能力被充分释放前围绕 Dubbo 构建微服务时它给微服务开发提供了哪些能力或者我们期望它提供哪些能力 Dubbo2 提供了包括服务注册、服务发现、负载均衡、流量治理等相当丰富的能力当然还包括微服务最需要的远程通信能力这些能力很好地解决了微服务的诉求。
而在云原生架构之下我们需要重新审视Dubbo2 的哪些能力是冗余的是需要接入基础设施的哪些能力是已经不适合云原生时代的需要被重构的 首先是接入云原生基础设施后一些能力出现了重复像服务定义、服务注册、甚至是服务治理能力在不同层面基础设施中出现了重复需要 Dubbo3 作出适配与调整以更好的解放业务开发效率利用好这些基础能力。
其次是 Dubbo 在微服务架构中的最基本的能力RPC 远程通信。通信协议和数据传输格式的标准化应该算是 Dubbo2 面临的又一重要挑战在云原生背影下协议、数据定义、传输格式的标准化和穿透能力成为更需要优先考虑的指标纵然私有协议具有更高效、灵活的潜力但考虑到云原生下多语言、组件间互通、网关等代理设备友好性、避免厂商锁定等诉求在 Dubbo3 中私有协议都应该被摒弃转而拥抱基于 HTTP/2 的更通用的协议采用跨语言的更通用的数据定义和传输格式。
最后是关于服务治理能力Dubbo 的服务治理能力应该充分结合底层基础设施的特点比如之前绑定 ip 的流量过滤方案在地址不固定的 Kubernetes 平台就已不再适用另外流量治理也要充分的与调度平台的灰度发布、动态扩缩容能力整合起来考虑到未来微服务可能会有多种不同的部署形态下文会讲到Dubbo3 应该制定一种能适用于各种部署形态的路由规则。
从云原生视角来说Dubbo3 的核心能力基本上也就成围绕以上几点分析展开的主要涉及抽象全新的服务发现模型、定义下一代的更能用的 RPC 协议与数据传输格式、服务治理能力重构等。接下来我们就看看 3.0 preview 中这些能力的具体实现。
Preview 版本功能速览
就在今天Dubbo 3.0.0.preview 版本正式通过了 Apache 社区投票并完成了正式发布作为 3.0 的首个发布版本代表了社区 3.0 版本的全面启动也展示了未来 3.0 的发展方向。当然我们要意识到 preview 版本还远未达到生产可用它只是为了让大家快速、方便了解 Dubbo3 的一个预览版本离正式版本甚至 alpha 版本还有一段时间要走具体大家可关注文后的 Dubbo Roadmap。
以下 preview 版本发布的几个核心特性
全新的服务发现模型下一代基于 HTTP/2 的 RPC 协议Triple服务治理重构全新路由规则 性能提升 百万节点级水平扩容调用链路 QPS 性能提升
在 preview 以上能力中特别值得注意的是得益于 Dubbo3 与 HSF 的融合Dubbo3 的整体性能也有望得到大幅提升。
Preview 版本是从架构层面对 Dubbo 的一次全面升级接下来社区一方面会从功能完善度、稳定性等几个方面继续增强 3.0 版本并将在 6 月份发布首个稳定版本另一方面社区将兑现更多新的功能。首先接下来即将交付的是 Kubernetes Service 集成而 Proxyless Mesh、基于反压的智能流量调度等功能正在前期的调研或开发阶段。
下面我们就选取以上三个核心功能深入了解它们的实现机制。
1. 全新服务发现模型
下图是 Dubbo2 的服务发现模型Provider 注册服务地址Consumer 经过注册中心协调并发现服务地址进而对地址发起通信这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于它把 “RPC 接口”的信息也融合在了地址发现过程中而这部分信息往往是和具体的业务定义密切相关的。 而在接入云原生基础设施后基础设施融入了微服务概念的抽象容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示基础设施即承担了注册中心的职责又完成了服务注册的动作而 “RPC 接口”这部分信息由于与具体的业务相关不可能也不适合被基础设施托管。
在这样的场景下对 Dubbo3 的服务注册发现机制提出了两个要求
Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型并确保这部分模型足够合理以支持将地址的注册行为和存储委托给下层基础设施Dubbo3 特有的业务接口同步机制是 Dubbo3 需要保留的优势需要在 1 中定义的新地址模型之上通过框架内的自有机制予以解决。这样设计的全新的服务发现模型在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。 在架构兼容性上如上文所述Dubbo3 复用下层基础设施的服务抽象能力成为了可能另一方面如 Spring Cloud 等业界其它微服务解决方案也沿用这种模型在打通了地址发现之后使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。
Dubbo3 服务发现模型更适合构建可伸缩的服务体系这点要如何理解这里先举个简单的例子来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化假设一个微服务应用定义了 100 个接口Dubbo 中的服务则需要往注册中心中注册 100 个服务如果这个应用被部署在了 100 台机器上那这 100 个服务总共会产生 100 100 10000 个虚拟节点而同样的应用对于 Dubbo3 来说新的注册发现模型只需要 1 个服务只和应用有关和接口无关 只注册和机器实例数相等的 1 100 100 个虚拟节点到注册中心。在这个简单的示例中Dubbo 所注册的地址数量下降到了原来的 1 / 100对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是地址发现容量彻底与业务 RPC 定义解藕开来整个集群的容量评估对运维来说将变得更加透明部署多少台机器就会有多大负载不会像 Dubbo2 一样因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
2. 下一代通信协议Triple
我们将 Dubbo3 的新协议命名为 Triple有代表第 3 代协议的意思。在云原生背景下Triple 协议需要解决两大问题
通信协议和数据传输格式的标准化问题。这涉及到 RPC 协议、数据定义、数据传输等环节未来可移植性、不被厂商锁定会成为每个上云企业用户的诉求组件内的私有协议和特有数据格式必然会成为很多用户选型的顾虑。穿透性、通用性问题。在 Mesh 等架构设想下微服务甚至所有组件的通信都要经过 sidecar 代理转发理论上Sidecar 是要透明的转发流量的收到什么就转发什么起码 payload 不应该是 Sidecar 关注的而 Sidecar 在某些时候也需要感知流量内容的因为它要基于些做流量的调度这个时候Triple 就要做到足够通用 -- 让所有的 Sidecar 都能在预期的地方取到其关注的元数据而不用解析整个 payload。除了以上两个核心问题Triple 协议还需要被设计用来支持更多的业务语义。
协议应该提供更完善的请求模型除了 Request/Response 模型还应该支持 Streaming 和 Bidirectional。在性能上新的协议应该保留 request Id 机制以避免 HOL 带来的性能损耗。新协议应该易于扩展包括但不限于 Tracing、Monitoring、BackPressure 等支持。
基于以上需求Triple 协议是完全基于 HTTP/2 之上构建的另外Triple 协议将会做到完全兼容 gRPC 协议在服务定义、数据格式定义以及传输格式上Triple 将更增加对 Protobuf 的支持。
3. 统一的路由规则
Dubbo3 会对服务治理规则进行全面的重构以更好的适应云原生基础设施的变革。
当前的 3.0 preview 版本提供了一个重构后的路由规则机制原型虽然当前版本的实现还需要继续增强但从设计理念上我们可以解读出Dubbo3 期望提供一种跨平台、跨语言、跨多种部署架构的通用路由规则。
随着微服务对治理需求的挖掘Dubbo2 路由规则除了在语义表达上不能涵盖所有场景之外更为重要的是其基于特定语言、特定主机 ip 的过滤机制已不再适应底层调度平台的工作机制Dubbo3 需要引入一种全新设计的路由规则。而对于“跨多种部署架构” 这个点我们设想未来以 Dubbo 构建的微服务会有三种部署架构传统 SDK、基于 Sidecar 的 Service Mesh以及脱离 Sidecar 的 Service Mesh这三种部署形态都将由 Dubbo3 统一的路由规则进行治理。
基于 Sidecar 的 Service Mesh经典的 Mesh 架构独立的 sidecar 运行时接管所有的流量。脱离 Sidecar 的 Service Mesh变种 Mesh 架构没有 sidecar 运行时富 SDK 直接通过 xDS 与控制面通信我们将在后续发布关于 Proxyless 模式更详细的解读。实践中的 Dubbo3
云原生微服务变革在各大厂商内部早已展开相比于当前开源社区的 preview 版本Dubbo3 在阿里巴巴的开发与实践已经在逐步铺开部分功能已经在阿里巴巴的部分业务线上得到了规模化验证考拉并且更多的功能和业务线也将进入试点、推广阶段饿了么、钉钉等。有一点是值得特别提及的是在接下来阿里巴巴的微服务架构升级战略中Dubbo3 将成为阿里巴巴经济体未来唯一的标准服务框架它将逐步在所有业务线取代 HSF 和 Dubbo2并且我们期待在接下来的 1-2 年 Dubbo3 内能覆盖大多数重要的业务线。
说在这里有必要提一下阿里巴巴的微服务框架演进历程。大概在 2011 年阿里巴巴开源了 Dubbo2 这一款服务框架并获得极大成功在 Dubbo2 开源不久在阿里巴巴内部又发展出了一款全新的服务框架 -- HSF两者在设计理念上是高度相似的而经过这么些年的发展HSF 得以跟随阿里巴巴的业务系统更快速的成长由其是在大集群、大流量治理下展现出了更好的性能和稳定性。在阿里云原生微服务战略下整合各个优秀的框架并发展统一品牌的 Dubbo3 被纳入发展规划在此背景下Dubbo3 实现了Dubbo2 与 HSF 的融合并将推动实现内、外技术栈的统一。
除了阿里之外工商银行等标杆用户也已启动了对 Dubbo3 项目的试点。从社区角度来说preview 预览版本的发布只是开始未来随着阿里巴巴、工商银行等更多标杆用户的全面落地将推动项目更快、更高质量的发展助力项目保持持续的创新能力和社区生命力。
未来规划Roadmap
以下是 Dubbo3 的 Roadmap截止此文发稿社区已经完成了 3.0 preview 版本的发布。 在 6 月份我们期望能迎来 Dubbo3 的首个社区正式版本。
随后一直到下半年的 11 月份我们将重点投入在对 Kubernetes、ServiceMesh 架构的支持上中间当然也包括了对服务治理规则的全面重构。
在此之后我们将开始在服务柔性上的尝试以期提供一种能更高效的利用资源且能提高系统稳定性的流量高度机制。
本文开篇关于云原生微服务变革部分思想引自阿里云高级技术专家、CNCF TOC 张磊 《Microservices - A Cloud Native View》一文分享。
原文链接
本文为阿里云原创内容未经允许不得转载。
