什么是微服务，它们与 API 驱动的架构有何不同？

Question

我希望能够回答“您使用微服务吗？”这个问题。我不知道“微服务”的具体含义。基本上我在“什么是微服务？”中读过的所有内容。要么是一堆无用的术语，例如“松散耦合”、“细粒度”和“轻量级”，要么听起来像是管理顾问为企业高管写的，没有真正的内容。

我目前的理解是：

• monolithic application 是将所有内容（数据库除外）都集成到单个代码库中。例如，我编写了一个带有模型、视图和控制器的 ASP.NET MVC 应用程序。它是一个运行在 IIS 之上并连接到 MSSQL 的单一代码库。
• API-driven application 是业务逻辑与应用程序逻辑分离的一个； API 定义/实现业务逻辑，应用程序通过调用 API 与用户交互并执行业务逻辑。例如，我将我的 ASP.NET MVC 应用程序转换为 A) 在一个容器中运行的 API 和 B) 在单独的容器中运行并在客户端执行 API 调用的单页应用程序 (SPA)。

后来，当我开始编写其他应用程序时，每个应用程序都有自己的 SPA 和 API，我决定将身份验证和授权分解到自己的 API 中。后来，我决定将每个 API 共有但与 authn/authz 无关的一些业务逻辑分解到另一个 API 中。所以现在每个 SPA 都与（至少）三个 API 独立通信。 （每个 API 是一个单独的容器，每个 SPA 是一个单独的容器。）

这些是微服务吗？什么是微服务？每个应用程序都有一个 API，在大多数情况下，我可以将它们分解为多个较小的 API。那么这些是单体 API 还是微服务？

Answer 1

我同意你的观点，似乎没有成熟的方法来实际衡量诸如“小”、“松散耦合”等目标。可能很难给出准确的定义，因为它取决于上下文和在应用程序的工作方式上。

但是，对于微服务架构的开发和部署过程，有一些标准：

• 您应该能够相互独立地交付和部署服务。
• 开发团队应该能够独立于其他服务实施服务。

现在有趣的问题实际上是如何为服务找到合适的边界。我喜欢这篇文章How to break a Monolith into Microservices，它有很好的陈述：

在遗留单体应用中查找域边界既是一门艺术，也是一门艺术 科学。

听起来您已经考虑了很多关于在单个服务中分离什么，所以您显然至少在使用微服务的道路上做得很好。