如何評價Uber不用Node.js，而用Go語言構建地理查詢服務？

如何評價Uber不用Node.js，而用Go語言構建地理查詢服務？

點評《Uber是如何基於Go語言構建高QPS服務的》一文，解答讀者疑問，經過比較Node.js和go來談架構演進過程，分享我對將來技術的思考

緣起

你們都是知道uber是大量採用Node.js開發的公司，而2016年4月12日infoq發了一篇名爲《Uber是如何基於Go語言構建高QPS服務的？》

http://www.infoq.com/cn/articles/uber-build-high-qps-services

不少人問我，是否是uber之後要用go去替代Node.js？

個人回答是，目前看它只是地理查詢的地方使用go重寫了，這並不意味着，它徹底會用go替代Node.js的，並且在絕大部分場景下Node.js是有它的優點的，除了文章講的場景外，真的不多能找出差別特別大的點，各有優缺點，一個公司想棄用一項技術棧也是很難的一件事兒。

區分場景

QCon見到朱贇，她說灣區那邊ror很是多，而我所瞭解的國內只有少數極客在用，爲何呢？地域是一方面，文化是一方面，馬斯洛的需求層次理論固然也是重要點，再舉個例子,北京招聘Node.js很是多，在天津，js能寫明白的都很少，爲何呢？

咱們看問題，是否也要區分一下場景？好比mvp（最小可用原型）在創業初期很是實用，但是若是你已通過了初期，你的其餘功能沒有跟上，你的mvp會讓你死的很慘，血與淚的教訓都在告訴咱們，這個世界不是二分法來判斷的，對與錯以外，還有場景這個變量集合。

先看一下文章說的「選擇Go的緣由」

當咱們評估所要使用語言的時候，Node.js正是廣大的服務設計團隊廣泛採用的編程語言。而咱們也在Node.js的使用方面有着豐富的經驗。然而，Go語言卻因爲如下緣由知足了咱們的需求：

• 高吞吐量和低延遲的需求。Uber的手機端App在發送請求時，必然會觸發一次查找地理圍欄的操做。而服務器必需要可以對每秒上萬次的請求以99%的機率響應時間小於100ms的速度進行響應。
• CPU密集型負載。查找地理圍欄須要使用計算密集型的Point-In-Polygon（PIP）算法。儘管Node.js能夠很好的用於I/O密集型的服務，解釋執行以及動態類型定義等的特性使得它並不適合於咱們的使用場景。
• 非中斷式的後臺加載。爲了保證查詢操做是基於最新的地理圍欄信息而進行的，服務必需要可以根據多個數據源的信息在後臺實時刷新內存中的地理圍欄數據。由於Node.js是單線程的，後臺刷新極可能會佔用必定的CPU時間（如CPU密集型的JSON的編譯工做），最終致使部分查詢的響應時間過長。可是，對於Go語言而言，這徹底不是問題。Goroutine能夠運行在多個CPU核上，而且能夠在響應前端查詢的同時後臺並行進行刷新數據的工做。

這個理由解釋是ok的，go確實在併發上有它的優點，異步流程控制上比Node.js要強很是很是多，對於一些tcp長鏈接（im、遊戲），多核計算類的都有很是好的性能優點。

但是，親，你的瓶頸出在哪裏呢？真的是性能麼？

黑一下go語言吧: 夠(go)不着

go的缺點是很難夠(go)着

• 沒有好的包管理，目前生態還不是特別好，選擇的可能很少
• 沒有好的調試工具，tdd/bdd新手難掌握(vscode-go還湊合)
• 語法問題，強c背景的人很少

總結：適合高端人羣，但對團隊開發是有門檻的，不適用國內大部分大團隊，固然若是你的團隊足夠牛逼，選go是很是好的選擇。

羊和駱駝的故事告訴咱們：夠得着你牛逼，夠不着，累死你也夠不着

架構的演進

架構的演進過程，通常以下

• 不管如何，先實現(不擇手段，或者說用本身擅長的)
• 優化（一棵樹上吊死）
• 服務化（東拼西湊，捉襟見肘，趨於穩定）
• 合適的技術作合適的事兒（有選擇的挖坑優化）

若是Uber的服務都很是成熟了，那麼它是有能力徹底用其餘語言重寫的，用go重寫地理查詢服務，是由於它已經演化到了第四階段，有了以前的精力纔有今天的可轉變。

其實，我對語言並無什麼偏見，按照目前技術發展速度來看，將來應該是一個技術多樣性，語言性能趨於相同，你們只看喜愛來決定選用那種語言的局面，而不是語言之爭。

其實最終仍是要回歸到架構的本質上去的，場景決定技術。

在將來很長一段時間，Node.js都會是Uber的主要服務，即便替換也會一點一點的來，積累與成本是不可能短期消失的。

咱們要問的是：「如今處於什麼階段？當前場景下使用Node.js是否合適？」，而不是看人家用go重寫了。。。

全文完

歡迎關注個人公衆號【node全棧】