别再管你的 API 叫微服务了

你是否听说过这样一句格言：”计算机科学中只有两个难题，即缓存失效和命名”？据称，菲尔-卡尔顿（Phil Karlton）曾在 1996/97 年间说过这句话。围绕这句格言确实出现了很多带有喜剧色彩的说法，它们也提到了其他的一些问题，但最近我对 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 是网络的基本构件之一，但有点神奇，它允许客户端在不知道服务器性质或位置的情况下访问信息或服务。客户端可能不知道 URL 指向的是藏在某人地下室的树莓派，还是由遍布各大洲的庞大数据中心组成的全球交付网络，只要他们收到响应即可。这正是API如此令人兴奋的原因之一，因为各类开发人员都可以利用他人构建和公开的基础设施来增强其应用程序的附加功能。

然而，应用程序接口提供商不仅要设计、实施和记录应用程序接口，还要考虑其背后的基础设施。不过，在云计算时代，这已经很少意味着购买硬件和租用数据中心空间。取而代之的是，API 提供商可以选择各种即服务产品，从可管理的虚拟机集群或容器，到完全无服务器的代码托管环境。无论选择哪种基础架构，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。

原文链接：Stop Calling Your APIs Microservices