运营商系统上云的背景

系统上云是数字经济发展的潮流，在数字化转型的浪潮中，上云已经成为推动各行各业创新和效率提升的关键力量。运营商作为服务行业和企业上云的服务商，积极响应国家号召的同时为行业上云打造案例标杆，自身的系统要首先上云。

运营商运营支撑体系上云也有内在的需要，系统架构不统一、依赖传统IOE硬件、单体架构等，带来了部署成本高、维护困难、无法根据业务弹性伸缩、新业务扩展支撑响应慢等一系列问题。互联网企业的云化实践以及前期的试点经验都表明，上云是高效解决这些问题的必由之路。

系统上云的目标

参考互联网企业云化实践思路，结合运营商现网系统情况，按照“先云化，再上云”的策略，采取去IOE、微服务化、容器化、中心化、统一和多底座兼容、云化工具配套 6大举措实现上云，最终达成节省IT投资、简化配置部署、弹性伸缩、快速集成、灵活扩展和降低运维难度的目标。

上云的挑战

运营商系统上云存在很多挑战，包括但不限于架构适配改造工作量大，性能、可靠性和安全风险高，现有标准不满足云化特性，缺乏底座能力，存在工程实施周期长、风险高、业务迁移难和运营效率低等多方面挑战。

传统架构笨重，适配改造困难

运营商的系统往往是基于传统的、大型的、集成度高的架构设计，这些系统需要大量的改造才能适应云环境。例如，将单体应用拆分为微服务架构，需要重新设计服务的模块、通信机制等等。旧系统未微服务化，依赖较重的中间件，烟囱式支撑业务，升级较为繁琐，无法动态伸缩部署，前后端未做分离，定位问题困难等，需要在较短时间内完成系统的架构升级。

现有标准不满足云化特性，缺乏统一平台底座

现有系统基于IOE构建，使用重量级中间件或开源中间件，未使用统一的PAAS组件。缺乏统一平台底座，导致系统云化改造缺乏统一架构标准、改造工作量大、扩展支撑难度高，例如不具备低代码快速配置实现前端需求能力、报表快速配置能力。

工程实施风险大周期长

上云要求复杂的项目管理、多方协调和技术实施，这些因素可能导致上云项目延期或预算超支。追求快速上云的过程中，过于复杂或不明确的项目目标和范围设定可能导致实施进度缓慢，难以在预定计划完成。

业务迁移难

运营商业务复杂，为保证业务正常运行，需同时兼顾新老系统需求的并行支撑。共性需求没有统一研发，不能共享成果，人力资源浪费，个性化需求响应不及时，端到端全流程有断点，无法快速的承接迁移业务。

配置开发工作量大/表单界面多

流程业务配置工作量大，需要配置流程、环节、时限和业务组件埋点等，表单个性化需求较多、表单界面多，需投入较多前段人力开发。

运营困难

定制化需求多，变更较为频繁，上线后难运维，缺乏故障快速发现、定位、处理手段，并且无法快速进行需求研发迭代。

运营商系统快速上云实践

在运营商系统上云实践过程中，为达成系统云化特性标准，针对上云过程中的诸多困难点，按照“八步法”组织实施，有序推进，实现了系统并行实施和快速上云。

画蓝图

总体思路是基于统一底座实现多业务系统统一云化架构，优化资源利用率，整体上实现业务与技术的解耦，提高系统的灵活性和可维护性。

架构自下而上分为硬件层、PAAS层、应用层以及展示层，其中硬件层提供必要的计算能力、数据存储能力和网络通信能力，是支撑上层应用运行的物理基础，硬件资源通常通过虚拟化技术被抽象化，以支持更灵活和可扩展的网络功能和服务；PAAS层为上层业务应用提供了统一的云化技术底座，提供流程平台与搜索引擎、开放的API设计能力、低代码能力的表单设计器、灵活的规则配置平台与报表平台等组件或能力；应用层基于服务能力开放平台支持模块化服务，通过API快速集成构成多业务系统，采用容器化技术来封装和部署各种应用和服务，保障云资源环境的一致性，支持快速部署和拓展，资源隔离，可伸缩性；展示层提供云化应用系统的统一对外交互界面。

定标准

针对上云的挑战和目标，对标上云目标特性，制定了以下目标措施：

• 完成系统去IOE及去Weblogic、Websphere 等商业软件；

• 统一使用平台PaaS组件，包括不限于Cache,pg,mq等等；

• 能力注册：对外提供能力注册平台，有效调用，应用和界面解耦，核心功能能够注册并调用；

• 代码平台托管：全量代码托管到平台代码仓库且动态更新；

• CI/CD：容器化实现平台的编译打包和部署，实现动态伸缩；

• 敏捷开发：平台实现从软件开发需求到可部署代码的开发全过程管理；

• 故障快速定位解决: IaaS/PaaS/SaaS相关业务指标监控，故障时快速发现并定位，较短时间内处理解决。

搭底座

以微服务化架构对外提供服务，实现应用与平台解耦，基于这个核心底座，可以快速进行业务流程的加载，实现敏捷开发、实现需求开发测试上线转维的全周期管控。统一底座包含如下一系列共享平台组件：

流程平台：严格遵循BPMN规范，提供全面的流程管理功能，包括流程定义、监听配置和部署。支持流程实例的创建、启动和完成，支持任务节点的生成、完成，以及环节参与者的指定、签收、改派和加派等操作。此外，平台还提供灵活的微流程设计工具，以适应各种业务需求，确保流程管理的高效和灵活。

自定义表单设计器：支持低代码的方式快速配置表单的各项业务属性、数据源，适合不同设计与应用场景。

API设计平台：支持多种通信协议，如：http/restful、soap/webservice、websocket。

规则平台：支持一个规则定义下有百万级规则实例数，可根据多种条件组合规则进行智能调度。

报表平台：新报表平台支持多数据源、可视化设计、多种类型表格及图表，提供丰富模板，支持快速自定义配置。

搜索平台：集成高效的Elasticsearch查询分析服务，优化并加速工单搜索过程确保快速准确地检索相关工单信息。

升架构

架构升级原则依托于云原生的10要素（前后端分离、应用与数据解耦、中心化&微服务设计、无状态设计、应用与配置分离、统一日志、水平扩展、快速启动、容器部署、应用敏捷交付）实现架构弹性伸缩，具备研发云、云眼、云桥等平台对接的能力。

用工具

合理的利用工具能提升研发、配置效率，做到事半功倍的效果，业务发布助手以及底代码表单工具为快速上云实践提供了巨大助力。

业务发布助手：实现将业务场景设计的流程、表单、埋点、调度策略、时限规则等业务配置打包，发布到其他环境，如从研发环境生成业务包，发布到生产环境，避免重复配置，提升上云业务配置效率。

低代码表单工具：基于低代码表单平台“拖拉拽”的模式快速实现界面需求，省去大部分的编码工作量，降低了研发门槛，节约资源投入，提高效率。

迁业务

业务迁移的过程采取专题需求版本统一研发、规范发布、自动数据迁移比对和共性能力预置等手段，帮助核心业务流程快速迁移整合。

统一研发：针对专题需求，由统一团队对需求进行统一分析、设计和研发，制定基线版本，最大程度上缩短交付周期。

规范发布：统一版本包（应用包+数据包）、部署操作手册、演示脚本等，支持定制需求落地。

自动数据迁移比对：对于复杂流程，针对性的设计了数据迁移比对流程，较好的实现了旧系统数据的迁移到云化系统。

共性能力预置：针对具有共性的业务场景在出厂时预置了对应的模块以及配置数据，实现快速的业务迁移，具备可复制性可推广性。

建模式

为应对多项目并行交付的挑战，确保项目同步推进，统一支撑团队通过优化资源配置和规范化交付流程，快速识别并解决潜在问题，统一版本输出，加强各省项目的统一性和效率。同时建立了项目交付模型框架，在交付前中后六个阶段规定了标准动作输出，系统化地推进交付运营并提升交付质量。

优运营

系统迁移上云，需优化需求保障、研发提效、运维提升等各种运营指标，做到事中并行保障，事后优化提升。

1、针对多项目并发需求，采取统一支撑，亮点共享，个性需求小循环，共性需求大循环的模式。

统一团队作为需求分析接口人过滤共性需求还是个性化需求，如果判定为个性化需求就由各自团队内部进行分析、设计、研发、测试、交付；如果是共性需求则由统一团队进行后续的流程，做到多点交付，亮点共享，节约成本。

2、运维上采取多个有效措施，来解决发现难、定位慢、解决差的问题。

针对中间件比如cache，mq，数据库等问题，利用监控平台进行日常监控，出现问题及时发现并告警通知。针对应用类故障的引入调用链相关，提供图形化界面快速定位故障点，避免传统人工排查日志定位。针对故障出现的业务数据修复，引入业务清障助手，可以批量快速的处理故障引发的异常业务数据。

基于上云采取的积极有效措施，团队在一年内完成了超过30套系统的快速上云，取得了良好的效果。经运行监测发现，系统上云后，系统性能上提升35%左右，稳定性大幅提高，系统部署和运维成本降低幅度达到75%，系统不再依赖昂贵的硬件和商用中间件，节省了大量的IT投资；云环境支持快速部署新服务和应用，响应变化的速度比传统IT架构快50%以上；DevOps和自动化工具的集成简化了开发和运维流程，使得新功能从开发到上线的时间可以缩短至几小时或几天。