电信运营商电子签名系统多业务场景方案的设计与优化

李炎戌

摘要：电子签名系统实现了业务受理的无纸化，提升了业务受理效率，大大缩减了企业成本[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.

【通联编辑：谢媛媛】