2.1.1　降低研发成本和项目维护复杂度

首先，云原生架构大幅度降低了研发成本和项目维护复杂度。

总的来说，任何应用都提供了两类特性：功能性特性和非功能性特性。功能性特性由为业务实现带来直接价值的代码实现，比如，如何建立客户资料、如何处理订单、如何安全支付等，即使是一些通用的业务功能特性（比如组织管理、业务字典管理、搜索等），也是紧贴业务需求的。而非功能性特性是指虽不能为业务实现带来直接价值，但又必不可少的特性，比如，高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。

图2-1展示了在传统架构和云原生架构中代码通常包含的三个部分：非功能性代码、业务代码和三方软件调用。

其中，“业务代码”指实现业务逻辑的核心代码；“三方软件调用”指业务代码中依赖的所有第三方软件库，包括业务库和基础库；“非功能性代码”指实现高可用、安全、可观测性等非功能特性的代码。

在以上三个部分中，业务代码最为核心，能真正为业务带来直接价值，另外两个部分都用于支持业务代码的实现。然而，由于软件和业务模块规模扩大，部署环境趋于繁杂，分布式复杂性增强等，为了应对这些变化带来的挑战，应用中的支持型代码在整个研发流程中的占比越来越大，这直接导致了软件构建变得越来越复杂，对开发人员的技能要求越来越严苛。

相较于传统架构，云原生架构强调业务研发应充分利用云平台所提供的IaaS和PaaS的通用能力。虽然云计算不能解决所有的非功能性问题，但是云平台确实能够处理大量的非功能性问题，特别是分布式环境下的复杂非功能性问题。以最具挑战性的高可用性为例，云平台在多个层面为应用提供了解决方案，具体说明如下。

（1）虚拟机层面

当虚拟机检测到底层硬件异常时，可以自动将应用热迁移，且迁移后的应用无须重新启动就具备对外服务的能力，应用对整个迁移过程甚至都不会有任何感知。

（2）容器层面

有时，虽然应用所在的物理机运行正常，但应用由于自身的问题（比如，出现Bug、资源耗尽等）而无法正常对外提供服务。对于这种情况，如果采用容器，就能够通过监控探测到进程的异常状态，从而实施异常节点下线、新节点上线和生产流量切换等操作。整个过程自动完成，无须运维人员人工干预。

（3）云服务层面

云服务具备极强的高可用特性和7×24小时服务能力，如果应用把“有状态”部分（如缓存、数据库、对象存储等）全部交给云服务，加上进程内存中全局对象的持有小型化和应用快速重构能力（比如基于快照快速恢复到最新状态），那么应用本身就会变成更轻量的“无状态”应用，从而使可用性故障造成的业务中断时间降至分钟级；如果应用采用的是N-M对等架构模式，那么结合负载均衡产品则可获得几乎无损的高可用能力。

借助云原生架构，业务研发可以降低原本大量耦合的非业务逻辑占比，缩减业务代码开发人员的技术关注范围，并通过云平台提供的服务提升应用的稳定性和可持续发展性。