转载

【译】微服务 vs API：微服务不仅仅是API

原文链接

在开发软件的时候，既要考虑代码的实现也要考虑架构。当以一种逻辑上有意义的方式进行开发的时候，开发会更为有效。除了架构，软件也需要考虑用户交互，以及界面。

API与微服务都牵涉到结构与交互。微服务可能会被误解为仅仅是在一个端点上提供一个API。事实上，微服务包含了更多的弹性与功能性。这篇文章会浅析API与微服务的不同，以及微服务能够提供的好处。

开始之前，先看一些定义。

什么是API

首先，让我们看看什么是API。根据维基百科，API是一系列子程序定义，通信协议，以及建立软件的工具。通常情况下，它是一系列定义清晰的方法用于在多个组件之间进行通信。

简单来说，可以将API看做是一个契约，通过一个契约你可以请求一个特定的服务。如今，API大量运用于Web应用，例如社交媒体，银行软件等等。标准的契约让外部程序可以进行交互。

现在，假设你要开发一个与Facebook交互的应用程序。你需要使用 Facebook Graph API 获取数据，例如用户，发布内容，评论等。API简化了使用数据的复杂度并提供了易用的方式让开发者获取数据。

如今，API通常都以RESTful风格开发。这些API有一系列与HTTP相关的动词，例如：

这种一致性的好处是在执行各种操作时有一个统一的标准。四种不同的HTTP动词与CRUD相对应。当在一个应用程序中处理不同的API时，这有助于理解不同操作的含义。

好了，关于API我们就讲这么多，下面让我们看看微服务吧。

维基百科这么定义微服务：一种软件开发技术——面向服务架构的变体，以一系列松耦合的服务组织一个应用程序。在微服务架构中，服务是细粒度的且协议是轻量级的。

在我们深入了解什么是微服务之前，让我们看看Monolith。理解微服务与Monolith之间的差别有助于你更好地理解微服务的好处。

在早前的软件开发中（以及当前的许多企业环境中），诞生了Monolith的概念。Monolith是一个应用程序，包含了完整的功能集合，在一个地方提供服务，并存储所有内容。它看起来就像这样：

所有的应用程序组件位于一个地方，包括UI层，业务逻辑层，以及数据访问层。以Monolith方式开发程序是一个简单自然的过程，大部分项目都以这种方式开始。但是添加功能导致了大小与复杂度的增加，随着时间的增加monolith的不断变大带来了很多缺点，包括：

因此，替代方案就是将monolith分离成微服务。

让我们将上面的例子转为微服务，程序的架构将像下面这样：

这个重构中有几个要点：

业务逻辑的细分部分，每个都围绕着一个微服务。整个应用程序不再仅有一个边界，应用程序被拆分开来。程序的复杂度降低，因为不同的的服务之间都有定义良好的交互。例如，允许为每一个服务指派一个团队，负责实现这个抽象的部分。
UI层仅需要与客户及事件微服务交互，移除了对账单微服务的依赖。
账单微服务不需要存储数据，它不需要数据访问层及数据库。它直接与客户与事件微服务交互。

这种架构有着诸多优势：