在云計算發展飛速的時代，傳統通訊正在與互聯網、IT等各大領域融合發展，無論是IM、視頻、VoIP、還是呼叫中心，企業都需要根據自身業務形態開發和部署屬于自己的通訊平臺。那么，在用戶群體不斷壯大之時，云平臺如何該支持百萬千萬或者上億的在線用戶?日前， 容聯云通訊CTO(首席技術官)許志強為程序員們帶來了一場主題為“云通訊PaaS平臺的挑戰和應對之道”的在線培訓。
一個云平臺怎么支持百萬千萬或者上億的在線用戶?許志強認為這里有幾個關鍵點：
1、操作系統調優
第一步是操作系統的調優，因為操作系統的缺省設置并不是適合這種大規模的系統訪問的，包括打開文件數、TCP接收發送緩沖等，你需要根據你的業務請將操作系統各項的參數設置進行一個調優。
2、采用異步接口
第二步，因為現在大多數的網絡協議都是基于TCPIP協議的，客戶端在很多情況下是非活躍的，那么要單臺機器處理幾十萬或者上百萬以上的連接需要采用異步的接口。在Linux上使用的是epoll,在windows上就是I/O Completion Port. 十年前，我們會討論一臺Web服務器怎么支撐一萬個用戶(著名的C10K問題)，現在這個問題已經隨著操作系統的完善已經非常輕易的解決了，關鍵是怎么使用操作系統提供的這些接口。現在如果采用長連接，目前的技術水平達到幾十萬甚至上百萬(依賴實際的吞吐量)的長連接單臺服務器是沒有任何問題的。
3、內存數據庫緩存、減少數據庫操作
第三點，我們知道數據庫的操作是比較重的，像內存數據有可能用(Memcache、Redis)或者各種內存數據庫緩存一些數據，減少數據庫的操作,衡量哪些數據放內存數據庫中的一個重要原則就是： 如果數據訪問比較頻繁，可以通過key訪問，業務邏輯上不需要強一致的數據適合放內存數據庫。
4、內部模塊交換采用長連接、Protocol Buffer等
系統內部盡可能采用長連接，因為系統的每一次連接都是一個開銷，可能在低負載情況下沒有關系，每次請求一個連接，看上去也挺快，一秒鐘幾百個請求，一千多請求也行，但是一旦系統負荷增大，這部分開銷在整個系統開銷就會非常大了。另外在協議編碼的盡可能采用像Protocol Buffer的協議，這是谷歌開源的協議，具有很好的編解碼效率和傳輸流量優化。
5、節點可并行擴展、Cluster集群
設計的時候需要考慮各個模塊、節點是否可并行擴展的?是不是增加一個模塊、節點就能夠提供服務擴展系統容量?將每個節點盡可能做成無狀態的，只有做到這點，系統才能可擴展、才能做集群、才能采用Cluster集群來做負載均衡服務。
6、自動部署新業務節點支持服務的自動化擴容
云服務的用戶可能突然業務量大增，系統能不能通過自動部署解決彈性自動擴容?這是云通訊現在正在做的。我們跟運營商的線路不是可以通過動態增加的，那是物理接口沒有辦法增加的。但是針對IP端的設備我們是可以做自動部署的，像阿里云、亞馬遜，可以提供API讓你自動地創建虛擬的主機，你可以提前做好相應的磁盤映像, 當檢測到某個類型的設備負責過高后，可以通過接口把這個服務部署起來。當你業務節點快速增加的時候，你采用這種自動部署的方案可以大幅減少人工干預維護的工作。
7.一次性Hash的負載分配方式
講到集群，就必須說的是集群中負載的分配方式。舉個例子，之前阿里云余額寶是從IOE架構移到阿里云上，當時存在一個很大的一個挑戰，余額寶的請求量太大了，mysql數據庫性能不夠，怎么解決這個問題呢? 常見的方法就是根據賬號分數據庫、分系統處理，按照賬號分配到對應的數據庫和處理系統， 這就是負載分配的方式。一般來說，大家一個很直觀的想法可能是根據這個帳號做一下hash計算。有三個節點，就除三，余數在哪兒就去哪個節點，這是慣用的思路。但是這里有一個問題，之前的三個節點，后來可能變成四個節點，五個節點，一旦變成四個節點，五個節點以后，原來的Hash的值就不對了，如果加了一個節點以后，后面所有的分配都會不對，數據庫什么都要重新調整，整個負載會劇烈的進行一個移動，對增加處理節點是不友好的。
下面是百度上的一個圖，這個是一次性Hash的負載分配方式：
假如這是一個環，這個環是從0到2的32次方，我們保證Hash出來的值在這個區間內隨機分布。在這個區間內，我們這里只有四個節點，圖中藍色的節點是我們的服務節點。當一個請求來了，或者一個帳號來了，這個請求是由誰來服務呢?我們把這個請求計算一個hash，hash值會落在這個環的其中一個點上，就是圖中的這個紫色的點。紫色的點實際上不是一個具體的服務點，它會按方向找最近的點，假如我們以順時針方向，他就找順時針最近的一個點。假如在第三和四節點之間，這兩個節點的負載增加了，我們就在這兩個節點中間加一個節點，把他們中間的負載做一個分擔，這樣其他的節點負責的這種負載請求不會波動不會發生變化。只有落在我們分配的節點順時針之前的節點會有一些變化。所以這樣就非常容易把一個節點加到里面不影響整個系統的動蕩。
京公網安備 11010502049343號