如今，随着系统复杂性的增加，微服务在公司中非常流行。目标是让每个微服务处理一项特定工作，并将其处理好。这通常会带来易于维护服务、隔离错误以及使服务更可靠和可扩展的益处。
采用微服务的益处是显而易见的。
- 可维护性。解耦功能，以便可以单独维护每个功能，从而降低由与该功能完全无关的其他代码中的错误引起的风险。应用程序团队可以轻松地维护它，并拥有专门的范围。
- 易于部署。如果一个项目非常庞大，并且有很多开发人员为同一服务贡献代码，那么部署和回滚服务将是一个问题，因为出现错误的可能性更高，有时某些开发人员的更改必须包含在内，但由于其他开发人员代码中的某些错误，他们不得不回滚。微服务模型会在一定程度上减少此类麻烦。
- 技术栈选择的灵活性。由于每个微服务都是一个独立的功能，并单独托管。每个服务的技术栈可以不同。这意味着每个服务团队可以选择最适合该服务且团队感到舒适的技术栈。它可以是 GoLang、Java 或 Python 等。
- 易于扩展。如果服务流量突然激增，可以快速启动服务实例，因为它不会很重，也不需要启动太多进程。
- 易于迁移。如果某些功能可以用其他服务替换，则只需要上游或下游系统连接到新服务，并在迁移完成后删除旧服务。
然而，任何事物都有两面性，除了这些好处之外，如果在实际项目中处理不当，微服务也会给公司带来问题。
以下是如果微服务采用不当会引起的一些问题。
- 可维护性。随着每个新微服务的引入，都需要设置和维护一组新的基础设施（服务器实例、网络连接、安全组等）。这些配置需要维护良好，尤其是在云环境中。这增加了对 SRE 的挑战。
- 可扩展性。当需要进行任何升级或修补程序时，SRE 需要对每个服务的全部实例进行额外的工作。当它变得庞大时，这将是过度杀伤。
- 可用性。每个服务都通过 HTTP 或 RPC 进行通信，因此它对网络连接有很高的要求，如果网络连接不稳定，则会导致问题，从而导致延迟增加。
- 依赖性。如果设计不当，会导致依赖性问题，其中一个服务必须在另一个服务部署后部署，因为会在两个服务之间添加和共享一些新内容。
- 一致性。在分布式环境中，每个服务都处理其自身的职责。如果某些功能需要作为一个整体完成，则需要一个协调器。在这种情况下，维护状态一致性的难度会增加，如果一个服务未能完成某些请求，则需要通知所有其他服务并相应地回滚。
- 技术复杂性。如优点部分所述，每个服务都可以拥有自己的技术栈。这样做的缺点是人们在服务之间移动并不理想。有些人可能不了解其他服务使用的语言，当他转到其他团队或接管其他服务时，学习曲线会增加，从而减慢过渡速度。
每当要引入新功能时，请谨慎考虑是否需要新的微服务。下面记录了一些通用建议。
- 尝试使用关于创建新微服务的标准模板。这应该包括为什么需要新服务、使用的技术栈、服务如何与其他服务交互等等。它需要由来自不同团队的一组人进行审查，以确定是否应该创建新服务。
- 需要提供一个工具或流程，以便可以轻松设置新服务，而无需服务团队手动设置所有内容（服务器实例、数据库、缓存、api 网关等）。
- 在微服务中使用通用的技术栈，以便于在公司内部进行管理和移动。
