单个数据库
>关联来自不同服务的数据可以通过外键约束绑定在一起
>分析提取更易于编写,执行速度更快
>如果发生灾难,将平台恢复到一致状态会更容易
>对于由多个服务引用的数据,一个服务缓存的数据很可能很快被另一个服务使用
>预先管理和监控更简单,更便宜
多个数据库
>维护工作,硬件问题,安全漏洞等不一定会影响整个平台
>假设每个数据库都在不同的硬件上,扩展多台计算机比扩展一台大型计算机产生更多的性能优势
从运营的角度来看,这个平台中的每个服务都有自己的数据库,或者它们都在同一个数据库中,这样更有利吗？哪些关键因素可以回答这个问题？
解决方法
在这种情况下,为每个服务分离底层数据库是合乎逻辑的或必需的.但是,如果你有相互依存的服务,那么从分裂中获得的东西很少(也许没有).
我建议阅读诸如HighScalability.com这样的网站,这些网站深入研究了永不失败类型网站所采用的架构.我最近最喜欢的一个是在Coding Horror上提到的Netflix Chaos Monkey的故事.
解决你问题中的几点：
In the event of a disaster,restoring the platform to a consistent
state is easier.
这是事实,但你应该考虑如何更好地解耦这些服务,这样就不会成为问题.或者,有一些方法可以确保跨多个数据库的同步,例如transaction marks in SQL Server.
For data that is referenced by multiple services,data cached by one
service is likely to be used soon after by another service.
分布式缓存解决方案(memcached等)可以在这方面提供帮助,但是你违反了服务独立性原则.这可以与两个服务直接相互通信,或者更糟糕的是具有服务访问和其他数据存储,完全绕过服务接口.不可避免地,数据将是相关的,并且将由调用平台在服务之间传递,棘手的决定倾向于围绕哪个服务将拥有哪些数据. StackOverflow或Programmers站点可能更适合帮助解决更常见的SOA问题.
Assuming each database is on separate hardware,scaling up yields more
performance benefits.
当然,跨越多个较低规格的机器扩展比扩展单个机器更便宜.尽管如此,当考虑额外开发工作和操作复杂性的软成本时,较低的硬件成本可能在总体拥有成本中相形见绌.
如果这不是SOA,并且您只是因为后勤原因而不同团队/供应商正在构建此平台的组件服务,请坚持使用单个数据库并完全忽略上述所有内容！ 原文链接：https://www.f2er.com/mssql/80492.html
