電信運營商電子簽名系統多業務場景方案的設計與優化

李炎戌

摘要：電子簽名系統實現了業務受理的無紙化，提升了業務受理效率，大大縮減了企業成本[1]，然而隨著業務發展需求的多元化、個性化，如何實現電子簽名在差異化業務場景的快速應用，已有領域尚缺乏相關研究。該研究提出一種基于業務路由的電子簽名系統，在原系統通用能力基礎上構建業務路由，能夠快速實現差異化業務場景快速穩定處理。經過方案實施及結果驗證，該系統實現了電子簽名在兩種橫向業務場景下的快速應用，為客戶經理解決了協議簽字在不同業務場景下高效辦理電子簽名流程問題。

關鍵詞：電子簽名;業務路由;差異化業務場景;高效穩定

中圖分類號：TP311 ? ? ?文獻標識碼：A

文章編號：1009-3044（2022）02-0061-03

1 概述

隨著電子信息科技的快速發展及用戶需求多元化，電信運營商業務受理量倍增且業務更加靈活多變，對于業務穩定高效運營提出了更高要求。近年來，業務受理量的增加，導致運營商需要大量處理并保存與用戶簽約的各類協議[2]，這對運營商業務辦理的穩定性、時效性提出較高要求，為存儲用戶信息帶來巨大挑戰，問題具體表現為：1）大量紙質協議存儲安全性和用戶爭議較多，降低了客戶滿意度;2）紙質協議的企業運營成本巨大;3）業務場景增多且變化更快，紙質協議難以快速應用于各類場景。在此背景下，針對不同業務場景快速落地無紙化業務辦理流程，某地運營商在傳統電子簽名系統的基礎上，針對多種業務場景的電子簽名通用能力快速落地進行了部署模式的優化探索，解決了傳統電子簽名系統在滿足個性化業務需求的痛點。

2 電子簽名系統現有架構

本研究所述的電子簽名系統，主要應用于兩類業務場景：一是配備了外部簽字設備[3]的臺席業務受理;二是使用行銷類App的業務受理。

第一類場景是通過無紙化流程實現，通信流程如圖1所示，具體如下：

1）用戶在完成業務辦理時，電子簽名系統提供縱向能力在無紙化協議簽署的過程中支撐協議前出;

2）將協議推送到電子簽名后臺服務，電子簽名后臺服務完成協議存儲后返回結果給無紙化流程;

3）通過HTTP請求調用電子簽名客戶端的守護進程本地監聽端口，本地監聽端口實現了拉起PDF展示進程的邏輯;

4）拉起PDF展示進程后，通過HTTP服務調用電子簽名后臺服務完成PDF文件拉取;

5）電子簽名客戶端收到響應后和硬件DLL交互推送到簽字硬件完成簽字展示;

6）客戶使用簽字硬件完成簽字流程，并點擊簽字提交;

7）電子簽名客戶端收到響應后將簽字軌跡提交到后臺，由后臺服務完成簽字軌跡合成、數字簽名合成、加密服務，異步上傳到分布式存儲。

第二類場景是將電子簽名能力打包到行銷類App中，在客戶經理完成業務受理時彈出電子簽名界面，用戶通過手機端的查看協議和手寫滑動完成簽名確認業務受理內容，具體處理流程如圖2所示。

既有營業廳無紙化業務受理系統解決了使用紙質協議的問題，但仍然存在不足：一，采購簽名設備增加了企業的生產成本，運營商的邊際收益降低;二，只有客戶經理的手機上安裝了行銷類App才能進行電子簽名，但客戶無法通過自助的形式查看協議和簽名。為解決上述不足，本研究提出了優化電子簽名的服務部署架構。

3 電子簽名業務落地過程痛點分析

根據相關要求，所有業務辦理流程須用戶知情，因此電信業務受理無論是在營業廳或在后臺處理都須有用戶確認的環節。本研究基于現有電子簽名系統進行完善，將電子簽名的使用場景從單一的營業廳業務受理，推廣到線上受理、遠程用戶確認環節，建立了一套完整的用戶確認流程。基于線上受理、遠程用戶確認，本文將分析具體流程和實時性能。

在線上受理時，用戶在系統完成業務受理后的業務激活階段進行電子簽名，并完成業務實際開通，但在用戶確認前業務實際并不能夠使用，具體流程如圖3所示。

在用戶遠程確認場景時，后臺會向用戶發送短信，用戶完成電子簽名后系統才會實際完成業務受理工作，整個流程中營業員不能跳過電子簽名流程的步驟，從而確保業務受理在用戶許可的情況下進行，確保業務受理的安全性，具體流程如圖4所示。

4 系統設計與驗證

4.1 方案設計

在既有系統基礎上，為了保障在系統升級過程中，不影響用戶的感知和體驗，引入了灰度發布[4]，基于灰度發布機制化業務需求制定了整體部署方案規劃，如圖5所示。系統使用F5、Nginx、Tomcat三層架構，由F5完成流量路由、Nginx實現按業務需求轉發到相應的Tomcat集群[5]，達到實現地市個性化需求上線和穩定運營的目標。本研究使用營業員工號 （staffCode）、渠道ID （channelId）、地區ID （regionId）業務參數來進行路由（優先級如下：staffCode>channelId>regionId）。本研究基于Nginx的反向代理能力，利用配置不同的upstream服務集群地址映射到不同的服務集群，不同個性化業務需求的服務集群可以實現水平擴展。因此在具有個性化需求需要更新到生產時，可先增加業務服務節點，并在 Nginx集群上配置業務路由信息，相關業務需求的請求就能夠分發到對應的地市驗證環境服務器上。圖5 是本研究的架構方案圖：

4.2 方案實施

4.2.1 電子簽名系統的改造

1）App中實現上層業務無感的SDK通信版本更新，升級通信協議到V2版本，增加后臺業務路由中需要的請求參數;

2）PC端拉起電子簽名頁面增加業務路由參數，電子簽名頁面由HTML5實現包含很多靜態文件，這里借助Cookies機制保證頁面和靜態文件都路由到相同的服務集群，具體流程如下：

①Nginx判斷流程：HTTP請求到達Nginx集群后，經過Nginx請求解析后路由到對應的應用服務集群。具體流程見圖6。

②調用方的改造：上游系統調用需要添加業務需要的HTTP請求頭實現請求不同的個性化業務電子簽名服務能力。

4.3 方案論證

基于以上方案，電子簽名在某地運營商成功實現了多個不同業務場景下電子簽名業務的快速落地，將電子簽名通用能力以穩定快捷的方式應用至不同電信業務受理場景，極大提高了電信業務無紙化受理效率及協議合規簽署數量。

在J省S地市，率先推行的使用手機端完成電子簽名成功降低了對電子簽名書寫屏幕的依賴，降低了一線營業廳的使用成本，其簡單高效也得到了其他地市的高度認可。在S地市使用后陸續推廣到全省使用。S地市的手機和PC雙屏電子簽名基于上述的部署方案落地，J省后續也安排了更多的使用場景基于本架構落地，為后續電子簽名多業務場景落地提供了更加敏捷可靠的落地方式。

5 結束語

本研究提出了基于Nginx構建業務路由的電子簽名方式，發揮了根據不同場景的特點發揮電子簽名通用業務能力，滿足了差異化業務場景的業務快速受理及穩定運營的需求，不僅提升了一線業務運營人員感知，而且將系統運維風險降到可控范圍內，提升了客戶的滿意度。

參考文獻：

[1] 劉小發，曲金豹，王欣，等.無紙化營業在電信運營商的應用部署探討[J].郵電設計技術，2016（12）：1-5.

[2] 辛笛.運營商無紙化業務受理平臺建設方案[J].通訊世界，2016（18）：35.

[3] 王立明，陳奇輝.電信行業無紙化營業廳實現技術分析[J].科技傳播，2013，5（18）：193-194.

[4] 任韻.移動電子渠道灰度發布系統的設計與實現[D].長沙：湖南大學，2017.

[5] 熊軍軍，彭曉剛，鄭曉勇，等.基于“Nginx+Lua”組件的應用系統灰度發布[J].金融電子化，2020（5）：92-94.

【通聯編輯：謝媛媛】