微服務(wù)架構(gòu)在客服系統(tǒng)中的應(yīng)用

摘要：
隨著5G、物聯(lián)網(wǎng)以及云計算等技術(shù)的迅猛發(fā)展，以及中國電信自身業(yè)務(wù)的快速發(fā)展，對客服系統(tǒng)的交付與迭代速度和效率有了明確要求，必須為業(yè)務(wù)創(chuàng)新和業(yè)務(wù)持續(xù)提供一個良好的基礎(chǔ)平臺。微服務(wù)架構(gòu)憑借其簡單清晰、靈活可擴(kuò)展、獨(dú)立部署等優(yōu)勢，越來越成為分布式架構(gòu)中的主流，成為傳統(tǒng)客服系統(tǒng)重構(gòu)的優(yōu)先項(xiàng)。微服務(wù)架構(gòu)通過服務(wù)的小型化、原子化以及分布式架構(gòu)的彈性伸縮和高可用性，可以實(shí)現(xiàn)業(yè)務(wù)之間的松耦合、業(yè)務(wù)的靈活調(diào)整組合以及系統(tǒng)的高可用性。
一、客服系統(tǒng)現(xiàn)狀分析
1、傳統(tǒng)客服系統(tǒng)的問題
存在“煙囪式系統(tǒng)建設(shè)模式”，即每個系統(tǒng)單獨(dú)建設(shè),包括IVR系統(tǒng)、坐席門戶系統(tǒng)、工單系統(tǒng)、運(yùn)營管理系統(tǒng)，每個系統(tǒng)之間架構(gòu)完全獨(dú)立，獨(dú)立開發(fā)和運(yùn)維，其實(shí)系統(tǒng)之間都是有公共和通用功能的。對于煙囪式建設(shè)有三大弊端:每次新業(yè)務(wù)都需要重新造輪子，在功能建設(shè)和維護(hù)過程中帶來投資浪費(fèi);打通煙囪式”系統(tǒng)間信息孤島的成本高昂;不利于業(yè)務(wù)的創(chuàng)新、經(jīng)驗(yàn)沉淀和業(yè)務(wù)持續(xù)發(fā)展。
2、客服系統(tǒng)單體化架構(gòu)
傳統(tǒng)客服坐席門戶系統(tǒng)存在單體化架構(gòu)，不利于企業(yè)的業(yè)務(wù)快速發(fā)展。存在如下弊端:不靈活，無法使用Spring Cloud等多種技術(shù)構(gòu)建一體化應(yīng)用;不可靠，例如客服系統(tǒng)CRM接口出現(xiàn)問題，也會造成整個系統(tǒng)不工作;不可擴(kuò)展，應(yīng)用無法輕易地被擴(kuò)展，例如能力平臺中計費(fèi)的欠費(fèi)能力發(fā)生變動時，都必須重新構(gòu)建整個客服系統(tǒng);阻塞持續(xù)集成，客服應(yīng)用中的很多功能如計費(fèi)專區(qū)、增值專區(qū)、寬帶專區(qū)無法同時被構(gòu)建和部署;迭代速度慢，客服門戶系統(tǒng)- -個EAR包，代碼需要很長時間來構(gòu)建，例如智慧診斷、客戶全視圖、各專區(qū)等模塊都無法并行構(gòu)建，因此系統(tǒng)中任何程序的改變，都需要對整個系統(tǒng)進(jìn)行重新編譯部署，升級后需要大量人員留守測試驗(yàn)證，發(fā)現(xiàn)問題時需要反復(fù)部署測試驗(yàn)證，系統(tǒng)的水
平擴(kuò)展也只能基于整個系統(tǒng)進(jìn)行，無法針對某一個功能模塊按需擴(kuò)展。
3、傳統(tǒng)客服系統(tǒng)設(shè)計缺陷
傳統(tǒng)客服系統(tǒng)設(shè)計存在缺陷或者使用的框架本身存在一些不足 ，出現(xiàn)故障時不能快速地定位問題，甚至很長時間無法分析出問題原因,在沒有分析到問題原因的情況下，只能規(guī)避問題的重現(xiàn)。針對上述系統(tǒng)之間存在的信息孤島、單體化架構(gòu)、 故障點(diǎn)多、新業(yè)務(wù) 需求滿足慢等問題，亟需對傳統(tǒng)客服系統(tǒng)進(jìn)行微服務(wù)架構(gòu)重構(gòu)。
二、客服系統(tǒng)重構(gòu)設(shè)計方案
鑒于以上的問題，客服系統(tǒng)重構(gòu)解決方案按領(lǐng)域驅(qū)動設(shè)計(Domain-Driven Design,DDD)方法進(jìn)行設(shè)計，DDD是一套 綜合軟件系統(tǒng)分析和設(shè)計的面向?qū)ο蟮慕�模方法，該方法要求接觸到需求的第一步 就是考慮客服系統(tǒng)的領(lǐng)域模型，而不是將其切割成數(shù)據(jù)和行為，然后數(shù)據(jù)用數(shù)據(jù)庫實(shí)現(xiàn)，行為用服務(wù)實(shí)現(xiàn)，最后造成需求的首肢分離。DDD首先考慮的是客服的業(yè)務(wù)語言，而不是數(shù)據(jù)，從客服的業(yè)務(wù)流程開始分析，形成業(yè)務(wù)架構(gòu)。
1、客服業(yè)務(wù)流程分析
客戶服務(wù)的頂層業(yè)務(wù)流程主要分為主動服務(wù)業(yè)務(wù)流程、被動服務(wù)業(yè)務(wù)流程兩類。其中被動服務(wù)主要是客戶發(fā)起的投訴、故障申告、咨詢、業(yè)務(wù)處理、查詢等流程，客服代表是被動服務(wù);其中主動服務(wù)由客服代表發(fā)起，通過回訪、客戶關(guān)懷、維系挽留、營銷、通知繳費(fèi)等主動服務(wù)流程。客戶服務(wù)頂層流程如圖所示。 2、客戶服務(wù)中被動服務(wù)典型流程分析
對客戶服務(wù)中的被動服務(wù)流程，選取客戶支撐的流程進(jìn)行說明，如圖所示。 (1)智能預(yù)檢處理
客戶通過服務(wù)請求單進(jìn)入系統(tǒng)，首先進(jìn)行智能預(yù)檢處理,能在線處理的就在線處理并將工單辦結(jié)，不能在線處理的則受理一張銷單工單。
(2)全流程檢測
如不能在線處理，則對受理工單進(jìn)行端到端全流程檢測，根據(jù)工單智能處理的檢測結(jié)果，如不是線路問題，生成故障單，派往工單處理。
客服支撐部門聯(lián)系用戶，如能在線處理好的工單則直接辦結(jié)，收集客戶的反饋與歸檔;如不能在線處理則將工單派發(fā)到裝維部門進(jìn)一步處理。
(3)上門處理
如是線路問題,派往裝維部門;裝維部門通過接單、轉(zhuǎn)派及聯(lián)系用戶進(jìn)行上門處理，處理完以后進(jìn)行回訪，收集客戶的反饋并歸檔。
3、客服系統(tǒng)主動服務(wù)營銷流程分析
主動服務(wù)選取營銷流程進(jìn)行分析，如圖所示。 (1)客戶服務(wù)中心可通過10000號語音、短信、微信渠道主動對目標(biāo)客戶進(jìn)行節(jié)假日關(guān)懷、回訪、營銷、維系挽留、催繳等業(yè)務(wù)。
(2)渠道人員先將目標(biāo)用戶導(dǎo)入到門戶系統(tǒng)，再進(jìn)行精準(zhǔn)外呼,對有意向的用戶受理商機(jī)工單。
(3)受理商機(jī)工單后，在內(nèi)部進(jìn)行工單流轉(zhuǎn)及商機(jī)處理。訂單受理成功后，安排裝維人員上門服務(wù)，安裝完成后，進(jìn)行回訪，收集客戶的反饋并歸檔。
4、運(yùn)營流程分析
運(yùn)營流程包含錄音質(zhì)檢、工單質(zhì)檢、運(yùn)營監(jiān)控、培訓(xùn)、考試、排班等，只對重點(diǎn)運(yùn)營業(yè)務(wù)流程進(jìn)行說明，其他流程不進(jìn)行一一闡述，錄音質(zhì)檢包含實(shí)時質(zhì)檢和事后質(zhì)檢。
(1)實(shí)時質(zhì)檢:后臺支撐人員通過旁聽、內(nèi)部求助等功能實(shí)時支撐前臺話務(wù)代表通話過程中的疑難問題。
(2)事后質(zhì)檢:制定質(zhì)檢計劃，有計劃地對中心客戶錄音進(jìn)行質(zhì)檢，并通過質(zhì)檢報告分析中心話務(wù)服務(wù)質(zhì)量;與智能語音引擎對接實(shí)現(xiàn)全中心錄音準(zhǔn)實(shí)時轉(zhuǎn)寫，進(jìn)-步對客戶意圖進(jìn)行分析、挖掘，提升中心業(yè)務(wù)服務(wù)水平。
工單質(zhì)檢流程:
對工單處理及時率、工單回復(fù)及時率、工單內(nèi)容填寫規(guī)范性等內(nèi)容進(jìn)行質(zhì)檢。
工單監(jiān)控流程:
(1 )提供現(xiàn)場監(jiān)控、坐席監(jiān)控、技能隊列監(jiān)控等話務(wù)實(shí)時監(jiān)控功能，使后臺支撐能快速掌握中心話務(wù)情況;
(2)提供接口調(diào)用監(jiān)控、工單監(jiān)控、熱點(diǎn)話務(wù)監(jiān)控等監(jiān)控功能，實(shí)時監(jiān)控中心熱點(diǎn)事件以及周邊系統(tǒng)調(diào)用情況。
培訓(xùn)考試流程:
(1 )提供員工在線培訓(xùn)功能，完成員工技能賦能，通常與考試功能配合使用，完成學(xué)習(xí)與技能檢驗(yàn)的閉環(huán);
(2)提供員工在線考試功能，并提供報表支撐。
排班流程:
通過運(yùn)用科學(xué)合理的預(yù)測算法，結(jié)合呼叫中心現(xiàn)有運(yùn)營的特征，精準(zhǔn)地進(jìn)行話務(wù)預(yù)測后實(shí)現(xiàn)自動排班，從而達(dá)到“在準(zhǔn)確的時間，將有準(zhǔn)確技
能的人，安排到準(zhǔn)確的坐席上，上準(zhǔn)確的班次， 同時達(dá)到合理的接通率"的目的。
3.2吝服系統(tǒng)業(yè)務(wù)架構(gòu)
通過.上述業(yè)務(wù)流程分析，客戶服務(wù)中心根據(jù)不同的業(yè)務(wù)拆分為:話務(wù)服務(wù)中心、運(yùn)營服務(wù)中心、工單服務(wù)中心、公共服務(wù)中心4個客戶服務(wù)能
力中心。 3.3客服系統(tǒng)應(yīng)用架構(gòu)
根據(jù)上述業(yè)務(wù)架構(gòu)的結(jié)論，客服應(yīng)用架構(gòu)以統(tǒng)一應(yīng)用服務(wù)平臺(SaaS) 、統(tǒng)一平臺服務(wù)(PaaS) 、統(tǒng)-基礎(chǔ)服務(wù)(IaaS) 、統(tǒng)-接口平臺進(jìn)行構(gòu)建。應(yīng)用服務(wù)平臺(SaaS) 為多媒體智能客服應(yīng)用系統(tǒng)的坐席門戶前臺、IVR、 天翼客服、QQ客服、短廳、微博、微信客服等互聯(lián)網(wǎng)客服提供統(tǒng)-服務(wù)。 應(yīng)用服務(wù)平臺按業(yè)務(wù)模塊進(jìn)行劃分，各模塊之間進(jìn)行松耦合,為客服系統(tǒng)提供業(yè)務(wù)服務(wù),分別為話務(wù)服務(wù)中心、工單服務(wù)中心、運(yùn)營服務(wù)中心、公共服務(wù)中心提供共享服務(wù)。統(tǒng)-平臺服務(wù)為整個客服系統(tǒng)提供公共的組件管理，方便系統(tǒng)擴(kuò)展。統(tǒng)-基礎(chǔ)服務(wù)為平臺服務(wù)和應(yīng)用服務(wù)提供公共的基礎(chǔ)服務(wù)，例如引入集團(tuán)提供的分布式緩存(Redis)、 分布式消 息隊列、分布式數(shù)據(jù)庫等基礎(chǔ)服務(wù)。 3.4客服系統(tǒng)數(shù)據(jù)架構(gòu)
10000號業(yè)務(wù)模型的實(shí)體主要包括5個部分:客戶、客戶接觸、交互事件、任務(wù)及工單。
(1)客戶:客戶是有能力成為電信產(chǎn)品的所有者、支付者，或者電信產(chǎn)品的使用者的個人或組織。現(xiàn)階段中國電信的客戶是指以產(chǎn)權(quán)關(guān)系界定
的、在同一登記證件名下的中國電信產(chǎn)品的所有者(人或組織)，是中國電信營銷工作的對象和基本單元。
(2)客戶接觸:客戶與中國電信產(chǎn)生的一次業(yè)務(wù)處理過程，都會產(chǎn)生一次或多次交互記錄，一次客戶交互可能產(chǎn)生一次或多次服務(wù)受理或業(yè)務(wù)辦理，當(dāng)中國電信向客戶發(fā)起主動服務(wù)時也會產(chǎn)生一次或多次交互記錄。
(3)交互事件:交互事件是指中國電信客戶向中國電信所發(fā)起的咨詢、查詢、故障申告、投訴建議、業(yè)務(wù)申請等服務(wù)要求或中國電信主動向客戶發(fā)起的客戶挽留、客戶關(guān)懷等主動服務(wù)。
(4)任務(wù)(內(nèi)部發(fā)起) :任務(wù)是處理回訪、客戶關(guān)懷、營銷計劃時產(chǎn)生的需要分派給相關(guān)人員處理的工作事務(wù)。-個營銷計劃可以分解成多項(xiàng)任務(wù)派發(fā)給相關(guān)的人員。
(5)工單(客戶發(fā)起) :工單是指客戶代表不能對客戶提出的問題直接答復(fù)，而進(jìn)行留單，也就是為了完成某個交互事件或任務(wù)而派發(fā)的工作協(xié)同單。 客服系統(tǒng)主要實(shí)體描述
(1)客戶客戶接觸:一對多關(guān)系。
(2)客戶接觸客戶交互事件:多對多關(guān)系。
(3)客戶交互事件-事件類型:一個客戶交互事件對應(yīng)一個事件類型，一個事件類型對應(yīng)一個到多個客戶交互事件。
(4)工單客戶交互事件:多對多關(guān)系。
(5)工單-工單類型:根據(jù)具體業(yè)務(wù)需求，派生出催辦類工單、督辦類工單、管理類工單、施工類工單、資源分配類工單、寫作類工單等。
(6)任務(wù)-主動服務(wù):多對多關(guān)系。
(7)任務(wù)根據(jù)人物，派生出客戶關(guān)懷、客戶回訪、話費(fèi)催繳、客戶挽留、客戶調(diào)查等任務(wù)單。
3.5客服系統(tǒng)技術(shù)架構(gòu)
客服系統(tǒng)重構(gòu)，技術(shù)架構(gòu)采用Spring Cloud體系的微服務(wù)架構(gòu)，Spring Cloud基于Spring Boot,為解決微服務(wù)體系開發(fā)中的架構(gòu)問題，提供了一整套解決方案，專注微服務(wù)架構(gòu)生態(tài)，通信協(xié)議采用Restful HTTP ,通過Spring Cloud分布式架構(gòu)服務(wù)建設(shè)客戶服務(wù)能力中心，對外提供客服的服務(wù)能力，輸出智慧診斷、賬務(wù)專區(qū)、流量專區(qū)服務(wù)、寬帶專區(qū)服務(wù)、iTV專區(qū)服務(wù)、預(yù)判展示服務(wù)、投訴保障服務(wù)、業(yè)務(wù)查詢服務(wù)、客服智能機(jī)器人等能力。 本次重構(gòu)采用中國電信集團(tuán)提供的IaaS服務(wù),緩存采用中國電信集團(tuán)統(tǒng)一提供的分布式緩存服務(wù)，分布式消息中間件采用中國電信集團(tuán)統(tǒng)提供的ROCKETMQ服務(wù)，數(shù)據(jù)庫采用中國電信集團(tuán)統(tǒng)-提供的My SQL分布式數(shù)據(jù)庫服務(wù)。
通過Spring Cloud微服務(wù)體系提供PASS服務(wù)，即服務(wù)注冊中心、配置管理中心、服務(wù)監(jiān)控中心、服務(wù)跟蹤分析、服務(wù)網(wǎng)關(guān)、服務(wù)保障中心等平臺服務(wù)。
通過對不同的業(yè)務(wù)梳理形成不同的客戶服務(wù)能力，如業(yè)務(wù)查詢能力、流量專區(qū)服務(wù)、-鍵診斷等應(yīng)用服務(wù)能力，通過這些共享服務(wù)，完成話務(wù)服務(wù)中心、工單服務(wù)中心、運(yùn)營管理中心、公共服務(wù)中心的構(gòu)建。
4客服接口管理微服務(wù)化過程
在客服人員服務(wù)客戶的過程中，需要把企業(yè)中所有IT系統(tǒng)牽涉到該客戶的信息匯聚到客服系統(tǒng)中，方便客服人員全面了解客戶信息，所以在客服系統(tǒng)中對其他系統(tǒng)接口的管理非常重要。通過接口管理微服務(wù)化這個實(shí)例來闡述微服務(wù)架構(gòu)重構(gòu)過程。
4.1接口管理前端(前端SaaS)
接口管理前臺界面功能包括查詢、修改等服務(wù)。 4.2接口服務(wù)(PaaS)
通過對接口管理服務(wù)進(jìn)行封裝，再通過Service層實(shí)現(xiàn)該服務(wù)，為前臺界面服務(wù)。
4.3服務(wù)治理
在接口服務(wù)的Spring Boot工程的啟動application類上加上注解@EnableEurekaServer,同時配置好配置文件，該接口服務(wù)啟動后會自動注冊到Spring Cloud的套件注冊中心Erureka Server中。
4.4數(shù)據(jù)服務(wù)
通過封裝數(shù)據(jù)訪問接口服務(wù)訪問集團(tuán)分布式數(shù)據(jù)庫，為借口服務(wù)提供數(shù)據(jù)服務(wù)。接口管理的微服務(wù)過程整體如下:通過數(shù)據(jù)服務(wù)訪問分布式數(shù)據(jù)庫，該數(shù)據(jù)服務(wù)作為數(shù)據(jù)微服務(wù)單獨(dú)部署;接口服務(wù)通過訪問數(shù)據(jù)服務(wù)來服務(wù)前臺界面，該接口服務(wù)作為一個服務(wù)單獨(dú)部署;服務(wù)治理通過Spring Cloud提供的服務(wù)注冊中心、配置管理中心、服務(wù)監(jiān)控中心、服務(wù)跟蹤分析、服務(wù)網(wǎng)關(guān)、服務(wù)保障中心來實(shí)現(xiàn)。前臺界面調(diào)用接口微服務(wù)完成接口管理。
總結(jié)：
通過按領(lǐng)域驅(qū)動設(shè)計方法的重構(gòu),把客戶服務(wù)中心分為話務(wù)服務(wù)中心、工單服務(wù)中心、運(yùn)營服務(wù)中心以及公共服務(wù),打造了客服系統(tǒng)的共享服務(wù)體系,性能顯著提升，方便業(yè)務(wù)創(chuàng)新，能快速適應(yīng)業(yè)務(wù)需求，解決信息孤島，為企業(yè)的數(shù)據(jù)中臺發(fā)揮大數(shù)據(jù)威力提供客服的數(shù)據(jù)儲備。本次重構(gòu)雖帶來很多好處，但因業(yè)務(wù)的微服務(wù)化，造成平臺出現(xiàn)錯誤時很難定位問題，在實(shí)施階段企業(yè)為業(yè)務(wù)中臺統(tǒng)-打造了數(shù)字化運(yùn)營能力來解決該問題，該解決方案已經(jīng)上線，可以解決微服務(wù)定位難的問題。