在云計算發(fā)展飛速的時代，傳統(tǒng)通訊正在與互聯(lián)網、IT等各大領域融合發(fā)展，無論是IM、視頻、VoIP、還是呼叫中心，企業(yè)都需要根據自身業(yè)務形態(tài)開發(fā)和部署屬于自己的通訊平臺。那么，在用戶群體不斷壯大之時，云平臺如何該支持百萬千萬或者上億的在線用戶?日前， 容聯(lián)云通訊CTO(***技術官)許志強為程序員們帶來了一場主題為“云通訊PaaS平臺的挑戰(zhàn)和應對之道”的在線培訓。

一個云平臺怎么支持百萬千萬或者上億的在線用戶?許志強認為這里有幾個關鍵點：

1、操作系統(tǒng)調優(yōu)

***步是操作系統(tǒng)的調優(yōu)，因為操作系統(tǒng)的缺省設置并不是適合這種大規(guī)模的系統(tǒng)訪問的，包括打開文件數、TCP接收發(fā)送緩沖等，你需要根據你的業(yè)務請將操作系統(tǒng)各項的參數設置進行一個調優(yōu)。

2、采用異步接口

第二步，因為現在大多數的網絡協(xié)議都是基于TCPIP協(xié)議的，客戶端在很多情況下是非活躍的，那么要單臺機器處理幾十萬或者上百萬以上的連接需要采用異步的接口。在Linux上使用的是epoll,在windows上就是I/O Completion Port. 十年前，我們會討論一臺Web服務器怎么支撐一萬個用戶(著名的C10K問題)，現在這個問題已經隨著操作系統(tǒng)的完善已經非常輕易的解決了，關鍵是怎么使用操作系統(tǒng)提供的這些接口。現在如果采用長連接，目前的技術水平達到幾十萬甚至上百萬(依賴實際的吞吐量)的長連接單臺服務器是沒有任何問題的。

3、內存數據庫緩存、減少數據庫操作

第三點，我們知道數據庫的操作是比較重的，像內存數據有可能用(Memcache、Redis)或者各種內存數據庫緩存一些數據，減少數據庫的操作,衡量哪些數據放內存數據庫中的一個重要原則就是：如果數據訪問比較頻繁，可以通過key訪問，業(yè)務邏輯上不需要強一致的數據適合放內存數據庫。

4、內部模塊交換采用長連接、Protocol Buffer等

系統(tǒng)內部盡可能采用長連接，因為系統(tǒng)的每一次連接都是一個開銷，可能在低負載情況下沒有關系，每次請求一個連接，看上去也挺快，一秒鐘幾百個請求，一千多請求也行，但是一旦系統(tǒng)負荷增大，這部分開銷在整個系統(tǒng)開銷就會非常大了。另外在協(xié)議編碼的盡可能采用像Protocol Buffer的協(xié)議，這是谷歌開源的協(xié)議，具有很好的編解碼效率和傳輸流量優(yōu)化。

5、節(jié)點可并行擴展、Cluster集群

設計的時候需要考慮各個模塊、節(jié)點是否可并行擴展的?是不是增加一個模塊、節(jié)點就能夠提供服務擴展系統(tǒng)容量?將每個節(jié)點盡可能做成無狀態(tài)的，只有做到這點，系統(tǒng)才能可擴展、才能做集群、才能采用Cluster集群來做負載均衡服務。

6、自動部署新業(yè)務節(jié)點支持服務的自動化擴容

云服務的用戶可能突然業(yè)務量大增，系統(tǒng)能不能通過自動部署解決彈性自動擴容?這是云通訊現在正在做的。我們跟運營商的線路不是可以通過動態(tài)增加的，那是物理接口沒有辦法增加的。但是針對IP端的設備我們是可以做自動部署的，像阿里云、亞馬遜，可以提供API讓你自動地創(chuàng)建虛擬的主機，你可以提前做好相應的磁盤映像, 當檢測到某個類型的設備負責過高后，可以通過接口把這個服務部署起來。當你業(yè)務節(jié)點快速增加的時候，你采用這種自動部署的方案可以大幅減少人工干預維護的工作。

7.一次性Hash的負載分配方式

講到集群，就必須說的是集群中負載的分配方式。舉個例子，之前阿里云余額寶是從IOE架構移到阿里云上，當時存在一個很大的一個挑戰(zhàn)，余額寶的請求量太大了，mysql數據庫性能不夠，怎么解決這個問題呢? 常見的方法就是根據賬號分數據庫、分系統(tǒng)處理，按照賬號分配到對應的數據庫和處理系統(tǒng)，這就是負載分配的方式。一般來說，大家一個很直觀的想法可能是根據這個帳號做一下hash計算。有三個節(jié)點，就除三，余數在哪兒就去哪個節(jié)點，這是慣用的思路。但是這里有一個問題，之前的三個節(jié)點，后來可能變成四個節(jié)點，五個節(jié)點，一旦變成四個節(jié)點，五個節(jié)點以后，原來的Hash的值就不對了，如果加了一個節(jié)點以后，后面所有的分配都會不對，數據庫什么都要重新調整，整個負載會劇烈的進行一個移動，對增加處理節(jié)點是不友好的。

下面是百度上的一個圖，這個是一次性Hash的負載分配方式：

假如這是一個環(huán)，這個環(huán)是從0到2的32次方，我們保證Hash出來的值在這個區(qū)間內隨機分布。在這個區(qū)間內，我們這里只有四個節(jié)點，圖中藍色的節(jié)點是我們的服務節(jié)點。當一個請求來了，或者一個帳號來了，這個請求是由誰來服務呢?我們把這個請求計算一個hash，hash值會落在這個環(huán)的其中一個點上，就是圖中的這個紫色的點。紫色的點實際上不是一個具體的服務點，它會按方向找最近的點，假如我們以順時針方向，他就找順時針最近的一個點。假如在第三和四節(jié)點之間，這兩個節(jié)點的負載增加了，我們就在這兩個節(jié)點中間加一個節(jié)點，把他們中間的負載做一個分擔，這樣其他的節(jié)點負責的這種負載請求不會波動不會發(fā)生變化。只有落在我們分配的節(jié)點順時針之前的節(jié)點會有一些變化。所以這樣就非常容易把一個節(jié)點加到里面不影響整個系統(tǒng)的動蕩。