我需要微服务吗？

Question

我正在学习微服务架构，当我将一个功能部分包装到微服务中并且最好将它保存在依赖微服务中安装组件的单独组件时，对我来说有点不清楚。

示例：

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

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

基本上问题是：

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

2. 将symfony/security-acl包装到一个非常薄的微服务中是不是一个好主意（微服务不是很好）？

Answer 1

基于我的经验的微服务的非官方，非科学原因：

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

在您的特定情况下，很难说使用什么，因为您没有提供足够的上下文。一些相关问题：

• 您是否正在与团队合作？
• 这是框架的一部分吗？
• 模块的依赖关系是什么？
• 它的设计是考虑到DB的并行访问吗？