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