先說兩句
我常常在散步時思考很多技術上的「為什麼問題」，有時一個問題會想很久，直到問題的每一個點都能說服自己時，才算完結。於是想把這些思考記錄下來，形成文章，可以當做一個新的系列。這些文章中你可能看不到程式碼，但能窺探到一些容易被忽視的問題，以及問題更深層次的「為什麼」。
今天帶來第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 之間的橋樑。至於為什麼要「架起這座橋樑」，有如下幾個關鍵點：
- 搜尋關注微信公眾號"捉蟲大師"，回覆關鍵字「Nacos」送你一本《Nacos架構與原理》電子書，Dubbo資料也在準備中，不想錯過可以點個關注。