劉沛強
(1.華為技術有限公司,廣東 廣州 510627;2.廣州夢海信息技術有限公司,廣東 廣州 510665)
近十年來,隨著各種開源項目的蓬勃發(fā)展,IT業(yè)界出現(xiàn)了越來越多成熟可用的開源軟件。而互聯(lián)網(wǎng)廠商,特別是電商井噴式地發(fā)展,普遍要求高可用、高并發(fā)、大容量的系統(tǒng)架構?;ヂ?lián)網(wǎng)廠商與開源項目的結合日益加深,谷歌和亞馬遜等巨頭甚至自研開源軟件以支撐業(yè)務的發(fā)展。一系列互聯(lián)網(wǎng)龍頭企業(yè)的成功,為上述系統(tǒng)架構的推廣提供了最好的范例。與互聯(lián)網(wǎng)企業(yè)不斷進行技術創(chuàng)新和顛覆相反,移動運營商由于轉型較慢,系統(tǒng)架構相對保守,但運營商也存在系統(tǒng)架構更新?lián)Q代的迫切需求。一方面,由于用戶需求從語音、短信逐漸過渡到面向網(wǎng)際互聯(lián)協(xié)議(IP)的長期演進語音承載(Voice over Long-Term Evolution,VoLTE)、規(guī)模化的物聯(lián)網(wǎng)(Internet of Things,IoT)、低時延的車聯(lián)網(wǎng)、VR 等業(yè)務,需要支持網(wǎng)絡切片;另一方面,需要降低運營成本,特別是需要降低服務器成本和日常運維的成本,高昂的成本嚴重影響了運營商的利潤。因此,互聯(lián)網(wǎng)企業(yè)催化成熟的眾多開源軟件,為移動運營商的系統(tǒng)架構提供了很好的范例。
目前中國移動集團公司客戶關系管理(Customer Relationship Management,CRM)采用的是集團公司CRM+省公司CRM 的二級架構[1],各省份的CRM系統(tǒng)獨立進行建設,它們由不同的廠家進行研發(fā),只要滿足與集團公司的接口協(xié)議即可,但各廠家采用的是不同的系統(tǒng)架構。由于運營商對系統(tǒng)架構的高可用和高并發(fā)有極高的要求、對接的子系統(tǒng)繁多、數(shù)據(jù)量龐大而復雜,因此普遍采用相對保守的技術架構,對開源軟件持審慎的態(tài)度。總的來說,目前移動運營商的CRM 架構有以下特點:
單體式服務的優(yōu)點在于編譯、發(fā)布方便,結構簡單清晰,只需要訪問單臺的數(shù)據(jù)庫,因此容易進行網(wǎng)絡規(guī)劃,數(shù)據(jù)備份恢復也相對容易。但模塊之間耦合度很高,擴容比較麻煩,并且數(shù)據(jù)庫訪問壓力較大,因而對系統(tǒng)穩(wěn)定性要求極高,服務器一般采用小型機。分布式服務克服了單體服務的上述缺點,由于關鍵的模塊分開部署,分擔了系統(tǒng)的壓力,服務器可以采用小型機或X86 結構的PC server。
單體服務的系統(tǒng)結構,在存儲方面通常采用集中式的存儲,主要采用Oracle 數(shù)據(jù)庫和易安信(EMC)公司的存儲服務器,以滿足超大規(guī)模的存儲容量和超高的處理速度。同時,采用光纖通道與服務器進行傳輸,以滿足大容量的數(shù)據(jù)交換的要求。也有的省份采用分布式存儲結構,即將不同功能模塊的數(shù)據(jù)分開存儲,以減輕數(shù)據(jù)庫壓力。
CRM 的某些業(yè)務需要進行跨地市交互,例如省內家庭網(wǎng)、異地補卡等業(yè)務。有的省份數(shù)據(jù)量不大,可以使用同一個實例進行處理,能確保在一個事務中進行提交。而有的省份數(shù)據(jù)量非常大,不同的地市的服務和數(shù)據(jù)分布在不同的實例上,需要進行跨區(qū)服務調用進行業(yè)務處理。這種架構一般采用異步方式處理跨地市業(yè)務,因此需要一定的糾錯機制,例如業(yè)務回退或者數(shù)據(jù)一致性稽核,來保證不同地市的數(shù)據(jù)一致性。此外,不同省份的地市之間,只能使用跨區(qū)接口進行業(yè)務交互。
目前集團CRM 與省CRM 之間采用一級BOSS規(guī)范進行交互。集團公司對省公司的主套餐和重點業(yè)務有統(tǒng)一的規(guī)范和要求,集團CRM 通過一級BOSS 協(xié)議對省CRM 進行驗收和常規(guī)考核,如4G/5G 主套餐、WLAN、夢網(wǎng)業(yè)務、家庭寬帶等業(yè)務。
在互聯(lián)網(wǎng)時代,移動運營商除了傳統(tǒng)的營業(yè)廳、電子渠道、網(wǎng)站、移動商城等渠道之外,還需要通過互聯(lián)網(wǎng)廠商進行引流。能力開放平臺[2]為移動運營商提供核心業(yè)務能力輸出,支撐移動運營商與外部合作伙伴進行增值業(yè)務合作,通過提供統(tǒng)一、安全的輸出接口,實現(xiàn)“對外能力開放,對內服務集成”,助力CRM 系統(tǒng)在互聯(lián)網(wǎng)領域進行業(yè)務拓展。
這幾年來,各省份的移動運營商的架構升級持續(xù)進行中:海南移動向“云+平臺+應用”的互聯(lián)網(wǎng)架構轉型[3];山東移動使用華為產品成功完成了CRM 核心系統(tǒng)的軟硬件替換升級,引入面向服務的架構(Service-Oriented Architecture,SOA)、云計算、大數(shù)據(jù)等新架構建設了全新的CRM 系統(tǒng);2020 年12 月,青海移動省級CRM/BOSS 系統(tǒng)華南節(jié)點割接上線……總的來說,移動運營商架構演進體現(xiàn)出以下特點和趨勢。
隨著國內云化建設進程的加快,越來越多的硬件和軟件部署到云端。中國移動正在啟動全球最大規(guī)模的網(wǎng)絡云化變革,并計劃在2025 年達到100&的云化。作為5G 網(wǎng)絡的運營支撐系統(tǒng),CRM 必然深受影響[4]。新一代的CRM 架構,總體思路是云化部署,包括硬件系統(tǒng)的云化和分布式的應用架構[5]。云化有以下3 個優(yōu)勢。
(1)可以根據(jù)業(yè)務發(fā)展需要進行快速、彈性部署[6]。由于對業(yè)務增長難以準確預估,通過云化,可以對資源進行集約化管理,方便快速地進行資源調配,做到即開即用。
(2)管理簡單。CRM 業(yè)務需要維護人員每日巡檢軟硬件設施以保證7×24 小時不間斷服務,這對運營商來說是一筆很大的成本,而使用云服務器可以大幅度降低運維成本。
(3)價格相對低廉。云服務器可以使用X86服務器承載基礎應用,通過云平臺的自動化安裝部署,極大的節(jié)省搭建基礎網(wǎng)絡設施的成本。
移動運營商CRM 系統(tǒng)建設,走了一條各地市分別建設到全省規(guī)劃建設的道路。各省根據(jù)自身業(yè)務發(fā)展的規(guī)律自行獨立建設,開展了許多具有當?shù)靥厣臉I(yè)務。然而,這也導致各省的CRM 系統(tǒng)不僅在系統(tǒng)架構方面設計迥異,而且在業(yè)務規(guī)劃上也千差萬別。這就使得同一個相似的業(yè)務,各省的業(yè)務流程和功能各不相同,甚至在業(yè)務功能上相去甚遠,因此在集團頂層上難以進行統(tǒng)一。這樣,在硬件設施云化的基礎上,CRM 系統(tǒng)進行區(qū)域集中化建設的統(tǒng)一規(guī)劃就成為一個趨勢:地域相近的若干個省份,集中共建一套CRM 系統(tǒng),如圖1 所示。目前有的省份正在進行區(qū)域集中建設。例如,西部某省份在全球第二的業(yè)務支撐系統(tǒng)(Business Support System,BSS)廠商亞信的幫助下,正在開展CRM 集中化項目;吉林移動在國內知名CRM 廠商思特奇的支持下,也于2021 年3 月上線了全網(wǎng)集中化項目。
圖1 CRM 區(qū)域集中化云
區(qū)域集中化建設需要有一個統(tǒng)一的基礎平臺對各省的用戶和業(yè)務進行統(tǒng)一地集中管理。如圖2 所示,系統(tǒng)架構可以采用1 個基礎平臺+N個省份的定制模塊的方式,硬件設施的云化為統(tǒng)一的基礎平臺提供了保證。在此基礎上,允許區(qū)域內各省對服務接口進行定制化,可以優(yōu)先調用定制接口。如果不存在定制,則使用公共的服務。這樣既能最大程度的減少基礎平臺和服務的重復開發(fā)和運維,又能保留各省份業(yè)務的特色。
圖2 一種統(tǒng)一集成平臺的區(qū)域集中化CRM 系統(tǒng)
區(qū)域化統(tǒng)一運營,需要將不同省份的用戶數(shù)據(jù)云化存放,在統(tǒng)一的系統(tǒng)架構下對不同的省份進行數(shù)據(jù)隔離,這就要使用到多租戶模式,將每個省作為一個租戶。多租戶隔離模式主要有以下3 種。
(1)每個租戶獨立創(chuàng)建數(shù)據(jù)庫,這種模式安全性最好,隔離級別也最高。其優(yōu)點是每個租戶都可以使用不同的擴展方案以滿足不同省份的獨特需求,如果系統(tǒng)出現(xiàn)的故障只影響一個省,恢復也相對容易;缺點是采購和維護成本比較高,一旦修改公共部分的數(shù)據(jù)和結構就要把所有數(shù)據(jù)庫都修改 一次。
(2)所有租戶共享數(shù)據(jù)庫,但每個租戶使用不同的schema。它也可以為租戶采用個性化的擴展方案,租戶數(shù)據(jù)也能實現(xiàn)一定程度的隔離。因為會涉及到其他租戶的數(shù)據(jù),所以數(shù)據(jù)恢復比較麻煩。這是一種平衡型的模式。
(3)所有租戶共享數(shù)據(jù)庫,共享 Schema 和數(shù)據(jù)表,僅在每一個表中增加租戶標識以區(qū)分不同省份的數(shù)據(jù)。這是共享程度最高的模式,數(shù)據(jù)并不進行物理隔離,僅在邏輯上區(qū)分。該模式的配置成本最低,每個數(shù)據(jù)庫的租戶數(shù)量最多;缺點是數(shù)據(jù)安全性和隔離性最差,數(shù)據(jù)的備份和恢復最麻煩,每個表都需要針對不同租戶進行不同處理。
上述3 種方案,除了考慮隔離性和成本外,還需要對其他因素進行綜合考慮,例如各租戶數(shù)據(jù)量大小是否合適,如果單個租戶的數(shù)據(jù)量已經(jīng)非常巨大,則傾向于隔離;反之,如果單個租戶數(shù)據(jù)量不大但租戶數(shù)量比較多,則傾向于共享。
隨著用戶量的劇增,移動運營商的CRM 承受的壓力越來越大,傳統(tǒng)的單體式服務已經(jīng)越來越難以滿足高并發(fā)訪問的要求,繼續(xù)橫向擴展也難以為繼。有的省份甚至已經(jīng)考慮從熱點城市、繁忙時段和服務接口等幾個維度對用戶訪問進行“限流”,即按照一定比例隨機性的限制訪問。而微服務架構在誕生之初就攜帶著擴展成本低、高可靠性、高并發(fā)性的基因,因而在互聯(lián)網(wǎng)廠商中早已得到普遍的應用。在CRM 系統(tǒng)中引入微服務架構,不僅能以較小的成本在X86 架構的PC Server 中進行部署,而且便于橫向擴展,對熱點服務部署多套,由負載均衡器對請求進行動態(tài)分配。由于每個服務都存在若干個“無狀態(tài)”的實例,如果個別服務器出現(xiàn)擁塞甚至故障,用戶請求就會被動態(tài)分配到其他服務器,并且對用戶無感知,這樣就兼顧了服務的低成本和高可用性,同時還有利于去IOE(IBM 小型機、Oracle 數(shù)據(jù)庫、EMC 存儲設備)。
在微服務架構中,各服務之間的調用非常繁雜,一旦出現(xiàn)問題就需要根據(jù)服務日志一層一層的定位。解決問題的辦法,是將這個請求經(jīng)過的每一個節(jié)點都記錄下來,形成一個完整的鏈條,這就是服務調用鏈,如圖3 所示。顯然,通過服務調用鏈技術,可以快速定位問題,全盤理解和監(jiān)控整個系統(tǒng)。
圖3 微服務調用鏈
服務調用鏈還可以用來分析用戶行為。在大數(shù)據(jù)時代,用戶數(shù)據(jù)越來越受到重視。與業(yè)務日志只能在用戶結果層面呈現(xiàn)用戶需求不同的是,服務調用鏈技術不僅可以看到用戶提交的操作,還可以從用戶點擊瀏覽器的行為過程為用戶進行精準畫像,以便更加有針對性地對用戶開展營銷活動。
由于容器化部署具有持續(xù)集成部署、跨云平臺支持、環(huán)境標準化、隔離性和安全性等優(yōu)點,目前已經(jīng)得到廣泛的應用。將CRM 程序運行在容器內部,顯著的好處就是互相隔離、互不影響,并且可以快速部署多套鏡像而不需要考慮基礎環(huán)境的差異。這種優(yōu)點顯而易見,由于服務器內可以部署多個容器,每個容器內運行著一套獨立完整的程序,一個容器內的服務出現(xiàn)故障,并不影響其他容器內程序的運行。目前最為廣泛流行的容器是Docker 和CoreOS Rocket,常用的容器編排工具有Kubernetes、Docker Swarm 等。
由于復雜的數(shù)據(jù)關系和龐雜的功能,中國移動各省CRM 架構改造進展緩慢[7]。但是,隨著互聯(lián)網(wǎng)許多先進技術的出現(xiàn),多種成熟的技術正在往傳統(tǒng)的CRM 領域進行滲透,并深刻影響著下一代CRM 系統(tǒng)的發(fā)展。特別是硬件系統(tǒng)云化、多租戶、微服務、服務調用鏈等技術在CRM 系統(tǒng)的應用,不但能顯著降低后者的建設和運營成本,并且能提升后者高并發(fā)、高可靠性和高可用性的能力,助力運營商進行數(shù)字化轉型。
目前,各地的5G 網(wǎng)絡正在大規(guī)模進行建設,移動運營商需要對CRM 系統(tǒng)進行升級改造,提升用戶的使用體驗,占據(jù)更大的市場份額。