设计一个平台：一个数据库还是多个数据库？

Question

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

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

单一数据库

• 来自不同服务的相关数据可以通过外键约束绑定在一起
• 分析提取更易于编写且执行速度更快
• 发生灾难时，更容易将平台恢复到一致状态
• 对于被多个服务引用的数据，一个服务缓存的数据很可能很快就会被另一个服务使用
• 预先管理和监控更简单、更便宜

多个数据库

• 维护工作、硬件问题、安全漏洞等不一定会影响整个平台
• 假设每个数据库都在不同的硬件上，扩展多台机器比扩展一台大机器会产生更多的性能优势

从操作的角度来看，这个平台中的每个服务都有自己的数据库，还是都放在同一个数据库中更有利？哪些关键因素决定了这个问题的答案？

Answer 1

在我看来，真正的 SOA 系统（相对于伪 SOA、越来越普遍的 ntier/分布式系统）的关键区别在于离散服务之间应该有零交互。在实现这一点的情况下，您从这些服务组成的任何应用程序都可以并且应该构建为容忍任何一致部分的故障。故障会降低功能，但会维持服务。

在这种情况下，为每个服务分离底层数据库是合乎逻辑的或必需的。但是，如果您拥有相互依赖的服务，则拆分几乎没有（可能什么都没有）获得。

我建议阅读诸如HighScalability.com 之类的网站，这些网站深入研究了永不失败类型网站采用的架构。最近我最喜欢的故事之一是Coding Horror中提到的Netflix Chaos Monkey的故事。

解决您问题中的几点：

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

这是真的，但您或许应该考虑如何更好地分离这些服务，这样就不再是问题了。或者，有一些方法可以确保跨多个数据库同步，例如SQL Server 中的事务标记。

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

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

假设每个数据库都在不同的硬件上，向上扩展会产生更多的性能优势。

当然，在多台较低规格的机器上横向扩展比纵向扩展一台机器更便宜。但是，当考虑到额外开发工作和操作复杂性的软成本时，较低的硬件成本在总拥有成本中可能相形见绌。

如果这不是 SOA，并且您只是遇到此平台的组件服务由不同团队/供应商出于后勤原因构建的情况，请坚持使用单个数据库并完全忽略上述所有内容！:)