首页天道酬勤dubbo底层是不是netty,dubbo k8s

dubbo底层是不是netty,dubbo k8s

张世龙 05-04 00:04 63次浏览

首先,我总是在散步中思考很多技术性的“为什么是问题”。 有时候一个问题需要思考很久,直到问题的每一点都能说服自己才算完成。 所以我想把这些思考记录下来,写成文章,做成新的系列。 在这些文章中可能看不到代码,但可以窥探到容易被忽视的问题和问题更深层次的“为什么”。

今天拿来第一线圈,Dubbo为什么要用Go重写?

出生于阿里巴巴,2011年开源Dubbo走过了10年。 到了2019年,它将被Go改写并开源,现在已经过去两年了,从最初的V1.0.0版本发展到V3.0.0,现在的star数量为3.8K。

有一次同事问我,为什么像Dubbo这样的“旧”项目需要在Go上重写,有什么现实意义吗?

今天说几个我的意见吧。

我认为要回答这个连接过去和未来的问题,必须从Dubbo-go的初衷开始。 在github主页上,是这样介绍自己的。

官方的中文翻译是

Apache Dubbo Go语言的实现,搭建了Java与Golang的桥梁,与gRPC/Dubbo生态互通,引导Java生态享受云原生时代的技术红利。

试着翻译得更通俗一点吧。 某公司或部门内有人使用Java版Dubbo,有人使用Go。 这两者需要通信,为了解决通信问题有Dubbo-Go。

于是第一个问题来了。 为什么一家公司用了Java,又用了Go?

我认为编程语言的选择相对于编程语言的选择,在商业公司中,最主要的考虑点是效率,其他方面都是次要的。 商务公司的主要目的是为了盈利,所以不管是什么语言,只要能以最低的成本获得同等的利润就好了。

效率有几个方面。

开发效率。 开发效率高,项目快上线,占领市场,还可以节约劳动力成本运行效率。 人们把运营效率高、节约服务器成本、可以展望国内许多商业公司的选择当成蚂蚁一样。

早期的蚂蚁是PHP,选择PHP的考虑主要是开发效率,但是随着业务的发展,PHP的性能无法支撑,必须转变为执行效率高的语言。

执行效率当然考虑丙/丙,但这两种语言的开发效率很低,必须在开发效率和执行效率之间取得平衡。 于是蚂蚁选择了Java。

蚂蚁公式在知道的基础上回答为什么选择Java时,主要考虑以下几点。性能简单易学生态丰富社区活跃

性能放在第一位,简单易学,生态丰富,社区活跃,其实也说的是开发效率。 正因为有这些优点,开发效率高。

阿里巴巴选择Java后,研究了大量的Java中间件,培养了很多Java人才,因此其他公司在技术选型时也借鉴了阿里巴巴,越来越多的公司选择了Java。

而且,选择Go也是这样。 一些年轻公司早期可能是脚本语言,如PHP或Python。 长大后,你必须面对和蚂蚁一样的问题。 是性能问题。

2012年Go发布,大家又多了一个选择。 Go虽然有很高的性能,但是非常容易得到。 像字节跳动这样的新公司以Go为主。

因此,总的来看,选择Java或Go是合理的,存在是合理的。

为什么会有选择Java,想使用Go的公司呢?

Go语言与Java相比具有启动快、编译速度快、占用内存小、擅长高并发(APP )的特性,因此已经有Java的公司也考虑Go。 但是,目前这类公司的比例不多。 有些公司没有强制的技术堆栈,新部门的新业务可以摆脱束缚,选择开发新语言Go。 综上所述,无论是选择Java还是Go都是合理的,在一个公司内两者都有合理的地方,虽然占有率很少,但有Java和Go通信的需求。

在RPC框架中,Dubbo获胜的公司初期一般是单体服务。 如果规模变大到一定程度,而单个APP应用程序无法支持业务发展,请选择微服务体系结构。 在这种情况下,需要一个易于使用的RPC框架。

在支持Java语言的RPC框架中,Dubbo是国内第一个开放源代码,并于2011年成为开放源代码。

Spring Cloud于2014年成为开源,微博Motan于2017年成为开源,多语言gRPC于2015年成为开源,Thrift于2017年成为开源。

比这更早的只有Thrift,但Thrift只是RPC框架。 Dubbo包含开箱即用的服务治理功能,包括服务注册和发现、负载平衡、容错和动态资源调配。

可以说初期的Java的RPC框架无法选择。

到了RPC框架百花齐放的时代,即使这么多公司的使用再加上蚂蚁的背书,Dubbo也有它的位置。

当一家公司选择Java编程语言和Dubbo框架,然后他们想尝试Go,或者一些新业务、新部门想尝试Go,他们就面临着挑战。 Go如何与Java的Dubbo通信?

由于Dubbo协议是专用协议,因此在Go上再次实现的成本仍然很大。 于是Dubbo-Go应运而生。 从这个角度来看,Dubbo-Go在连接Java和Go的通信这条路上具有相当大的价值。

如果使用了结束与线程池的斗争的Dubb

o框架,很多时候需要一个Dubbo网关,关于Dubbo网关可以参考我这篇文章:《微服务网关演进之路》。

在这篇文章中,详细介绍了一款Dubbo网关的背景、难点、选型、设计、演进以及踩坑经历,其中我花了大篇幅介绍了「与线程池所做的斗争」,在Java中,线程是很宝贵的,但Dubbo网关如果是同步调用,必须一个请求占用一个线程,这就导致并发上不去,而且线程池打满后,会影响其他请求。

所以解决方案要么是隔离线程池,要么改成异步调用。隔离线程池只解决了请求不相互影响,但并发还是上不去,改成异步调用可以完美解决,但是编码实在是太复杂。

而Go的协程可以刚好解决这个问题,Go的协程很轻量,调度效率也更高,所以我们可以用简单的代码写出非常高效率的网关。

举个例子可以直观感受一下,Nginx的性能大家有目共睹,但如果用Java来实现,不知道得堆多少机器才能达到Nginx的性能,但百度在反向代理上使用了Go写的BFE来代替Nginx,可见其性能有多夸张。

关于协程的介绍和原理,可以参考我这篇文章:《写了一年golang,来聊聊进程、线程与协程》。

小结

所以在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 之间的桥梁。至于为什么要「架起这座桥梁」,有如下几个关键点:

搜索关注微信公众号"捉虫大师",回复关键字「Nacos」送你一本《Nacos架构与原理》电子书,Dubbo资料也在准备中,不想错过可以点个关注。
阿里巴巴国际站的支付方式,阿里小马哥dubbo