别再管你的 API 叫微服务了：容器、微服务和API之间是什么关系？

做者 | Lukas Rosenstock译者 | 无明最近我对 API 世界的观察彷佛证实了“命名”确实是个大难题：人们对“API”和“微服务”这两个术语存在混淆，有些人彷佛已经把它们混为一谈了。

你有没有听过这句名言：“计算机科学领域只有两个难题，缓存失效和命名”？听说这句话是 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