陳軍

摘要：電信客戶關(guān)系管理（CRM）系統(tǒng)作為電信核心業(yè)務(wù)支撐系統(tǒng)，支撐電信日常的生產(chǎn)服務(wù)。傳統(tǒng)CRM系統(tǒng)采用典型的“IOE”架構(gòu)，系統(tǒng)的耦合度很高，當(dāng)業(yè)務(wù)增長(zhǎng)時(shí)，由于IOE架構(gòu)的擴(kuò)展性不足，導(dǎo)致數(shù)據(jù)庫(kù)壓力大、系統(tǒng)運(yùn)行性能不足。為解決系統(tǒng)性能問題，同時(shí)提升業(yè)務(wù)支撐效率，滿足業(yè)務(wù)增長(zhǎng)需求，構(gòu)建一套分布式CRM系統(tǒng)勢(shì)在必行。本文通過介紹構(gòu)建分布式CRM系統(tǒng)需要重點(diǎn)解決的關(guān)鍵點(diǎn)，提供系統(tǒng)的建設(shè)思路。

關(guān)鍵詞：CRM系統(tǒng);分布式架構(gòu);共享服務(wù);數(shù)據(jù)拆分;分布式事務(wù)

1 集中式架構(gòu)下電信CRM系統(tǒng)存在的問題及演進(jìn)目標(biāo)

電信客戶關(guān)系管理（CRM）系統(tǒng)作為電信核心業(yè)務(wù)支撐系統(tǒng)，支撐電信日常的生產(chǎn)服務(wù)，支持全客戶管理、全業(yè)務(wù)受理、全產(chǎn)品營(yíng)銷、全渠道協(xié)同以及全過程銷售。系統(tǒng)有主要幾個(gè)特點(diǎn)：高并發(fā)、大數(shù)據(jù)量、以聯(lián)機(jī)事務(wù)處理為主的交易型業(yè)務(wù)系統(tǒng)、業(yè)務(wù)復(fù)雜、模型復(fù)雜、外圍渠道接口繁多。系統(tǒng)傳統(tǒng)實(shí)現(xiàn)方案是采用典型的“IOE”架構(gòu)，即小型機(jī)+Oracle+EMC，系統(tǒng)的耦合度很高。傳統(tǒng)架構(gòu)下的CRM系統(tǒng)面臨的主要問題：數(shù)據(jù)庫(kù)壓力大、系統(tǒng)運(yùn)行性能不足，但是IOE架構(gòu)下的小型機(jī)的CPU、內(nèi)存已經(jīng)滿配置，橫向擴(kuò)展困難，同時(shí)因?yàn)橄到y(tǒng)耦合度很高，造成無(wú)法快速支撐業(yè)務(wù)需求。

電信IT架構(gòu)演進(jìn)目標(biāo)是能夠解決目前的問題并滿足未來(lái)業(yè)務(wù)發(fā)展的支撐要求，因此建設(shè)一套采用基于分布式架構(gòu)的CRM系統(tǒng)勢(shì)在并行。分布式CRM系統(tǒng)建設(shè)的整體目標(biāo)是按照“平臺(tái)+應(yīng)用”、基于IT云服務(wù)平臺(tái)、應(yīng)用分中心的互聯(lián)網(wǎng)分布式架構(gòu)來(lái)改造CRM應(yīng)用。系統(tǒng)需要采用平臺(tái)+應(yīng)用模式建設(shè)，PaaS核心能力包括分布式數(shù)據(jù)庫(kù)、分布式緩存和分布式消息等核心能力組件;遵循功能內(nèi)聚的原則，應(yīng)用功能由原來(lái)的大融合劃分成多個(gè)業(yè)務(wù)中心，沉淀基礎(chǔ)能力;CRM數(shù)據(jù)散列存儲(chǔ)，數(shù)據(jù)按照業(yè)務(wù)對(duì)象聚合劃分邏輯中心，不同中心數(shù)據(jù)邏輯隔離，不允許關(guān)聯(lián)訪問，具備動(dòng)態(tài)擴(kuò)縮容的能力。

2 如何構(gòu)建分布式CRM 系統(tǒng)

構(gòu)建分布式CRM系統(tǒng)需要把握五個(gè)關(guān)鍵點(diǎn)，即構(gòu)建共享服務(wù)、數(shù)據(jù)拆分、異步化和緩存實(shí)現(xiàn)、分布式事務(wù)、分布式架構(gòu)運(yùn)維工具。

2.1構(gòu)建共享服務(wù)

系統(tǒng)需要按業(yè)務(wù)類型拆分功能應(yīng)用，形成一個(gè)個(gè)能力中心，比如客戶中心、受理中心、配置中心等，每個(gè)中心面向企業(yè)提供業(yè)務(wù)運(yùn)營(yíng)及支撐，可對(duì)外提供標(biāo)準(zhǔn)化服務(wù)且相對(duì)獨(dú)立的一組服務(wù)的載體。中心能力具備高內(nèi)聚的特性，且中心間低耦合，通過各中心的協(xié)同形成一個(gè)完整的業(yè)務(wù)流程。它有四個(gè)原則：第一、功能內(nèi)聚，中心的功能必須是緊密相關(guān)的，中心服務(wù)所提供的業(yè)務(wù)處理邏輯可以在中心內(nèi)部閉環(huán);第二，應(yīng)用解耦，中心之間的引用與交互通過服務(wù)調(diào)用或者通知消息的方式實(shí)現(xiàn);第三，部署獨(dú)立，每個(gè)中心必須是可以獨(dú)立部署和運(yùn)行;中心的代碼是獨(dú)立的版本且可以獨(dú)立升級(jí);第四，服務(wù)復(fù)用，中心提供對(duì)外部使用服務(wù)，要求被高度復(fù)用，不容許相同能力的服務(wù)在不同的中心中都有實(shí)現(xiàn)。

2.2數(shù)據(jù)拆分

主要考慮三方面原則，1）聚集性：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)里的聚集，把關(guān)系緊密的表放在一起，可在一定程度上規(guī)避跨分片JOIN、分布式事務(wù)，頻繁調(diào)用分片索引。2）擴(kuò)展性：具備良好的擴(kuò)展性，增加分片節(jié)點(diǎn)時(shí)，避免數(shù)據(jù)遷移，且已經(jīng)達(dá)到存儲(chǔ)上限的節(jié)點(diǎn)不再寫入數(shù)據(jù)。3）均衡性，能均勻分布數(shù)據(jù)讀寫，避免“熱點(diǎn)”問題。在數(shù)據(jù)架構(gòu)設(shè)計(jì)時(shí)，可以按照三層來(lái)做數(shù)據(jù)分片：第一層，按時(shí)間分為生產(chǎn)在用表 + 歷史數(shù)據(jù)庫(kù);第二層：按功能子域分為客戶資料中心、訂單中心、營(yíng)銷資源中心、配置中心。第三層：按ID散列，對(duì)于客戶資料中心、訂單交易中心和營(yíng)銷資源中心這三類實(shí)體，分別根據(jù)客戶ID、訂單ID和營(yíng)銷資源ID散列存儲(chǔ)，而配置數(shù)據(jù)中心作為公共數(shù)據(jù)，全部分片冗余存儲(chǔ)?；谝陨显瓌t，像訂單模型分為在用表和歷史表，在用表按照訂單ID來(lái)分片，訂單相關(guān)數(shù)據(jù)散列到同一個(gè)分片中，訂單ID是唯一主鍵，節(jié)點(diǎn)擴(kuò)展時(shí)，可以避免大量數(shù)據(jù)遷移，數(shù)據(jù)可以均衡的散列到各個(gè)分片中。

2.3異步化和緩存實(shí)現(xiàn)

在分布式系統(tǒng)云化部署、數(shù)據(jù)散列存儲(chǔ)的情況下，通過處理異步化，實(shí)現(xiàn)緩存化，達(dá)到降低耦合，提升性能的效果。比如通過把一個(gè)訂單提交環(huán)節(jié)進(jìn)行拆解成多個(gè)子環(huán)節(jié)，實(shí)現(xiàn)每個(gè)環(huán)節(jié)之間異步化處理來(lái)提升訂單提交性能。同時(shí)在分布式系統(tǒng)中，緩存需要得到普遍使用，比如分布式查詢會(huì)變得復(fù)雜，以根據(jù)號(hào)碼查詢訂單項(xiàng)列表為例，因?yàn)橛唵雾?xiàng)被散列的多個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)，傳統(tǒng)方式下需要一個(gè)個(gè)數(shù)據(jù)庫(kù)查詢結(jié)果再匯總，查詢速度是非常慢的，通過緩存實(shí)現(xiàn)，在緩存中同步建立查詢條件與實(shí)例數(shù)據(jù)的關(guān)聯(lián)關(guān)系，那么查詢的時(shí)候就可以快速定位到要查詢的數(shù)據(jù)庫(kù)范圍，從而大幅提升查詢效率。

2.4分布式事務(wù)

分布式CRM系統(tǒng)比較關(guān)鍵的一個(gè)難點(diǎn)就是分布式事務(wù)的解決，因?yàn)橄裣窨蛻絷P(guān)系管理這樣復(fù)雜的信息管理系統(tǒng)，涉及分布式事務(wù)的場(chǎng)景就比較多，舉一些例子：像訂單的提交、流轉(zhuǎn)、竣工都會(huì)涉及數(shù)據(jù)事務(wù)處理。從事務(wù)完成數(shù)據(jù)時(shí)效要求，需要考慮事務(wù)一致性類型，有些是要要求立即生效，有些是要求快速生效，有些可以有一定的時(shí)延，有些要求對(duì)時(shí)延不敏感。關(guān)注點(diǎn)主要是在前面兩種，我們實(shí)現(xiàn)的時(shí)候主要有兩種實(shí)現(xiàn)方案，第一，將跨數(shù)據(jù)節(jié)點(diǎn)的事務(wù)調(diào)整為單數(shù)據(jù)節(jié)點(diǎn)事務(wù)，在設(shè)計(jì)時(shí)進(jìn)行規(guī)避，比如訂單提交實(shí)現(xiàn)思路：在訂單中心保存過程客戶資料數(shù)據(jù)，規(guī)避為數(shù)據(jù)節(jié)點(diǎn)內(nèi)事務(wù)。訂單竣工實(shí)現(xiàn)思路：通過將訂單竣工服務(wù)，分解為訂單節(jié)點(diǎn)服務(wù)、客戶節(jié)點(diǎn)服務(wù)、產(chǎn)品檔案節(jié)點(diǎn)服務(wù)，進(jìn)行按順序處理，最終達(dá)到整個(gè)訂單竣工的完成，訂單提交的時(shí)候先存過程數(shù)據(jù)，由過程數(shù)據(jù)再進(jìn)行正式訂單一次提交。第二，將分布式事務(wù)分解為具有冪等性子執(zhí)行事務(wù)，最終一致性來(lái)解決，在關(guān)鍵的業(yè)務(wù)環(huán)節(jié)是需要進(jìn)行些特殊判斷，確保相應(yīng)的事務(wù)都完成后才能進(jìn)入下一業(yè)務(wù)處理。第三，通過上面提的異步化實(shí)現(xiàn)，通過消息的補(bǔ)償機(jī)制規(guī)避分布式事務(wù)。

2.5分布式架構(gòu)運(yùn)維配套工具

系統(tǒng)分布式之后，問題定位非常復(fù)雜，需要有一套分布式架構(gòu)下的運(yùn)維工具進(jìn)行問題的快速定位。解決方式是基于日志的實(shí)時(shí)收集、實(shí)時(shí)統(tǒng)計(jì)以及進(jìn)行數(shù)據(jù)展現(xiàn)，通過把所有日志進(jìn)行計(jì)算、排序進(jìn)行一個(gè)調(diào)用鏈，實(shí)現(xiàn)分布式系統(tǒng)下的問題快速定位。

3 構(gòu)建分布式CRM系統(tǒng)的演進(jìn)方式

以某電信運(yùn)營(yíng)商的CRM系統(tǒng)升級(jí)方式來(lái)說(shuō)明，整體采用分階段方式，循序漸進(jìn)開展實(shí)施改造。首先，提前進(jìn)行技術(shù)儲(chǔ)備和技術(shù)驗(yàn)證，由于分布式系統(tǒng)無(wú)論從系統(tǒng)架構(gòu)還是從系統(tǒng)運(yùn)維都有大幅技術(shù)提升要求，提前進(jìn)行技術(shù)儲(chǔ)備是非常關(guān)鍵，可以從組織架構(gòu)上、項(xiàng)目培訓(xùn)上進(jìn)行調(diào)整。組織架構(gòu)上可以增加定義系統(tǒng)架構(gòu)師和業(yè)務(wù)架構(gòu)師角色，系統(tǒng)架構(gòu)師牽頭研究和落地已有的分布式系統(tǒng)建設(shè)經(jīng)驗(yàn)，業(yè)務(wù)架構(gòu)師規(guī)范分布式系統(tǒng)下的操作規(guī)范;項(xiàng)目培訓(xùn)上可以組織參與國(guó)內(nèi)外一些技術(shù)峰會(huì)，或請(qǐng)互聯(lián)網(wǎng)技術(shù)專家現(xiàn)場(chǎng)培訓(xùn)和指導(dǎo)，目的是更快地讓團(tuán)隊(duì)轉(zhuǎn)變思路。技術(shù)驗(yàn)證遵循循序漸進(jìn)方式，可以先通過數(shù)據(jù)雙寫-數(shù)據(jù)讀取-數(shù)據(jù)讀寫，充分驗(yàn)證下分布式架構(gòu)下的數(shù)據(jù)準(zhǔn)確性、可靠性等。其次，采用模塊試點(diǎn)方式，可以先從周邊非核心模塊開始，驗(yàn)證分布式系統(tǒng)整體運(yùn)行穩(wěn)定性，然后逐步進(jìn)行模塊的升級(jí)，最后再全面上線，特別是核心模塊的改造，需要有分布式技術(shù)架構(gòu)和分布式系統(tǒng)運(yùn)維作為保障。

4 結(jié)語(yǔ)

本文以構(gòu)建分布式CRM系統(tǒng)的五個(gè)關(guān)鍵點(diǎn)來(lái)展開說(shuō)明，實(shí)際上構(gòu)建一套分布式系統(tǒng)是一個(gè)非常大的工程，特別對(duì)交易類的核心系統(tǒng)，需要理論聯(lián)系實(shí)際，建議采用分階段循序漸進(jìn)的方式來(lái)推進(jìn)實(shí)施。

參考文獻(xiàn)

[1]李智慧.大型網(wǎng)站技術(shù)架構(gòu)[M].電子工業(yè)出版社，2013

[2]鐘華.企業(yè)IT架構(gòu)轉(zhuǎn)型之道[M].機(jī)械工業(yè)出版社，2017