连接过去和未来
我认为要回答这个问题，必须从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的通信这条路上具有相当大的价值。
使用33558www.Sina.com/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之道公众号
好文章，我在看❤️