1.3 云原生给组织带来的变化

云原生是软件行业的主要趋势，重新定义了现代企业的软件开发运维方式。拥抱云原生应用程序意味着要改变思考、开发和部署应用程序的模式，这种转变不仅是技术应用或观点上的升级转变，更关乎整个体系流程、开发模式、应用架构、运行平台等方面的升级转变。

1.3.1 体系流程的变化

云原生技术的持续演进，要求企业在业务应用建设的体系流程上做出巨大改变，即逐渐实现从产品功能独立到体系化流程设计的转变。

在传统IT环境下，传统IT模式均基于独立的产品进行功能实现，以满足企业业务要求，即通常会将各个产品进行独立部署和离散管理，然后通过各个产品功能组合完成业务逻辑。

在云原生环境下，云原生模式更加强调多层级、体系化、流程化设计，以实现针对业务的稳态运行和灵活扩展：通过将各个层级的产品进行系统集成，使之成为交互式、体系化平台，同时基于企业业务流程需求进行流程规则设计，然后将各类产品构建成云原生平台的基础功能组件，形成完整的支撑体系。

体系化设计能够保障业务资源供给的全面性，流程化设计能够保障业务构建的各个环境自动化地实现高效扩展。

1.3.2 开发模式的变化

云原生改变了开发模式，使原有的瀑布开发模式逐步转变为DevOps研发运维一体化的开发模式，为组织带来了新的关键能力。下面我们来了解一下开发模式的演变进程。

1.瀑布模型

传统的瀑布模型是一种将软件开发分解为有限阶段的模型，通常开发流程为“需求—设计—编码—测试—交付”，如图1-1所示。只有在前一阶段完成后，开发才会进入下一阶段。在这种模型下，各个阶段不会发生重叠。

基于瀑布模型进行软件开发，需要具备非常可靠的工作逻辑，一个项目分为多个阶段，在每一个阶段内都需要投入相应的资源来完成本阶段的工作。从一个阶段到下一个阶段，都有明确的输入和输出，不同的阶段根据所需进行输入，在完成工作活动之后，输出本阶段的产物，将其输入下一阶段的工作中。

然而瀑布模型对软件开发有着诸多的限制，比如用户需求必须表达全面并且准确，代码编写必须高效并且稳定，测试工作必须全面覆盖使用功能，

交付环境必须稳定可靠等。任何环节出现偏差都可能导致软件项目交付失败，这种弊端也促使开发模式由瀑布模型走向敏捷开发模型。

2.敏捷开发模型

敏捷开发模型是一种迭代的、基于团队的开发模型，如图1-2所示。这种开发方式强调团队以完整的功能组件快速交付应用程序，所有的开发时间都被“固定时间段”划分为“迭代阶段”，每个应用程序的迭代周期都有一个确定的持续时间（通常以周为单位），交付物根据客户确定的业务价值进行优先级排序。如果迭代中的所有计划工作都不能完成，那么工作将被重新排序，这些信息将用于未来的迭代计划。当工作完成后，项目团队和客户可以通过每日构建和迭代演示对其进行审查和评估，敏捷开发更依赖于整个项目中水平非常高的客户参与，尤其是在评审期间。

在敏捷开发模式中，项目团队大多时候都无法了解到全部内容，或者即使了解到了，项目团队也无法保证这些内容是固定不变的。所以他们先根据主开发路径，在完成主要功能后，通过不断地迭代，完善对应的工作。这样当项目产生变化的时候，项目团队推翻的工作量很少，可以很快地去完成新的需求变更。通过这样不断地变更、重构，他们容易开发出客户相对满意的产品。

在高举效率与拥抱变化的大旗之下，敏捷开发模式似乎就是最好的开发模式，然而高效敏捷的软件交付为运维保障带来了诸多挑战。比如，敏捷开发更加强调对客户需求的快速实现，而运维更加强调客户业务的稳定运行，双方需要大量的信息交互才能完成高质量的软件项目交付和运维保障工作，因此新的DevOps开发模式呼之欲出。

3.DevOps开发模式

DevOps开发模式是一组过程、方法与系统的统称，用于促进开发、运维和测试部门之间的沟通、协作与整合，如图1-3所示。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”流程，DevOps能使软件构建、测试、发布更快捷、更频繁，也更可靠。

在DevOps模式下，开发和运维团队不再“孤立”，整个软件开发生命周期的流程遵循“从最初的软件规划到编码、构建、测试和发布，再到部署、运营和持续监控”，这种关系改进了“开发、测试、部署”这一持续的客户反馈循环，这种循环象征着整个生命周期中持续协作和迭代改进的需要。在理想情况下，DevOps意味着IT团队编写的软件完全符合用户的要求，在不浪费任何时间的情况下进行部署，并在第一次尝试进入生产环境时就能以最佳状态运行。

DevOps得益于敏捷开发模式在提高开发速度方面的成功，同时也意识到了开发和运维团队之间、IT和组织业务之间的严重脱节阻碍了敏捷软件向用户的交付进度。为了按时交付软件产品和服务，开发和运维团队必须更加紧密地合作。当一个组织同时使用DevOps和敏捷开发模型时，开发和运维团队都可以在整个软件开发生命周期中管理代码。

除了打破开发和运维团队之间的沟通和协作障碍，DevOps的核心价值是客户满意度和更快的交付价值，推动业务创新和持续改进流程。DevOps模式再次给开发模式带来了全新的改变，让研发能够更加精准、稳定、持续交付客户业务价值。DevOps模式已成为主流的软件开发模式，被定义为云原生“三驾马车”之一。

1.3.3 应用架构的变化

云原生快速发展改变了软件应用的架构：由原来的单体应用架构逐步迈向微服务体系架构。

在传统的企业系统架构中，针对复杂的业务需求通常使用对象或业务类型来构建一个单体项目。在项目中通常将需求分为三个主要部分：数据库、服务端处理和前端展现。

在业务发展初期，由于所有的业务逻辑都在一个应用中，开发、测试、部署都比较容易且方便。但随着企业业务的发展，系统为了满足不同的业务需求会不断为该单体项目增加不同的业务模块。同时，随着移动端设备的发展，前端展现模块已经不仅局限于Web形式，这就要求系统后端向前端的支持需要更多的接口模块。

不断新增的业务模块让单体应用变得越来越臃肿，单体应用的问题逐渐凸显出来。由于单体系统被部署在一个进程内，企业即便是要修改一个很小的功能，在将其部署上线后也可能会影响其他功能的运行。此外，由于单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同，对于资源的利用又互相影响，这就导致企业很难对各个业务模块的系统容量给出较为准确的评估。所以，虽然单体系统在初期可以非常方便地进行开发和使用，但是随着系统的发展，维护成本会变得越来越大，且难以控制。

通常情况下，服务由多个模块组成，各模块间会根据自身所提供的功能不同而具有一个明确的边界。在编译时，这些模块将被打包为一个整体的软件包。这种将所有的代码及功能都包含在一个软件包项目中的组织方式被称为Monolith（单体应用）架构模式，如图1-4所示。单体应用将带来以下四个主要问题。

● 人力负债严重：大型单体应用建设，要求团队中的每个人员必须对项目有整体、清晰的目标认识，这就需要项目管理人员、软件架构人员与团队中的各个成员都进行沟通说明，以保证团队人员充分理解项目。在大型项目建设过程中，人员投入数量庞大的情况往往比较多，这也产生了大量的人员沟通成本。而且，大型单体应用建设项目要求关键核心技术人员必须要稳定，由于大型项目的功能、性能、场景的设计内容非常复杂，各个软件模块间的关系非常密切，关键技术人员的人力价值尤为突出，一旦核心人员出现变化，就会带来严重的软件交付风险和后续维护保障问题。综上所述，大型单体应用建设的人力资源负债非常严重。

● 运行维护麻烦：在单体应用建设项目中，即便更改一行代码，运维也需要重新编译、打包整个项目。如果代码量多，那么每次都需要花费大量的时间重新编译、测试和部署，而且，每次编译、部署都会造成业务模块下线，影响业务的持续运行。

● 技术选型固定：随着项目日益庞大，为了能满足更多需求，所使用的技术也会越来越多，但是有些技术之间是不兼容的。例如，在一个项目中大范围地混合使用C++和Java几乎不可能。在这种情况下，就需要停止使用某些不兼容的技术，选择一种兼容性更强的技术来实现特定的功能。

● 可扩展性差：单体应用建设项目的代码通常会产生一个包含了所有功能的软件包，因此，在对服务容量进行扩展时，只能重复地部署这些软件包（集群）来扩展服务能力，而不能只扩展出现瓶颈的某一个模块。也就是说，在单体应用中多个模块的负载不均，导致扩容高负载的模块时，也对低负载的模块进行了扩容，极大浪费了资源。

为了解决单体系统日益庞大、臃肿所产生的维护难等问题，微服务架构应运而生。

微服务架构是一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、配合，为用户提供最终价值，如图1-5所示。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并能被独立地部署到生产环境、类生产环境中。

由于每个服务都运行在自己的进程内，在部署上有稳固的边界，因此，每个服务的更新都不会影响其他服务的运行。同时，由于是独立部署的，运维人员可以更准确地为每个服务评估性能容量，通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，并给出较为准确的系统级性能容量评估数据。

一个大型复杂软件应用由多个微服务组成。应用中各个微服务可以独立部署、高度松耦合，仅关注于完成一种服务。因此，微服务架构存在着一些明显的优势，如下所示。

● 人力负债很轻：在微服务架构下，复杂的软件功能被分解成很小的微服务颗粒，软件开发人员无须关注项目中的整体功能模块，可以更加聚焦于局部的功能实现。因此，微服务架构能够极大地降低人力交流成本和理解学习成本，更加易于大型软件项目的设计和交付。微服务建设更加强调通过将小的服务颗粒进行组合，形成完整的业务应用。各个开发人员所负责的开发模块相对集中，对开发人员的技能水平要求也较低。因此，即使人员出现变化，技术交接和人员学习的成本也较低。所以，运用微服务架构进行软件研发的人力负债很轻。

● 复杂度可控：在微服务架构下，研发人员在将应用分解的同时，规避了原有的复杂度不断积累等问题。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务都可以由一个小规模开发团队完全掌控，易于保持高可维护性、提升开发效率。

● 灵活独立部署：由于微服务具备独立的运行进程，所以每个微服务都可以独立部署。当某个微服务发生变化时，无须编译、部署整个应用。由微服务组成的应用具备流程并行发布的优势，让发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

● 技术选型灵活：在微服务架构下，技术选型过程是去中心化的。每个团队可以根据自身服务的需求和行业发展现状，自由选择最适合的技术栈。由于每个微服务都相对简单，因此在技术栈进行升级时面临的风险也相对较低，甚至完全重构一个微服务也是可行的。

● 容错性好：当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，导致软件应用出现全局不可用的情况。在微服务架构下，故障被隔离在单个服务中，若设计良好，那么其他服务可通过重试、平稳退化等机制实现应用层面的容错。

● 扩展性好：单体架构应用也可以实现横向扩展，即通过将整个应用完整地复制到不同的节点上来部署实现。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务都可以根据实际需求进行独立扩展。

如今，随着企业以闪电般的速度开发应用程序，技术趋势已经从传统的单体Web应用程序开发转向现代微服务开发，这让组织能够以更快的速度发布或更新应用程序。

1.3.4 运行平台的变化

如今，企业业务应用建设方式正在改变：逐步从原来基于业务需求的独立资源配置方式，转变为运用云资源和云服务的灵活编排部署方式。

原有的云业务模式通常基于IaaS、PaaS、SaaS等进行层级建设，这种自下而上的层级建设为业务运行提供了稳定的保障。但是，随着互联网业务量的激增，业务对资源灵活编排的诉求日益强烈，促使云平台逐步朝着业务流量管理运营的方向动态转变。

基于IaaS、IPaaS、APaaS、FaaS等不同层级的云资源层出不穷，面对不同的业务，各平台亟需具备快速配置的能力。当前，以Kubernetes作为资源编排组件的云原生平台，以业务流量作为运行平台资源分配条件的方式，都开始日益流行，云原生运行平台的工作负载方式也正在发生改变。

---

[1] 无服务器，一种架构模式和服务模型，让开发者无须关心基础设施，仅专注于应用程序业务逻辑。