在軟件定義的世界里，企業通過Web應用和移動應用程序來提供大部分的服務，而Node.js迅速成為時下最為流行的一個平臺之一，就和它可以搭建 響應速度快、易于擴展的web應用和移動應用很很大關系，并憑借這點成為了新的主流。作為大規模使用Node.js 的云計算服務提供商，UCloud積累了豐富的使用經驗。

本文為UCloud 公司高級工程師文天樂在深JS大會上發表的演講內容，主要介紹了UCloud內部如何利用Node.js 構建分布式集群，并分享了實踐過程中走過的坑，希望對正在使用Node.js或是即將使用Node.js的朋友有一些幫助。

圖：UCloud高級工程師文天樂

UCloud內部大規模使用了Node.js 技術，利用Node.js研發了一套RPC框架，主要涉及API、Web Console、服務中間層、運營報表、內部運營工具和內部系統等，解決以下四個問題：

1. 服務調動發現程序間解耦；

2. 自動快速擴容服務能力；

3. 腳本語⾔言提高研發效率；

4. 配置集中管理變更應用自動加載。

架構演進

在RPC框架V1版本的架構中，如下圖。從圖中可以看出，是一個金字塔架構，也就意味所有通信服務需要首先和名字服務進行通信，獲取到對端節點狀態和IP端口信息，然后再進行通信，這樣導致系統的高耦合，增加了系統的復雜性，這并不是一件好事。

圖1

為此，我們改進了RPC框架架構，如圖2。在V2版本中，可以看到改進的架構已是一個網狀架構，實現了將所有消息出入口統一到RabbitMQ Server ，以便所有的通信可以在不知道對端節點狀態時，就可以調用對端服務，從而實現了服務端調用關系解耦。

圖2

實現方案

那么到底是如何實現服務端調用解耦的呢？在實現方案中，我們采用了（Node.js + Protocol Buffers + Zookeeper + RabbitMQ）的組合，從而實現配置集中化管理：

1. Node.js，主要用于開發業務邏輯。

作為天生的異步腳本語言，Node.js 使用事件驅動、 非阻塞I/O模型大大提升了研發效率，非常適合在分布式設備上運行的數據密集型的實時應用。

我們通過 fibers庫采用協程的方式來解決Node.js 異步編程匿名回調問題，將異步回調邏輯轉化為同步，同時也滿足了程序員使用同步方法編寫異步程序的情懷。

可參考官方介紹：https://nodejs.org/
https://github.com/laverdet/node-fibers

2. Protocol Buffers，用于強約束消息定義。

Protocol Buffers一種數據交換的格式，它獨立于語言，獨立于平臺。由于它是一種二進制的格式，相比XML和JSON，傳輸效率會更高，可以將它用于分布式應 用之間的數據通信或者異構環境下的數據交換。我們主要將Protocol Buffers用來模版化定義消息結構。
可參考：https://github.com/google/protobuf

3. Zookeeper，實現配置集中管理。

Zookeeper分布式服務框架是Apache Hadoop 的一個子項目，簡單的說，Zookeeper=文件系統+通知機制。它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。

我們使用ZooKeeper看重的是它不僅支持集群高可用，還支持持久化節點、臨時節點存儲和節點變更監控的特點，主要使用了它提供的命名服務、配置管理和集群管理服務。其中，臨時節點特性用以實現名字服務注冊，節點變更監控實現配置集中管理。
參考：https://zookeeper.apache.org

4. RabbitMQ，實現異構通訊服務間的解耦。

Rabbitmq是一種應用程序對應用程序的通信方法，選擇RabbitMQ的原因在于它可以支持集群高可用、簡單易用、性能出色和完善的管理工具（如：Web ui / Rest API ）的特點。

使用Rabbitmq中間件服務端實現解耦，其中主要是利用（ Work Queue + Topics Exchange ）來實現后端的無縫擴容，并采用Publish/ Subscribe + RPC 實現調用解耦，并利用MQ 統一輸入輸出。
參考：https://www.rabbitmq.com

走過的一些坑

***，總結經驗避免犯同樣的錯，是非常重要的，還有一些技術遺留問題，需要我們自行避開這些坑。以下是我們在構建RPC框架過程中遇到的一些坑：

♦ 異步編程效率問題(Fibers)& Node.js 內存泄漏問題

在復雜在構建復雜應用的時候，很多地方都可能發生內存泄露，也需要考慮異步編程效率問題。為解決這兩個問題，我們目前主要采取以下四個手段來解決：

a) 框架封裝所有網絡通信，業務方只關注業務邏輯、提高研發效率；

b) 通過Fibers 封裝所有異步匿名函數調用轉換為同步方法；

c) 謹慎選擇第三方庫。

♦ 異步框架中日志跟蹤

異步程序記錄日志亂序不利于跟蹤業務邏輯調用路徑。為解決這個問題，我們通過包裝 Fibers 對每一個 Fiber 實例進行編號，在所有日志輸出中打印 Fiber id 記錄異步調用路徑，并配合跨模塊會話編號實現請求調用跟蹤，以此解決日志紀錄的無序問題。

♦ RabbitMQ HA 高可用問題

如果需要實現RabbitMQ HA 高可用特性，有兩種途徑可以實現：Server 端 HA 和 Client HA。Server 端的高可用性可使用 LVS 或 HAProxy來實現，Client 端的高可用性也是一種選擇，這樣可以減少架構復雜度和層次依賴。值得注意的是，實現高可用特性時，要記得開啟Queue 高可用配置。

(https://www.rabbitmq.com/ha.html)

♦ RabbitMQ HA 網絡閃斷導致節點分區問題

網絡不穩定導致RabbitMQ HA 網絡閃斷，進而導致節點分區問題。針對這個問題，需要添加對 /api/nodes 進行監控，并及時處理分區問題。

具體的解決方法可參考： https://www.rabbitmq.com/partitions.html。

♦ ZooKeeper Session Expired

針對ZooKeeper 會話過期問題，需要大家特別關注處理Zookeeper 集群斷開后的重連處理，因為如果重連邏輯沒有處理好的話，所有依賴ZooKeeper的特性都將不可用。

具體解決方法可參考：http://wiki.apache.org/hadoop/ZooKeeper/FAQ

【結語】

經過應用實踐，目前看來 Node.js幾乎可以做到其他后端語言所能做到所有的事情，ES6特性正式發布如今有人已經開始高喊“JavaScript: The World's Best Programming Language”，但我也并不認為整個后端完全用Node.js來實現會是一個很好的方案。

本文中提到了Node.js的諸多優點，如異步、非阻塞和事件驅動等，但其也存在一些缺點，如默認單進程單線程不能利用多核，腳本弱類型容易出現運 行時BUG，同時因為它簡單易用，也導致了代碼質量不易控制，對開發人員也提出了更高的要求。所以，就個人經驗來看，建議偏復雜業務邏輯控制使用 Node.js，如果是偏***性能的業務建議和C++等其他方案結合使用。