我们已经考虑过的每种方法的一些优点包括：
单个数据库
外键约束可以将来自不同服务的数据关联在一起
分析摘录更易于编写且执行起来更快
在发生灾难的情况下，恢复平台更容易达到一致状态
对于由多个服务引用的数据，由一个服务缓存的数据很可能会在另一服务之后不久被使用
管理和监视更简单，更便宜/>
多个数据库
维护工作，硬件问题，安全漏洞等并不一定会影响整个平台
假设每个数据库都位于单独的硬件上，与在大型机上进行扩展相比，在多台计算机上进行扩展可带来更多的性能优势
从操作角度来看，这个平台中的每个服务都拥有自己的数据库，或者它们都位于同一个数据库中，这是否更为有利？哪些关键因素可以回答这个问题？
#1 楼
我认为，真正的SOA系统（在伪SOA之上，无处不在的ntier /分布式系统）的关键区别在于，离散服务之间应该零交互。实现此目标后，您可以并且应该构建从这些服务编写的任何应用程序以容忍任何一致性部件的故障。故障会减少功能，但会维护服务。在这种情况下，逻辑上或有必要为每个服务分离基础数据库。但是，如果您拥有相互依赖的服务，那么从拆分中获得的收益很少（也许什么也没有）。
我建议阅读诸如HighScalability.com之类的站点，以深入了解该站点采用的体系结构。永不失败类型的网站。我最近最喜欢的一个故事是在《编码恐怖》中提到的Netflix混沌猴子的故事。
解决您的问题中的几点：
在发生灾难的情况下，将平台恢复到一致的状态更容易。
确实如此，但是您可能应该考虑如何更好地分离这些服务因此，这不再是一个问题。另外，还有一些方法可以确保多个数据库之间的同步，例如SQL Server中的事务标记。
对于由多个服务引用的数据，由一个服务缓存的数据
可能很快就会被其他服务使用。
分布式缓存解决方案（memcached等）在这里可能会有所帮助，但是您将违反服务独立性原则。这相当于两个服务直接相互通信，或者更糟的是，一个服务访问另一个数据存储，而完全绕开了服务接口。不可避免地，数据将是相关的，并且将由调用平台在服务之间进行处理，棘手的决定往往是围绕哪个服务将拥有哪些数据。最好使用StackOverflow或Programmers站点来解决更一般的SOA问题。
假设每个数据库都在单独的硬件上，则扩大规模可带来更多的性能优势。
/>
当然，在多台低规格机器上进行扩展要比在一台机器上进行扩展便宜。虽然，如果考虑到额外的开发工作和操作复杂性的软成本，那么较低的硬件成本可能会在总拥有成本中相形见<。
如果这不是SOA，而您只是一个案例如果出于后勤原因，该平台的组件服务由不同的团队/供应商构建，则只使用一个数据库，而完全忽略上面的所有内容！ :)
评论
关于分布式缓存解决方案的要点。但是，在SAN或数据库级别进行缓存时，这不是问题。在那里，由于部署拓扑（即，不同的服务恰好共享同一硬件），而不是由于服务之间的直接通信（如与memcached一起使用），您将获得缓存优势。
–尼克·查玛斯（Nick Chammas）
2011年10月21日19:00
评论
您最终选择了什么？@BobSinclar-现在已经有一段时间了，但是我们最终使用了多个数据库。
模式更改更困难还是没有？假设您必须更新每个数据库的架构。
@BobSinclar-我不是你要的。如果您已经按照SOA原则构建了平台，那么何时需要一次更新每个数据库的架构？不同的系统应该松耦合。
我知道已经有一段时间了，但是您介意共享您选择的不同数据库及其原因吗？