API 与微服务：微服务不仅仅是一个 API

API的概念和微服务的概念都涉及软件的结构和交互。微服务可能会被误解为提供 API 的简单端点。但微服务具有比这更多的灵活性和功能。本文将讨论 API 和微服务之间的差异，并详细介绍微服务可以提供的一些好处。

首先，让我们定义我们的术语。

什么是 API？

首先，我们来定义一下什么是API。根据维基百科，API（应用程序编程接口）是：

“一组用于构建软件的子例程定义、通信协议和工具。总的来说，它是一组明确定义的各种组件之间的通信方法。”

考虑 API 的一个简单方法是将其视为您可以为特定服务请求的操作契约。如今，API 广泛用于社交媒体、银行软件等众多 Web 应用程序中。标准化合约允许外部应用程序与另一个应用程序交互。

常见 API 操作

在当今世界，API 通常是使用 RESTful 风格开发的。这些 API 将具有一系列与 HTTP 操作相关联的动词，如下所示：

• GET（获取单个项目或集合）
• POST（将项目添加到集合中）
• PUT（编辑集合中已存在的项目）
• DELETE（删除集合中的项目）

通过不同的应用程序实现这种一致性的优点是在执行各种操作时有一个标准。上面的四个不同的 HTTP 动词与当今许多应用程序使用的常见 CRUD 功能相关。当在一个应用程序中使用不同的 API 时，这提供了一种可识别的方式来理解跨不同接口所采取的操作的含义。

什么是微服务？

维基百科将微服务定义为：

“一种 软件开发技术 -面向服务的架构(SOA) 架构风格的一种变体，它将应用程序构建为松散耦合服务的集合。在微服务架构中，服务是细粒度的，协议是轻量级的。”

但在我们深入研究什么是微服务以及它们如何发挥作用之前，让我们先快速了解一下整体架构。了解微服务与单体应用的不同之处将使您更好地了解迁移到微服务架构的好处。

微服务的先驱：单体应用

在软件开发的早期（并且在今天的许多大型企业环境中仍在继续），存在单体的概念。单体应用程序是一个拥有完整功能集合的单一应用程序，可以作为存储所有内容的一个地方。从架构上来说，它看起来像这样：

应用程序的所有组件都驻留在一个区域中，包括 UI 层、业务逻辑层和数据访问层。在整体中构建应用程序是一个简单而自然的过程，大多数项目都是这样开始的。但是，向代码库添加功能会导致整体的大小和复杂性增加，并且随着时间的推移，允许整体变大会带来缺点。其中一些包括：

• 存在陷入反模式泥球的风险，其架构没有任何韵律或原因，并且难以从高层次理解。
• 单体内部技术堆栈的限制。特别是随着应用程序的增长，迁移到不同技术堆栈的能力变得越来越困难，即使该技术被证明不再是最佳选择。
• 对代码库进行更改会影响整个应用程序，无论多么小。例如，如果只有一个业务逻辑部分不断发生变化，就会迫使整个应用程序重新部署，从而浪费时间并增加风险。

那么除了构建单体应用之外还有什么替代方案呢？将整体架构分解为微服务。

进入微服务

让我们采用上面的整体示例并将其转换为使用微服务。在这种情况下，应用程序架构将更改为如下所示：

这次重新架构有一些关键要点：

• 业务逻辑的细分部分，每个部分都包含一个微服务。整个应用程序不是只有一个边界，而是被分成多个部分。应用程序的复杂性降低了，因为不同的服务彼此之间具有明确定义的交互。例如，这允许将团队分配给每个单独的服务，将责任包含在一个抽象的部分中。
• 之前的 UI 层只需要与客户和事件微服务交互，从而消除了计费微服务对 UI 的依赖。
• 计费微服务不需要存储数据，因此它没有数据访问层或数据库。相反，它直接交互和处理来自客户和事件微服务的数据。

这种架构具有很多优点：

• 分离关注点更容易。这些区域之间的界限有助于开发（您只需要关心微服务，而不是整个应用程序）并有助于理解应用程序的架构。
• 与单体应用不同，微服务可以根据需要使用不同的技术堆栈。考虑用新语言重写所有内容？只需更改一项微服务以使用新技术堆栈，评估所获得的好处，并确定是否继续。
• 整个应用程序的部署变得更加集中。微服务使您可以根据需要灵活地部署不同的服务。

在上面的示例中，注意到 API 与微服务的其他部分并存吗？我们会详细讨论这一点。终于到了谈论 API 和微服务之间的区别的时候了。

API 和微服务之间的区别

以下是 API 和微服务之间的主要区别：

• API是一种合约，为消费者使用底层服务提供指导。
• 微服务是一种架构设计，它将应用程序（通常是整体式）的各个部分分成小型的、独立的服务。

根据定义，这意味着 API 通常是微服务的一部分，允许与微服务本身进行交互。另一种思考方式是，API 充当微服务内交互的契约，提供可用于与微服务交互的选项。

但是，如果我们查看上面的微服务图，我们可以看到每个微服务的构建根据其需求略有不同。以下是微服务可以具有的不同功能的一些示例：

• 为特定实体类型（例如客户、事件等）提供 CRUD 操作。该服务能够将数据保存在数据库中。
• 提供一种接受参数并基于（可能密集的）计算返回结果的方法。上面的计费微服务可以获取有关事件或客户的信息并返回所需的计费信息，而不需要存储数据。

通过上面的示例，您可能会发现微服务不仅仅是系统的 API。整个应用程序可以包含一系列微服务，这些微服务使用自己的 API 相互通信。此外，每个微服务都可以抽象自己的功能，为应用程序中的职责绘制逻辑边界，并分离关注点以形成更易于维护的代码库。