Postman公司微服务最新实践

2018 年，Postman 首席技术官和联合创始人 Ankit Sobti 分享了 Postman 如何《摆脱微服务依赖困境》。为什么 Postman 冒险进入微服务领域以及如何进入这个领域，如果你想了解更多信息。不妨看下 Ankit 的故事。

https://medium.com/better-practices/conquering-the-microservices-dependency-hell-at-postman-with-postman-part-1-introduction-a1ae019bb934

本文是关于最新进展，介绍 Postman 工程部门现在是如何做微服务的。

Postman 工程部门在全球 8 个地区拥有 100 多名工程师。这家公司刚刚宣布了 C 轮融资，因此，事情的发展必然会和任何成长中的初创公司一样。

让我们深入了解一下这些团队是如何组织的。我们很快就会看到，这确实会影响到微服务的实现。

根据康威定律，软件开始的时候看起来像创建它们的组织。人们交流、协作的方式，甚至他们的工具都会对其产生影响。相关团队之间信息流动的方式也会影响输出。

设计的结构受制于组织的沟通结构。——康威定律

这就是为什么像亚马逊和 Netflix 这样的公司都以小而独立的团队开展工作。它支持 API 优先的设计和开发，并且两家都是有名的微服务 deathstar。

https://medium.com/better-practices/api-first-software-development-for-modern-organizations-fdbfba9a66d3

微服务deathstar

你可以按照职能、产品或工作流对团队进行分组，通过比较这些团队的产品来观察康威定律。

按照职能、产品或工作流对团队进行分组

如何利用这一现象？

Inverse Conway Maneuver 建议通过改变组织结构来获得你想要的技术结构。通过规定组织的沟通协作方式，来实现理想的设计。

https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver

请记住这一点，在 Postman，开发团队被称为小分队（squads）。小分队根据领域驱动设计（DDD）原则开展工作，这让每个小分队都能专注于自己的核心领域。

例如，一个小分队拥有 Identity 领域。Identity 小分队提供诸如创建用户和认证用户等服务。

示例：拥有 Identity 领域的小分队创建的服务

在我们整个公司里，12 个小分队为 Postman 工程提供了 40 个服务。在大多数情况下，每个团队都独立管理他们的路线图和 sprints。他们可以自由地选择工具和配置工作流。

虽然小分队专注于特定的服务，但他们是跨职能的，成员来自设计、产品、工程、安全、质量、技术写作和开发人员关系部门。

跨职能小分队专注于一个领域

实现微服务的方式有很多，下面是 Postman 的做法。

假设 Identity 小分队想要创建一个新服务来验证一个现有的用户。

在 Postman，Identity 服务所有者是这个新服务的生产者。该生产者会创建一个团队工作区作为新服务的单一数据源。

工作区是服务的单一数据源

在 Postman，工作区是协作的基础。我们很快就会看到，工作区包含服务的预期行为。单元测试和集成测试都在这里进行。它是开发期和开发完成后所有交流的主线。

https://learning.postman.com/docs/postman/workspaces/intro-to-workspaces/

在新建的工作区中，Identity 服务所有者拟定一个集合来描述他们的服务。这个集合就像一个蓝图，其中有请求和潜在服务器响应的建议示例，描述了各种应用场景。实际上，集合的名称包括#blueprint标签，表示其用途。

https://learning.postman.com/docs/postman/collections/examples/

从新服务的建议蓝图入手

蓝图集合是一个服务建议。服务的潜在消费者会在设计中权衡，可以通过离线方式或是 App 的评论，来决定服务到底什么样。

协商服务建议的评论

一旦所有涉众成功地就服务的设计完成了协商，集合就成了新服务的协议或契约。这些请求和响应示例会被发送给支持并行开发的模拟服务器。

配对好的请求和响应会被发送给支持并行开发的模拟服务器

模拟是这个服务的生产者和消费者之间的契约。双方可以同时开始开发他们的代码。编写测试。开始编写文档。所有这些活动都是并行的，并由对新服务的一致看法所驱动。

当准备好部署服务时，我们需要进行测试，以确保没有工作流被破坏。Postman 工程用来管理微服务的最强大的工具之一是 consumer-driven contract(CDC) 测试。

在上一节中，我们讨论了服务所有者如何依赖蓝图集合提出建议、进行协商，然后确定如何使用他们的服务。

一旦就服务契约达成一致，使用者就使用模拟服务器作为引用点来编写测试。使用者只测试他们需要的端点和属性，并将测试保存在一个集合中。同样，这些集合的名称包括#contract标签，表示其用途。这些测试集合是在生产者的团队工作区中维护的。

消费者编写的测试是作为生产者 CI 管道的一部分运行的

当生产者准备好部署他们的服务时，消费者的契约测试将作为持续集成（CI）管道的一部分来运行。

服务所有者使用 Postman API 在团队工作区中提取所有集合，查找任何带有#contract标签的集合来运行。他们使用 Docker 配置自己的环境，在 CI/CD 管道中部署自己的代码]，并依赖 Newman 在容器中运行集合。

https://api.getpostman.com/

只有契约测试通过，代码变更才会部署。

除了作为 CI 管道的一部分按需运行契约测试外，Postman 工程部门还定期运行数量庞大的其他测试。

我们的工程师可以调度监控器运行来自 Postman 服务器的测试集合。这些告警和摘要被发送到 Slack 和电子邮件，让我们可以全天保持对该服务的密切关注。

在监控器上持续运行健康和安全检查

因此，Postman 工程师依赖于根据需要持续运行的测试。在 CI 管道中加入 CDC 测试可以让服务所有者放心地部署更新，同时确保不会破坏其他人的代码。在监视器上持续运行其他测试还可以确保在部署后不会出现任何问题。

1）Newman 在构建时根据需要运行测试；2）监控器按照预定的节奏运行测试。

所有这些都反映了一个持续的反馈循环，该循环允许团队继续演进和更新他们的服务。

所有的架构都是一项不断演进的工作。

你可能已经想到，Postman 工程部门经常使用 Postman 的产品。这意味着我们是煤矿里的第一只金丝雀。如果有东西不正常或者可以改进，我们就能首先感受到。这让我们可以快速迭代新特性。

本文旨在简单介绍 Postman 现在如何使用微服务。我们将继续解决一些难题。

• 对其他小分队的依赖需要额外的协调。一个小分队的路线图可能会被另一个小分队的进展所阻碍，或者至少受制于他们的服务水平。

• 在 Postman，小分队是一个相对较新的概念，每个小分队都在单独了解哪些流程最有效。

• 在领域驱动设计中，领域需要不断评估。例如，专注于大型领域的小分队需要承担大量的责任，这就需要他们在管理微服务、单库和单体服务之间进行权衡。

https://en.wikipedia.org/wiki/Monorepo

原文链接：

https://medium.com/better-practices/how-postman-engineering-does-microservices-aa026a3d682d