電子渠道標準服務提供平臺的設計與實現

李家健，王海霞

（1.中國電信股份有限公司廣東分公司，廣東 廣州 510180；2.中國電信股份有限公司廣州研究院，廣東 廣州 510630）

1 引言

隨著移動通信和互聯網技術的飛速發展，以及全業務運營和3G大規模的推廣，電信業務種類更加豐富，市場競爭日益加劇。而智能手機、平板電腦等大量新型移動智能終端的出現，使得用戶的通訊行為、消費習慣發生巨變，如微信、易信等社交網絡平臺集聚人氣，O2O、C2B等銷售模式開始普及。

電子渠道已經逐步從過去作為實體渠道的補充，發展成為通信運營商不可或缺的市場營銷渠道和客戶服務渠道。如何借鑒電商行業的經驗來增強業務承載能力，優化客戶體驗，充分發揮電子渠道的優勢，成為電信運營商提升核心競爭力的重要戰略之一。

2 系統總體設計

2.1 現狀分析

中國電信廣東分公司的電子渠道現狀是整體結構較零散，前重后輕、相互獨立，既無法快速響應業務需求，也無法滿足協同運營的要求，快速拓展電渠服務及銷售觸點。其存在的主要問題如下：

（1）業務耦合性越來越高，需求開發周期長，實施效率低。

（2）電渠各個系統不統一，同一業務需求要在各渠道多次提出，容易造成業務邏輯混亂和運營效率低。

（3）業務可配置化程度低，缺乏統一的能力開放平臺。

2.2 業務目標

中國電信廣東分公司的電子渠道的發展目標是以互聯網企業為標桿，建設一套電子渠道標準服務提供平臺。平臺重點支撐以下業務目標：

（1）業務能力的統一接入、統一管理、快速封裝

◆業務能力的統一接入：電信對內外各個門戶及合作伙伴所使用的電信業務能力統一接入控制；

◆業務能力的統一管理：業務能力從申請、配置到開放、關閉的全生命周期管理；

◆業務能力的快速封裝：通過配置對基礎服務進行組合形成業務服務能力，并能實時對外開放或關閉。

（2）服務提供組件化、標準化

每個服務中心提供業務底層原子化服務，并統一服務接入、交換、訪問標準處理流程，服務和服務之間通過消息推送，實現服務異步調用，以達到松耦合和靈活擴展。

原子服務能夠通過組合及編排方式生成新服務組件，提高系統運營支撐效率，實現快速支撐和運營式開發模式。

（3）數據模型統一化

全面整合10000號、直銷渠道、社會渠道等渠道支撐，統一規劃網廳、自助終端、商城等電子渠道交互流程，提升內外部客戶的體驗一致性；設計符合電信電商化的數據統一模型，發揮體驗和運營效率，構建出高可用性和高擴展的數據模型，擺脫業務依賴。

（4）架構分布式

通過Session（會話控制）、業務、服務和數據庫分布式架構，構建出高可用性和高擴展的服務平臺。

（5）引入O2O線上線下模式互動營銷，提升用戶體驗

通過網廳、觸屏版、客戶端等形式支持用戶營業廳預約、資源查詢等服務體驗提升，實現商品訂單統一管理、完善分銷系統向B2B2C演進。

2.3 系統功能架構

電子渠道標準服務提供平臺核心應用功能包含服務接入、交換、訪問三層管理以及能力配置管理、生命周期管理、控制中心、運營支撐管理、開發測試支撐管理等關鍵功能。平臺功能架構如圖1所示。

（1）服務接入：主要負責根據單位時間內的訪問次數、流量對調用方進行訪問控制，當達到設置的閾值時，將調用方的調用返回，并通過返回流量限制錯誤明確告知調用方是屬于超過流量限制，以方便調用方進行相應的處理。安全控制包括：數字簽名認證，支持MD5等加密方式；IP黑白名單；OAuth 2.0校驗用戶是否授權應用訪問用戶信息，對接入平臺的用戶進行安全鑒權。超時控制通過設置每個服務的超時閾值，當服務代理調用服務提供方超時達到閾值后，調用探測偵聽接口，告知探測模塊對服務進行探測。

圖1 電子渠道標準服務提供平臺功能架構

（2）服務交換：主要負責對外提供Http Post、Web Service、Socket等不同方法服務的請求，并根據各個協議版本對應的節點描述配置，對接入的請求進行協議轉換。根據各個協議版本對應的節點描述配置，對接入的請求進行格式校驗，過濾消息中的個別字段或記錄。服務平臺接收到請求，在進行認證鑒權之后，把請求轉發到本地服務提供方，如果調用成功則返回調用結果，否則生成調用服務失敗信息。構建事務控制中心，所有事務的上下文都會注冊到事務中心，事務中心是可以允許事務的嵌套的，服務代理去調用其它服務時，如果這個服務有配置事務，那么它就會被當作一個子事務來注冊到事務管理中心去。服務代理端把交互日志入隊列到能力開放平臺上進行持久化，為了提高發送性能，把日志信息先發送到本地隊列，啟動多個發送線程從隊列中讀取信息，同步到能力開放平臺系統上，對于發送失敗的日志，需寫入本地文件進行重發。

（3）能力訪問：主要負責解析組合服務，處理數據轉換以及分發組合服務中的各個組合環節。將消息根據不同條件路由到不同端點，可以分為靜態路由和動態路由。

（4）能力配置：主要負責合作伙伴管理、服務提供、服務注冊、服務授權、服務目錄、服務編排、服務數據轉換、服務拓撲及服務測試。

（5）生命周期管理：服務生命周期管理的對象是服務能力，管理過程包括申請、審核、配置、發布、授權、關閉/注銷。服務生命周期管理是通過流程驅動管理，以確保標準服務的可用性、準確性和完整性。

（6）控制中心：主要負責服務探測管理、配置變更通知、協調控制、分布式、灰度上線及緩存管理。

（7）運營支撐：主要負責服務監控、實時監控、容器監控、數據采集、告警指標和報表分析的功能。

（8）開發測試支撐：主要負責開發指南和沙箱測試。

2.4 系統網絡架構

電子渠道標準服務提供平臺數據中心將應用、數據、服務器和存儲設備等集中管理，減少IT基礎設施和應用系統的重復建設，可有效降低維護成本，改進軟硬件性能，并通過統一的備份及災難恢復機制來增強可靠性和可用性。

數據中心將來需要為Internet、短信、WAP、VPN和專線等多種接入渠道提供可擴展的服務，承載核心應用，因此網絡系統必須在性能、可靠性、安全性、管理性、擴展性等方面滿足應用的需求。電子渠道標準服務提供平臺網絡架構如圖2所示：

圖2 電子渠道標準服務提供平臺網絡架構

3 系統的關鍵技術

3.1 SOA架構

采用業界已經廣泛采納的SOA（Service-Oriented Architecture，面向服務的體系結構）架構，進行電渠服務提煉。電子渠道標準服務平臺提供的落地思路是分析業務域中DFD（Data Flow Diagram，數據流圖）業務流程圖，經過顆粒度、耦合性、非功能需求分析，分解出電渠服務。基本分解過程如下：

（1）服務發現：包括業務域分解、業務流程分解、業務變化分析、現有系統分析。

（2）服務規約：顆粒度分析、耦合性分析、非功能性要求、接口定義。

（3）服務實現：服務實現決策、服務組件裝配、服務組合配置、服務重構、業務邏輯收斂。

3.2 去IOE技術

去IOE技術已經在互聯網得到很好的實踐落地，它給企業從軟件和硬件上帶來了更低的成本。電子渠道標準服務平臺去IOE主要集中如下：

（1）采用高性能中間件開源產品替換IBM、Oracle等中間件，需要有壓力測試研究，如不使用IBM服務總線產品、Oracle WebLogic產品，使用開源ESB、開源Web容器替換。

（2）數據庫存儲，對于可以容忍一定程序的數據，可以使用MySQL替換Oracle，關鍵業務繼續使用Oracle。引入NoSQL技術進行非核心數據存儲與分析，如平臺服務調用日志。

（3）存儲方面采用更加廉價的存儲設備。

3.3 緩存技術

采用緩存技術能夠有效解決業務系統對數據庫的壓力。緩存技術主要包括如下設計點：

（1）一致性Hash：解決了動態增減節點帶來的緩存節點失效問題，符合平衡性、單調性、分散負載均衡等特點。

（2）緩存加載：緩存數據初始加載與增量插入。

（3）緩存同步：根據場景設置主動與被動緩存失效策略。

（4）epoll網絡事件模型：使得在相同的硬件環境下較其它網絡模型支持更多的并發連接。

（5）緩存HA集群：避免節點失效后，緩存空窗現象導致大量數據庫操作而出現雪崩效應，通過HA實現失效轉移。

（6）實現服務配置數據可緩存、接口服務可緩存等。

（7）個性化緩存刷新策略。

（8）分布式緩存與本地緩存結合，要求緩存數據的一致性。

（9）可以使用分布式協調技術，實現數據緩存、同步刷新。

4 結束語

本文結合電子渠道發展的趨勢和業務目標，提出了電子渠道標準服務提供平臺的功能框架和網絡架構，并研究了平臺的3項關鍵技術，為電子渠道后續的發展建設提供參考。

[1]中國電信股份有限公司. 中國電信CTG-MBOSS系列規范集[Z]. 2011.

[2]趙一帆. 中國移動通信集團廣東有限公司電子渠道運營策略研究[D]. 北京: 北京交通大學, 2012.

[3]王大順. 營銷渠道如何適應電信競爭環境?[J]. 中國電信業, 2003(6): 42-44.

[4]周瑞峰. 電信運營商電子渠道建設初探[J]. 有線電視技術, 2012(12): 132-134.

[5]王越. 電信運營商服務營銷渠道模式市場適應性研究[J]. 世界電信, 2005(12): 19-23.

[6]李建州,宗新華,車立偉. 運營商電子渠道的演進和展望[J]. 移動通信, 2010(21): 38-41.

[7]張罡,田偉. 淺論電信運營商的電子渠道[J]. 數字技術與應用, 2010(6): 155-155.

[8]施戀林. 運營商和第三方支付平臺的合作與發展[J]. 通信企業管理, 2010(3): 82-83.

[9]張典曦,邱明清. “渠道建設+產品捆綁”模式 助運營商有線寬帶業務激增[J]. 通信世界, 2011(36): 18-19.

[10]陳永東. 增值業務市場：3G運營商激戰正酣[J]. 互聯網天地, 2009(9): 45-46.