隨著技術革命的不斷演進，特別是我們所在的通信行業(yè)，系統(tǒng)軟件本身都面臨技術轉型問題。在VOIP領域，傳統(tǒng)的系統(tǒng)平臺大部分基于硬件設備開發(fā)，缺少靈活性，缺少可擴展性，不能實現(xiàn)資源的彈性伸縮管理，更難實現(xiàn)敏捷開發(fā)，缺乏虛擬化完整的支持等問題。Matt Stine在2015年出版了第一本關于云原生技術架構的著作以后，很多開發(fā)人員都紛紛在其架構下開發(fā)不同的業(yè)務場景。在基于SIP網(wǎng)絡技術實現(xiàn)的語音視頻方案中，SBC，IPPBX，呼叫中心等也從硬件設備類型，虛擬化，包括絡功能虛擬化，SD-WAN方面不斷擴展。如果讀者對網(wǎng)絡編排有興趣的話可以閱讀以下文章：
　　基于SDN-NFV-SD-WAN構建的SIP/IMS/SBC/UC虛擬化部署，網(wǎng)絡編排的可行性討論和具體示例實踐分享

　　筆者將針對SIP網(wǎng)絡技術中會話邊界控制器在云原生技術架構中的實現(xiàn)進行討論分享，筆者讀者進一步了解如何在云原生技術架構的基礎上實現(xiàn)SBC 高可靠性實現(xiàn)方式，自動測試，軟件版本升級和灰度測試環(huán)境管理等方面的問題。以下討論中主要包括：云原生技術背景介紹，關于SIP網(wǎng)絡技術和SBC技術架構在云原生中的應用和其迫切性討論，關于基于云原生的SBC中信令媒體分離，共享數(shù)據(jù)庫狀態(tài)信息，SBC高可靠性中active/active，active/standby兩種機制的HA支持方式，資源自動伸縮，版本管理灰度測試的結果方面的問題進行討論。

　　在2017年，Matt Stine有針對云原生的技術架構提出來一個新的概念，新的概念包括六大技術特征：可處理，可替換，可監(jiān)控觀察，可測試，可部署和可模塊化。另外一個云原生的倡導者Pivotal 也對云原生技術架構做了四點概括，包括：DevOps+持續(xù)交付+微服務+容器，其技術架構部署方式如下：

　　此圖例以及以下圖例均來自于互聯(lián)網(wǎng)資源

　　諾基亞貝爾實驗室的Bessem和其他研究人員針對5GPP項目垂直行業(yè)，關于網(wǎng)絡中具體應用場景，包括智慧城市，直播娛樂產業(yè)如何支持云原生針對具體的應用模塊進行了分解部署討論-Cloud-Native and Verticals' services，特別針對網(wǎng)絡功能虛擬化和SD-WAN等邊緣終端業(yè)務進行了討論。這些研究成果都對云原生技術有了更進一步的指導。下面，筆者重點從SIP網(wǎng)絡，SBC相關業(yè)務角度進一步討論SBC云原生技術的演進。

　　在以上的分享中，我們可以看到，云平臺部署結合云原生技術架構會逐漸在很多領域進行部署。在我們重點關注的領域中，融合通信平臺往云平臺遷移，呼叫中心遷移往云平臺遷移，并且逐漸占據(jù)相對比較大的份額。從技術發(fā)展的方向來說，在云平臺軟件技術架構實現(xiàn)的方式上，云原生的各種技術需要滿足微服務，容器，自動交付，自動測試和自動伸縮等特點。進一步來說，SBC的技術架構需要支持這些云原生技術特點。

　　SBC作為SIP網(wǎng)絡或者IMS core網(wǎng)絡中最核心的管理模塊，它可以實現(xiàn)負載均衡處理，智能路由規(guī)則處理，實時智能媒體分析等處理，幫助IPPBX或者呼叫中心系統(tǒng)進行靈活控制和強大的路由管理。為了實現(xiàn)基于SIP網(wǎng)絡中各種業(yè)務需求的處理，SBC需要不斷在系統(tǒng)技術架構上滿足云部署和現(xiàn)在云原生的技術要求。

　

　　通過以上圖例我們可以看到，通過云原生SBC實現(xiàn)其主要目的在于云平臺架構的自動化處理，包括技術架構底層的自動化部署，產品生命周期管理，自動部署配置自動化實現(xiàn)和產品或者服務上線后自動化測試驗證等目標。

　　根據(jù)Exact Ventures的預測，到2024年，很多運營商的SBC都需要往基于云原生的環(huán)境中部署。

　　

　　為了滿足終端企業(yè)用戶的要求和運營商的戰(zhàn)略部署，基于云原生SBC部署是一個勢在必行的一個業(yè)務要求。為了實現(xiàn)基于最新云原生技術架構的要求，SBC也通過技術的演進逐漸滿足用戶的需求。

　　

　　為了實現(xiàn)基于 Cloud-Native 技術架構 的SBC的最新功能，SBC必須針對性地解決目前SBC應用環(huán)境中的各種要求：

　　在接下來的章節(jié)中，筆者將重點介紹如何通過具體的邏輯模塊的分離來實現(xiàn)以上關于云原生技術的目標。

　　當前，市場上最新的基于云原生會話邊界控制器-SBC的技術架構實現(xiàn)方式完全對各種功能模塊進行更深入的分解，媒體和信令解耦，數(shù)據(jù)庫共享，均衡負載，呼叫管理，網(wǎng)絡服務等進行主從備份和主主備份方式處理。另外，對用戶來說，很多傳統(tǒng)架構開發(fā)部署的融合通信平臺，IPPBX，呼叫中心。在部署和項目調研時，用戶都要考慮用戶人數(shù)，物理服務器資源等，通常按照最大用戶數(shù)量或者并發(fā)數(shù)量進行的部署。如果用戶數(shù)量減少以后，或者某些服務器不再使用以后，他們將要面對公司資源的浪費和閑置，導致極大浪費。因此，基于資源的彈性計算解決方案是一個非常不錯的選擇。筆者在以下討論中將針對SBC在基于云原生技術架構中的高可靠性設置，自動彈性收縮，金絲雀軟件灰度測試，版本管理方面進行討論。

　　

　　通過以上的SBC技術架構就可以實現(xiàn)當前SBC最需要支持的功能，包括信令和會話負載的分離，通過共享數(shù)據(jù)庫來實現(xiàn)狀態(tài)（會話狀態(tài)和注冊狀態(tài)）共享，實現(xiàn)高可靠性部署中的active/active方式和active/inactive方式支持，并且可實現(xiàn)廣泛的大規(guī)模集群部署方式。在關于SIP負載均衡的處理過程中，通過共享數(shù)據(jù)庫會話狀態(tài)數(shù)據(jù)和注冊狀態(tài)數(shù)據(jù)，SIP在會話入口和退出狀態(tài)中，分別對幾臺SBC worker進行負載處理，根據(jù)其不同狀態(tài)進行發(fā)布時分發(fā)機制的均衡負載。例如，如果 worker 3 出現(xiàn)故障，它down 掉以后，LB 負載均衡就會根據(jù)共享數(shù)據(jù)庫中當前的狀態(tài)自動調度到worker 4的示例上。

　　

　　除了負載均衡的自動化處理以外，SBC還要實現(xiàn)SBC worker的自動伸縮來滿足業(yè)務功能突發(fā)要求增加帶來的超載問題。這一功能可以滿足呼叫并發(fā)突然增加，視頻語音會議人員突然爆增時資源的負載均衡支持。

　

　　在以上SBC設置場景中，SBC通過評價指標實現(xiàn)自動控制的解決方案。如果評價指標觸發(fā)了多臺worker需要介入到流量處理時，通過閥值計算，SBC worker數(shù)量會自動實現(xiàn)擴展功能。如果SBC 評價指標的數(shù)據(jù)發(fā)生更新。如果數(shù)據(jù)流量降低以后，SBC worker會自動縮減到原來的數(shù)量。通過SBC自動擴展解決方案，企業(yè)用戶或者運營商級用戶不僅僅可以增加SBC 實例數(shù)量，同時也可以在無需更多空閑資源時，系統(tǒng)自動縮減SBC 示例的數(shù)量，這樣可以完全避免系統(tǒng)資源的浪費。

　　在軟件行業(yè)的開發(fā)流程中，Canary（金絲雀）更新是一個比較先進的軟件版本管理手段。用戶可以先發(fā)布一個Canary 金絲雀版本，和目前應用環(huán)境進行灰度測試。Canary版本經(jīng)過一定時間測試，用戶可以發(fā)現(xiàn)測試版本的bug，然后及時修復發(fā)現(xiàn)的bug，或者回滾到以前部署的版本，保證其系統(tǒng)完整的穩(wěn)定性。SBC測試開發(fā)流程也可以使用此手段來控制功能發(fā)布的結果。

　

　　在以上升級流程中，如果我們要升級 worker 2版本時，我們可以先部署一個worker 2（v2，金絲雀）版本，然后讓 worker2的v2 版本處理一定的數(shù)據(jù)流量。系統(tǒng)經(jīng)過一段時間運行后，根據(jù)系統(tǒng)狀態(tài)數(shù)據(jù)，如果我們發(fā)現(xiàn)其工作狀態(tài)正常的話，可以完全對work2 的v1版本進行升級，完全升級到v2版本。如果發(fā)現(xiàn)v2版本有問題的話，系統(tǒng)會回滾到原來的v1版本，不再對work2 v1 版本進行升級。通過Canary升級控制機制可以完全控制SBC軟件升級的可控性。

　　在云部署場景中，特別是需要大規(guī)模集群部署環(huán)境時，SBC的HA 高可靠性機制是系統(tǒng)穩(wěn)定性的絕對保證。通過active/active 和active/standby模式支持所有的SBC worker實例。在active/active 環(huán)境下，如果以下三個worker 有其中一個down 掉的話，例如worker IP-A出現(xiàn)故障，系統(tǒng)通過共享數(shù)據(jù)庫狀態(tài)數(shù)據(jù)，其他的worker（IP-B和IP-C）將自動承擔IP-A的工作量，把它的工作量發(fā)布到另外兩個SBC worker 實例上。

　　

　　在以上的SBC HA處理流程中，通過獲取共享數(shù)據(jù)庫的狀態(tài)數(shù)據(jù)，信令服務器出現(xiàn)故障以后，媒體功能或者編碼轉換功能仍然會繼續(xù)執(zhí)行。Active/Active部署方式及時實現(xiàn)故障服務器出現(xiàn)問題以后，通過共享數(shù)據(jù)庫狀態(tài)消息，重新發(fā)送re-INVITE請求分發(fā)請求到另外兩臺SBC worker（IP-B和IP-C的藍色指示部分）。

　　SBC的高可靠性部署環(huán)境中，通過active/standby也可以輕松實現(xiàn)其高可靠性處理方式。

　　

　　在以上的處理機制中，其中一個SBC worker 設置為standby模式，如果一個active SBC 出現(xiàn)故障以后，例如IP-A出現(xiàn)故障，standby就會通過其IP接管其媒體地址，保證其媒體流程繼續(xù)進行處理。standby模式不經(jīng)過re-INVITE處理，直接通過媒體地址進行媒體通信。

　　通過章節(jié)的以上介紹，讀者可以看到，云原生需要一套完整的自動部署框架來實現(xiàn)云原生的這些要求。Ribbon提出了以下這套完整的技術框架（RAF）來幫助運營商級用戶和企業(yè)用戶實現(xiàn)云原生SBC部署的流程。

　

　　雖然很多SBC廠家也提出了關于云原生SBC的技術框架。但是一些廠家的SBC產品還不能實現(xiàn)真正的云原生技術架構和部署要求。因為其架構的原因，很多性能指標可能受到了一定的限制。例如，Ribbon 云原生的SBC SWe Lite在SILK轉碼上，其成本比友商的低40%， 性能是友商的兩倍左右。在SBC HA處理上，很多廠家的SBC仍然只能使用的active/standby模式，因為沒有共享狀態(tài)數(shù)據(jù)的數(shù)據(jù)庫模式，部署模式仍然是傳統(tǒng)的active/standby，不是真正的云原生容器工作機制，不能實現(xiàn)自動彈性收縮，這樣也會導致系統(tǒng)很多資源浪費。

　　

　　在當前的云平臺環(huán)境中，隨著技術的不斷更新，SIP網(wǎng)絡技術的架構也必然發(fā)生很大的變化，這是一個SIP技術和業(yè)務要求轉型時期。雖然目前仍然存在硬件部署方式，虛擬化方式和云平臺部署方式，但是，未來很多的應用將需要通過云原生技術架構來實現(xiàn)和管理。在SBC的選型上，用戶也一定要考慮云部署的HA處理方式支持，可伸縮的彈性計算功能，部署管理測試等方面的問題。Ribbon SBC在基于云原生技術架構的實現(xiàn)方面已經(jīng)走在了同行業(yè)的前面，完全具備了云原生技術的要求。

　　云原生技術是當前互聯(lián)網(wǎng)云計算中比較熱門的主流技術架構，我們的客戶也會隨著技術的變化跟進這種策略。它本身符合了現(xiàn)代云技術發(fā)展的潮流。SBC作為SIP網(wǎng)絡核心控件，承擔著NAT透傳功能，呼叫均衡負載功能和兼容性測試等問題�；�于云原生SBC的技術通過不斷優(yōu)化，利用云計算各種技術實現(xiàn)了基于云原生SBC的解決方案，這種新的技術徹底實現(xiàn)了SIP網(wǎng)絡的HA高可靠性部署，同時滿足了大規(guī)模集群的配置支持。

　　在本文章中，筆者首先介紹了關于云原生技術的背景和特點，通過SBC技術架構分解，滿足了云原生SBC要求，實現(xiàn)了資源彈性擴展，資源伸縮調整等非常高級的功能。另外，一些廠家雖然也在逐步部署云原生技術，但是其底層架構因為不能共享數(shù)據(jù)庫狀態(tài)信息，它們仍然不是真正的云原生技術，因此，其性能和管理方式也存在一定的局限性。筆者希望通過市場上領先的Ribbon SBC 云原生技術的實現(xiàn)方式，和讀者分享真正的云原生技術是如何滿足云原生技術架構要求，并且?guī)椭�用戶能夠實現(xiàn)專業(yè)的SIP/SBC解決方案。