在这个系列里，我们列出了一组原则，帮助您判断何时使用微服务才是更有效的框架。今天我们来细讲一下第2个原则：独立的生命周期。
独立的生命周期这个概念很大。前面讨论的多个变更速度是这个概念的一部分。我们经常发现代码的某些部分需要独自提交到生产流程，这种情况以及微服务如何提供帮助呢？
一体化方法通常会阻碍我们快速交付、运行A/B测试和了解用户的能力。回想一下Widget.io这个示例，如下所示：
在我们假设的场景中，企业领导找到了需要加速推向市场的新商机。一般的一体化应用无法让我们以足够快的速度迭代，所以我们让“项目X”成为独立的微服务。“项目X”有自己的代码存储库和部署流水线，因而具有独立的生命周期。随着我们对业务商机的了解加深，这将帮助我们发展“项目X”。
独立的生命周期提高开发人员的工作效率
快速上市并不是我们为模块部署独立生命周期的唯一原因。我们还可以提高开发人员的工作效率！
很少有开发人员会说一体化应用能帮助他们高效工作。他们需要吃力地阅读冗长的开发人员设置指南。构建需要很多天，开发人员可能需要几个月才能快速上手一个项目。缩小范围之后，开发人员可以只用一两天的时间埋头于微服务，用几分钟或更短的时间内完成构建。如果构建中断，工程师马上就会知道，他们可以立即采取措施修复问题。
代码库更小也意味着测试微服务变得更加简单。
Spring Cloud Contract等工具可以帮助我们确保服务运行良好，并能与其他服务有效配合。不必应付一体化应用80小时的回归套件。相反，可以针对微服务构建一组精细的测试，在每次提交时执行。我们可以将合适的工具和技术用于指定微服务的各个环境，而不是使用“一套方案，全不适合”的测试方法。我们可以对微服务进行持续审查，而不是进行一次性的性能测试。如此一来，代码的质量大大提高。
从代码到生产：两个生命周期的“双城记”
让我们更具体地从生命周期的角度来比较一下一体化应用和微服务，也就是新代码如何从开发人员的笔记本电脑进入到生产环境。
就在不久之前，许多IT部门采用的都是单一软件开发方法。项目以典型的瀑布式方式进行，每季度或每年发布一次。代码可能需要有一两个评审委员会的签发才能投入生产。这似乎非常符合逻辑，但这通常会导致员工焦虑，在夜晚、周末不眠不休地加班，就像打仗一样。共享的生命周期意味着每个模块都受到从“提交到生产”这一过程耗时最长的模块的限制；还意味着每一行代码都经历了同样的流程，无论哪些阶段最适用都是如此。
微服务的意义就在于灵活性，包括自定义的部署流水线。我们再也不必推动每一行代码经过完全相同的环节。同样，微服务让我们能够针对工作选择最适合的技术，还可以针对每个微服务自由组合使用合适的测试、代码检查工具和代码质量扫描。
精细的组件（即微服务）还让我们能够更轻松地与架构目标保持一致。在重构代码时，不违反架构的关键要素至关重要。但我们如何确保以小型独立团队的形式开展工作的很多开发人员遵守这一点呢？答案在于适应度函数（fitness functions），脱胎于进化计算，让我们能够从根本上测试架构。对于每个微服务，我们可以选择合适的适应度函数来确保设计的发展支持关键质量属性。
假设驱动型开发
独立的生命周期让我们的生活更美好，也让我们针对软件的发展方式制定更明智的决策。在我的职业生涯中，关于指定场景的潜在解决方案，我与软件工程师同事们和客户们曾有过无数次辩论。虽然大家总是能提出很有力的观点，但很难获得数据。我们只能根据所知的少量信息以及怀着对最好结果的期待来制定决策。
当然，即使我们错了，漫长的部署周期导致我们在几个月后才能改变路线。这些限制让我们变得保守。我们不敢尝试打破常规，以免疏远用户。
预测很难，特别是预测未来。——Niels Bohr
假设驱动型开发这种科学方法非常简单。基于您的观察形成假设，然后设计实验来测试这个理论。如果我们将高中的科学课程运用到软件中，会怎么样呢？通过利用假设驱动型开发，我们可以围绕软件制定更明智的决策。独立的生命周期让这成为可能！
通过从传统的用户故事中获取提示，我们可以得到类似以下的内容：
例如：
我们通常可以将这种结构转化成适应度函数，并定期对代码执行这个函数。
当一项服务有自己的“提交到生产”流程时，我们可以运行多个试验来响应实际结果，而不是花费大量时间争论未来。如今，Google和Amazon等公司每天会运行多个试验。它们不断执行A/B测试，从而得到有关指定设计对关键指标的影响的硬性数据。哪些客户不希望持续改进产品，以便与需求更紧密地契合呢？从更实际的角度来说，哪些公司不希望交付这种服务呢？这就是微服务如此受欢迎的另一个原因！
掌握微服务的独立部署流水线
当然，您的微服务还是要运行。这就引发了几个有趣的问题：如何让服务正常运行？如何知道可以信任它们？
当我们称一个应用或微服务是“生产就绪”时，我们对它寄予了极大信任，即我们相信它能够以可靠的方式运行并完成工作。
——Susan J. Fowler
关键在于部署流水线。
部署流水线为我们提供了稳定的生产路径。如果只部署一两次，您无法成为指定任务方面的专家。知识在重复中不断增加，频繁部署，您就培养了数字肌肉记忆。如果只随机对代码进行单元测试或检查，我们就不会有太大的提高。如果在每次提交时都让代码完成同样的过程，我们就制定了一个值得信任的流程。
要确保我们部署到生产环境的代码符合预期，那么它应该通过严格的流程。Concourse、Visual Studio Team Services和Jenkins等工具可以帮助您创建稳健的流水线。我们可以设计合适的“门槛”，相信我们的代码可以战胜挑战。
这些流水线曾经是定制的一次性成果。如今，我们能够以Spring Cloud Pipelines或dotnet-pipelines等项目作为起点。通过遵循build/test/stage/prod flow流程，我们可以在环境中快速部署和运行。由于缩短了“从构想到生产”的周期，我们可以确信，代码会发挥我们期望的功能。
总结
上市速度关乎公司的成败。因为“我们一直都是这么做的”而坚持陈旧的流程，这是失败的一个原因。所幸，我们在2018年提供了经过验证的模式和实践，能够帮助您缩短上市时间！
考虑到快速迭代的需要，独立的生命周期可能是微服务架构得到最少赞赏的优势之一。找出代码中哪些部分需要有自己的“提交到生产”流程，可以成为一种宝贵的学习方式。
独立的生命周期只是微服务谜题的一部分！我们会在这个系列的下一部分介绍“独立的可扩展性”，敬请期待。
查看往期系列文章：
-
【干货分享连载一】微服务那么火，我也该用微服务吗？
-
【干货分享连载二】微服务那么火，我也该用微服务吗？
点击阅读原文查看英文博客
