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

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

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

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

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

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

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

　

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

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

　　

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

　　

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

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

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

　　

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

　　

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

　

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

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

　

　　在以上升級流程中，如果我們要升級 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版本進(jìn)行升級，完全升級到v2版本。如果發(fā)現(xiàn)v2版本有問題的話，系統(tǒng)會回滾到原來的v1版本，不再對work2 v1 版本進(jìn)行升級。通過Canary升級控制機(jī)制可以完全控制SBC軟件升級的可控性。

　　在云部署場景中，特別是需要大規(guī)模集群部署環(huán)境時，SBC的HA 高可靠性機(jī)制是系統(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）將自動承擔(dān)IP-A的工作量，把它的工作量發(fā)布到另外兩個SBC worker 實例上。

　　

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

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

　　

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

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

　

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

　　

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

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

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