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