本日带来第1篇，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的性能无法支撑，必须得换一个运行效率高的措辞。
运行效率高自然想到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网关可以参考我这篇文章：《微做事网关演进之路》。
在这篇文章中，详细先容了一款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 之间的桥梁。至于为什么要「架起这座桥梁」，有如下几个关键点：
