隨通訊行業不斷的業務迭代，新的賽道為業務帶來了新變化，生態合作和渠道的規模上量給系統帶來了模式創新的同時，也帶來了更大的壓力。

 

同時，國際站的地域環境和當地政策法規的因素，給全球化的建設也帶來了全新的機遇和挑戰。

 

本文將探討雲原生時代下的閘道器技術，面向全球化、平臺化、精細化的時代背景，如何在雲原生時代挖掘自我蛻變的契機，又如何拖著沉重的技術負債實現涅槃重生，實現高效能、高可用、低成本的架構演進和技術突破，本文結合歷年雙11頂流下的閘道器技術實踐經驗落筆成文，希望對各位讀者有所幫助。

雲通訊閘道器發展新趨勢與挑戰

阿里雲通訊簡訊閘道器是基於領先的通訊架構和大規模分散式閘道器處理技術打造的雲原生閘道器，提供穩定的通訊服務能力，具備可冗災、可恢復、可切換的高可用服務保障能力，實現客戶的SLA保障要求，最終實現資源的最大利用和利潤的最大化。

 

高效能、高可用、低成本——是趨勢，也是挑戰。

 

高效能，十萬級併發、秒級觸達

阿里雲通訊起步於2017年，早期孵化於阿里通訊，後與阿里雲整合，經過短短几年的發展，目前已經是阿里雲上最熱門的雲服務產品之一。在2019迎來規模化發展，這一年在天貓雙11活動當天實現了歷史峰值，覆蓋全球200多個國家。

 

從技術層面上看，雲通訊簡訊閘道器在雙11支撐了十萬級QPS的流量分發，而且這類併發不是簡單的查詢，而是需要實現與運營商或其它第三方系統互動。如此之大的業務流量和資源的排程，除了要做好系統保障，同時還要保障傳送與響應的低延遲，實現全球覆蓋、秒級觸達，這是很大的一個挑戰。

 

訴求是：同時滿足高併發和高效能。

 

那麼現在的問題瓶頸主要出在哪裡呢？

 

1.    目前的閘道器架構主要是以規模換效能，需要大規模叢集分散式部署提供高併發能力。

2.    在通訊網路傳輸上，需要依託通訊標準協議等長連線方式透過網際網路傳輸。

 

高可用，分鐘級故障隔離及恢復

隨著業務發展，雲通訊資源節點將要達到萬級，如何在十萬級併發下實現萬級節點的穩定性是非常大的難題。另外，雲通訊有著類似於秒殺一樣的突變型流量的業務場景，比如營銷簡訊，會在幾分鐘內傳送海量的簡訊請求，這種瞬時流量往往會形成洪峰對系統產生衝擊。

 

從技術層面上看，雲通訊簡訊閘道器採用微服務分散式架構進行領域拆分部署，並大量使用非同步程式設計多執行緒併發排程模型，系統複雜度可見一斑， 這麼大的叢集規模和密集型的通訊網路，除了要做好業務故障監控覆蓋率、告警準確率100%，同時還要保障故障隔離及快速恢復，實現整體系統高可用，這又是一大挑戰。

 

那麼現在的系統風險還存在哪些隱患呢？

1.    目前的閘道器架構主要是多中心多分組的部署架構，需要將不同維度的業務、場景、客戶進行隔離部署。

2.    其次在資料儲存資源上，需要重點關注資料庫的穩定性。

 

低成本，容器資源彈性可伸縮

隨著指數級增長的運算規模，尤其是在雙11期間部署的上百臺伺服器，當流量和資源進一步翻翻，成本消耗也會水漲船高。然而，在大促過後，潮漲潮落之後，就是容器資源的擴容與縮容，但是對於有狀態的服務來說，擴縮容所對應資源遷移成本和難度著實不是一件輕易的事。

 

從技術層面上看，有狀態的服務是捆綁住了資源，原因是簡訊是長連線非同步全雙工的通訊模式，本質上的衝突是潮汐流量下資源的利用率問題， 面對這種有狀態的服務和昂貴的資源成本，除了要做好流量和資源最優匹配，減少閒置資源的成本浪費，提升CPU利用率，同時還要實現無狀態的容器資源彈性可伸縮，進一步降低運維成本，這又是一大挑戰。

 

那麼現在的技術難點又有哪些呢？

 

1.    目前的閘道器部署主要是DevOps的模式，需要預先申請資源再進行映象容器的部署。

2.    在資源連線的管理上，需要對資源連線的進行預分配，實現資源連線與容器IP的繫結。

 

借力破局：基於雲原生的邊緣閘道器架構

雲原生是一套因雲而生，又應雲而行的技術方法體系，降本增效是雲原生應用最大價值。

下面，就結合雲原生的技術特點聊一下簡訊閘道器建立了哪些技術優勢。

 

易部署、廣覆蓋，分鐘級服務部署

雲原生是一套因雲而生的技術方法體系，而阿里雲又擁有遍佈全球的中心和邊緣節點，那麼簡訊閘道器如何基於容器化、服務網格、微服務等雲原生技術，結合邊緣雲，打造輕量級邊緣閘道器和雲網部署架構，實現易部署、廣覆蓋的全球就近接入和分發能力，以此達成提升閘道器效能和減少運維成本的發展目標。

 

為了實現異部署的目標，這裡主要有兩個重點：一是系統架構支援雲原生化的易部署，二是DevOps平臺支援應用環境的易部署。

 

首先在系統架構層面上，簡訊閘道器為此拆分解耦實現了兩層架構體系來對業務進行支撐，打造的輕量級閘道器架構更易於部署在各地域，使客戶實現就近接入，保障低延遲的簡訊傳送體驗。如下圖所示：

簡訊閘道器兩層架構對業務支撐提供多種解決方案，輕量級的閘道器架構非常易於部署在各地域，使客戶的實現就近接入，保障低延遲的簡訊傳送體驗。輕量易於部署，無論是公有云、混合雲或專有云，都可以基於容器化實現快速部署構建。簡訊閘道器兩層架構業支援相互獨立部署，也可以整合整合部署，幫助打造多樣化的部署架構。

 

其次在DevOps平臺層面上，為了適配多雲環境的部署情況，邊緣閘道器需要的中介軟體和資源要儘可能輕量級和開源化，包括部署到公有云、混合雲和專有云裡。基於此，我們在設計上邊緣閘道器完全基於雲原生的底座進行構建，實現部署上更強的適配性。

在DevOps平臺方面我們選擇了兩種方式進行支援：全託管叢集和邊緣全託管叢集，這兩個平臺都可以將底層的資源池透過虛擬化技術封裝成一個個的容器，在結合映象服務即可實現服務的快速部署，特別要說的邊緣全託管平臺還可以納管駐外的資源池，這樣我們在面向混合雲部署時，只透過映象就可以部署到客戶的容器化服務中。

綜上所述，邊緣閘道器基於阿里雲邊緣節點，助力業務下沉至離使用者10公里的地方，減少時延和頻寬成本，在保障穩定性的同時實現技術降本和全球多節點的快速部點。

 

易排程，低延遲，毫秒級響應

雲原生又是一套應雲而行的技術方法體系，上文提到簡訊閘道器是透過多分組的部署解決方案，在接近使用者的區域分別獨立部署閘道器，進行與供應商的低延時高質量對接。那麼這裡就有一個問題； 如此大規模的邊緣節點是如何被排程的？排程的複雜度又有多高？

 

針對流量排程複雜場景，降低業務架構複雜度，透過架構升級實現業務邏輯與流量管控邏輯解偶，讓複雜排程變為可觀測、可管控的統一的流量排程模型，以此實現易排程、低延遲的發現目標。

 

為了實現易排程的目標，同樣需要解決兩個重點：一是系統架構支援雲原生化的易排程，二是通訊網路架構支援應用環境的易排程。

 

首先在系統架構層面上，實現基於 三級策略的路由定址排程演算法實現節點間、節點與資源間、資源與連線間的資料鏈路通訊；以及 基於多因子多權重的路由協同控制動態感知演算法實現異常情況下的穩定可靠路由定址。

除此之外，簡訊面向的場景：驗證碼、通知、營銷等，對於時效性的要求非常高，技術上我們實現了 基於場景優先順序的自適應彈性流控演算法，多個訊息佇列之間不再是孤立的，每個佇列的流速控制都會受到其他佇列執行情況的影響，優先順序越高的佇列流速控制越大，優先順序越低的佇列流速控制越小，並且可以隨系統執行情況自行動態調整，具備高時效性的自適應調整能力。其實，無論哪種演算法，主要實現的目標都是讓流量更加平滑、更即時。

其次在通訊網路架構層面上，我們主要採用了雲上開源的中介軟體產品，比如Nacos、Redis、MNS等，另外在VPC組網過程中，也大量採用來EIP、NAT、SLB、VPN、IPSec等網路加速技術，以此來保障通訊的低延遲。

我們知道雲服務通常部署獨立VPC內，VPC訪問需要透過SLB/NAT，公網使用者主動訪問雲上資源的流量是經過SLB進行轉發，雲上資源主動訪問公網的流量是經過NAT進行轉發。針對跨region雲上網路互訪情況，我們採用的方法是對跨Region閘道器呼叫的是先走到本Region閘道器的彈內，再到達本Region閘道器的彈外，這樣網路傳輸的效能就會有所保障。

易運維，省成本，秒級彈性伸縮

上文中提到簡訊閘道器有著龐大的叢集規模和全球節點，除了在排程上的考量外，另外還有一個問題： 如此大規模的邊緣節點是進行成本控制的？潮汐流量下的彈性伸縮又如何運維？

 

從本質上來看，簡訊閘道器的運維核心難點還是因為連線的有狀態，有狀態就會產生各種的複雜問題，其中最大的難點就是有狀態的容器不能進行彈性擴縮容。所以，實現省成本的目標之一也在於此。為了實現易運維的目標，需要解決兩個重點：一是系統架構支援雲原生化的易運維，二是可觀測技術支援數智化的易運維。

 

首先在系統架構層面上，我們透過 分散式松耦合閘道器架構實現了對傳統通訊閘道器的雲端再造，解耦業務處理模組和通訊協議會話模組，業務處理層無需關心通訊連線狀態，可根據流量動態擴縮容，自研的資料聯結器提供路由發現、排程的能力。

為了更輕量級的部署和設計，我們將雲網架構從整體上拆分成獨立的領域模組，每個模組都獨立解決各自領域的問題。對一些協同關聯的業務服務領域，我們採用的是服務整合和擴充套件的方式進行服務間的通訊模式，而不是在本地閘道器進行開發，從而保障本地閘道器的輕量級和專屬性，進而更易於運維。

其次在數智化運維層面上，首先思考的是為什麼要深挖可觀測技術？可觀測資料覆蓋的範圍是哪些？資料是隔離的？還是聚合的？從網路結構上看是是什麼樣的？

 

“可觀測”是個比較大而全的概念，包括了應用效能指標、鏈路追蹤、容器監控、系統監控、日誌監控等等，每個都是單獨一個點，但是對於業務應用系統來講，我們要做的應該是一個全方位的可觀測體系。

 

具體從層次來看，最上面是“看到”，能看到指標，能告警；下一層是可以“分析”，可以追蹤呼叫鏈，可以分析RT、異常出在哪裡；最下層是反作用， 對於一些比較明確的場景，透過系統自動化實現基於編排的根因分析、基於編排的故障自動定位。

總結來說，可觀測應該是一個多面的，我們其實解決的是如何基於這些可觀測資料聚合分析並反作用於業務閘道器，能做到自動化AIOps的運維管控。

 

經過演進發展，閘道器始終致力於規模化、邊緣化、數智化三個方向發展：

 

透過雲閘道器和邊緣閘道器的雲網架構實現全球多站點、多節點的網路拓撲部署；

 

著力邊緣化的架構演進助力規模化閘道器的快速、便捷的部署能力，同時重建雲網通訊模式，實現雲閘道器的彈性水平伸縮能力；

最後透過可觀測技術對全球閘道器節點實現監控、埋點的Metrics和Trace，構建基於編排的根因分析能力。

希望透過上面的內容可以幫助到大家對雲通訊全新的理解，如果有感興趣的同學也歡迎進行溝通交流。

「影片雲技術」你最值得關注的音影片技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音影片領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲影片雲產品技術交流群，和業內大咖一起探討音影片技術，獲取更多行業最新資訊。