微服務架構在客服系統中的應用

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