编者注:《明朝那些事儿》主要讲述了明朝近300年历史,按照时间轴为主线进行讲解,本文也按照时间轴为主线,讲述下dubbo版的"明朝那些事" -- dubbo的发展历程。
Apache Dubbo™ 是一款高性能Java RPC框架。说起dubbo,国内开发者几乎都知道它的大名,既然现在的dubbo很流行,那么让我们回顾下过去的dubbo吧,一起看下dubbo的发展历程:
从dubbo最初开源的火热,到14-17年的基本停滞,再到17年下半年到现在的迅猛发展,可以从github上commits图看出来明显变化:
目前已有150+公司在使用,包括阿里巴巴集团、中国人寿、中国电信、当当网、滴滴出行、海尔、中国工商银行、网易、去哪儿、有赞等。dubbo提供的主要能力是基于接口的远程代理,容错和负载均衡,以及自动服务注册和发现等,功能包括:
这里不得不提一个人,梁飞,花名(虚极),2009 年加入阿里巴巴,负责中间件的开发,Dubbo 开源分布式服务框架作者。
Dubbo 项目诞生于 2008 年。梁飞最早进入阿里的时候,Dubbo 项目还没有 Dubbo 这个名字,那时的 Dubbo 还是一个阿里内部的系统。2010 年,Dubbo 项目进行了重构。2011 年的阿里,憋了一股劲儿要成为一家技术人向往的企业。那个时候,开发者刚刚成为国内各大厂商争相夺取的宝贵资产,靠什么吸引最顶尖的开发者?黑客文化、工程师文化、开源文化。
当时在淘宝、在阿里 B2B,都有团队在推动开源。阿里 B2B 这边决定先拿 Dubbo 项目开源出去。当时淘宝(2C)也有一个和dubbo类似的项目叫做HSF,也是一个中间件服务框架,跟 Dubbo 做的事情高度重合。当时的情况是:整个淘系都在用 HSF,而阿里金融、集团、B2B 都在用 Dubbo。
在Dubbo和HSF的"竞争"中,从最初的开始让 HSF 合并到 Dubbo 里面,但是由于时间未达到预期实际上并没有合并起来,后来就决定反向合并,把 Dubbo 合并到 HSF 里面去。之后,Dubbo就在14年之后没更新过了,同时Dubbo 团队调整,去到了各个地方。
不过,墙内开花墙外香,阿里之外,还是吸引很多公司和开发者使用dubbo的,比如当当网开发的扩展版本Dubbox 后来就在持续发展。
关于dubbo和HSF的竞争中失败,这里不讨论技术上实现哪个更好?(严格来讲,二者实现思想不同,前者更加轻量级、扩展性强,后者稍微重量级、依赖较多)而是结合当时环境来分析,当时阿里处于系统大重构过程中,特别是淘宝的系统大重构,由于淘宝用的是HSF,已经与淘宝系统深度融合了,根植于淘系的基因了,因此后续换一个新的技术,成本较大收益不明显。
既然dubbo都已经好长时间不维护更新了,那么怎么在17年会突然宣布维护并且推动孵化Apache呢?难道是传说中的KPI的原因?
实际上dubbo的转机,在于阿里云的流行。
2017 年的阿里云,发现有一批客户上云之后,想要用 Dubbo。因为他们 Dubbo 已经用的很熟了,不想因为上云而被迫改变自己的使用习惯。
于是,阿里云就把 Dubbo 服务作为自己的一个产品,卖给了这些客户。但是,客户们又提出了一个问题:
“你看你们 Dubbo 都不怎么更新代码了是吧?你们自己都不维护了,我们用你的框架就觉得特别不放心。”
这下好了,真正的客户提出要求了,提升客户对 Dubbo 的信心,成为了一件在公司层面有价值的事情。因此阿里进一步升级Dubbo并把它捐赠给Apache。2018 年初,Dubbo 项目正式进入了 Apache 的孵化器。
dubbo的重生和进入Apache,已经说明dubbo旺盛的生命力了,但是如何让这种生命力更强呢?
拥有更强的生命力,不仅是dubbo本身发展的需要,也是适应未来技术发展的需要。dubbo在Apache孵化阶段,Dubbo正在从一个微服务领域的高性能 Java RPC 框架,演进到微服务框架 Dubbo Ecosystem,打造出一个完整的微服务生态。
为什么dubbo需要完成的微服务生态,这里拿Spring Cloud做个对比:
Spring Cloud由众多子项目组成,如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等,提供了搭建分布式系统及微服务常用的工具,如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等,满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心,对配置进行统一管理;使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现(Eureka)、智能路由(Zuul)、客户端负载均衡(Ribbon)。
关于服务治理的配置中心、服务发现、降级熔断等等,dubbo同样也是需要的,但是dubbo目前对这些的支持还不是很完善,需要开发人员自定义并引入对应组件,这种就提高了使用成本。因此构建一个dubbo版的微服务生态,也是Dubbo社区满足开发者更高效的构建微服务体系期望的使命和担当。关于Dubbo Ecosystem系统构建,阿里开源了Nacos、Sentinel、seata等项目。
云原生越来越火热,dubbo为了更好地适配云原生,在2.7.5版本新引入了一种基于实例(应用)粒度的服务发现机制,这是为 Dubbo 适配云原生基础设施的一步重要探索。
除了上述的这些,Dubbo 3.0 的规划也在全面进行中,如何让应用级服务发现成为未来下一代服务框架 Dubbo 3.0 的基础服务模型,解决云原生、规模化微服务集群扩容与可伸缩性问题,也已经成为Dubbo发展的重点。
最后,对于Dubbo的发展,我们应该抱有更大的信心,一方面是国内互联网业务复杂度,发展迅猛,将带来更多样的应用场景,对于开源技术和项目的推动落地,提供了一个很好的试验场;另一方面是国内公司对开源技术越来越重视,社区文化越来越浓重。