[[443126]]

先說兩句

我常常在散步時思考很多技術(shù)上的「為什么問題」，有時一個問題會想很久，直到問題的每一個點都能說服自己時，才算完結(jié)。于是想把這些思考記錄下來，形成文章，可以當(dāng)做一個新的系列。這些文章中你可能看不到代碼，但能窺探到一些容易被忽視的問題，以及問題更深層次的「為什么」。

今天帶來第1篇，Dubbo為什么要用Go重寫?

誕生于阿里巴巴，2011年開源的Dubbo已經(jīng)走過了10個年頭。在2019年，它被用Go重寫并開源，如今兩年過去，已經(jīng)從當(dāng)初的V1.0.0版本發(fā)展到了V3.0.0，截止目前star數(shù)3.8K。

有一次同事問我，為什么Dubbo這么"老"的項目還要用Go重寫，有什么現(xiàn)實意義嗎?

今天就來談?wù)勎业囊恍┛捶ā?/p>

連接過去和未來

我覺得要回答好這個問題，得從Dubbo-go的初衷談起，github主頁上它是這樣介紹自己的：

官方給出的中文翻譯是

Apache Dubbo Go 語言實現(xiàn)，架起 Java 和 Golang 之間的橋梁，與 gRPC/Dubbo 生態(tài)互聯(lián)互通，帶領(lǐng) Java 生態(tài)享受云原生時代的技術(shù)紅利。

我再通俗地翻譯一下：一個公司或部門內(nèi)有人用Java版Dubbo，有人用Go，這兩者需要通信，于是就有了Dubbo-Go，用來解決通信問題。

所以第一個問題來了，為什么一個公司用了Java，又用了Go?

編程語言的抉擇

對于編程語言的選擇，在商業(yè)公司里，我覺得最最主要考慮的點就是效率，至于其他的點都是次要。因為商業(yè)公司的主要目的就是盈利，不管什么語言，只要能用最低的成本拿到相等的收益就是好語言。

效率又包含了好幾個方面：

• 開發(fā)效率。開發(fā)效率高，項目能早日上線，占領(lǐng)市場，也能節(jié)約人力成本
• 運行效率。運行效率高，能省下服務(wù)器成本

縱觀國內(nèi)很多商業(yè)公司的選擇都是如此考慮，比如阿里。

阿里早期是PHP，選擇PHP的考量點主要是開發(fā)效率，但隨著業(yè)務(wù)的發(fā)展，PHP的性能無法支撐，必須得換一個運行效率高的語言。

運行效率高自然想到C/C++，但這兩個語言的開發(fā)效率低，得在開發(fā)效率和運行效率中找到一個平衡點，于是阿里選擇了Java。

阿里官方在知乎上回答為什么選擇Java時，主要有以下幾點考慮：性能、簡單易學(xué)、生態(tài)豐富、社區(qū)活躍

把性能放第一位，簡單易學(xué)、生態(tài)豐富、社區(qū)活躍其實也都是說的開發(fā)效率，正是有了這些優(yōu)點，開發(fā)效率才高。

當(dāng)阿里巴巴選擇Java后，自研了大量的Java中間件，培養(yǎng)了大量的Java人才，所以其他公司在技術(shù)選型時，也參考了阿里巴巴，導(dǎo)致越來越多的公司選擇了Java。

而選擇Go也是如此，一些年輕的公司早期可能是PHP、Python等腳本語言，等發(fā)展壯大后，不得不面臨和阿里一樣的問題：性能問題。

在2012年Go發(fā)布了，大家又多了一個選擇，Go既有很高的性能，又非常地簡單易上手，像字節(jié)跳動這類新公司就以Go為主。

所以綜合來看，選擇Java或者Go都是合理的，存在即合理。

為什么有公司選擇了Java，又想用Go呢?

• Go語言相比Java有啟動快，編譯速度快、占用內(nèi)存小、擅長高并發(fā)(協(xié)程)的特性，所以在已經(jīng)有Java的公司，也會考慮Go，只不過目前這類公司占比不多。
• 某些公司沒有強制的技術(shù)棧，所以新部門新業(yè)務(wù)可以擺脫束縛，選擇新語言Go來進行開發(fā)。

小結(jié)

綜上看來，選擇Java或選擇Go都合理，一個公司內(nèi)兩者都選擇，也有合理之處，雖然占比不多，但還是有Java和Go通信的需求。

Dubbo在RPC框架中的勝出

公司早期通常是單體服務(wù)，在規(guī)模達到一定程度，單體應(yīng)用無法支撐業(yè)務(wù)發(fā)展時，會選擇微服務(wù)架構(gòu)，這時就需要一個好用的RPC框架。

能適配Java語言的RPC框架中，Dubbo是國內(nèi)最早開源，于2011年開源。

而和他類似的競品如Spring Cloud在2014年開源，微博的Motan在2017年開源，跨語言的gRPC在2015年開源，Thrift 2007年開源。

只有Thrift 比它早，但Thrift只是個RPC框架，Dubbo可是包含了開箱即用的服務(wù)治理能力，如服務(wù)注冊與發(fā)現(xiàn)、負(fù)載均衡、容錯、動態(tài)配置等等。

可以說早期Java的RPC框架沒得選。

就算到了RPC框架百花齊放的時代，這么多公司的使用加上阿里的背書，Dubbo也有它的一席之地。

小結(jié)

當(dāng)一個公司選擇了Java編程語言和Dubbo框架(這種選擇還是挺多的)，后來又想嘗試Go，或者一些新業(yè)務(wù)、新部門想嘗試Go時，他們就面臨了一個難題，Go如何跟Java的Dubbo通信。

由于Dubbo協(xié)議是私有協(xié)議，用Go重新實現(xiàn)一遍的代價還是挺大。于是Dubbo-Go應(yīng)運而生，從這個角度看，Dubbo-Go在連接Java和Go的通信這條路上還是具有相當(dāng)大的價值的。

終結(jié)與線程池的斗爭

如果使用了Dubbo框架，很多時候需要一個Dubbo網(wǎng)關(guān)，關(guān)于Dubbo網(wǎng)關(guān)可以參考我這篇文章：《微服務(wù)網(wǎng)關(guān)演進之路》。

在這篇文章中，詳細(xì)介紹了一款Dubbo網(wǎng)關(guān)的背景、難點、選型、設(shè)計、演進以及踩坑經(jīng)歷，其中我花了大篇幅介紹了「與線程池所做的斗爭」，在Java中，線程是很寶貴的，但Dubbo網(wǎng)關(guān)如果是同步調(diào)用，必須一個請求占用一個線程，這就導(dǎo)致并發(fā)上不去，而且線程池打滿后，會影響其他請求。

所以解決方案要么是隔離線程池，要么改成異步調(diào)用。隔離線程池只解決了請求不相互影響，但并發(fā)還是上不去，改成異步調(diào)用可以完美解決，但是編碼實在是太復(fù)雜。

而Go的協(xié)程可以剛好解決這個問題，Go的協(xié)程很輕量，調(diào)度效率也更高，所以我們可以用簡單的代碼寫出非常高效率的網(wǎng)關(guān)。

舉個例子可以直觀感受一下，Nginx的性能大家有目共睹，但如果用Java來實現(xiàn)，不知道得堆多少機器才能達到Nginx的性能，但百度在反向代理上使用了Go寫的BFE來代替Nginx，可見其性能有多夸張。

關(guān)于協(xié)程的介紹和原理，可以參考我這篇文章：《寫了一年golang，來聊聊進程、線程與協(xié)程》。

小結(jié)

所以在Dubbo網(wǎng)關(guān)上，Dubbo-Go也提供了一種新的解法，涂鴉智能已經(jīng)有用于線上的Dubbo-Go網(wǎng)關(guān)，并且已經(jīng)開源為Dubbo-go-pixiu。

為Dubbo Mesh鋪路

Service Mesh也漸漸成為了下一代微服務(wù)架構(gòu)，Go在Mesh上也絕對是一個閃亮的明星語言，無論是K8S、Docker等云原生基礎(chǔ)設(shè)施都采用Go編寫，還是Go的開發(fā)速度以及協(xié)程的高并發(fā)能力，都使它成為了Mesh的首選語言。

基于此，Dubbo的Mesh化，Dubbo-Go也為其鋪平了道路，但目前Dubbo Mesh還處于小面積階段，完整落地的方案并沒有開源，從這點上來說，如果某公司想走Dubbo Mesh化之路，Dubbo-Go可能也是他們要著重考慮的點之一。

總結(jié)

說了這么多，該正面回答Dubbo為什么要用Go重寫，這個問題的答案還是官方給出的那句話：架起 Java 和 Golang 之間的橋梁。至于為什么要「架起這座橋梁」，參考下圖：