10分钟了，总算是搞懂了微服务交付：交付演进历程进阶，直接拿捏

早期的软件交付模式

从软件过程模型的变化，我们可以发现，软件工程开发过程最早借鉴了建筑行业。建筑行业的特点是施工周期长，工种众多，涉及的专业分门别类，从开发商到工程设计师，从实施建设的工人到质量监理等。而建筑行业的工作流程是把项目分为不同阶段，每个阶段每个流程都由不同的专业人士负责，而且各阶段之间还要保持严格的顺序性，下图是瀑布模型交付阶段的分解过程。

软件最早的瀑布模型正是借鉴的这一流程方式，成为软件开发早期（20世纪80年代）事实上的软件交付标准。而这一流程本身存在诸多问题，例如项目前期投入巨大，导致后期被取消，50%以上项目预算需要翻倍等。增量模型本质上是基于瀑布模型的构建方式，这一软件交付主要模式的特性如下图所示。

敏捷开发模式

在软件最后交付阶段，瀑布模型很难对前期设计或者构建进行根本性的改动，这是导致采用软件失败的根本原因。如果前期无法确切知道要构建怎样的产品，就无法保证每个阶段的正确性。而软件工程与建筑行业有很大不同的地方是，软件的变更是很容易的，而实体建筑的每个阶段都需要缜密的设计，否则返工的成本是巨大的。软件变更后的构建并不困难，所以我们可以把软件开发的迭代过程分割成更小的周期，这样就可以在分解后的每个小周期中检验和改进，有利于减少返工，如下图所示。

敏捷开发的方法论和过程模型强调，软件应该灵活应对变化。敏捷开发的核心价值观是：互动交流高于需求规格文档设计，软件架构师无法在软件开发的初期就设计完备的架构解决方案，而是将分析、设计分解到每个小的迭代开发周期中，给软件开发工程师赋予更高的责任，这样软件架构师不再是软件过程的瓶颈，而一线开发人员在面临挑战时可以提出更好和更切合实际的解决方案。在敏捷开发方法论中，项目的范围也是随着实际情况而变动的，时间和成本估计可以根据交付物通过大致推算得到，前期无法给出实际的价值评估和判断，敏捷开发的主要软件交付模式的特性如下图所示。

持续集成/交付（CI/CD）

我们看到敏捷开发方法论的软件过程模型解决了项目响应变化的问题，但客户还是无法体验产品，并获得实际的反馈，我们还需要面对频繁的测试集成和交付的挑战。

持续集成的好处是我们的代码在任何一个小的阶段中都是可供部署的，所以我们可以在更早的阶段验证软件的局部功能是否满足用户的期望，也可以及早发现软件潜在的问题，解决问题的成本也会更低，而软件集成和软件交付往往是可重复的工作，如果在每一次迭代中，我们都将这些测试、交付的工作自动化构建，将极大地提高生产率，开发工程师也可以将主要精力投入到业务的实际逻辑和业务功能中。

持续部署的好处是可以更快地发现软件的问题，也可以引入功能发布控制机制。我们可以把部分功能通过标识进行状态管理，例如A/B测试，进行量化的用户效果评估，这让我们可以更精准地验证用户的需求，也可以进一步改善产品，如下图所示。

在持续交付过程中，需求以小批量的形式在团队的各个角色间顺畅流动，并在较短的周期内完成小粒度的频繁发布。实际上，频繁的交付不仅能持续为用户提供价值，还能产生快速的反馈，帮助业务人员制定更好的发布策略。该交付模式的特性如下图所示。

 

本文给大家讲解的内容是微服务交付：交付演进历程进阶

1. 下篇文章给大家讲解的内容是微服务交付：微服务如何持续集成交付？
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！