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

　　筆者將針對(duì)SIP網(wǎng)絡(luò)技術(shù)中會(huì)話邊界控制器在云原生技術(shù)架構(gòu)中的實(shí)現(xiàn)進(jìn)行討論分享，筆者讀者進(jìn)一步了解如何在云原生技術(shù)架構(gòu)的基礎(chǔ)上實(shí)現(xiàn)SBC 高可靠性實(shí)現(xiàn)方式，自動(dòng)測(cè)試，軟件版本升級(jí)和灰度測(cè)試環(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支持方式，資源自動(dòng)伸縮，版本管理灰度測(cè)試的結(jié)果方面的問題進(jìn)行討論。

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

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

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

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

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

　

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

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

　　

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

　　

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

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

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

　　

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

　　

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

　

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

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

　

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

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

　　

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

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

　　

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

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

　

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

　　

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

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

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