服务|Postman公司微服务最新实践

作者 | Joyce Lin
策划 | 万佳
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 工程部门现在是如何做微服务的。
1
Postman 工程部门
Postman 工程部门在全球 8 个地区拥有 100 多名工程师。这家公司刚刚宣布了 C 轮融资，因此，事情的发展必然会和任何成长中的初创公司一样。

文章插图
让我们深入了解一下这些团队是如何组织的。我们很快就会看到，这确实会影响到微服务的实现。
2
在微服务架构下，如何组织你的团队？
根据康威定律，软件开始的时候看起来像创建它们的组织。人们交流、协作的方式，甚至他们的工具都会对其产生影响。相关团队之间信息流动的方式也会影响输出。
设计的结构受制于组织的沟通结构。——康威定律
这就是为什么像亚马逊和 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 的做法。
3
在微服务架构下，如何创建和维护新的微服务？
假设 Identity 小分队想要创建一个新服务来验证一个现有的用户。
第一步：创建一个团队工作区
在 Postman，Identity 服务所有者是这个新服务的生产者。该生产者会创建一个团队工作区作为新服务的单一数据源。

文章插图
工作区是服务的单一数据源
在 Postman，工作区是协作的基础。我们很快就会看到，工作区包含服务的预期行为。单元测试和集成测试都在这里进行。它是开发期和开发完成后所有交流的主线。
https://learning.postman.com/docs/postman/workspaces/intro-to-workspaces/
第二步：拟定蓝图集合来描述用例
在新建的工作区中，Identity 服务所有者拟定一个集合来描述他们的服务。这个集合就像一个蓝图，其中有请求和潜在服务器响应的建议示例，描述了各种应用场景。实际上，集合的名称包括标签，表示其用途。
https://learning.postman.com/docs/postman/collections/examples/

文章插图
从新服务的建议蓝图入手
第三步：协商建议服务如何运行
蓝图集合是一个服务建议。服务的潜在消费者会在设计中权衡，可以通过离线方式或是 App 的评论，来决定服务到底什么样。

文章插图
协商服务建议的评论
第四步：借助模拟实现并行开发
一旦所有涉众成功地就服务的设计完成了协商，集合就成了新服务的协议或契约。这些请求和响应示例会被发送给支持并行开发的模拟服务器。