增量迁移的重要性

If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang.

——Martin Fowler（《重构：改善既有代码设计》的作者）

如果已经确定拆分现有的单体系统是正确的选择，我强烈建议每次抽取一点点功能，逐步拆解这些单体应用。这种增量迁移的方法将帮助我们在实践中了解微服务，同时还可以限制所犯错误的影响面（我们肯定会在迁移过程中犯错）。可以把我们的单体应用视为一整块大理石。我们可以一下就把整块石头炸碎，然而这样的方式很少有完美的结局。采用蚕食的方法则更为明智。

问题在于，将可拆解的单体系统（nontrivial monolithic system）^译注1迁移到微服务架构的尝试成本可能很大，而且如果我们一次完成所有的操作，我们很难从迁移中得到良好的反馈——哪里是正常的，哪里是异常的。将迁移过程拆分为很多更小的步骤则会让迁移更容易，我们可以分析每一个迁移步骤并从中学习。正因如此，在敏捷出现之前，我就一直是迭代交付的忠实拥护者——因为我承认我会犯错误，因此我需要一种方法来降低错误的级别。

任何迁移微服务架构的操作都应谨记如下的原则：

• 将宏大的工程拆分成很多小的步骤
• 拆分之后的每个步骤都可以执行并从中学习
• 如果某一步被证明是错误的，则这也仅仅是一小步而已
• 对于每一步而言，无论对错，我们都可以从中学习，然后为我们的下一步骤提供信息

如前所述，将事情分解成较小的部分还可以让我们识别出快速成果并从中学习。这会帮助我们让下一步变得更容易，同时也帮助我们提升工作动力。通过一次拆分一个微服务，我们无需等待大规模的部署，同时还可以逐步释放微服务带来的价值。

对于为正考虑微服务的用户提供的建议而言，增量迁移已经成了最优先的建议。如果我们认为这是个好主意，那么就从小处着手。选择一两个功能领域，用微服务实现他们，将其部署到生产环境，并思考其是否有效。在本章的后面部分，将提供一个模型，该模型可以确定应该从哪些微服务开始迁移。

至关重要的是部署到生产环境

需要特别注意的是，只有把抽取的微服务部署到生产环境并使其发挥作用时，整个抽取工作才是完整的。增量抽取的部分目标是使我们有机会学习和理解拆分本身的影响。只有在服务投入生产环境之后，我们才能学习到大多数的重要经验。

微服务拆分可能导致很多问题，例如：定位的问题，链路跟踪的问题，延迟的问题，参照完整性^译注2的问题，级联故障的问题……。 其中的绝大多数问题只有在微服务投入生产环境之后才会出现。接下来的章节，我们将研究部署到生产环境时限制问题发生的影响的技术。如果我们进行较小的更改，发现（并修复）迁移产生的问题就会更加容易。

^译注1. 在线性代数中，非平凡解是齐次方程或齐次方程组的非零解。对应的，平凡解就是显而易见的解、没有讨论的必要但是为了结果的完整性仍需要考虑的结果，例如0解。因此，非平凡的单体系统意味着该系统可以拆解。 ↩

^译注2. 参照完整性是关系型数据库的完整约束之一，属于数据完整性的一种，其余的完整性约束还有：实体完整性、用户自定义完整性。 ↩