电信运营商统一信息平台系统集中化重点问题分析
宋璞璇1，熊文剑1，李岳梦2
(1 中移信息技术有限公司，北京 100032；2 中国移动通信集团设计院有限公司，北京 100080)
摘　要　电信运营商的统一信息平台（OA）系统伴随着IT支撑技术的发展，一直处于迅速发展状态。本文介绍了如何
从多租户、容器化、业务支撑、数据库支撑和系统灾备等维度，同时结合运营商自有的私有云资源来实现统一信息平台业务、技术、数据和功能的分离，从而达到提高硬件基础设施使用效率、提高业务技术复用度的目的。
关键词　多租户分权分域；容器化；数据库支撑；容灾备份
中图分类号  TN915      文献标识码  A      文章编号  1008-5599（2021）06-0086-07
收稿日期：2020-10-16
电信运营商IT 支撑系统的整体架构设计伴随着运营商私有云资源池建设能力的不断提升。其遵循云化、可
视化、移动化和SaaS 化的设计原则，充分应用云化技术，降低软件授权费用，提高硬件基础设施使用效率；采用分层组件化和多租户化实现平台业务和技术、数据和功能的分离原则，提高业务技术复用度；业务同时支持PC 和各种智能终端，实现业务的多终端接入；引入可视化业务开发和运维工具，使之成为既面向用户又面向业务开发和维护人员的可视化工具平台。
统一信息平台（OA）作为电信运营商企业内部员工统一的信息访问和展示平台，已成为企业发展过程中最重要的IT 支撑系统之一。在OA 集中化统一建设过程中，由于功能复杂需求多变和插件兼容性差等问题，平台通过系统硬件基础设施云化、业务应用平台化、套装软件开源国产化和部分功能运维开发工具化，来有效
控制建设成本，快速满足多变需求，分步实现OA 的整体云化和自主化。
OA 系统业务量大，流程种类繁多，除了公文和门户系统可以实现标准化之外，其它系统实现标准化的可能性比较低，这对集中化后的运维能力是巨大考验。本文从多租户分权分域、容器化支撑、平台建设与业务支撑模式、数据库支撑和灾难备份等方面来探讨OA 集中化的总体建设方案。
1  多租户分权分域方案
OA 集中化系统因为业务种类繁多、业务数据量和服务用户数量大，为保证数据安全和系统稳定性，可
从数据隔离和应用隔离两个方面对多租户、多子域的业务支撑模式进行分析和设计。参考Gartner 发布的权威多
租户模型，如图1所示。
根据模型图，多租户模型通常分为7种服务隔离模式。考虑到运营商各单位之间存在管理线条相互独立、基础技术平台统一建设的情况，建议OA集中化系统采用模式5（多子域模式），数据库层面通过多节点方式进行数据隔离，应用层面则通过租户ID进行逻辑隔离。
分权管理即OA集中化的跨域系统管理员可以为每个单位的管理员进行授权，使各单位管理员可对本单位应用系统运行参数的配置、用户权限的管理、系统的日常维护、应用组织结构数据和用户数据的管理等功能进行管理，方便各单位维护人员完成本单位系统维护管理的相关维护管理工作。具体要求如下。
（1）所有权限管理均应支持多级管理，并且自顶向下逐级授权。管理员划分为集团级管理员、省级/专业公司管理员和地市级/子公司管理员3个级别。集团级管理员拥有整个OA系统的所有权限，能够进行一切操作。
（2）省级/专业公司管理员拥有对本单位及下属地市单位/专业子公司系统维护管理平台的所有管理权限，可以给下属单位管理员分配权限。地市级/专业子公司管理员拥有对本地市OA系统的所有管理权限。
（3）集团级管理员可以查看及审计整体平台运行状态。集团级管理员在查看总体运行状态的同时，也可以针对各个省级单位的应用系统运行状态进行分省调整及审计。
（4）省级单位/专业公司作为OA系统的域用户，其管理员可以对接入其域的应用系统状态进行配置管理，可以查看本单位接入应用的运行状态。省级/专业公司管理员在对本单位系统维护管理平台子域运行整体管理以外，也可以针对其下属地市单位/专业子公司OA系统子域使用情况进行细化审计分析。
2  容器化支撑方案
容器技术是后于虚拟化技术出现的，主要应用于云化环境下的应用服务部署与管理。在云化环境中，通过合理的容器化部署和划分，能够简化部署架构，降低运维管理复杂度，使系统承载能力能够随需扩展。
虚拟化技术的出现主要是为了解决资源调配和隔
离的问题，容器技术重点解决的是应用开发、测试和部
署等提升效率的问题。Docker现在是容器技术的代表。图1  分权分域多租户模型图
Docker通过Namespace分离进程，隔离网络接口、挂载点和进程间通信，使用Croups将CPU和内存等物理资源隔离开。这样就将一个完全对宿主机“一无所知”而且拥有“独立”资源的容器构造出来了。容器之间共享同一个系统内核。
OA集中化的容器化支撑方案可分为按省级单位划分容器模式和按业务应用划分容器模式。
按省级单位分别划分一套容器承载业务，省级单位之间容器隔离，容器内部实现应用多租户隔离。按省级单位划分容器的优点是具有较好的隔离性，各省级单位发布更新应用及调整数据时互不影响。缺点是省级单位应用在容器内部仅实现租户隔离，不同应用在发布更新应用及调整数据时仍存在相互间影响的可能性；各省级单位应用容器隔离分散部署导致应用的规范度较低、复用性较差，并且资源利用率较低，会存在资源浪费的情况。
按业务应用分别划分一套容器承载业务，应用之间容器隔离，容器内部实现省级单位多租户隔离。按应用划分容器的优点是省级单位应用的规范度较高，复用性较好，资源利用率较高。缺点是各省级单位在容器内部仅实现租户隔离，不同省级单位在发布更新应用及调整数据时容易造成相互间影响。
容器化支撑方案的两种模式存在不同的优缺点，并具有一定互补性。对于个性化较强的非SaaS化应用，按省级单位划分容器模式可以较好满足个性化需求，并且能在频繁发布更新的情况下实现各省间互不影响。针对规范度较低和复用性较差的缺点，可以通过平台提供统一的组件库和最佳业务实践库，来提升省级单位应用的规范度与复用性。对于业务共性和规范度较高的需求场景，可以提供全网SaaS化服务的应用，结合按应用划分容器模式，可以较好满足规范服务和用户体验的要求，能在频繁发布更新的情况下实现应用间互不影响，同时能够有效保障应用的规范度、复用性和系统资源利用率。
综上所述，经过对两种模式的分析对比，针对通信行业管理和业务运营模式，可采用两种模式相结合的方式，根据不同类型的应用特性来选择对应模式。
3  平台建设与业务支撑方案
OA系统业务涵盖范围广泛，业务需求复杂，涵盖了单位管理的方方面面，业务需求实现紧急度与管理要求都较高，因此在OA系统集中化以后，如何能够快速有效支撑省级单位的业务需求成为一个极大的挑战。根据前面的分析，OA系统建设与业务支撑方案可分为集团集中建设支撑模式和集团与省级单位协同建设支撑模式。
3.1 集团集中建设支撑模式
集团集中建设模式的分工包括集团与省端两部分。
集团负责对OA集中化系统做整体业务规划，集中化投资。按各业务的集中化标准规范建设统一的集中化系统，按业务标准做集中化推广。在集中化系统上对省级单位需求分析梳理，梳理多套模板以满足不同省级单位间的需求差异。
省级单位负责按照集团的要求使用系统，业务部门结合业务规范和省级单位管理特性提出建设需求，省端支持对需求做汇总与集团做对接。
集团集中建设模式的特点是全集团统一建设，集中化投资，可以节约成本。对于标准化作业程度高的系统推广效果较好。但是省级单位OA系统已分散建设多年，存在大量个性化和地域化的管理需求，集中化
系统对省级单位的个性化需求支撑很弱，系统推广难度极高。此外，系统个性化定制多，不利于版本管控；省级单位支撑人员作用被削弱，只是汇总和传递需求，过程中需求反而有失真；集团支撑人员投入增大，由于需求的失真，需求反复优化情况较多。随着系统应用程度不断深入，集团支撑将越发吃力。
3.2 集团与省级单位协同建设支撑模式
集团与省级单位协同建设模式的分工包括集团端与省端两部分。
集团端负责利用云架构平台为省端提供标准化的信息化配置工具，负责工具的升级、使用管理和省级单位支撑人员培训。
省端单位负责业务部门结合本地管理要求，提出信息化建设需求。省级单位支撑人员使用集中的信息化配置工具管理建设本地化的信息系统。
集团与省级单位协同建设模式的特点是需要集团和省级单位的支撑人员在信息化的需求管理、开发配置管理、测试管理、上线管理和安全管理等各个层面通力合作，成为一个团队；基于云架构平台的信息化配置工具，建立了一套集团与省级单位一体化的信息化开发生态系统，在这个生态系统里集团与省级单位支撑人员各尽其职，提升需求开发效率和用户满意度。
3.3 模式对比与方案建议
综合分析OA系统的业务特性，主要有以下3个方面的特点。
（1）OA系统的个性化程度强于ERP等高度标准化的系统，并且OA系统属于省级单位领导常用的管理系统，因而关注度也更高，所以对需求和维护的响应速度有更高的要求。
（2）OA系统缺乏总体的业务牵头部门，不利于标准化的集中支撑。
（3）省级单位OA系统建设历史较长，个性化与地域化需求较为分散，且管理模式与管理水平差异较大。
结合上述特性，对两种建设模式进行对比，对省级单位OA系统建议采用集团与省级单位协同建设支撑模式，将平台开发能力下放给省端，由省级单位自行组织业务开发，后续的日常业务需求可由省端自建及维护支撑。
4  数据库支撑方案
OA集中化系统的数据库支撑方案可分为集中节点部署模式和分布式节点部署模式。
数据库支撑模式主要取决于平台建设模式的选择，如果平台选择集团和专业公司集中建设支撑模式，则应采用数据库集中节点部署模式，需要按应用划分数据库。在物理上采用集中化数据库，在逻辑上进行数据库分割，从而实现对集中建设模式的数据库支撑。
如果平台采用集团与省级单位协同建设支撑模式，省端支撑人员基于平台进行开发，对于SaaS化提供多租户服务的应用目前只能采用数据库集中节点部署模式。通过采用数据库分离方案，数据层可具备数据分散存储和数据库热切换特性。对于非SaaS化应用可以按分省分库划分数据库实例，实现分布式数据库节点部署模式，通过数据隔离更有利于维护权限的分配和控制，实现对省级单位建设模式的数据库支撑。
综上所述，经过对两种部署模式的分析对比，OA 集中化系统建议对集团和专业公司OA采用集中节点部署模式，对省级单位OA可采用分布式节点部署模式。
5  灾难备份方案
基于多年来运营商信息化发展模式，OA集中化系统中的门户、流程、用户认证、待办/已办等平台将逐渐演变成为运营商信息化系统的核心能力，为所有的信息化系统提供服务，所以OA集中化系统在建设的同时需要建设完备的灾难备份方案。本文基于运营商资源池所提供的支撑能力，比较说明“双活同城双中心”（两中心之间距离不超过70 km）和“主备异地双中心”两种方案的优缺点。
开源oa系统源码5.1 双活同城双中心方案
同城内系统部署在甲乙两个基地，甲基地与乙基地分别部署OA集中化系统主平台实现双主双活，双主平台应用更新时同步更新，数据库与文件实时同步，如图2所示。
用户访问时，通过跨同城异数据中心访问的4层交换机进行探测并分发请求，实现负载均衡（可通过业务拆分将请求分发到不同主平台的HAProxy，然后通过HAProxy访问部属在Docker的对应服务）。当其中主
平台A出现故障无法访问时（前提是4层设备还可对外提供服务），DCOS管理平台的服务监控探测到其无法提供服务，此时如主平台B的对应服务容器尚未启动，则通过DCOS平台任务调度立即启动对应服务的容器，所有请求都分发到主平台B，实现无缝切换。如4层设备所在的机房出现断电或自然灾害等故障导致4层设备也无法提供服务，则需要通过同城异数据中心间4层设置和主备切换来实现服务的切换。
当主平台A恢复服务能力后，DCOS管理平台服务监控探测到其可以提供服务，则4层交换机按之前规则进行请求分发并实现负载均衡。
双主平台都要在本地进行离线备份。离线备份每天执行一次，如果出现数据丢失等情况，可以恢复到前一天。
5.2 主备异地双中心方案
甲基地（部署在甲城市）部署OA集中化系统主平台甲，乙基地（部署在乙城市）部署备平台乙。应用更新时需要主备平台同步更新，数据库与文件实时同步，如图3所示。
当主平台甲出现宕机、断电、网络断开、存储损坏、自然灾害等故障并在规定时间内无法完成恢复时，维护
人员可以通过修改DNS实现主备
平台切换，将服务切换至备平台
乙。切换后主备平台应用、数据
库和文件保持一致。
当主平台甲恢复服务能力后，
需要中断业务暂停备平台乙的服
务，手动修改DNS切换回主平台
甲并恢复服务。
主备平台均需要在本地进行
离线备份。离线备份每天执行一
次，如果出现数据丢失等情况，
可以将数据恢复到前一天。
5.3 灾备方案对比
对于异常不可控的大型故障和自然灾害等问题场景，我们针对两种方案的恢复时间、恢复完整性、恢复可靠性、以及方案的优缺点等内容对主备异地灾备和同城双中心灾备方案进行了评估比较，比较结果见表1。
经过上述比较，双活同城双中心在实现容灾上技术优势明显，可以实现用户的无感知切换，符合现在主流的系统软件运维开发一体化高效上线投产的设计思想，但是整体架构的调整还依赖于私有云资源池和DCOS平台等底层基础能力的调整，投资比较高；
主备异地双中图2  双活同城双中心方案模型图
图3  主备异地双中心方案模型图

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。