运营商IT系统云原生部署方案研究

蒋明燕（上海邮电设计咨询研究院有限公司，上海 200092）

1 云原生的定义及关键技术

云原生应用（Cloud Native Application）是指针对云计算基础设施进行优化设计的应用，适合部署运行在现代的云计算平台上，能充分利用云平台所提供的资源和服务，是一系列云计算技术体系和管理方法的集合。云原生应用具备良好的扩展、伸缩和容错能力。云原生涉及的技术栈十分广泛，生态十分繁荣，产品也正在被广泛应用。

云原生技术由云原生计算基金会（Cloud Native Computing Foundation，CNCF）提出，有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的关键技术包括不可变基础设施、容器技术、微服务和无服务器（Serverless），其技术架构如图1所示。

图1 云原生技术架构

不可变基础设施指运行服务的服务器在完成部署后，不再进行更改。采用云端虚拟化基础设施作为构建基础，通过容器来打包及构建整体服务运行环境，实现容器镜像的自动化构建及版本化管理；通过持续部署系统，实现自动化部署。

容器技术包括容器运行时和编排调度。运行时是容器的运行环境，体现为各种开源容器产品，比如最常用的Docker。编排与调度是云原生的基石，是贯彻容器到服务实例的桥梁，其中Kubernetes 已成为事实标准。

微服务包括服务治理工具与编排调度服务。服务治理体系目前包括MicroService 与ServiceMesh，以及其中采用的一系列开源工具，如ZK、API网关等。

Serverless 构建服务形态，包括一系列产品，其中Lambda等注册平台比较成熟，开源产品则刚刚起步。

这些技术可用于构建容错性好、易于管理和便于观察的松耦合系统，让应用处于待发布状态，从而解决环境一致性问题。

2 云应用模型分类及云原生应用

如图2 所示，云应用模型分为IaaS、PaaS、Serverless及SaaS。

图2 云应用模型分类示意

IaaS 环境中，云服务提供商提供网络、存储、服务器及虚拟化，开发者则负责操作系统、中间件、运行时环境、数据及应用；PaaS 环境中，云服务提供商提供网络、存储、服务器、虚拟化、操作系统、中间件及运行时环境，开发者则仅需负责数据及应用；Serverless 环境中，云服务提供商提供网络、存储、服务器、虚拟化、操作系统、中间件、运行时环境及数据，而开发者则仅负责应用；SaaS 环境中，从网络、存储、服务器、虚拟化、操作系统、中间件、运行时环境、数据到应用均由云服务提供商提供。

一般认为IaaS 型应用属于从物理机环境直接迁移到虚拟机环境的云迁移应用，其开发、部署、管理和运维方式与传统应用类似，并非真正的云原生应用。其余3类应用才是具备敏捷交付和高度自动化管理能力的真正云原生应用。

目前云原生应用典型的应用交付方式包括代码式交付、镜像式交付、脚本式交付和应用包交付。基于Kubernetes 的PaaS 平台大多支持上述4 种应用交付方式。

3 云原生成熟度模型

云原生架构关键架构维度用SESORA 表示，即服务化能力（Service）+弹性能力（Elasticity）+无服务器化程度（Serverless）+可观测性（Observability）+韧性能力（Resilience）+自动化能力（Automation）。关键指标维度和云原生架构成熟度等级分别如表1和表2所示。

表1 关键指标维度

表2 云原生架构成熟度等级

云原生成熟度评估包括2 个步骤：第一，根据SESORA 对6 个维度分别评分并汇总；第二，根据分值分段获得评分结果。

对某运营商IT 应用进行云原生成熟度评估后，发现其成熟度较低，具有很大演进空间。

4 运营商IT系统上云需求

运营商IT 系统目前存在资源利用率低、运维成本高、管理复杂、部署耗时久、开发与生产运维割裂等问题。前期采用SOA 架构进行改造的效果并不理想，采用微服务化的架构方式及容器化的承载、运维模式更符合互联网化技术发展演进和企业发展趋势。

云原生核心特点是应用容器化封装、编排和交付、微服务设计、研发运营一体化。云原生应用将给运营商带来应用的敏捷构建和迭代、更顺畅的多团队协作以及更高效的云资源利用。微服务是把一个单体项目拆分为多个微服务，每个微服务可以独立技术选型、独立开发、独立部署、独立运维，并且多个服务相互协调、相互配合，最终完成用户的价值。微服务架构是一种松耦合、去中心化的架构模式。大部分大型网站系统如Twitter、Netflix、Amazon 和eBay 都已经从传统整体型架构迁移到微服务架构。

为了降低开发成本、提升软件生产率，云原生和微服务已成为软件架构的发展趋势。软件部署架构从单机到分布式再到云原生，软件组件可通过API 按需调用，从而实现了基础设施的自动化以及快速的软件交付。软件系统架构也经历了从单体架构到SOA再到微服务的架构演进，实现了服务的原子特性，可以更加灵活地独立开发和部署。

IT 系统主要包括互联网类、OLTP、OLAP、后台数据处理、大数据交互等不同应用类别，上云的技术特点也各有不同（见图3）。

图3 各类型IT系统上云技术实现示意

a）互联网业务。异构且技术栈众多，关键应用需容器化部署，架构易水平扩展，需着重考虑业务的安全隔离问题。

b）OLTP 业务。需实现集群多租户共享及应用容器化部署。

c）OLAP 分析报表业务。数据库采用PostgreSQL数据库进行替代，支持资源动态扩缩容。

d）后台数据处理。密集计算以物理机为主，数据库根据场景可以选择PostgreSQL、TeleDB、时序数据库等组件。

e）数据交互类。需实现应用容器化及动态伸缩。

f）公共基础类。平迁到运营商云资源池的虚机或物理机上进行部署。

运营商IT 系统上云有两大技术目标：第一，打造敏捷IT，提升交付效率与质量；第二，实现智慧IT，提升智能弹性计算能力、智能运维能力。云原生是云服务商、互联网企业、系统集成商、通信运营商等共同定义和遵循的应用开发、交付、运营范式，是今后云计算的主流技术方向。因此运营商IT 全面上云需参考和推广云原生应用。

5 运营商IT系统云原生部署方案

5.1 目标架构

运营商IT 系统总体向“平台+应用”架构逐步演进，采用微服务架构，能力微服务化，统一编排、高效复用。运营商IT 系统云原生目标架构自底向上包括基于容器的不可变基础设施层、中间件层、能力层、微服务层、应用层以及安全管理和运营监控（见图4）。

图4 运营商IT系统云原生目标架构

5.2 演进路径

云原生落地需基于业务敏捷性、健壮性逐步实施（见图5）。

图5 云原生演进路径

最初，基础设施云化为上层应用提供计算、网络、存储基础架构资源。然后，构建PaaS 平台实现Devops：通过容器+微服务+Devops，构建应用架构不断迭代更新的循环。最后，实现微服务治理及API运营：复杂业务分拆、松耦合，独立更新部署，管理及流程自动化，基于API实现分布式集成管理和流程自动化。

5.3 部署要点

为实现上述IT 系统云原生目标架构，需从构建不可变基础设施、下沉中间件统一开放服务化接口、采用微服务框架构建软件系统以及软件系统架构分层解耦几个方面分别考虑部署要点。

5.3.1 构建基于容器的不可变基础设施

不可变基础设施里的“不可变”和程序设计中的“不可变”概念类似。程序设计中的不可变变量在完成赋值后就不能再更改，只能创建新的不可变变量来整体替换旧的。由于该特性，并发环境下也可以安全地使用变量。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不再进行更改。

在构建云原生时，要实现不可变基础设施，需从以下几点着手。

a）使用云基础设施作为构建基础。标准化的敏捷基础设施通过服务化的方式对外开放，并对应用用量进行统计。底层基础设施根据容器和PaaS 中间件要求进行配置和扩容，硬件配置整体保持稳定、不允许修改，通过更新模板和实例实现运行环境的变更。

b）通过容器技术来打包及整体构建服务运行环境。软件系统不直接操作底层基础设施，而是通过业务性能指标提交具体需求，使用IaC、工具、API 方式进行配置和部署。

c）实现容器镜像的自动化构建及版本化管理。软件系统可根据通用模板定制镜像运行应用，对模板有更新需求时统一提交申请。所有应用通过镜像进行发布、构建，按照统一的DevOps流程自动化构建、自动化测试、自动化发布，不允许定制发布。

d）通过持续部署系统，实现自动化部署。资源统一观测和管控，根据业务运行情况和应用配置自动伸缩。

5.3.2 下沉中间件，统一开放服务化接口

中间件处于系统软件（操作系统和网络软件）与应用软件之间，它能使应用软件进行跨网络的协同工作。中间件为应用软件提供了操作系统所提供的服务之外的服务，可以将其描述为“软件胶水”。中间件能够让软件开发者方便地处理通信、输入和输出，专注在应用本身。中间件包括消息中间件、分布对象中间件、远程过程调用中间件、数据访问中间件、事务处理中间件等。

a）将标准中间件下沉到云基础设施（容器、裸金属容器），成为云原生服务的一部分。

b）对中间件进行服务化改造，提供标准调用规范。

c）应用与中间件解耦，不感知中间件的存在，通过API服务的方式使用中间件能力。

d）中间件统一运维管理，可感知应用状态，实现计算和存储能力的自动伸缩。

e）引用标准镜像方式，实现虚拟机和裸金属的标准化安装，根据应用要求实现自动化部署。

应用软件根据业务要求提出性能、网络、负载均衡等业务指标要求，硬件评估和扩容由不可变基础设施统筹管理。

5.3.3 采用微服务框架构建软件系统

采用微服务框架构建软件系统需考虑微服务能力抽取、能力分层、能力构建、能力调用和能力编排等几个方面。

a）微服务能力抽取。主要包括面向客户操作的逻辑控制抽取能力和面向数据存储、计算的对象操作抽取能力。在领域层（软件所关注的主题区域）以单个、场景化的能力为主抽取，微服务不能超过单一职责。

b）能力分层。区分场景和业务原子化能力，构建可复用的原子化能力。复杂逻辑按照业务需求基于原子服务组合能力在应用层实现。

c）能力构建。原子化能力以完成业务的最小操作为目标，需要具备幂等性（任意多次执行所产生的影响均与一次执行的影响相同）；事务能力需要同时提供DO/UNDO 2种，以保障事务一致性。

d）能力调用。面向客户UI 操作的能力要同步调用，如果异步则需要考虑调用过程可视；事务型业务能力调用要按照统一监控要求自动埋点，跟踪标识业务流程；面向后端逻辑处理的能力尽量异步，并提供失败重试机制。

e）能力编排。面向能力规格、能力对象进行能力调用时要设定优先级，以便在资源紧张时优先保障重点客户的重点业务。

此外，在部分业务场景，微服务还需逐步按需引入Serverless、服务网格（Service Mesh）技术。

Serverless 可以细分为后端即服务（BaaS）和函数即服务（FaaS）2 类。BaaS 指任何第三方提供的应用和服务，可通过API的形式开放不同细分领域的功能，比如提供云数据库服务的Google Firebase 和Parse、提供统一用户身份验证服务的Auth0 等，让用户实现“前端+BaaS”完成整体服务的构建。FaaS 应用以函数的形式存在，并由第三方云平台托管运行，函数是比微服务更小更独立的运行单元。应用软件开发业务逻辑，注册触发事件，通过事件触发函数逻辑并执行，后端服务通过调用下沉的中间件服务实现，资源管控由基础设施统一提供。根据需求，应用形态可选择服务形态和函数形态。

作为云原生技术栈的一部分，Service Mesh指由云原生应用的服务化组件构成的一种网格，即在应用内部或者应用之间由服务访问、调用、负载均衡等服务连接关系构成的一种网络。Istio 是目前Service Mesh技术的实施标准，是一个与Kubernetes 紧密结合的、适用于云原生场景的、Service Mesh 形态的、用于服务治理的开放平台。Istio服务治理涉及连接、安全、策略执行和可观察性。在实践中，Service Mesh通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，应用程序无需感知代理的存在。

将业务能力、数据能力等能力微服务化，可实现统一编排、高效复用。

5.3.4 软件系统架构分层解耦

基于分层解耦原则，软件系统采用微服务化架构建设，将业务实现与底层能力构建分离，屏蔽外部变化对业务核心服务能力的影响。软件系统根据本系统的业务特征划分领域构建原子能力，根据层次结构构建功能。每一层设计保持内聚，并且只依赖其下层，上层和下层松散耦合（各自为独立个体，通过简单引用关联）。

采用微服务架构的软件系统分层包括表示层、网关层、应用层、领域层、中间件层以及基础设施层。如前文所述，中间件层和基础设施层由不可变基础设施和统一开放服务化接口的下沉中间件提供。软件系统以领域层为核心构建微服务原子能力。

6 云原生对运营商的意义

云原生对运营商具有重大意义，具体如下。

a）避免软件厂商的绑架。基于微服务的架构解耦使得软件系统从黑盒变为白盒，核心微服务自主掌控；通过定义统一的微服务交互接口，支持实现同一功能的微服务的可替换。

b）支持软件系统的全网统一部署。构建集团级容器镜像库，通过软件镜像的统一下发，实现软件系统的集约管理；支持以微服务为单位的软件升级，降低系统运维压力。

c）助推业务应用创新。容器和微服务可用于支持PaaS 平台的能力开放，实现云服务的增值；容器和微服务有效支持持续集成和交付，加速业务上线。

7 结束语

云原生具备快速交付、容器运行、可靠容错、灵活扩展、自动伸缩、透明通信等特点。本文分析了云原生的关键技术，对云应用进行模型分类并定义了云原生应用，给出了云原生成熟度模型及评估办法，进而结合运营商IT系统上云的需求，阐述了运营商IT系统云原生目标架构及部署要点，包括构建基于容器的不可变基础设施，实现自动化部署、动态扩缩容；下沉中间件，统一开放服务化接口；采用微服务框架构建软件系统；软件系统架构分层解耦等。

运营商IT 系统云原生部署便于运营商自主掌控核心微服务、构建容器镜像库、汇聚全网原子能力池，沉淀数据资产。一方面，可将云网资源及能力通过服务的方式提供给数字化平台，并支持多种服务模式和灵活的商业模式；另一方面，数字化平台可以通过云网基础设施提供的云原生开发能力，灵活构建更高层次的数字化能力并面向行业提供数字化解决方案。