围绕应用的云原生转型建设

以往业务应用的实现有很多难点，导致数字化转型不得不把重心放在应用的基础设施和应用软件架构上。业务应用的实现难点如下。

• 应用架构设计难度大。业务模型到应用软件架构模型之间的转换难度较大。这个转换过程涉及将业务模型中的实体转换成软件领域中的实体。在转换过程中，需综合考虑软件实体间的依赖，同时也要考虑软件工程自有的技术特点，包括网络、计算或存储资源等的特点。

• 应用规模扩展难度大。在以前没有利用云计算能力的时代，实现应用弹性伸缩的技术难度很大，同时为了应对应用规模的变化，不得不提前投入额外的基础设施成本。在云计算时代，硬件基础设施能力的弹性扩展问题已经被云计算厂商解决了。但是，在软件层面上，实现软件应用的弹性伸缩能力仍然有一定的技术难度。

• 应用规模扩展难度大。在以前没有利用云计算能力的时代，实现应用弹性伸缩的技术难度很大，同时为了应对应用规模的变化，不得不提前投入额外的基础设施成本。在云计算时代，硬件基础设施能力的弹性扩展问题已经被云计算厂商解决了。但是，在软件层面上，实现软件应用的弹性伸缩能力仍然有一定的技术难度。

• 应用的跨云扩展难度大。与上一个问题的原因一样，由于应用无法简易地完成跨云迁移，业务应用的跨云扩展也是不可能的。尤其是需要私有云和公有云混合协同的业务，比如在私有云上搭建基础保底的业务运行环境，把公有云作为私有云的资源扩展池，以应对访问风暴和其他特殊的情形。但是，由于跨云迁移的成本和风险很大，导致私有云和公有云都只能选择同一家云服务提供商，即所谓的“同构混合云”。这就导致业务应用上云初期对云服务提供商的选型难度很大，后续的跨云扩展难度就更大了。

• 应用的迭代更新成本投入大、迭代速度与业务变化速度不匹配。在传统应用开发流程和自动化体系成熟度不够的情况下，新业务的上线速度以及创新性业务的迭代更新速度不够快。一方面政企业务需求的更新速度要求迫在眉睫，而另一方面 IT 基础设施和应用开发速度却难以跟上，带来了较大的应用迭代更新和升级成本。

在云原生时代，应用实现的几大难题在很大程度上都得到了解决，具体如下。

• 微服务和领域驱动的架构设计方法成了云原生时代的标准软件架构模型和方法论。领域驱动设计将真实世界的业务模型在软件架构层面上进行了真实的还原。一个领域(Domain)就是一个实际的业务自治域，一个单一的业务实体在自己的业务自治域中被完整地管理，这个业务自治域在软件架构中就还原为单一的微服务。多个微服务结合，就成为整个业务本身。通过微服务架构实现和设计思想，软件架构的设计方法实现了标准化，软件架构的设计难度也大幅降低。

• 容器编排技术在支持业务应用弹性扩展方面有很大的优势。Kubernetes 可以很容易地将单个业务 Pod 进行扩展，扩展的参数指标包括一些默认的指标，比如 CPU、内存利用率等。也支持指标扩展机制，通过扩展可以支持以业务请求速率、接口返回速度等指标作为扩展的锚。Kubernetes 和容器技术成为云原生的标准底层技术，通过标准底层技术，应用在扩展性及故障自愈方面变得很容易。

• 云原生标准对容器及容器周边的技术体系都进行了标准化约束，包括容器运行时标准、容器网络标准、容器存储标准，以及云原生应用所依赖的周边技术，包括中间件、数据库、大数据、日志、监控等，都在规范上给出了指导。基于云原生实现的业务应用，天然具备在各云服务提供商之间进行迁移的能力。如果出现某些云服务提供商的标准化程度不够，那么结果很可能是这个云服务商由于缺乏标准化和规范化支持而导致市场认可程度降低。

• 由于云原生广泛的标准化建设，基于云原生技术开发的应用可以比较方便地做跨云扩展。在私有云 Kubernetes 平台上构建的业务系统，可以较为容易地扩展到公有云上。

• DevOps 推崇业务迅速上线、迅速试错，应用开发和应用运维人员协同工作，大幅加快了应用的开发速度。同时基于成熟的自动化开发、测试、发布流水线，可以最大程度地提升开发速度，加快应用的上线速度，从而促进应用的迭代更新速率，最终体现为业务进化速度的提升。

云原生解决了上面提到的数字化转型的几个底层难题。在云原生时代，政企业务与 IT 基础设施技术之间的技术鸿沟被填平，数字化业务的关注点有条件地转向业务应用。在云原生时代，转型的原则是：以业务应用为中心，以加快业务进化速度为首要目标。