在軟件定義的世界里，企業(yè)通過Web應(yīng)用和移動(dòng)應(yīng)用程序來提供大部分的服務(wù)，而Node.js迅速成為時(shí)下最為流行的一個(gè)平臺(tái)之一，就和它可以搭建 響應(yīng)速度快、易于擴(kuò)展的web應(yīng)用和移動(dòng)應(yīng)用很很大關(guān)系，并憑借這點(diǎn)成為了新的主流。作為大規(guī)模使用Node.js 的云計(jì)算服務(wù)提供商，UCloud積累了豐富的使用經(jīng)驗(yàn)。

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

圖：UCloud高級(jí)工程師文天樂

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

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

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

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

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

架構(gòu)演進(jìn)

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

圖1

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

圖2

實(shí)現(xiàn)方案

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

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

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

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

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

2. Protocol Buffers，用于強(qiáng)約束消息定義。

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

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

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

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

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

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

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

走過的一些坑

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

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

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

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

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

c) 謹(jǐn)慎選擇第三方庫。

♦ 異步框架中日志跟蹤

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

♦ RabbitMQ HA 高可用問題

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

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

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

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

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

♦ ZooKeeper Session Expired

針對(duì)ZooKeeper 會(huì)話過期問題，需要大家特別關(guān)注處理Zookeeper 集群斷開后的重連處理，因?yàn)槿绻剡B邏輯沒有處理好的話，所有依賴ZooKeeper的特性都將不可用。

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

【結(jié)語】

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

本文中提到了Node.js的諸多優(yōu)點(diǎn)，如異步、非阻塞和事件驅(qū)動(dòng)等，但其也存在一些缺點(diǎn)，如默認(rèn)單進(jìn)程單線程不能利用多核，腳本弱類型容易出現(xiàn)運(yùn) 行時(shí)BUG，同時(shí)因?yàn)樗?jiǎn)單易用，也導(dǎo)致了代碼質(zhì)量不易控制，對(duì)開發(fā)人員也提出了更高的要求。所以，就個(gè)人經(jīng)驗(yàn)來看，建議偏復(fù)雜業(yè)務(wù)邏輯控制使用 Node.js，如果是偏***性能的業(yè)務(wù)建議和C++等其他方案結(jié)合使用。