介绍：随着Dubbo与HSF的融合，我们在整个开源体系中展示了HSF更多的能力，让更多的人通过使用Dubbo来更好的使用Dubbo构建一个面向服务的系统，就像阿里巴巴之前使用的HSF。2011年，阿里B2B团队决定将项目开源，并在一年内收获了大量不同行业的用户；2014年，由于团队调整，Dubbo暂停更新；2017年，Dubbo开源重启；2020年，阿里内部开始整合HSF和Dubbo；2021年3月，Dubbo3.0Preview即将发布……从2011年到2021年，Dubbo开源十年。十年对于风起云涌的云计算领域来说是一段漫长而充满变数的岁月，但Dubbo不仅没有成为这个时代浪潮中被遗忘的“前浪”，更迎来了全面的云原生核心技术栈。云原生时代。升级。本文是对阿里巴巴集团服务架构负责人贝微的采访。他还在阿里巴巴负责HSF、Dubbo和SpringCloudAlibaba。本文介绍他在2017年接手Dubbo后社区的进展，期待开源十年的Dubbo如何走云原生之路。2017年，我开始接手Dubbo项目后，我们表示会重新维护这个项目，得到了很多积极的反馈。随着对这个项目的深入了解，我发现国内很多大型厂商甚至传统国企都在广泛使用。项目，才意识到责任在身上。Dubbo3.0Preview版本将于3月发布。我们准备了一系列Dubbo3.0预览版电子书，点击立即下载《Dubbo 3.0 前瞻》，借此机会谈谈Dubbo重启开源后的常见问题：·两年前从Apache毕业，我们做了什么不到一年？·阿里内部如何整合Dubbo和HSF？尺度是多少？您如何看待SpringCloud和gRPC？3.0会发生什么？自从我2017年开始负责这个项目后，一些开发者担心Dubbo只是阿里主导的一个KPI开源项目，更担心这个项目能不能继续发展，不会更新。在这种情况下，我只是将其置于中立位置。Apache基金会是一个不错的选择。正是这个决定让Dubbo迅速从Apache基金会毕业：2019年5月21日，Dubbo在15个月后从Apache基金会毕业。事实证明，将Dubbo捐赠给Apache，让Dubbo成为一个社区主导的项目，是一个非常正确的决定。根据X-lab开放实验室最新发布的《2020 年微服务领域开源数字化报告》，Dubbo的开源活跃度全球排名693，在微服务框架中排名第五。参与社区建设的开发者人数已超过10,000人。代码贡献量已经超过了阿里员工。资料来源《2020 年微服务领域开源数字化报告》Dubbo项目从Apache毕业不到2年。整个社区有21个PMC成员，61个committer，贡献者多达370个。在过去的一年里，Dubbo在多语言构建方面从社区收获了JS、Python、Erlang、PHP、Go的实现。衷心感谢千里网、携程网、乐信等开发者捐赠或提交这些多语言版本的大部分代码，为社区带来丰富的多语言支持解决方案。在余宇的带领下，Dubbo-go可以说是目前多语言版本中最为活跃的一个分支。围棋子社区非常活跃，企业用户不断增长。目前，Dubbo-go在1.5版本已经和Dubbo打成平手。Java2.7的特点；目前正在与Java携手规划Dubbo3.0的云原生路线图。我们对这个大版本Dubbo3的定义是云原生的，阿里背书的。该计划分为三个版本迭代，在后面的Dubbo3路线图中有详细说明。Dubbo3.0正在紧锣密鼓的开发中。核心功能包括Dubbo3协议、应用级服务发现、新路由规则等，go和java版本有望同时完成上述所有功能。预览版将于3月底向社区发布。社区近2年的经验让我确信，核心团队中的少数工程师很难继续保持纯粹的开源情怀。全国有几十万家公司在使用Dubbo。光靠我们小团队的力量是不够的。我们希望社区中的开发者能够更多地参与进来。对于Dubbo来说，开发者最初是出于什么原因进入并为项目做出贡献并不重要。重要的是我们希望保持整个社区的开放，即使个别工程师只是想在未来找份工作参与社区，我觉得这种想法很正常，毕竟贡献项目会占据一个开发者的空闲时间很多，我们也希望这个项目能够对大家有所帮助。我面临的第二大问题是：阿里内部不使用Dubbo，如何获得开发者的信任？熟悉阿里技术史的同学可能知道，淘宝的HSF项目也是一个中间件服务框架，和Dubbo做的东西重合度很高。在Dubbo的开源过程中，很多开发者批评阿里自己没有使用Dubbo。这也是我们一直担心的：阿里内部自研系统、商业产品技术和开源项目，三者的技术路线一直没有机会融合。随着阿里自研系统向云端的迁移，整合的机会终于来了。2020年，阿里云提出“三位一体”理念，即形成“自研技术”、“开源项目”、“商业产品”的统一技术体系，实现技术价值最大化。HSF目前以Dubbo3.0为核心，内部特性以Dubbo插件的形式存在，并将HSF在阿里巴巴集团内部大规模场景的高并发、高性能优化经验应用到Dubbo3.0核心，实现内部和外部功能的统一，让社区和客户都可以使用这些高质量的体验；另一方面，借助社区的发展，Dubbo3.0的云原生相关功能得到了进一步完善。通过“三位一体”实现与社会各界的开放共赢。我的老领导林浩和阿里，人称毕大师，今年因为HSF的设计开发获得了中国计算机学会杰出工程师奖。他在颁奖采访中提到：作为一名工程师，很大的成就感来自于自己所做的事情。我做的技术被公司大规模使用，可以对公司的业务发展起到很大的支撑作用；更大的成就感来自于我做出的技术背后的思想和实现思路，可以影响到中国各地。大型互联网公司和企业正在拥抱微服务。通过Dubbo和HSF的融合，我们在整个开源系统中展示了HSF更多的能力，让更多的人使用Dubbo更好的构建服务化系统，就像之前阿里巴巴使用HSF一样。2020年双11，Dubbo3.0进入集团电商业务落地阶段，我们将在电子书中与大家分享一些实践经验。在Dubbo沉寂的岁月里，出现了很多新的服务框架。Dubbo和SpingCloud是什么关系？两者选其一就够了吗？Dubbo和gRPC有什么区别？Dubbo和SpringCloud如何选择？一直以来，总有开发者喜欢拿Dubbo和SpringCloud进行比较。提到这两个名字，第一反应往往是应该选哪个，而不是两者应该如何搭配使用。在我看来，这主要是技术选择的问题，以及用户对后续切换成本的顾虑。其实这是一个误会，两人的关系也不是非此即彼。今天的Dubbo已经成为SpringCloudAlibaba中的重要技术组件。Dubbo服务和SpringCloud服务可以完美的相互调用。未来，Dubbo3.0将进一步简化Dubbo和SpringCloud混合场景下服务基础设施的部署。SpringCloud依托于Spring，成为Java开发的标准框架已经是不争的事实。结合大量的行业经验，逐步抽象出一套微服务通用架构模式标准。这套标准的好处是可以让开发者非常方便的开发微服务软件产品，并且在整个Spring生态的支持下，成为了开发者的“一揽子”解决方案。与SpringCloud不同的是，Dubbo在设计之初就将可扩展性和灵活性放在了非常重要的位置。Dubbo易于与他人集成，他人也可轻松集成Dubbo。同时，Dubbo已经得到大量用户的验证，是阿里在服务领域不断践行的产品。这两点目前是SpringCloud所不具备的。随着Dubbo恢复更新，其场景的丰富性和稳定性也得到了极大的提升，并在众多龙头企业得到广泛应用。回到很多开发者在技术选型上的顾虑：两个框架不是非此即彼。相反，得益于SpringCloudAlibaba的出现，用户可以在这两个框架之间轻松切换，甚至在未来可以完美协同工作。SpringCloud拥有强大的国际社区。作为社区的重要一员，阿里巴巴也贡献了SpringCloudAlibaba的实现，是目前SpringCloud整个体系中最完整、持续更新的实现。随着SpringCloudAlibaba的出现，Dubbo2.7已经可以很好的运行在SpringCloud体系下。通过在SpringCloudAlibaba中集成Dubbo，SpringCloud应用可以调用原生发布的Dubbo服务，原生Dubbo客户端也可以调用SpringCloud发布的Dubbo服务。这得益于2.7中服务自省的实验项目，以及Dubbo在SpringCloud端的适配。在正在进行的3.0大版本中，这个实验项目已经演化为原生的应用级服务注册机制。通过这个特性，可以让SpringCloud应用和Dubbo应用在未来更加完美的混合。用户可以为SpringCloud和Dubbo复用同一套服务发现、服务配置、服务管理系统。Dubbo与Spring互通需要额外搭建网关将成为历史。用户可以零成本在两者之间切换，或者针对不同的场景选择不同的框架，甚至可以在同一个应用中混合使用。在Dubbo和SpringCloud混合部署场景下，终于去掉了业界常规的Proxy集群，整个系统的架构更加简单和稳定。在Dubbo3.0版本中，整个团队将继续演进应用级服务注册的思路。期待通过这项工作，SpringCloudAlibaba和Dubbo在注册数据模型上实现高度统一，复用同一套服务注册中心，进一步简化混合场景中的schema。此外，我们团队也在积极开发SpringCloudAlibaba生态。作为国内Java界最有影响力的团队之一，阿里中间件团队一直密切关注Spring项目，通过Spring的封装提升阿里的中间件开发体验。阿里巴巴电子商务系统中的大部分应用程序都已经启动。当SpringCloud开始有影响力的时候，我们主动通过SpringCloud集成阿里巴巴开源组件就成了水到渠成的事情。目前SpringCloudAlibaba已经支持Nacos作为服务注册中心和配置中心，Sentinel作为限流器，作为分布式事务组件的Seata，作为分布式消息组件的RocketMQ，当然还有作为RPC组件的Dubbo，全面替代了已经宣布停止更新的SpringCloudNetflix全家桶。此外，为了加速国内工程师对SpringInitializr的接入，团队还提供了通过托管在阿里云上的start.aliyun.com快速生成SpringCloudAlibaba应用的能力。无论从GitHub的项目活跃度数据还是关注度数据，毫不夸张地说，SpringCloudAlibaba已经成为SpringCloud框架中的事实标准。您如何看待gRPC？我们从不回避gPRC，它是一个值得尊敬的对手，也是云原生基础设施之间通信协议的事实标准。但是Dubbo的优势在于，它不仅仅是一个RPC，更是一个具有强大治理能力的服务框架。我们认为：Dubbo是带电池的gRPC。我们从gRPC中学到的最有价值的东西是反思Dubbo2在协议设计上的不足，并开始关注云原生支持领域的两个重要问题：多语言支持和网关/Mesh解析友好性。在Dubbo3.0中，协议的新版本是重中之重。除了解决以上两个问题，兼容gRPC协议也是新协议的设计目标之一。gRPC有几个明显的优势：它在支持HTTP/2协议方面走在了前列，提供了非常丰富的多语言库支持，无缝对接了以Google为首的众多云原生基础设施。gRPC和流行的Mesh等云原生技术已经构建了比较完整的微服务技术栈。这个技术栈的实现好像是基于gRPC的微服务方案。但是gRPC框架本身仍然专注于RPC通信。相比之下，Dubbo提供了一站式的微服务开发和治理解决方案。Dubbo拥有更易用的面向接口的服务定义模型和更完善的服务发现和服务治理机制。同时，在即将到来的3.0计划中，Dubbo3也将提供官方Mesh方案支持，继续为社区带来易用、一站式的解决方案。社区中的许多开发人员期待已久的3.0版本。Dubbo3的基调是云原生支持，计划分为三个版本迭代。专注于交付云原生友好的下一代RPC协议、应用级服务注册与发现、K8s原生服务发布、Mesh控制面xDS协议对接、分布式服务灵活性。·3.0版本，重点发布应用级服务注册发现、Tripe、新路由规则·3.1版本，重点发布K8s原生服务、Mesh控制面xDS协议对接·3.2版本，重点发布分布式服务灵活性内部和一些顶级用户场景作为试点。随着项目的推进，团队将尽快发布功能实现细节。通过Dubbo3.0的发布，我们期待带来新一代对云原生迁移和云原生基础设施友好的服务框架体系。未来，Dubbo项目的总体开发基调仍将坚持合作开放的开源路线，追求更高品质、更完善功能的路线不会动摇。目前社区发展的重中之重是Dubbo3.0的演进。9月，Dubbo3.0应用级注册发现将在阿里巴巴内部和开源端各公司落地。这不仅是Dubbo迈向云原生微服务的第一步，也是对接K8s注册发现和跨框架RPC互通的前提。对于应用端来说，从接口级的注册发现到应用级的注册发现，可以显着降低注册中心和客户端的内存压力。今年双11，云原生服务治理规则将Dubbo多年来在大规模高并发服务治理方面的最佳实践融入云原生。下一代协议将带来更好的生态，全面支持基于http2/protobuf的Reactive。灵活性增强所涵盖的自适应策略和分布式负载均衡，将在性能和稳定性上带来更大的突破。当年Dubbo重启开源的时候，生态还比较薄弱。如今，Dubbo的生态已经越来越完善。以Dubbo丰富的扩展实现为例，已经达到6种多语言支持，30+个生态子项目。Dubbo在积极整合外设的同时，我们也被SpringCloudSleuth、Zipkin、Skywalking、Envoy、tengine等第三方开源项目积极整合。心中的完美就是希望能出一个官方推荐的DubboStack，免去用户选择上面的麻烦。至于DubboStacks是否全部来自阿里，我是抱着顺其自然的态度。这还是需要数??据来说话。谁的组件在生产系统中应用最广，谁就推荐谁。总的来说，这件事的决定权在社区和Dubbo用户手中。原文链接本文为阿里云原创内容，未经许可不得转载。
