Postman 如何处理庞大难以管理的网关服务

Postman如何处理庞大难以管理的网关服务 来自 Postman 的服务基础（Server Foundation）团队关于 Bifrost websocket 网关的真实故事的分享。

在漫威电影宇宙中，Bifrost 是彩虹桥的名字，它可以在神界和人界之间进行瞬间旅行。类似地，我们的 Bifrost websocket 网关也同样神奇地让 Postman 客户端即时连接到 Postman 服务。

正如我之前在Postman如何实现微服务中所分享的那样，所有的软件架构都是一个持续进行的工作。在实际执行中意味着需要偶尔重新评估旧的思维方式以适应新的情形，这是软件设计的自然演化。

下面是一个关于 Postman 的工程师们如何通过精简一个增长过大的服务来开发 Bifrost websocket 网关的故事。

Postman 公司的开发团队

Postman 公司的大多数开发团队都在跨职能部门工作，专注于单一的核心领域，比如文档或版本控制。每个小队都遵循领域驱动设计的原则，为 Postman 用户开发内部微服务和产品功能。

虽然大多数工程师都是以小组形式工作，但有些工程师以功能团队形式工作，这些功能团队构建用于整个工程组织共享的组件。服务基础团队就是一个 Postman 功能团队的例子。这些工程师创造了工具，其他小组用这些工具来构建、交付和观察自己的特性。这个团队也是 AWS 专家和基础设施专家们的集中地。

服务基础团队是一个 Postman 功能团队的例子，他们创建和管理供整个工程组织使用的东西

Postman 的大多数微服务都是松耦合的，因此它们可以独立于其他团队进行发展。不幸的是，服务有时候可能会变得太大，提供一些看似毫不相关的服务。这些服务让团队能够快速迭代，但可能开始表现得更像一个臃肿的庞然大物、一个大泥团或是某种笨重的生物。

当这种情况在 Postman 出现时，来自不同团队的很多工程师们都会贡献代码，针对每个修改都需要非常仔细的跨团队协作。

单体 Sync 服务

其中一个 Postman 服务变得过于庞大而难以有效管理，这个服务叫做 Sync。它具有令人生畏的任务，与 Postman 服务器同步您本地计算机上的 Postman 客户端的所有活动。Postman 中的每个用户操作，都会通过 websocket 连接来触发一系列的 API 调用，并遵循发布-订阅模式，使得这些信息可以在用户及团队之间实时流动。

例如，当你登录到 Postman 并更新一个集合时会发生以下情况:

1. 你向 Postman 集合添加一个参数
2. Postman 将这条更新的记录和 Profile 信息保存在版本控制中
3. 实时地在集合视图展示最新信息

Sync 服务最初希望用于处理数据库事务，比如更新集合。然而，去年的这个时候 Sync 还管理了一些额外的活动，比如给所有集合订阅者通知和显示最新版本。