认识达内从这里开始

随着互联网的不断发展，不同的科学技术之间也越来越细分化，这就导致了许多的程序员在对不同的技术概念进行理解记忆的时候会发生一些混淆。下面我们就一起来了解一下，关于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)管理的一组容器中。可以肯定地说，容器和微服务的崛起其实是相互影响、相互促进的结果。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!