我需要微服务吗？

Question

我正在学习微服务体系结构，对于我来说，当我应该将一个功能包装到微服务中，以及何时最好将其保留在将组件安装在相关微服务中的单独组件中时，我有点不清楚。

实例：

1. Symfony的安全ACL组分（symfony/security-acl）。我可以将它封装到一个微服务中，它只会在Symfony Security ACL API顶部的REST API形式中添加一层抽象。除此之外，我将需要一个服务代理组件，它安装在相关的微服务上并提供对ACL微服务的访问。重点是什么？在需要的地方安装symfony/security-acl并为其提供单独的数据库连接更容易吗？

2. 支付系统。在这种情况下，它更加清晰，它需要包装到微服务中。它包含了大量的业务逻辑，这只是要求分离。

基本上问题是：

1. 我应该考虑什么标准决定把一个软件在微服务，而不是成为一个模块时？

2. 将symfony/security-acl封装成非常薄的微服务（对微服务来说不是很好）吗？

Answer 1

非官方，根据我的经验对于微服务非科学的理由：

• 横向扩展：如果你的服务不扩展均匀，你可能希望有10台服务器与服务A，但服务B只有1个。
• 更快部署：每个服务都有一个单独的部署过程，允许您按需部署较小的部分，而不是仅仅因为一个小的更改就部署一个大部分。
• 独立的开发风格和生命周期：当一个项目变得更大时，您可能希望让其他人接管它。对于比模块依赖性小的微服务，这显然更好。贡献者和团队可以随心所欲地开发他们想要的东西。每个团队都可以使用不同的语言，不同的管道，测试工具，编辑器等。唯一的共同点是最终API的格式，协议和约定。
• 更简单的依赖关系管理：升级或更改依赖于其他库的库可能会导致并发症，因为显然不是所有依赖项都会同时更新，并且会有不兼容性。
• 更清晰的API：记录所有公共类和函数可能是一场噩梦。另一方面，具有不完整或过时文档的API是放弃项目的理由。微服务在这方面不提供任何开箱即用的功能，但接口是明确定义的，通常是URL端点和HTTP方法。如果你遵循REST范例，这变得更容易。

在你的特殊情况下，很难说出使用什么，因为你没有给出足够的上下文。一些相关问题：

• 您是否正在开发团队？
• 这是框架的一部分吗？
• 什么是模块的依赖关系？
• 它的设计是否考虑了对数据库的并行访问？