构建微服务架构我遇到了同一微服务实例之间数据共享的问题。
我有微服务，它大量使用它的数据源——每个服务请求都会导致数据库请求（通常是插入）。该服务将被大量使用，我计划在负载均衡器后面隐藏多个实例。这里提出了一个问题：这些实例应该使用 ONE 数据库（数据库会成为瓶颈吗？）还是 MULTIPLE（每个实例的数据源）？
【问题讨论】：
标签： database architecture microservices
根据我的 mSOA 架构经验，我从未见过
MULTIPLE（每个实例的数据源）
被使用。即使您打算大量加载它，最常见的数据库本质上也支持多线程访问。通常数据库系统的瓶颈（或最慢的部分）是磁盘。我们不得不多次扩展我们的集群（如果你在云中相对便宜，但可扩展性也可能成为一个问题，因为需要更多的线程来管理和执行扩展的数据库系统）。请记住，某些 RDBMS 使用临时数据库 (tempdb)，该实例上的所有数据库都使用该临时数据库进行排序、散列、临时变量等。多线程和拆分此 tempdb 文件可用于提高 tempdb 的吞吐量，从而提高整体服务器性能。
自从我现在与Orchard 合作以来，我不得不说存在一些极端情况，当您对一个实例的操作没有完全（和及时）同步时。即使在正确的身份验证之后，这也会导致对资源的访问被拒绝（在事件注册之后）。
我打算在负载均衡器后面隐藏多个实例
这是适合您的应用服务器的设计，因此使用数据库集群也应该是合适的。针对完整的答案 - 你可以考虑DWH，以防你有很多服务并且你希望能够从他们的所有数据库中进行一些数据挖掘和分析。
【讨论】：
很大程度上取决于您的实际用例，但我认为后写或回写可能是您的解决方案之一。 This 链接讨论了 EhCache 的技术，我认为应该有其他缓存支持该功能，你可能想谷歌一下。
【讨论】：
每个微服务实例拥有一个数据库实例是一种非常不寻常的架构。如果您担心数据库上的负载，您可以将其集群以获得更高的吞吐量，但是，插入不会导致太多负载。
如果您担心数据库会成为瓶颈，我建议您研究一下 NoSQL 数据库。 NoSQL 数据库旨在更好地扩展以实现高吞吐量并很好地处理大量数据。当然，缺点是它们不能很好地处理复杂的数据模型。
【讨论】：
这实际上取决于您的可扩展性要求，以及您的微服务实例如何/是否需要协作以提供单一结果。这有助于了解权衡是什么：
将所有内容保存在一个数据库中
更简单的配置
不与您的服务的其他实例进行协调或通信 需要
将数据库分开
请求的完整答案可能分布在微服务中 实例 在这种情况下，您增加了沟通和 协商解决请求 当你失去它时处理数据 微服务节点（即使数据库还在up，也拿不到 直到一个具有正确配置的新设备重新启动）
配置复杂度增加
【讨论】：
我的方法是服务本地数据库（阅读：每个实例的数据源）。在内存中或在同一个 Pod 中。为了在启动时同步始终新鲜的数据库，我将使用 Apache Kafka。一旦服务开始初始化，它就会向 Kafka 查询它感兴趣的所有条目（注意 compact log-Kafka 的功能，它只返回实体的最近状态）填充其 DB 并开始服务请求。
这当然会增加启动时间，但好处是，数据库可以是服务希望它成为的任何技术或方案（这甚至可以随着服务的版本而变化）。此外，不需要 DB-Cluster，但您需要正确配置的 Kafka-Service，但这也可以用于您的服务之间的事件溯源。
【讨论】：