1992年，世界上第一條短信發送成功。
2001年，我國移動短信業務量達189億條，到2008年這一數字直接蹿升至5900多億條。
網絡沒有普及的年代，短信作為即時通訊工具，必不可少，尤在熱點假日的短信發送量更是爆增。
然而，2012是曆史轉折點，我國手機使用者短信發送量到達9000億條頂峰後，開始下降。
随着移動網際網路的發展和即時通訊工具的疊代，“短信”驟然被拉下神壇。
“短信”已經成為了過去式了嗎？
資料告訴我們：并不是。
無論是常見的使用者登陸、驗證碼身份認證，還是針對金融、電商、物流、教育等各類具體場景的短信産品，企業業務的短信市場需求均極大。
在“雲”的概念出現以前，企業對外的溝通還停留在資訊的交流和資料的傳遞，無法做到實時，也更談不上互動。
雲通信的出現，解決了這一問題。
雲通信是一種基于網際網路雲服務的語音與資料通信功能服務，通過資源整合、技術創新、風險控制等将營運商提供的基礎通信能力進行PAAS與SAAS化，提供給客戶統一、可靠、便捷、安全、創新的通信服務。
随着通信行業不斷的業務疊代，新的賽道為業務帶來了新變化，生态合作和管道的規模上量給系統帶來了模式創新，同時也倍增了壓力。
同時，國際站的地域環境和當地政策法規的因素，給全球化的建設也帶來了全新的機遇和挑戰。
本文将探讨雲原生時代下的網關技術，面向全球化、平台化、精細化的時代背景，如何在雲原生時代下，挖掘自我蛻變的契機，又如何拖着沉重的技術負債實作涅槃重生，實作高性能、高可用、低成本的架構演進和技術突破。
本文也将結合曆年雙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的運維管控。
經過演進發展，網關始終緻力于規模化、邊緣化、數智化三個方向發展：
通過雲網關和邊緣網關的雲網架構實作全球多站點、多節點的網絡拓撲部署；