成功迁移到微服务的 5 个关键要素 作者 | Beyang Liu 译者 | Sambodhi 策划 | 闫园园 啊，微服务。 黑格尔的辩证法已经在程序员中形成了一种传统——即 React 与 Angular、Emacs 与 Vim、Tabs 与 Spaces——关于微服务与单体的大辩论还在继续。 一般而言，在初始阶段就“做微服务”是过早的抽象化。所以，大部分的微服务架构都是由单体架构迁移而来。这样的迁移往往是软件企业成功与否的关键。如果你的应用能够很好地迁移，那么当你的应用能够满足更多的用户时，你就有望保持快速的能力。如果你的应用不能很好地迁移，那么你的整个工程团队将会在几个月甚至几年里停滞不前，陷入无休止的工作中，无法实现关键的特性，也会影响到你的扩展能力。 在 Sourcegraph，我们很荣幸地与全球最优秀的工程组织一起工作，并且在很多不同的行业中完成了重要的架构迁移。在这篇文章中，我们将分享一个共同的模板，这是我们在见证哪些是行得通的，哪些不管用的之后发现的。 下面是 5 个成功的大规模架构迁移的关键要素： 1、指定单个所有者并确定所有利益相关者。 2、定义什么是成功，什么不是成功。 3、在不突破的大变化和突破的小变化之间交替。 4、人机回圈的自动化。 5、跟踪进展。 1指定单个所有者并确定所有利益相关者 确定一个团队或者个人来负责推进迁移。通常的做法是选择开发人员体验团队的领导者。他必须理解，眼前的工作并不只是一项技术工作，更应该是各利益相关者之间的协调与沟通。他们会推动改变，这些改变会对很多团队的工作产生影响。重要的是，他们有能力，并且愿意协助这些团队了解改变的重要性，并且在这项工作中寻求他们的合作。 从策略上讲，所有者应该及早地确定出所有需要投入的利益相关者。这样做可以保证，所有的利益相关者都会对这项工作表示支持，这样才能保证利益相关者能够支持他们所做的工作，而不会觉得自己没有付出就会被强制执行。利益相关者名单中应当包含所有需要修改的代码所有者。在这个过程中，你的编辑器或者代码浏览器的“查找引用”这一特性就是你的得力助手！ 找到代码中所有需要改变的位置，并确定它们的所有者。接下来，把你需要批准的所有者的名单或电子表格列出来。 2定义成功 为迁移的最终状态设定一个明确的愿景，并把它和你希望达到的目标相关联。很多大规模的迁移之所以会拖延，是因为最初的目标没有明确定义。如果迁移被拖延，并且不清楚终点线有多远，那么迁移也可能被抛弃。 定义最终状态还能帮助你证实需要进行更大的改变，从而带来真正的改变。避免渐进主义的惯性，选择一个能反映出你真正的架构目标的期望的最终状态。比如，如果你的目的是将单体的主要组件进行模块化，那么一些相当大的变化就有必要。如果你想把自己限制在局部的、保守的变化，就不可能实现你的目标。 下面是从某些大规模迁移计划文档中的范例中得到的模板： 一个示例架构图，显示了正在实施的高级更改。 与你在步骤 1 中创建的利益相关者名单分享这份文档。反馈目标有二： 1、反馈将通过指出某人无法预见的困难来改进建议。 2、反馈会增强利益相关者的认同感，因此可以跟踪整个代码库上的变更。 3在不突破的大变化和突破的小变化之间交替 一旦你确定了最终状态，就可以将它分解成更易于管理的中间里程碑。在你的路线图中，要避免做出大的、破坏性的、不可逆的变化。这些类型的变化会扰乱开发，或在很长一段时间内降低生产环境。 一种常见的模式是，在保留 BackCompat 时，交替地做出大规模的变化和突破性的、小规模的、原子性的变化（最好是可逆的）。将按下列步骤循环完成很多工作： 1、构建一个新的服务而不需要更改现有的系统。 2、在新旧代码路径之间进行条件化的转换。（这会导致新接口或者特性切换，或者仅仅是一个简单的 if 语句）。 3、进行一些小规模的、突破性的变化。（例如，切换接口的实现或者翻转特性的切换）。最理想的情况是，你已经设计好了，当发生错误时，你可以轻松的进行回滚。 4、清理不再使用的旧代码。 在迁移的过程中，这个循环可能会重复一至数十次。如果单体规模足够大，足够复杂，整个迁移过程要花费数年才能完成，这种情况并不少见。如果是这样的话，你一定会想要更短期的中间里程碑，让开发环境和生产环境都处于工作状态。 特性标记是一种常见的方法，可以使突破性的变化变得很小，而且具有原子性。 4人机回圈的自动化 迁移循环中的第 2 步（添加条件切换）和第 4 步（清理旧代码）通常涉及在整个代码库中进行大规模的简单重构。你会希望将那些步骤自动化，不然将会成为一件令人厌烦的事情。 首先，尝试在一两个地方手动进行必要的改动，以了解哪些地方需要自动化。 然后，在整个代码库中扩展这一变化。 重要的是，你使用的工具可以提供反馈和调整，因为总是会出现你没有预见到的边缘情况。 在微服务迁移中，经常会有很多地方需要做一些简单的改动。自动化能帮你做一些繁琐的工作，但重要的是要保持人机回圈，因为有时候这些改变会有细微的差别，或者你要和那些已经更新代码的团队进行交流。 以下是我们所见过的用于指导这种大规模迁移的工具： 专门的脚本，克隆受影响的仓库，并使用命令行代码修改工具（如 sed、codemod 或 Comby）来应用变化。 内部工具，如谷歌的 Rosie。 Sourcegraph 的 Batch Changes。 5跟踪进展 最后，跟踪最终目标的进展。工程领导、在代码库中工作的开发人员，以及来自产品、销售和其他部门的利益相关者都想知道迁移的进展情况，特别是如果它阻碍了他们关心的其他产品开发工作。 你会希望在两个层面上跟踪进展： 1、每一个中间里程碑的进展，每一个里程碑都可能涉及许多代码审查，所有受变化集影响的团队都必须批准。 2、总体最终目标的进展，这可能需要几个月或几年的时间。如果你不清楚地定义这个进展表，你将浪费大量时间向越来越质疑的利益相关者解释和沟通进展。 跟踪迁移进展的一种方法是使用燃尽图。 燃尽图可以跟踪单个变更活动的进展，但许多微服务迁移会被分解成多个里程碑。为了跟踪实现目标架构的总体进展，在代码中绘制指示使用旧架构和新架构的模式的出现情况可能会很有帮助。 6这与旅程无关 当涉及大规模重构和迁移时，真正的问题是定义你的目的地，并尽快到达那里——得到所有利益相关者的支持。好消息是，许多组织已经进行了这种迁移。这 5 个成功的单体到微服务迁移的要素来自我们所合作的一些最好的工程组织的集体经验。很明显，他们已经吃过不少苦头。让我们从中汲取教训。 作者介绍： Beyang Liu，Sourcegraph 的首席技术官和联合创始人，Sourcegraph 是开发团队的代码智能平台，让更多的人可以使用编码。在加入 Sourcegraph 之前，Beyang 是 Palantir Technologies 的软件工程师，为财富 500 强公司开发新的数据分析软件。Beyang 在斯坦福大学学习计算机科学，他在斯坦福大学人工智能实验室发表了概率图模型和计算机视觉方面的研究论文。 原文链接： https://about.sourcegraph.com/blog/monolith-microservices-migration/ 你也「在看」吗？??