Node.js中怎么構(gòu)建一個分布式集群

這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)Node.js中怎么構(gòu)建一個分布式集群，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

UCloud內(nèi)部大規(guī)模使用了Node.js 技術(shù)，利用Node.js研發(fā)了一套RPC框架，主要涉及API、Web Console、服務(wù)中間層、運營報表、內(nèi)部運營工具和內(nèi)部系統(tǒng)等，解決以下四個問題：

1. 服務(wù)調(diào)動發(fā)現(xiàn)程序間解耦；

2. 自動快速擴容服務(wù)能力；

3. 腳本語?言提高研發(fā)效率；

4. 配置集中管理變更應(yīng)用自動加載。

架構(gòu)演進

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

圖1

為此，我們改進了RPC框架架構(gòu)，如圖2。在V2版本中，可以看到改進的架構(gòu)已是一個網(wǎng)狀架構(gòu)，實現(xiàn)了將所有消息出入口統(tǒng)一到RabbitMQ Server ，以便所有的通信可以在不知道對端節(jié)點狀態(tài)時，就可以調(diào)用對端服務(wù)，從而實現(xiàn)了服務(wù)端調(diào)用關(guān)系解耦。

圖2

實現(xiàn)方案

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

1. Node.js，主要用于開發(fā)業(yè)務(wù)邏輯。

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

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

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

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

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

3. Zookeeper，實現(xiàn)配置集中管理。

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

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

4. RabbitMQ，實現(xiàn)異構(gòu)通訊服務(wù)間的解耦。

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

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

走過的一些坑

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

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

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

a) 框架封裝所有網(wǎng)絡(luò)通信，業(yè)務(wù)方只關(guān)注業(yè)務(wù)邏輯、提高研發(fā)效率；

b) 通過Fibers 封裝所有異步匿名函數(shù)調(diào)用轉(zhuǎn)換為同步方法；

c) 謹慎選擇第三方庫。

♦ 異步框架中日志跟蹤

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

♦ RabbitMQ HA 高可用問題

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

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

♦ RabbitMQ HA 網(wǎng)絡(luò)閃斷導(dǎo)致節(jié)點分區(qū)問題

網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致RabbitMQ HA 網(wǎng)絡(luò)閃斷，進而導(dǎo)致節(jié)點分區(qū)問題。針對這個問題，需要添加對 /api/nodes 進行監(jiān)控，并及時處理分區(qū)問題。

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

♦ ZooKeeper Session Expired

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

上述就是小編為大家分享的Node.js中怎么構(gòu)建一個分布式集群了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。