API 与微服务：初学者指南

不久前，建立网站的技术还相当简单。

在过去的美好时光里，HTML、CSS 和 JavaScript 就足够了。而且大多数时候，你甚至不需要最后一个！

但现在，情况变得有点复杂了。你需要跟踪所有这些新技术。虽然它们一开始可能会让人感到困惑，但学习它们可以帮助我们提高开发效率。

如今我们经常听到的一个概念就是微服务架构。它引起了不小的轰动，尤其是在最近，因为它通常没有得到很好的解释……

即使是经验丰富的开发人员也不知道微服务是什么，这没关系。通常，当被问及他们认为微服务是什么时，大多数 Web 开发人员都会这样说：

这和 API 没有关系吗？

答案是……（有点类似）。在 Jamstack 的世界里，我们经常把它们当作同一件事来讨论，但实际上它们是互补的概念。了解每个想法的细节对我们很有帮助，尤其是在我们只需要 API 和微服务中的一个的时候。

让我们来探讨一下这两个概念。我们会先从字典定义开始，不过别担心。我稍后会略过那些晦涩的术语，直接进入正题。

什么是API和微服务？

API代表应用程序编程接口( API)。根据维基百科，API“定义了多个软件应用程序之间的交互。它定义了可以进行的调用或请求的类型、调用方式、应使用的数据格式、应遵循的约定等。” 在 Web 开发领域，我们最常使用的 API 是可以通过互联网访问的。

根据microservices.io的说法，微服务是“一种架构风格，将应用程序构建为一系列服务，这些服务具有高度可维护性和可测试性、松散耦合、可独立部署、围绕业务功能进行组织，[并且]由一个小团队拥有”。

这些定义可能看起来有点晦涩，所以我将这样定义它们：

API代表应用程序接口( API )。API 定义了两个软件如何连接和通信。如果您的应用程序是一家大公司，那么 API 的作用就是与外部各方（例如客户或公司合作伙伴）保持联系。大多数 API 都遵循某些标准，例如REST或GraphQL，以便每个人都知道如何使用它们。

微服务是由软件组件（通常只是一些独立的功能）组成的，它们负责大型应用程序中单个、微小且独立的部分。如果您的应用程序是一个大公司，那么每个员工都将是一个微服务，每个员工都扮演着各自特定且微小的角色，与其他员工协同工作，但又彼此独立。这使得您可以对单个微服务进行更改，而不会影响应用程序的其余部分。在一家大公司中，替换或重新分配大型团队中的一名员工可能不会对公司的其他部分造成太大影响。

这是单体架构的演进。它不再由一个整体构成整个应用程序，而是将每个组件划分为更小的构建块。

这样说来，您是不是更容易理解它们的不同之处以及它们如何协同工作？

API 和微服务在现实生活中的实际意义

让我们深入研究一个更实际的用例，以帮助您进一步理解。

假设我有这个完全原创的支付处理服务，我称之为 Tripe（你知道，因为这是一个愚蠢的想法，而不是因为我受到任何现有公司的启发😉）。

这个应用程序需要大量的小功能。以下是我脑海中浮现的一些：

• 从数据库读取
• 插入或更新数据库
• 创建发票 PDF
• 联系银行
• 为订阅安排重复任务
• 运行实际交易
• 发送电子邮件

所有这些小功能块都拥有各自的功能，并且各自独立维护。这就是微服务架构的精髓。所有这些独立的任务都是微服务。这也使得调试变得更容易，因为你几乎可以立即将问题缩小到单个函数。如果你像我一样讨厌调试，那就太棒了：

我们再进一步探讨一下。Tripe 可能会允许用户触发其中一些功能，对吧？创建发票、客户资料、订阅、收费和退货是用户可以启动的五个操作，所有这些操作都会用到上面提到的一些微服务。因此，这里的解决方案是创建五个新的微服务，每个操作对应一个我们要对外暴露的新操作。

例如，新的发票微服务会调用读取数据库的微服务，然后调用生成 PDF 的微服务，最后调用发送电子邮件的微服务。你可以用我之前提到的大公司的比喻来理解；公司里可能有一些员工，他们的全部工作就是收集同事完成的工作，然后呈现给公司外部的人员。本质上，我们创建了一组微服务，用于收集其他微服务完成的工作，并通过互联网将其交付给用户。它们的存在只是为了通过编程的 HTTP 请求在你的应用程序和外部世界之间建立接口。

听起来很熟悉？嗯，因为这是一个API！

快速补充：API 从技术上讲是任何两个程序（包括微服务本身）通信的方式，但在 Web 开发中，我们通常指的是面向 HTTP 的 API。API 遵循 REST 或 GraphQL 之类的协议，将数据和功能暴露给更广泛的互联网。本文中我所说的 API 指的是 API，但了解其定义相当广泛也很有用。

这五个微服务允许用户直接访问 Tripe 的 API。并非每个微服务都必须成为 API 的一部分，就像并非每个员工都需要成为与客户沟通的团队的一部分一样。许多员工只是执行内部任务，协助面向客户的员工，就像许多微服务只执行内部任务或协助 API 功能一样。此外，有很多方法可以在不使用微服务的情况下构建 API，因此这些技术之间的互补性大于竞争性。

让我们借助图表让它变得更加直观！

Tripe 的架构看起来是这样的：

这东西表面上看起来有点复杂，但毕竟是个支付处理器。我可不会把我的信用卡信息给比这更简单的……

让我们逐一浏览这些列。最左边是 Tripe 的用户。他们只能访问“外部 API”列中的微服务。第二列（外部 API）中的端点组合起来构成了 API。它们是唯一以明确的方式与用户通信的微服务（例如，通过 API 文档中设置的特定 JSON 对象）。它们各自独立地完成任务，并使用一些其他微服务（在“业务逻辑”列中）来执行用户无法直接触发的任务。大多数业务逻辑函数也相互调用，这表明整个 Tripe 应用程序被分解成最小、可重用、隔离且独立的部分。

使用微服务构建应用程序可以降低复杂性，并使维护更加轻松，因为您可以单独编辑这些小块。这就像用乐高积木搭建网站：如果您不喜欢其中一个，只需将其替换，而网站的其余部分保持不变。这意味着您的技术债务几乎可以降为零，如果您坚持这种方法，您将永远不会陷入我们都讨厌的“双输”架构困境。

微服务和 API 实际应用

由于线条众多，我们的三重图可能看起来相当复杂，但与亚马逊或 Netflix 等大公司的相同图表相比，它相对简单：

这个结构看起来有点笨重，但实际使用起来却容易得多。图片来源的文章开玩笑说，亚马逊微服务节点图“看起来几乎像一颗死星，但功能强大得多”。

仔细想想，这种架构对于像亚马逊和 Netflix 这样的大公司来说非常合理。他们的开发人员在需要更新时无需编辑整个代码库或重新部署整个网站。例如，Netflix 的工程师们正在全天候改进他们的产品。想象一下，如果他们每次想要添加一个内部功能时都必须暂时关闭网站，那会是怎样一番景象。Netflix 将会一直处于宕机状态；再见，追剧的乐趣就此告别！😧

相反，他们每次只需处理一个可管理的代码块，即图表上的一个点。

相比之下，想想 Netflix 的微服务图上，真正需要与外界通信的节点数量究竟有多少。Netflix最近一直在修改他们的 API，所以我无法确切计算出有多少节点是对外通信的。不过，与他们内部实际使用的微服务数量相比，这个数字仍然相当小。以下图为例：

以下是附带的解释：

假设用户在手机上点击了《怪奇物语》第一集的“播放”按钮。为了开始播放，手机会向 API 发送“播放”请求。API 会调用后台的多个微服务。其中一些调用可以并行执行，因为它们彼此不依赖。其他调用则需要按特定顺序排序。API 包含所有必要的逻辑，用于对调用进行排序和并行化。反过来，设备无需了解客户点击“播放”时后台进行的任何编排。

很有意思，对吧？我想特别强调一句话：“API 包含所有必要的逻辑，用于对调用进行排序和并行化。” 这意味着客户端（观看 Netflix 的人）<!-- 您在这里指的是客户端吗？--> 在按下“播放”按钮时会调用 API 端点，而这本身就是一个微服务。

附注：据我了解，Netflix 此处提到的 API 并非公开。请记住，API 只是“两个软件连接和通信”的一种定义方式。在本例中，这两个软件指的是 Netflix 的后端和前端。即使你我无法通过互联网使用它，它仍然是一个 API，因为前端和后端之间的交互被赋予了相应的结构和规则。这一点非常重要，因为这意味着你可能在职业生涯中创建的 API 数量可能比你意识到的还要多。每当我们在内部连接两个服务并赋予它们相互通信的方式时，我们就是在创建一个 API。我们应该意识到这一点，因为这让我们有机会在架构失控之前仔细思考。

TLDR；它们是互补的。

结论是什么？API 可以全部或部分由微服务构成。不过，微服务的用途远不止于此。最初的定义（那个冗长、枯燥的定义）将微服务称为“一种架构风格”的组成部分。整个应用程序，包括业务逻辑等等，都可以分解成微小的、可重用的、单一用途的代码块，这就是微服务架构。

如果您想以另一种方式直观地了解它，这里有一个维恩图。如您所见，微服务可以是 API（圆圈的重叠部分），但 API 不一定是微服务。

还记得我之前说过，有些 API 由微服务组成（比如我们虚构的 Tripe API），但它们并不总是需要协同工作吗？有些微服务不属于 API（维恩图的右侧部分），比如 Tripe 示例中的业务逻辑，因为它们不必对外界开放。另一方面，创建 API 的方法有很多，其中大多数都不涉及微服务。大多数使用传统后端语言（PHP、Ruby、Java 等）构建的 Web 后端都是单体的，也就是说不是由微服务构成的。即使是用 JavaScript 构建的后端，如果不将所有功能拆分成最小的部分，也可能是单体的。

API 和微服务如今已成为现代 Web 开发流程的重要组成部分。没有它们，我们的发展就无法进行。因此，如果您正在尝试突破传统的单体式 Web 架构，并且/或者想进一步了解这些新技术如何协同工作，以下是一些可供进一步学习的链接：

• 10 家实施微服务架构并为其他公司铺平道路的公司
• 工程权衡和 Netflix API 重构
• 100 个 Jamstack 工具、API 和服务，为您的网站提供支持
• Jamstack 新手入门指南
• API 初学者指南：如何集成和使用它们

如果你还有其他问题，欢迎在Twitter上或在下方评论区联系我。我很乐意听取你的意见！