我们正在构建一个包含多个服务的网络平台，每个服务都有自己的基础数据。这些服务是按照面向服务的体系结构的原则独立构建的，但是它们会针对潜在的相关数据进行交易。我们正在考虑这些服务应该共享一个大数据库还是每个都有自己的数据库。（我们计划在Windows 2008群集上使用SQL Server 2008 Enterprise。）

我们已经考虑过的每种方法的一些优点包括：

单一数据库

• 可以通过外键约束将来自不同服务的数据关联在一起
• 分析摘录更易于编写和执行
• 在发生灾难的情况下，将平台恢复到一致状态更加容易
• 对于由多个服务引用的数据，一个服务缓存的数据很可能会在另一服务之后不久使用
• 管理和监控更简单，更便宜

多个数据库

• 维护工作，硬件问题，安全漏洞等未必会影响整个平台
• 假设每个数据库都在单独的硬件上，则与扩展一个大型机相比，扩展多台计算机可获得更多的性能优势。

从操作角度来看，此平台中的每个服务都拥有自己的数据库，或者它们都位于同一个数据库中，是否更具优势？哪些关键因素可以回答这个问题？

我认为，真正的SOA系统（在伪SOA上，无处不在的ntier /分布式系统）的关键区别在于，离散服务之间的交互应该为零。实现此目标后，就可以并且应该构建由这些服务组成的任何应用程序以容忍任何一致性部件的故障。故障会降低功能，但会维护服务。

在这种情况下，为每个服务分离基础数据库是合乎逻辑的，也有必要的。但是，如果您有相互依赖的服务，那么从拆分中获得的收益很少（也许没有）。

我建议阅读诸如HighScalability.com之类的网站，以深入研究永不失败类型的网站所采用的体系结构。我最近的最爱之一是Netflix的《混沌猴子》的故事，该故事在《编码恐怖》中被提及。

解决您的问题中的几点：

万一发生灾难，将平台恢复到一致状态更加容易。

的确如此，但是您也许应该考虑如何更好地分离这些服务，所以这不再是一个问题。另外，还有一些方法可以确保多个数据库之间的同步，例如SQL Server中的事务标记。

对于由多个服务引用的数据，由一个服务缓存的数据可能很快就会被另一服务使用。

分布式缓存解决方案（memcached等）在这里可能会有所帮助，但是您将违反服务独立性原则。这相当于两个服务直接相互通信，或者更糟的是，一个服务访问另一个数据存储，而完全绕开了服务接口。不可避免地，数据将是相关的，并且将由调用平台在服务之间进行处理，棘手的决定往往是围绕哪个服务将拥有哪些数据。StackOverflow或Programmers站点可能更适合于解决更一般的SOA问题。

假设每个数据库都在单独的硬件上，则扩展可带来更多的性能优势。

当然，在多个较低规格的计算机上进行扩展要比在单个计算机上进行扩展便宜。但是，如果考虑到额外的开发工作和操作复杂性的软成本，则较低的硬件成本可能会在总拥有成本中相形见.。

如果这不是SOA，而您只是出于逻辑原因，该平台的组件服务由不同的团队/供应商构建，请坚持使用单个数据库，并完全忽略上面的所有内容！:)