别再管你的 API 叫微服务了

2019 年 3 月 10 日 InfoQ

作者 | Lukas Rosenstock

译者 | 无明

你有没有听过这句名言：“计算机科学领域只有两个难题，缓存失效和命名”？据说这句话是 Phil Karlton 在 1996 年或 1997 年左右说的。围绕这句格言确实出现了很多带有喜剧色彩的说法，它们也提到了其他的一些问题，但最近我对 API 世界的观察似乎证明了“命名”确实是个大难题：人们对“API”和“微服务”这两个术语存在混淆，有些人似乎已经把它们混为一谈了。

计算世界在不断发生变化。开发人员使用各种概念和技术，并以不同的方式将它们连接在一起。因此，我们使用不一致的术语，用多个术语来描述大致相同的概念，或者用同一个术语表示不同的事物，这些情况并不罕见。

关于 API 和微服务：是的，它们是相关的概念，它们之间存在相互作用，但它们并不是同一种东西。所以，我想直截了当地说出我的看法！

什么是 API？

API 是应用程序编程接口（Application Programming Interface）的缩写。维基百科指出，“总的来说，它是各种组件之间的一组明确定义的通信方法”。它可以是软件框架或库的接口，也可以是操作系统为原生系统软件（如 POSIX）开发人员公开的底层接口。

这也是 API 能够如此令人感到兴奋的一个方面，因为各种开发人员可以利用其他人构建和公开的基础设施来增强其应用程序的附加功能。

现如今，当人们谈论 API 时，他们通常指的是通过 HTTP 端点公开的远程接口。为了区分这些远程 API 和上面提到的本地系统 API，我将用术语“Web API”指代远程 API。（虽然有些人将这个术语用来指代浏览器的本地 API——有点令人困惑，对吧？）

我们通过底层设计范式（如查询、RPC 或 RESTful）或协议（如 SOAP、gRPC 或 GraphQL）进一步对远程 API（或 Web API）进行分类。除此之外，我们还通过目标受众来区分 API，将它们分为公共、合作伙伴或私有 / 内部 API。

API 的两面性

严格来说，API 仅用来描述接口，也就是客户端和服务器、API 消费者和 API 提供者之间用于交换信息的语言。对于 API 消费者来说，API 只不过是对接口和端点 URL 或 URL 集的描述。URL 是 Web 的基本构建块之一，客户端可以在不知道服务器性质或位置的情况下访问信息或服务。只要客户能够收到响应，它根本不管 URL 是指向隐藏在某个地下室的 Raspberry Pi 还是位于某个大陆数据中心的全球交付网络。这也是 API 能够如此令人感到兴奋的一个方面，因为各种开发人员可以利用其他人构建和公开的基础设施来增强其应用程序的附加功能。

但是，API 提供者不仅要设计、实现和文档化 API，还要考虑它背后的基础设施。在云计算时代，可能不需要购买硬件和租用数据中心。相反，API 提供者可以选择各种“XX 即服务”产品——从虚拟机或容器的托管集群到完全无服务器的代码托管环境。无论选择了什么样的基础设施，他们都需要部署 API。

我这里说的部署 API 是指部署暴露 API 所必需的代码和基础设施。从提供者的角度来看，API 并不是一个神奇的大门，而是需要在某个地方运行的有形资产。而且，随着公司转向微服务架构，这种资产就会变成微服务或一组微服务。

什么是微服务？

微服务是系统或应用程序中的自包含独立组件。每个微服务都应该有明确的作用域和责任，理想情况下，一个微服务只做一件事。它应该是无状态的或有状态的，如果它是有状态的，它应该带有自己的持久层（即数据库），不与其他服务共享。软件开发团队基于微服务架构以更分散的方式开发可重用的独立组件。他们可以为每个微服务使用自定义框架、依赖关系集，甚至是完全不同的编程语言。微服务也有助于实现可扩展性，因为它们本质上是分布式的，并且每个微服务都可以独立增长或复制。

容器和微服务

容器是在操作系统中建立隔离上下文的一种方法。实际上，这意味着它们中的每一个都有一个单独的包含了一组已安装的软件和相关配置的虚拟文件系统。由于它们是相互隔离的，因此任何容器都不能直接访问或影响其他容器或底层宿主操作系统。

创建容器的能力已经成为 Linux 操作系统的一部分，这种能力已经存在了很长一段时间，但直到 2013 年 Docker 的推出，容器才成为一种流行的技术。

当我们在谈论定义时，需要注意的是微服务和容器其实是不一样的东西，但这两个概念经常被放在一起谈论，就像 API 和微服务一样。如果没有容器，要么把服务器配置成可以运行多个微服务，让这些微服务不可避免地相互产生负面干扰，要么每个微服务都需要一个单独的服务器或自己的虚拟机，导致不必要的开销。因此，微服务通常被部署在一组由容器集群软件（如 Kubernetes）管理的一组容器中。可以肯定地说，容器和微服务的崛起其实是相互影响、相互促进的结果。

微服务之间的通信

基于微服务架构构建的应用程序或 API 不仅要把自己完全暴露出来，还需要在内部组件（微服务）之间建立连接。由于每个微服务都可以使用不同的编程语言实现，我们需要依赖标准协议（如 HTTP）来建立微服务之间的连接。这个时候我们就回到了 API 上。

最基本的形式是每个微服务都公开一个 API，让其他服务可以向这个 API 发出请求并获取数据。也可以使用其他不同的方法，比如消息队列。微服务 API 是私有 API，仅限用在单个应用程序中。它通常不提供公共 URL，而是使用组织内部专用网络的私有 IP 或主机名，甚至是单个服务器集群内的 IP 或主机名。不过，这些 API 可以遵循类似公共 API 那样的设计范式或协议。而且，尽管它们的消费者数量有限，也应该遵循开发者体验的基本规则。也就是说，它们应该拥有相关的、一致的、可演化的 API 设计和文档，让其他团队（甚至是你自己）知道如何使用这些微服务。因此，你可以而且应该使用类似的工具来创建你的微服务 API。

当然，与更面向外部的 API 相比，在设计微服务 API 时有不同的侧重点。

微服务和 API 是不同的东西，就像微服务和容器也不是同一种东西一样。不过，这两个概念以两种不同的方式协同工作：首先，微服务可以作为部署内部、合作伙伴或公共 API 后端的一种方法。其次，微服务通常依赖 API 作为与语言无关的通信手段，以便在内部网络中相互通信。开发团队可以使用相似的方法和工具来创建公开 API 和微服务 API。

英文原文：

https://blog.stoplight.io/stop-calling-your-apis-microservices-e165a80eba9d