摘要：哪怕是看上去一個很簡單的即時通訊雲服務，想要覆蓋5億+用戶的併發需求，都不再是一件小事。
文：寧川
一轉眼，雲計算已經十年了。十年間，從AWS亞馬遜雲開始，涌現了Salesforce、微軟、谷歌、IBM、VMware、阿里、騰訊、網易等一批雲計算服務商，從互聯網公司到傳統IT巨頭都捲入了這場雲計算的時代大潮中。Gartner數據顯示，2016 年全球公有云服務市場規模有望達2,086 億美元，較2015年的1,780 億美元市場規模增長17.2%。
然而，雖然十年過去了，公有云市場也將超過2000億美元規模，但很多人依然不明白，到底什麼是雲計算？雲計算的架構與傳統IT架構到底有何區別？本文就以一個看似非常簡單的即時通訊雲服務爲例，看一看典型雲計算架構的真實世界。該案例以網易雲信的即時通訊雲服務爲實際案例，由網易雲信首席架構師周樑偉在2016全球架構師峯會上介紹。
不同雲服務場景中，消息也有很多種
（圖一：具有不同時效性的消息）
可能有些人會說，消息不是很簡單麼？就是一個數據包，在接收方和發送方之間傳輸一下，不就這麼回事兒嘛？但實際在雲計算環境中有各種應用場景，包括即時通訊、CDN直播、在線客服等等具體的場景，不同的場景裏有不同類型的消息。
從功能上來區分，可以分爲帶有多媒體文件的消息，需要在消息裏內嵌採用了對象存儲服務的文件以及提供上傳下載功能，從而避免開發者接入第三方存儲服務的麻煩；自定義消息，可以根據需求定製個性化消息功能，如閱後即焚、紅包等。
從使用場景上區分，可分爲單聊、羣聊與聊天室等。對於單聊消息來說，只有單一接收者，且當接收者處於離線期間，有意義的消息也需要存儲下來；對於羣聊消息來說，每條消息都有多個接收者，而且也需要存離線消息；對於聊天室消息來說，只有在線消息，接收者是當時所有在聊天室的成員。
從時效上來區分，可分爲發送者多端同步消息、Online在線、Offline離線、漫遊消息和雲端歷史消息等。其中，發送者多端同步消息，指從發送者的角度，在任何一個端上發出的消息都會被實時同步到其它在線端上。Online消息主要指當有客戶端在線時，消息直接投遞到對方的設備上，需要秒級送達。Offline消息主要是爲了保證消息不丟失，消息被存儲在Cache和關係型數據庫中，當上線之後可在第一時間獲得到離線期間的未讀消息。
漫遊消息，這類消息不侷限在單一設備上，只要通過賬號登錄，即使是在不同的設備上發生的消息，也能通過雲端在其它設備中獲取。雲端歷史消息，指存儲在海量數據庫中的歷史消息，這類消息發生的時間可能已經很久，單位可以年來計算，它的訪問頻率低但存儲量大。
由上述的幾種消息類型的分法，就可以看到不同的消息適用於不同的應用場景和環境中，相互之間有着複雜的搭配與組合關係。
雲計算架構的兩大特徵（1）：規模化併發與應用邏輯節點分離化
雲計算最大的特點就是分佈式計算，而且是互聯網規模的分佈式計算，這種計算模式在應用開發的架構上有兩大主要特徵：原有APP應用的邏輯節點的分離化與按着新邏輯的節點的集羣化。
怎麼理解？先看一個原有應用的邏輯及邏輯節點。以消息投遞過程爲例：
首先，要理解在每個IM客戶端都會各自維護一條與服務器的長連接，各自的消息和信令都在這條長連接上傳遞，這是最基本的原理。
【圖二：傳統點對點型消息投遞】
在圖二中是一個點對點型的Link服務器，當發送者A發送一條消息之後，通過Link這條消息提交到APP中處理，APP中查詢到該消息接收者B所在的Link服務器是Link y，於是向Link y服務器下發一條下行通知包，Link y上再找到用戶B對應的長連接並將通知下發到客戶端。
這種模式下，所有的接入點Link對於所有的用戶來說都是對等的，可以接入到任何一個服務器中，任何消息的發送都必須在業務層查詢到目標接收者所在的Link服務器，並往相應的Link服務器下發通知包。
因此，如果是一次羣發行爲，那就需要在業務APP上把所有羣內的成員所在的Link列表都查詢一遍；這是一個比較耗時的操作，並且是隨着消息接收成員的數量不斷上升而開銷不斷增大。所以如果需要往聊天室內發送消息，由於聊天室內的成員數量非常龐大，這種模式很快就會遇到性能瓶頸，消息投遞的延時會非常嚴重。
【圖三：多點對多點型廣播型（例如聊天室）消息投遞】
對於廣播型的Link服務器，在分配接入點時要遵循一個原則：那就是同個聊天室內的成員在分配聊天室時，儘量分配在同一組接入點上；在Link上維護了每個房間內所有成員的長連接集合；在App上維護的不再是特定用戶和Link之前的映射關係，而是維護了特定房間分配的Link集合。
於是任何一個成員發出一條聊天室廣播消息之後，消息通過link上行到App，App只要找到該聊天室已經分配的Link地址列表，往每個Link上下發一個廣播消息，Link在收到下行的廣播消息之後再在本地做廣播分發，這個效率比點播的模式高出了不止一個數量級。
通過這個對比，可以明顯看到，針對聊天室這種特殊的場景採用廣播的消息投遞機制可以使消息併發能力得到指數級的增強：針對一個10000人的房間，假定同時只有1/10的人在發言，那每條消息會被廣播給所有人，整體的消息併發就能達到百萬千萬量級。
而在廣播模式中，將消息的分發拆解到了兩個過程中：第一步先將消息從App投遞到Link服務器中，這個過程每條消息只有一份；第二步是將消息通過Link服務器再次拆分後投遞到本地最終的客戶端上，這個過程在Link中直接完成。
因爲作了節點的分拆，就可以在每個節點由單點對單點模型變爲單點對多點甚至多點對多點，從而達到了規模化併發和分佈式處理的效果。
雲計算架構的兩大特徵（2）：應用彈性與分離後節點的集羣化
在前面的廣播型消息投遞過程中，可以發現單個Link節點的業務壓力非常大，消息的上行壓力和下行壓力也有同樣的很大,不可避免得很快會遇到單個節點的性能瓶頸。怎麼實現應用彈性？這就是集羣化發揮作用的時候了。
集羣化分爲兩步，第一步是消息在進出Web瀏覽器過程中的Web服務的集羣化與優化。
雲信最初在設計針對Web瀏覽器的長連接服務器時，由於服務器既需要處理SSL編解碼、又要做請求包的格式轉換、還要做長連接的管理，這直接導致了服務器性能很快達到瓶頸。特別是在用戶側的連接有比較頻繁的重建的場景下，大部分的CPU資源都花在了SSL握手過程中。
針對這個問題，網易雲信使用nginx（一種高性能的軟服務器）作爲前端代理，並把SSL的處理過程移到了nginx上，並使用性能較好的服務器來做nginx代理服務，而在後端WebLink上直接使用http協議，極大提升了後端節點的處理能力。通過這種代理方式，在4核8G的虛擬機上，單個節點的承載能力從1萬連接數飆升至10萬。
【圖四：實際的互聯網超大規模併發消息投遞】
集羣化的第二步是網絡環境的集羣化與優化。
在圖四中可以看出，在網易雲信實際的實踐過程中，把Link服務器與APP之間再做了拆分，中間增加了網關接入層和路由層。
網關接入層負責客戶端長連接的維護和管理，所有的接入節點甚至可以是無狀態的對等節點。網關接入層只負責客戶端與服務器之間請求的傳遞和轉發，並優化轉發效率，網關接入層在實際部署時會同時分佈到不同的網絡環境中，比如分佈在異地的兩個機房中。
而應用業務層需要處理大量請求並負責數據庫、緩存、隊列、第三方接口等組件的交互，其穩定性、可用性和擴展能力直接影響了整個雲服務的質量。爲了使業務層具有更好的彈性，在網關接入層和業務層之間引入了一個路由層來解耦。業務節點在上線之後，會將自己註冊到服務中心，路由節點會轉接網關層的請求包，並從服務節點中挑選匹配的節點分發請求。因此，這種三層架構使系統整體具有更好的彈性。
爲了提高業務的可用性，還會將業務節點分佈到分屬於不同網絡的環境中，正常情況下可以同時提供服務，一旦其中一個環境的網絡或者基礎設施出現故障，可以快速得通過路由層來將故障集羣下線。對於一些對資源獨佔需求比較強烈的應用或客戶，可以通過路由層將該客戶應用下的所有流量導入到獨立的集羣中。這樣的模式還靈活支持灰度升級模式，可以將其中部分業務節點升級，然後通過路由層的配置將指定的用戶流量導入到新升級的節點中。
（圖五：實際案例數據）
以2016年某衛視中秋晚會現場活動爲例，該晚會有一個在線評論區就是一個典型的聊天室，觀衆可以在其中發佈自己的消息。這種場景的特點是突發流量非常高，用戶幾乎在同一時間連接到服務器上，發消息的行爲也具有很強的突發性。針對這個特殊活動，雲信分配了6臺雲主機作爲長連接服務器，整個活動的活躍人數達到了50萬，併發在線人數達到了10萬多，廣播消息的峯值在1000萬每秒以上。
再以一個典型的在線秀場類型應用爲例，開發者使用聊天室消息來發布文字和禮物等消息，這種使用場景的特點是每個房間的人數不會特別多，平均單個房間的同時在線人數在幾百人左右；但是房間個數非常多，用戶活躍行爲沒有突發性，卻具有持續性。網易雲信分配了10臺雲主機，承載的單日活躍人數達到百萬+，併發在線用戶數峯值也達到了10萬以上，單日的消息總量2億+。
支持千萬級高併發消息的雲服務架構
網易雲信是網易公司集16年IM經驗打造的即時通訊雲服務（PaaS），也是網易雲第一個開放給市場的雲服務產品。網易雲信從2015年10月13日上線至今，已成功接入15萬+APP開發者，覆蓋用戶達到5億+。在網絡和區域上面覆蓋了196個國家、567個地區，並保證100%的送達率。
開發者通過集成客戶端SDK和雲端OPEN API，即可快速實現強大的IM功能，網易雲信全面支持Android、iOS、Web、PC等多平臺。除了應對傳統開發者的各項IM基本功能外，網易雲信還提供了高級通訊功能，包括實時音視頻、教學白板、互動直播、專線電話、短信、專屬雲在內的獨家功能以及更多其他服務。
（圖六：網易雲信的架構圖）
圖五爲網易雲信的分層架構圖，處於最下層的是客戶端SDK覆蓋了安卓、iOS、Windows PC桌面端、Web網頁端和嵌入式設備等多種開發平臺。在SDK層使用的網絡協議有TCP協議和Socket.IO協議，後者專門用於Web SDK中提供長連接能力。A/V SDK是基於UDP協議的實時音視頻SDK，用於實現基於網絡的語音和視頻通話。
再往上就是客戶端直接接入並與服務器建立長連接的連接層，這裏提供了Link服務，以及基於HTTP協議上API服務和LBS服務等，其中LBS服務用於幫助客戶端SDK選取最合適自己的網關接入點，從而優化網絡效率。
在網關接入層之上有一個路由層，這是一個比較有意思的負載均衡層，它在Link層和Service層之間解耦並提供高可用和易擴展等特性。在HA的具體實現方式上，提供了一個叫協議路由的服務，代爲分發業務請求——路由層會按照預定義的規則將來自客戶端的請求轉發到相應的業務節點上，當業務集羣擴容之後路由服務馬上能發現新的可用節點，並將請求轉發過去，當發現業務節點出現異常時也會被路由層標記並隔離下線以備替換。
在路由層上就是具體的業務節點集羣，後端直連數據庫、cache等各種基礎服務，這個集羣中節點的特點就是輕量級，並且每個節點都是無狀態的。在實際部署這個集羣時會跨網絡環境部署，比如在同城雙機房中分別部署一套業務服務節點，前端通過路由層來分發業務請求，平時正常時業務互爲熱備，平均分擔線上的業務流量，當單一網絡環境或者基礎設施出現故障時馬上會被路由服務檢測到，並將該環境下的計算節點標記下線，將線上的流量請求全部轉發到正常工作的集羣中，從而提高了服務的整體可用性等。
最後在業務層之上，雲信中提供了關鍵功能；包括核心的單聊消息、羣聊消息和聊天室、通知等；以及用戶信息託管，特殊關係管理等；還有面向API提供的如短信業務、回撥電話和專線會議等；還有實時音視頻和直播功能等。
最右邊的是從服務層上單獨列出來的更重要的功能，包括與開發者應用的第三方數據同步、個性化的內容審覈支持、超大羣服務、登陸登出事件日誌、漫遊消息和雲端消息歷史功能、推送服務等等。
周樑偉介紹網易雲信服務有三大特點：穩定、安全和快速。在穩定方面，網易雲信的SDK採用長連接機制來實現，並且由SDK+心跳的方式來檢測斷線和自動做重連，同時針對移動網絡等弱網環境，對SDK做大量的優化工作。對Web端，雲信使用socketIO協議，實現長連接的同時也解決了瀏覽器的兼容性問題。
在安全方面，網易雲信對所有在公網傳輸的數據都進行了加密，主要採用了流式加密。即客戶端需要生成一個一次性使用的加密祕鑰，並使用非對稱加密方式將這個祕鑰加密之後傳給服務器，之後該加密祕鑰被保留在該長連接的會話信息中，數據來往均使用該祕鑰加密。經過實踐，這種流式加密能夠有效防止中間人攻擊和數據包回放等攻擊手段。
在快速方面，網易雲信藉助LBS服務，幫助客戶端尋找到最適合自己的網關接入點。對頻繁的前後臺切換和重登陸這種移動客戶端場景，SDK提供自動登錄和重連等機制，即在UI界面起來的同時已經提前把消息通道建立。而在接入網關的選擇策略中，通過並行來提升連接建立的速度。
周樑偉說網易雲信不把自己定義爲一個狹義上社交工具，雲信可以定義爲一個OTT，以即時通訊爲切入，提供一個管道，用戶通過網易雲信的管道可以實現任何意義上連接服務，而不限於IM.可以是電商平臺、社區、在線教育，也可以做任何一個想做的產品。雲信不會集成賬號，賬號都是用戶自己的。“因爲網易雲信就想做一個非常專業的‘管道’”，周樑偉說。
看到這裏，讀者應該對雲服務有了新的認識。哪怕是看上去一個很簡單的消息傳遞雲服務，想要覆蓋5億+用戶的併發需求，都不再是一件小事。