2007 年 9 月 20 日，關(guān)于設(shè)計一門全新語言的討論正式開始，這門全新的語言，就是后來的 Go。時至今日，Go 語言已經(jīng)發(fā)布到 1.9 版本，走過了整整十年的歷程。在這十年間，Go 語言兩奪 TIOBE 年度語言大獎（2009/2016），許多初創(chuàng)公司在早期使用 Go 進(jìn)行開發(fā)，包括現(xiàn)在的云計算巨頭 Docker，也由此催生出了 Kubernetes 這樣的項目。在大洋彼岸的中國，Google Trends 顯示 Go 的異�；鸨�更讓 Go 語言之父感到震驚。而這一切，跟一位名叫許式偉的技術(shù)人密不可分。

Go 語言剛剛度過了它的十周年紀(jì)念日。而要說我與 Go 的緣分，也同樣始于十年前（2007 年）。這十年，是 Go 成長的十年，同樣也是我成長的十年。

2007 年 2 月，我建立了金山實驗室，主攻分布式存儲方向。這是我職業(yè)生涯至關(guān)重要的一個轉(zhuǎn)折點。此前我已經(jīng)做了 7 年的 WPS Office 辦公套件的研發(fā)。這對我有兩個重要的挑戰(zhàn)：一個是角色轉(zhuǎn)換上的，從做軟件研發(fā)的架構(gòu)師到做業(yè)務(wù)的產(chǎn)品經(jīng)理；一個是技術(shù)領(lǐng)域變化上的，從單機的桌面軟件開發(fā)到分布式的后端服務(wù)器開發(fā)。

我第一個面臨的問題是技術(shù)選型。幾乎沒有作任何糾結(jié)，我們選擇了 Java 作為主體的開發(fā)語言。作為初入后端開發(fā)領(lǐng)域的團(tuán)隊來說，這只是一個從務(wù)實角度出發(fā)的選擇。但 TrustNo1 在程序員雜志發(fā)表的《一場茶杯里的風(fēng)暴》一文讓我認(rèn)識了 Erlang 語言，并深深被 Erlang 的編程思想所打動。我意識到這種編程思想將會極大釋放服務(wù)端編程的生產(chǎn)力。為了推動服務(wù)端最佳實踐的探索，也為了進(jìn)一步推動更多人了解和研究 Erlang，我發(fā)起了 ECUG 社區(qū)。ECUG 到現(xiàn)在已經(jīng)十年。這十年我們風(fēng)雨無阻，每年年底都會舉行一場 ECUG Con 大會，和來自各行各業(yè)的技術(shù)大拿們齊聚一堂，大家一起分享這一年來服務(wù)端開發(fā)的實踐心得。

盡管我們選擇了 Java，但是隨后我們也做了小范圍使用 Erlang 進(jìn)行開發(fā)的嘗試。在 2008 年我們啟動了一個用 Erlang 來編寫存儲系統(tǒng)（極簡版）的業(yè)余項目。這次的嘗試讓我對 Erlang 有了進(jìn)一步的判斷：盡管 Erlang 的編程思想很好，但是 Erlang 語言本身并不適合大型的工程項目。

到了 2009 年 3 月，也就是我加入盛大創(chuàng)新院重啟分布式存儲項目時，我面臨了第二次技術(shù)選型。這一次我選了最難的一條路：用 C++ 來開發(fā)。這是一條艱苦的路。促使我做出這一選擇的最大原因是，我很希望能夠制造一個新輪子，它應(yīng)該既有 Erlang 編程思想的優(yōu)勢，又可以克服 Erlang 語言的劣勢。如果這事能夠干成，它將是一件偉大的創(chuàng)舉，所有的服務(wù)端開發(fā)人員都將受益于此。于是，在心懷滿腔熱血之下，一個名為 CERL 的項目誕生了。在我們存儲的第一個版本期間，實際上我們花費在 CERL 庫的時間遠(yuǎn)超過了做存儲本身，無論從代碼量還是花費的精力來說都是如此。

CERL 項目經(jīng)歷了 2 個大的版本。CERL 1.0 完全遵循 Erlang 的編程思想，主要編程范式如下：

• 可以啟動任意多的進(jìn)程（這里進(jìn)程是抽象的概念，實現(xiàn)上是纖程 / 協(xié)程），進(jìn)程數(shù)上限只受限于內(nèi)存大小。

• 每個進(jìn)程有進(jìn)程郵箱，相互發(fā)消息通過進(jìn)程郵箱。

• 消息分同步消息和異步消息，同步消息會阻塞等待對方返回消息。

• 網(wǎng)絡(luò)服務(wù)器是單進(jìn)程模型（就是大家理解的單線程模型），一次只處理一個消息。

• 沒有鎖。

• …

基于 CERL 1.0 的編程模型，我們實踐中發(fā)現(xiàn)了這樣一些問題：

• 在網(wǎng)絡(luò)服務(wù)器 A、B 相互給對方發(fā)送同步消息時會發(fā)生“死鎖”。因為雙方可能都正在處理消息中而無法及時響應(yīng)，這種“死鎖”最終表現(xiàn)為超時（但是實際上超時更可怕，是服務(wù)器性能的殺手）。

• 解決“死鎖”的方法是把同步消息改為異步，但是這對編程復(fù)雜性帶來很大的影響，程序語義變得晦澀。本質(zhì)上，這是回到了傳統(tǒng)的異步編程模型，放棄了 Erlang 編程模型最大的優(yōu)勢。

• “沒有鎖”的假設(shè)代價過高：在網(wǎng)絡(luò)服務(wù)器的單個處理響應(yīng)時間較長（存儲服務(wù)必然如此）時，必然希望啟動獨立的進(jìn)程來響應(yīng)單個請求。但是各個處理請求的進(jìn)程之間需要共享網(wǎng)絡(luò)服務(wù)器的狀態(tài)，這就意味著需要有鎖（除非網(wǎng)絡(luò)服務(wù)器是無狀態(tài)的，但是很不幸存儲服務(wù)器必然是帶狀態(tài)的）。要么放棄性能串行化地處理請求，要么有鎖 —“沒有鎖”，想說愛你不容易。

• …

在發(fā)現(xiàn)“死鎖”問題后，我們立刻對我們整個編程模型進(jìn)行了反思，決定重構(gòu)整個編程模型，修改后的 CERL2.0 要點如下：

• 可以啟動任意多的進(jìn)程（這里進(jìn)程是抽象的概念，實現(xiàn)上是纖程 / 協(xié)程），進(jìn)程數(shù)上限只受限于內(nèi)存大小。

• 沒有進(jìn)程郵箱。

• 進(jìn)程之間只有同步消息（要發(fā)送異步消息，用啟動一個新的進(jìn)程并發(fā)送同步消息來達(dá)到同樣的效果）。

• 網(wǎng)絡(luò)服務(wù)器是多進(jìn)程模型，每個請求都由一個獨立的進(jìn)程來處理。

• 有鎖。

兩個版本的編程模型的關(guān)鍵差異在于拒絕鎖還是拒絕異步消息。CERL 1.0（也就是 Erlang 編程模型）中拒絕鎖，而 CERL 2.0 拒絕異步消息�；�于 CERL 2.0 我們實現(xiàn)了分布式存儲的第二版、第三版。事實證明，完全杜絕了異步消息這個概念后，這個版本的服務(wù)器編程模型心智負(fù)擔(dān)小了很多。

然后，如大家所知，后來 Go 語言就發(fā)布了。我們團(tuán)隊一看，在服務(wù)器編程模型這一點上，CERL 2.0 和 Go 語言居然一模一樣（包括所有細(xì)節(jié)上的決策）。有一次團(tuán)隊聚餐談起這事時，道哥（李道兵）說了一句：我們趕緊把 CERL 開源吧，不然等 Go 流行起來它就沒機會了。我還真和創(chuàng)新院院長陳大年談了 CERL 開源的事情，大年說：沒問題，你發(fā)個郵件申請吧，留個憑證。然而我最終沒有發(fā)出這封郵件。在嘗試用 Go 寫了一周的代碼后，我心里已經(jīng)有了結(jié)論：我并不打算讓 CERL 面世。因為有人已經(jīng)把它的目標(biāo)完成了，而且遠(yuǎn)超預(yù)期。

于是，2011 年 6 月，我們離開盛大創(chuàng)新院創(chuàng)辦七牛云的時候，我面臨了第三次技術(shù)選型。這一次，我很堅決地選擇了 Go 語言。為此我還專門給團(tuán)隊發(fā)了一封郵件，郵件中有一段是這么說的：

在創(chuàng)業(yè)過程中我們會面臨很多選擇，也會有很多選擇后來會被證明是錯的，但是今天我可以確定的是，選擇 Go 將會成為我們最正確的選擇。

在選擇了 Go 語言后，考慮到 Go 仍然是一門十分小眾的語言，我們開始有意識地培養(yǎng) Go 中國社區(qū)。為了讓更多人能夠知道 Go，加入 Go 的行列，我們做了很多工作。我們啟動了《Go 語言編程》一書的編寫工作，并最終和 Go 1.0 版本同步發(fā)布。2012 年 2 月，我首次在公開場合說：Go 會超過 C、Java，成為最流行的語言。這一年我到處宣講，做了不下十場的 Go 語言講座，平均每個月有一場。講得最多的一個 PPT 是《Go，Next C》這篇，它基本上算我對 Go 的革命性到底在哪里的一個總結(jié)。對于一個初創(chuàng)公司來說，為一個并不屬于自己業(yè)務(wù)的技術(shù)這么花時間去宣傳，有些人可能會覺得比較不可理解。但是實際上有三個理由支撐我們這么做：

• Go 真的是一門革命性的語言，它的流行將對產(chǎn)業(yè)發(fā)展具重大意義。

• Go 仍然是一門小眾語言，而我們不止要招 Go 程序員，更重要的是要說服他們相信 Go 語言是有遠(yuǎn)大前景的專業(yè)技能方向。

• 七牛的用戶是程序員，我們需要建立在用戶心目中的專家形象。

七牛云的起步第一個業(yè)務(wù)是云存儲，我們選擇了完全用 Go 來實現(xiàn)我們的存儲系統(tǒng)。這是全球第一個用 Go 寫的云存儲，也是第一個用 Go 寫的云服務(wù)。而到了 2014 年，在我們決定進(jìn)入大數(shù)據(jù)領(lǐng)域時，我們再一次面臨技術(shù)選型問題。坦白說，我們還是糾結(jié)了一段時間的。從生態(tài)來說，選擇 Java，或者某種 JVM 平臺的語言（比如 Scala）有非常顯著的優(yōu)勢。尤其對于我們大數(shù)據(jù)業(yè)務(wù)的負(fù)責(zé)人陳超這個 Scala 的狂熱粉絲（八卦一下：陳超的網(wǎng)絡(luò) id 是 CrazyJVM），選擇 JVM 平臺似乎更加是毋庸置疑的選擇。那么我們糾結(jié)什么呢？我們認(rèn)為未來 Go 會占領(lǐng)整個基礎(chǔ)設(shè)施領(lǐng)域，而大數(shù)據(jù)無疑是其中極具關(guān)鍵意義的一個領(lǐng)域。所以面向現(xiàn)在做選型，還是面向未來做選型，這是一個問題。

說到這里我提一個有意思的細(xì)節(jié)。在陳超剛加入七牛的時候，我對他說：“不管未來你會用什么語言，但是進(jìn)入七牛必須要會寫 Go�！庇谑撬�被我逼著寫了一個月的 Go 代碼。一個月后我問他感覺如何，他說：“能夠理解為什么你推薦 Go 了，寫了 Go 代碼后不想回去寫 Scala 代碼。”不久之后，在他啟動 Pandora 大數(shù)據(jù)平臺項目時，就碰到了我說的選型問題。在做了非常細(xì)致的思考之后，他決定用 Go 做 Pandora。這對我來說是一個意料之外的決策。因為我自己在這個事情上并沒有傾向性，而陳超我覺得他很可能還是會優(yōu)先選 Scala。就在最近（國慶節(jié)前）某次聊天中，陳超回顧起這件事，總結(jié)了一下他為什么選擇了 Go：極低的學(xué)習(xí)成本，極低的心智負(fù)擔(dān)。如果用 Scala，新人入職要培訓(xùn)，還要擔(dān)心寫出糟糕的 Scala 代碼。但是用 Go 新人不培訓(xùn)直接上崗，幾次 Code Review 完后基本就能夠知道怎么寫出質(zhì)量不錯的 Go 代碼了。

十年過去，Go 已經(jīng)不再是一門小眾語言。越來越多人在用 Go，喜歡上 Go。不記得是什么時候了，但是某一天通過 Google Trends 搜索 golang 發(fā)現(xiàn)全世界 Go 最火的地區(qū)是在中國時，那一刻真的很開心。

下一個十年會怎樣？我知道有一些人很期望 Go 語言特性的迭代。但是如果你抱有這種想法可能會失望，因為下一個十年 Go 不會發(fā)生太大的變化。對遠(yuǎn)期需求變化的預(yù)測和把控能力，是 Go 的最大魅力之一。這一點上能夠和 Go 相比的是 C 語言（C 語言不同版本的規(guī)范差異極少），但因為 Go 要解決的問題更多，做到這一點實際上也更難。下一個十年 Go 仍然會繼續(xù)深耕服務(wù)端開發(fā)的生態(tài)，同時積極探索其他潛在的應(yīng)用市場。

延展閱讀

在 QCon 2015 上海站上，許式偉曾經(jīng)做過《Go 語言發(fā)展?fàn)顩r》的主題分享。對于 Go 語言，他提到過三個預(yù)測：

• 第一個預(yù)測，我最早在 2012 年新浪微博里提過，Go 語言 10 年內(nèi)一定會超過 C 和 Java，變成排行榜第一的語言。今天大家可能會略相信，但在 2012 年的時候沒有多少人會相信，即使今天講出來，絕大部分人都會覺得太早，畢竟它還沒有排進(jìn)前五。

• 第二個預(yù)測，Go 語言將在兩年內(nèi)制霸云計算領(lǐng)域。

• 第三個預(yù)測，Go 將統(tǒng)治下一個 10 年。（來自于 Deferpanic 創(chuàng)始人 Lan Eyberg）。

最新動態(tài)

12月17日在上海舉辦的 ECUG Con 十周年盛會中，許式偉提出，Go在占領(lǐng)了云計算領(lǐng)域后，下一個戰(zhàn)場會是在游戲領(lǐng)域！并且進(jìn)行了細(xì)致的分析，演講內(nèi)容也將在 Go 中國公眾號上公布，敬請期待～

 

來自：http://mp.weixin.qq.com/s/iU7gaZNgCsU3DHaHa5PZ_Q

 

標(biāo)簽： Google 產(chǎn)業(yè)發(fā)展 大數(shù)據(jù) 大數(shù)據(jù)平臺 代碼 服務(wù)器 服務(wù)器性能 搜索 網(wǎng)絡(luò) 網(wǎng)絡(luò)服務(wù)器 云服務(wù) 云計算

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。