我是微服务设计和架构的新手，请帮助我。我需要启动一个项目，该项目主要包含9个搜索功能（来自后端的所有GET）和2个审核日志记录功能。我打算从微服务设计开始。我主要的困惑是，为什么我不能使用单个后端数据库并将11（9 + 1）个功能拆分为离散/分离的微服务。从理论上讲，我理解所有这些功能都应指向不同的DB或需要封装，但是就我而言，我没有那种自由。请让我知道您的想法。
答案 0 :(得分：1)
冒着首先涉足宗教辩论的风险，没有什么可以阻止整体数据库，就像没有什么可以阻止整体应用程序一样。
每种方法都需要权衡，就像单片应用程序或God-box服务器一样；重构和/或升级的成本变得如此之大，以致无法执行，升级数据库的软件以及架构迁移（和支持代码）的后果也随之而来。
理想地，微服务的目标是在软件级别上最小化依赖关系，并隔离代码所依赖的组件。通过利用Api来处理将用例与数据联系起来的业务逻辑，我们避免了数百个直接依赖于同一表的代码。只要将微服务逻辑隔离扩展到数据库表结构和访问控制以及大多数良好意图，就可以遵守。话虽这么说，但数据库升级和中断严重。通过将数据库从1个主集群划分为多个集群，您可以限制中断（有意或无意）的影响，同时还使开发团队自己能够处理架构更新，因为基础数据库仅直接影响其应用程序，并间接影响应用程序他们支持。这也使代码可以附带附加的模式迁移，从而减少了模式更新和代码发布之间的时间，并且在某种程度上减少了功能切换和发布后模式更新的需要。
归根结底是动机，您和您的团队将必须确定增加服务器管理，拥有更多数据库还是在出现问题时是否愿意接受所有微服务的总中断是值得的。