在这篇文章中，我们将学习何时使用以及何时不应使用微服务架构。
图示：微服务架构
通过这篇文章，我们将了解微服务架构的最佳应用场景，并使用微服务架构来设计我们的电子商务应用程序。
微服务架构
微服务是一种构建和部署软件应用的建筑方法，它将应用拆分为更小、独立的服务，这些服务可以分别开发、部署和维护。虽然使用微服务有很多好处，但也存在一些需要考虑的挑战。
什么时候使用微服务架构
确保你有充分的理由实施微服务
在开始微服务之前，你应该检查你的应用程序是否可以不需要微服务。
当你的应用程序需要高度独立的可扩展性，并且需要敏捷地以零停机时间部署、独立更新来实现快速上市时，那么你应该采用微服务架构。
但关键在于你必须确保你有充分的理由实施微服务。开发者往往过于关注最新的技术工具，例如微服务。相反，开发者和架构师应该考虑实施的原因。他们还应该关注技术工具为实现这些结果所驱动的结果。
通过小步迭代，并将单进程单体应用作为你的"默认"选择
当我们讨论模块化单体架构时，模块化单体架构也涵盖了微服务的大部分好处，同时避免了微服务的许多复杂性。因为单进程单体应用程序具有简单的部署拓扑。
建议从小的变更开始，并保持单进程单体作为"默认"方案。即使转向微服务，也应该从模块化单体开始，并逐个将单体中的一个模块重构为微服务，看看效果如何。
需要独立部署新功能且无停机时间
然后当组织需要变更功能并部署该功能而不影响系统其他部分时，微服务就非常实用。这就是微服务的力量，它允许在不造成任何停机的情况下部署新功能。
独立服务：每个服务都可以独立部署和更新，提供了更高的灵活性。微服务中的错误，仅影响特定服务，不会影响整个应用程序。此外，为微服务应用程序添加新功能比单体应用程序更容易。无论应用程序是大还是小，添加新功能和维护现有代码都很容易。因为只需在相关服务内部进行更改即可。
需要独立扩展应用程序的一部分
此外，如果你的应用程序需要独立扩展应用程序的一部分，那么微服务是这种操作的绝佳选择。
更好的可扩展性：每个服务都可以独立扩展。因此，整个应用程序无需扩展。这节省了大量的时间和金钱。此外，每个单体应用程序在可扩展性方面都有局限性。然而，在微服务上分配流量以多路复用服务，不太不方便，并且能够处理整个负载。这就是为什么大多数面向大量用户的项目开始采用微服务架构的原因。
需要使用不同数据库技术进行数据分区
如果你的应用程序需要使用不同数据库技术进行数据分区，那么在组织需要用不同用例存储和扩展数据时，微服务就非常有用。
技术多样性：团队不必完全选择服务开发所依赖的技术，他们可以随着时间的推移选择适合他们开发的服务的技术。例如，一个服务可以开发为使用"机器学习"功能，与在.Net 上开发的微服务一起使用。每个微服务都可以使用所需的技术或数据库。
需要自主团队和组织升级
此外，如果贵公司需要通过组织升级组建自主团队，那么微服务将有助于发展和升级您的团队及组织。
组织需要将责任分配到各个团队，每个团队独立做出决策并开发软件。当团队需要独立工作而无需密切协调时，基于微服务的架构能够推动这种自主性在组织内部实现。
微服务架构
不使用微服务的情况--微服务的反模式
不要做分布式单体应用
确保你正确地分解服务，并遵循解耦原则，如应用边界上下文和业务能力原则。否则，你将失去微服务的优势。同时确保服务应该是松散耦合的。如果你的服务之间存在大量通信且强耦合，最终你会得到高度耦合的服务架构，这意味着你开发了一个分布式单体应用，它没有任何微服务应带来的好处。
分布式单体应用是最坏的情况，因为它增加了架构的复杂性，却得不到任何微服务的益处。微服务的核心在于自主性。当你失去自主性时，团队必须在开发和部署期间进行协调，团队之间会高度依赖。随着时间的推移，你将失去新功能部署的敏捷性。
所以如果你最终得到的是分布式单体应用，应用程序的延迟会更高，可能会出现同步问题，并且管理和调试会变得非常困难。当出现问题时，耦合服务会让调试变得极其痛苦。
不要在缺乏 DevOps 或云服务的情况下进行微服务
微服务是拥抱分布式云原生方法。并且你只能通过遵循这些云原生原则来最大化微服务的效益。
其中一些原则是
- 具有 DevOps 自动化的 CI/CD 管道
- 合适的部署和监控工具
- 支持您基础设施的托管云服务
- 遵循关键使能技术和工具，如容器、Docker 和 Kubernetes。
- 通过消息传递和事件流服务，中断了依赖关系，并使用异步通信。
如果你在微服务架构中不遵循这些原则，你将再次陷入分布式单体应用的困境，这是最糟糕的情况，因为你增加了架构的复杂性，却得不到微服务的任何好处。
有限的团队规模，小团队
如果你没有足够规模的团队来处理微服务的工作负载，这只会导致交付延迟。
对于小团队来说，微服务架构很难得到辩护，因为团队只需要处理微服务自身的部署和管理。
如果您的团队规模足够承担这些任务，那么就更容易证明其合理性，但如果您五人团队中的一个人在处理这些问题，那将浪费大量宝贵的时间，而这些时间本应用于产品开发。
全新产品或初创企业
I如果您正在开发一个需要重大变更的新产品或全新产品，那么在开发和迭代产品时，您不应该从微服务开始。这类项目在领域模型上需要频繁调整，跨服务边界的变更将是一种昂贵的方式。
一般来说，我认为在领域模型足够稳定后再迁移到微服务更为合适。因为重新设计业务领域时，微服务成本非常高。这就是为什么初创企业最好从模块化单体架构开始，当领域模型稳定后逐步过渡到微服务。对于初创企业来说，即使您成功到足以需要高度可扩展的架构，这一点也并不明确。
共享数据库反模式
是的，可以为微服务集成数据库。我们可以创建一个单一共享数据库，每个服务通过本地 ACID 事务访问数据。但如果你认真考虑这种做法，请立即停止并重新思考。
需要注意的是，模块化单体架构并不是微服务架构的替代品。这两种方法都有其优缺点，架构的选择取决于正在构建的系统的具体需求。对于可能随着系统增长和复杂性增加而最终演变为微服务架构的系统，模块化单体架构可以是一个很好的起点。
设计模块化单体架构-电子商务应用
如果我们使用模块化单体架构设计电子商务应用，您可以看到下方的图片：
模块化单体架构。根据架构，我们可以将新功能开发封装到一个模块中。并且每个模块都可以实现自己的架构，如分层架构、洋葱架构、干净架构等。
设计微服务架构-电子商务应用
I如果我们使用微服务架构设计电子商务应用，您可以看到下面的图片：
图示：微服务架构
产品微服务可以使用 NoSQL 文档数据库，购物车微服务可以使用 NoSQL 键值对数据库，订单微服务可以根据微服务数据存储需求使用关系型数据库。
本文到此结束，感谢阅读。
原文地址：When to Use and When NOT to Use Microservices: No Silver Bullet