什么是微服务，它们与API驱动的体系结构有什么不同？

Question

我希望能够回答这个问题，“你使用微服务吗？”具体而言，我不知道“微服务”意味着什么。本质上，我读到的所有关于“什么是微服务？”要么是一堆无用的术语，比如“松散耦合”、“细粒度”和“轻量级”，要么听起来像是由管理顾问为企业高管编写的，没有真正的内容。

我目前的理解是：

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

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

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

Answer 1

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

然而，对于微服务体系结构的开发和部署过程，有一些标准：

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

现在有趣的问题是如何为服务找到合适的边界。我喜欢如何将Monolith分解为Microservices这篇文章，它有一个很好的表述：

在遗留的独角石中寻找领域边界既是一门艺术，也是一门科学。

听起来，您已经对在单个服务中分离什么进行了大量的思考，因此您显然在使用微服务的过程中做得很好。