示例用例：有一个微服务在属于同一业务域的几个表中保存了数TB的数据。
- 数据导入通过AMQP消息以事件驱动的方式进行(用CQRS术语-命令)。处理包含导入数据的消息可能需要几分钟时间。不允许丢失这样的消息/命令
- 导入的数据需要通过AMQP消息传递被其他有界上下文的其他微服务访问，请求/响应消息周期最多需要1秒(用CQRS术语——查询)。允许丢失查询消息
初始注意事项：命令和查询的可扩展性、弹性、性能、容错性以及其他一些功能要求是不同的。在不同的部署中，将查询处理与命令处理隔离开来似乎也很诱人，以便通过以尽可能好的方式满足命令和查询处理的能力要求
- 避免查询处理因命令处理时间过长而受阻的情况
- 避免同时处理命令和查询时出现内存不足错误
- 在一些技术堆栈中，如Spring AMQP，与没有消息传递保证的最大性能相比，性能较低的消息传递保证配置是为整个应用程序集中完成的，例如消息确认、并发等。这可能会对查询消息处理性能产生负面影响
但随后我们可能会讨论以下问题：
- 我们是否将2个可部署程序(1个用于慢速命令命令，1个用于实时查询处理)视为2个微服务
- 在这两个微服务/可部署程序之间共享数据库模式是一种反模式，不应该这样做吗？vs.但是我们在命令和查询的操作解耦方面获得了好处
你对此有什么想法和论点？
就我个人而言，我认为微服务对于正确进行面向服务的重命名来说是一个糟糕的选择。"；微型；名义上，它驱使人们在遵守所有原则(如自治)的同时构建小型服务，从而产生了我喜欢称之为纳米服务的服务——其效用小于其产生的开销。你可以看到，像优步这样全力以赴、陷入分布式泥沼的公司正在后退一步，重新思考服务边界，而不是使用多个可执行文件。
我认为这些是单一服务的各个方面。因此，该服务是关于处理这些数据的，它有一个接收方面和一个查询方面，它们需要独立扩展和开发。只要你守住服务内部和外部的边界，耦合<->；服务内的自由度权衡可以控制
所以是的，微服务；按书"；将要求您将每个可部署单元视为具有自己数据库等的单一服务，但您不需要货运决策来驱动您的架构，您需要做出深思熟虑的选择，以满足您的业务和技术需求
我对微服务的理解是，它本质上是自包含的：可以独立部署，并且与其他微服务松散耦合，但理想情况下与任何东西都松散耦合。更多信息请点击此处。
如果数据库是微服务的内部和排他性部分，那么让微服务直接使用数据库/模式/任何东西都是可以的。但就你而言，这是一种共享资源。所以你有一些可能是紧密耦合和共享的东西。
有一件事要经常问自己：；我想解决什么问题"；。微服务是一种强大的方法，但不是灵丹妙药。如果你有一些东西吸引了一组强大的约束，那么这些约束有时会挑战更广泛的架构——因此微服务可能对80%的解决方案都有好处，但不是100%。可能迫使您做出特定体系结构决策的强大约束包括非琐碎的NFR、系统约束(例如难以更改的遗留系统)等。
那么，你该怎么办呢？一些想法：
- 如果逻辑/分析让您选择了当前的选项，并且解决方案似乎是合理的，那么也许它是正确的。如果它不符合微服务架构风格，那么这就不是"；错误的"；就其本身而言，您的解决方案不是微服务
- 接受你的两个"；微服务；不是真正的微服务，而是一些稍微大一点的特定系统的逻辑部分。即便如此，您仍然可以对其应用合理的体系结构规则：适当地应用SOLID等
- 保持查询和导入功能在逻辑上分离听起来很明智，您甚至可以以这样一种方式构建它，即它们在物理上也可以分离
- 如果你开发这个特定的系统，它不像你的架构中的其他部分那样是微服务，那么你需要适当关注文档、架构、与开发人员的沟通等内容，这样每个人都清楚为什么解决方案的这一部分不同
- 看看你正在使用的技术堆栈，看看它有什么特定的工具来处理你的问题。缓存可能是一个值得探索的领域
- 关于高速缓存；写在后面"；以及"；"直写"；设计模式(以及其他)。基本上，有各种模式用于处理缓存和主记录，这些模式优先于不同的驱动程序。你只需要选择一个符合你需要的。这可能是一个有用的入门(我通过@qwr的回答找到了这个)