Dubbo为什么用Go重写?

Hollis

共 2588字,需浏览 6分钟

 ·

2022-01-09 21:15

连接过去和未来
我觉得要回答好这个问题,得从Dubbo-go的初衷谈起,github主页上它是这样介绍自己的:
官方给出的中文翻译是
Apache Dubbo Go 语言实现,架起 Java 和 Golang 之间的桥梁,与 gRPC/Dubbo 生态互联互通,带领 Java 生态享受云原生时代的技术红利。
我再通俗地翻译一下:一个公司或部门内有人用Java版Dubbo,有人用Go,这两者需要通信,于是就有了Dubbo-Go,用来解决通信问题。
所以第一个问题来了,为什么一个公司用了Java,又用了Go?

编程语言的抉择

对于编程语言的选择,在商业公司里,我觉得最最主要考虑的点就是效率,至于其他的点都是次要。因为商业公司的主要目的就是盈利,不管什么语言,只要能用最低的成本拿到相等的收益就是好语言。
效率又包含了好几个方面:
  • 开发效率。开发效率高,项目能早日上线,占领市场,也能节约人力成本
  • 运行效率。运行效率高,能省下服务器成本
纵观国内很多商业公司的选择都是如此考虑,比如阿里。
阿里早期是PHP,选择PHP的考量点主要是开发效率,但随着业务的发展,PHP的性能无法支撑,必须得换一个运行效率高的语言。
运行效率高自然想到C/C++,但这两个语言的开发效率低,得在开发效率和运行效率中找到一个平衡点,于是阿里选择了Java。
阿里官方在知乎上回答为什么选择Java时,主要有以下几点考虑:性能简单易学生态丰富社区活跃
把性能放第一位,简单易学、生态丰富、社区活跃其实也都是说的开发效率,正是有了这些优点,开发效率才高。
当阿里巴巴选择Java后,自研了大量的Java中间件,培养了大量的Java人才,所以其他公司在技术选型时,也参考了阿里巴巴,导致越来越多的公司选择了Java。
而选择Go也是如此,一些年轻的公司早期可能是PHP、Python等脚本语言,等发展壮大后,不得不面临和阿里一样的问题:性能问题。
在2012年Go发布了,大家又多了一个选择,Go既有很高的性能,又非常地简单易上手,像字节跳动这类新公司就以Go为主。
所以综合来看,选择Java或者Go都是合理的,存在即合理。
为什么有公司选择了Java,又想用Go呢?
  • Go语言相比Java有启动快,编译速度快、占用内存小、擅长高并发(协程)的特性,所以在已经有Java的公司,也会考虑Go,只不过目前这类公司占比不多。
  • 某些公司没有强制的技术栈,所以新部门新业务可以摆脱束缚,选择新语言Go来进行开发。

小结

综上看来,选择Java或选择Go都合理,一个公司内两者都选择,也有合理之处,虽然占比不多,但还是有Java和Go通信的需求。

Dubbo在RPC框架中的胜出

公司早期通常是单体服务,在规模达到一定程度,单体应用无法支撑业务发展时,会选择微服务架构,这时就需要一个好用的RPC框架。
能适配Java语言的RPC框架中,Dubbo是国内最早开源,于2011年开源。
而和他类似的竞品如Spring Cloud在2014年开源,微博的Motan在2017年开源,跨语言的gRPC在2015年开源,Thrift 2007年开源。
只有Thrift 比它早,但Thrift只是个RPC框架,Dubbo可是包含了开箱即用的服务治理能力,如服务注册与发现、负载均衡、容错、动态配置等等。
可以说早期Java的RPC框架没得选。
就算到了RPC框架百花齐放的时代,这么多公司的使用加上阿里的背书,Dubbo也有它的一席之地。

小结

当一个公司选择了Java编程语言和Dubbo框架(这种选择还是挺多的),后来又想尝试Go,或者一些新业务、新部门想尝试Go时,他们就面临了一个难题,Go如何跟Java的Dubbo通信。
由于Dubbo协议是私有协议,用Go重新实现一遍的代价还是挺大。于是Dubbo-Go应运而生,从这个角度看,Dubbo-Go在连接Java和Go的通信这条路上还是具有相当大的价值的。

终结与线程池的斗争

如果使用了Dubbo框架,很多时候需要一个Dubbo网关
在这篇文章中,详细介绍了一款Dubbo网关的背景、难点、选型、设计、演进以及踩坑经历,其中我花了大篇幅介绍了「与线程池所做的斗争」,在Java中,线程是很宝贵的,但Dubbo网关如果是同步调用,必须一个请求占用一个线程,这就导致并发上不去,而且线程池打满后,会影响其他请求。
所以解决方案要么是隔离线程池,要么改成异步调用。隔离线程池只解决了请求不相互影响,但并发还是上不去,改成异步调用可以完美解决,但是编码实在是太复杂。
而Go的协程可以刚好解决这个问题,Go的协程很轻量,调度效率也更高,所以我们可以用简单的代码写出非常高效率的网关。
举个例子可以直观感受一下,Nginx的性能大家有目共睹,但如果用Java来实现,不知道得堆多少机器才能达到Nginx的性能,但百度在反向代理上使用了Go写的BFE来代替Nginx,可见其性能有多夸张。

小结

所以在Dubbo网关上,Dubbo-Go也提供了一种新的解法,已经有用于线上的Dubbo-Go网关,开源项目可参考Dubbo-go-pixiu

为Dubbo Mesh铺路

Service Mesh也渐渐成为了下一代微服务架构,Go在Mesh上也绝对是一个闪亮的明星语言,无论是K8S、Docker等云原生基础设施都采用Go编写,还是Go的开发速度以及协程的高并发能力,都使它成为了Mesh的首选语言。
基于此,Dubbo的Mesh化,Dubbo-Go也为其铺平了道路,但目前Dubbo Mesh还处于小面积阶段,完整落地的方案并没有开源,从这点上来说,如果某公司想走Dubbo Mesh化之路,Dubbo-Go可能也是他们要着重考虑的点之一。

总结

说了这么多,该正面回答Dubbo为什么要用Go重写,这个问题的答案还是官方给出的那句话:架起 Java 和 Golang 之间的桥梁。至于为什么要「架起这座桥梁」,参考下图:

有道无术,术可成;有术无道,止于术

欢迎大家关注Java之道公众号


好文章,我在看❤️

浏览 15
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报