鲸品堂｜运营商系统快速上云的实践分享

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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