开发团队通过 API 模拟打破关键路径依赖，将串行流程变成了并行。 本文将探讨在哪些地方使用 API 模拟可以产生最有效的影响，并提供了一个模型用于估算 API 模拟和 API 优先开发模式的回报率。 企业软件行业正在从单体系统转向部署在私有云或公有云上的分布式微服务架构。 这种架构转变推动了 API 优先开发模式的发展，不同的开发团队通过 API 来定义业务契约。 在实现与特定 API 耦合的特性之前先定义好契约，让团队能够并行开发 API 的生产者和消费者。 在大多数情况下，为了有效地实现 API 优先模式，需要采用 API 模拟。 请参见下面的图 1，了解 API 模拟是如何被应用在测试当中的。 关于如何在测试微服务时使用 API 模拟以及其他 Test Double 测试技术，请参见“测试微服务：12 个有用的技术（第 1 部分）”。 图 1：微服务架构中的模拟 API 一家 InsurTech 初创公司使用 Golang 和 Python 开发微服务，并部署在 Kubernetes 的 Docker 中。他们使用基于 gRPC 的 API 实现微服务之间的通信。一个开发团队必须等待其他团队先完成 gRPC API 才能开始自己的开发工作，导致团队之间发生时间线堵塞，初创公司无法以客户需要的节奏交付产品。工程副总裁很清楚，他们需要找到一个解决方案，能够让团队实现独立开发。 通过使用模拟 gRPC API，他们消除了团队之间的时间线阻塞。与开源替代方案不同，它提供了复杂的消息模式特性以及最新的协议特性支持。 开发团队使用模拟 API 并行开发他们的 gRPC API，不需要等待服务器端代码就绪就可以测试客户端代码。他们在 CI 构建代理上运行自动化测试套件，模拟 API 就运行在代理上的 Docker 容器中。 我们基于上述的例子创建了一个电子表格，你可以用它计算出采用 API 模拟所获得的回报率。 点击阅读原文下载这个表格。 图 2：两个团队使用 API 模拟之前和之后的对比 图 3：用模型计算不使用 API 模拟的成本延迟 在图 3 中，用户输入是蓝色的，计算结果是黄色的。 图 3 的用户输入包括：
针对这个模型，我们做了一些关键性的假设：
如果这些假设与你的开发流程相匹配，我们很愿意一起讨论一下，并为你们创建合适的模型。 我们已经看到 API 模拟适用于有两个开发团队相互依赖的场景，对于需要多个团队一起开发新产品或新功能的项目，也同样适用。 团队 A 的新功能在发布到生产环境之前需要依赖团队 B 的东西。 图 2 给出了一个描述此种情况的甘特图。团队 B 在开发新功能，他们的 API 在第 20 天才能提供，团队 A 开发的新功能在第 35 天就绪，然后开始做集成测试。最后，新功能在第 37 天部署到生产环境。 假设这两个团队决定采用 API 优先的开发模式，开始定义团队之间的业务契约。他们定义系统之间的 API，并使用了 API 模拟，新功能在第 26 天部署到生产环境。对于这种场景，在团队 B 的部分成员已经开始开发新功能的同时，其他成员和团队 A 的部分成员在几天内定义好系统的 API。通常，团队 A 可以开始培训如何使用 API 模拟，并在大概 4 天的时间里创建好模拟 API。团队 A 有了模拟 API 就可以开发他们的新功能，并在开发完成之后与团队 B 集成，这可能比使用真实 API 要多花一天时间，毕竟模拟 API 不可能完全精确地模拟真实系统，要与真实 API 顺畅集成，需要做一些细小的改动。 要想加快速度，还有另一种选项，就是将模拟 API 外包给第三方供应商。如果模拟 API 外包出去，那么新功能就可以在第 20 天完成。 因为采用了 API 模拟和 API 优先的开发模式，我们加快了发版速度，可以在第 20 天发版，而不是第 37 天。 我们对上面的例子做一个扩展，将两个团队扩展到四个团队。在这个例子中，我们有团队 A、B、C 和 D，它们一起为公司开发一个复杂的功能。 团队 A 负责开发手机号转移功能，他们依赖了手机号客户服务 API，该 API 由团队 B 负责。团队 B 的 API 依赖了手机号查询功能，该功能由团队 C 负责。团队 C 依赖了团队 D，团队 D 负责手机号的第三方服务集成。 团队 A 要等到第 70 天交付他们负责的部分，但他们感到压力很大，他们要等到第 61 天才能开始他们的开发工作，因为团队 B 的功能要在那天才能完成。见图 4。 图 4：四个团队串行开发，共同完成一个大功能 在看了项目计划之后，团队 A 决定提早开始开发工作。他们找到团队 B，与他们一起定义 API。他们创建了模拟 API，在第 43 天就开始开发，而不是第 61 天。见图 5。 图 5：团队 A 和团队 B 并行开发 这样团队 A 就有了更多的喘息时间，因为他们在第 66 天就完成了开发工作，而不是第 70 天。如果其他团队出了什么差错，他们有更多的纠错余地。 在看了更新过的项目计划之后，团队 B 意识到自己是离交付截止日期最近的。他们本来有 10 天时间（距离第 70 天），但现在只有 6 天（距离第 66 天）。他们决定开始与团队 C 并行开发。在与团队 B 沟通过后，团队 C 意识到他们也可以与团队 D 并行开发。这么看来，这个功能应该可以在第 30 天交付，而不是第 70 天。见图 6。 图 6：所有团队都并行开发 值得一提的是，如果有必要，各个团队使用模拟 API 的顺序是可以调换的。例如，如果团队 C 率先使用了模拟 API 并提前几天交付功能，这样就可以降低团队 B 和团队 A 的风险，为后续 API 定义的变动腾出了一些缓冲时间。 由于不可预见的复杂性，计划的时间越长，里程碑延后的风险就越大——你可以尽早使用 API 模拟开始开发工作，将里程碑向左移，并尽早识别出关键风险。 尽管这个模型做了一些关键性的假设，但它所传达的要点在于在采用 API 优先开发模式时如何通过 API 模拟来并行化团队的开发工作。 正如上面的甘特图表所示，这个功能现在可以提前 40 天交付。我们可以在“RESULTS”部分看到这个。 这对那些为初创公司工作的高管来说很重要，因为他们已经向股东或投资者承诺某个功能将在指定日期前准备好。这个模型可以降低交付时间方面的风险，并帮他们实现承诺。 这个电子表格计算出了在 12 个月内没有采用并行开发所造成的延迟成本。 图 7：延迟成本电子表格的 RESULTS 部分 这也可以估算出延迟在企业中采用 API 模拟所造成的价值损失。对于图 7 所示的情况，我们假设当新功能对客户可用时，公司每天应该多赚 5000 美元。我们把 40 天乘以 5000 美元，也就是说，如果他们不采用 API 模拟，公司将损失 20 万美元。假设该公司决定每年花 1 万美元购买付费解决方案，延迟成本也只下降到 19 万美元。在本例中，我们假设公司不只开发这一个功能，相反，在未来 12 个月内将开发三个功能。在这种情况下，由于没有采用 API 模拟和 API 优先的开发模式来交付这些功能，他们可能会损失 59 万美元。 采用 API 优先的开发模式和 API 模拟可以先从一个团队开始。让整个组织都采用这种方法确实是有好处的，但这并不妨碍你先从其中的一个团队开始，设定一个容易实现的目标。 在选择第一个采用 API 优先开发模式和 API 模拟的团队时，可以先确定业务关键特性，在甘特图上列出所有涉及的团队，并选择在进行并行开发时对项目截止日期影响最大的那个团队。 或者，如果你是团队负责人，面临着交付截止日期的压力，就像上述例子中的团队 A，你可以主动让团队采用 API 优先的开发模式和 API 模拟，以此来减轻团队正在承受的压力。 这个 Wiki 页提供了一个对团队十分有用的 API 模拟工具清单。 关于作者： Wojciech Bulaty 专攻企业软件开发和测试架构。他在写作中融入了十多年的亲身编程和领导经验。他现在是 Traffic Parrot 团队的一员，通过提供 API 模拟和服务虚拟化工具帮助微服务开发团队加速交付、提高质量并缩短发布时间。你可以在推特上关注 Wojciech，也可以在 LinkedIn 上联系他。 查看英文原文： https://www./articles/api-mocking-break-dependencies/? |
|
|
