针对单一数据库架构的多个应用

我们目前正在为我们的内部应用程序创建新策略.我们目前有大约10-15个应用程序直接针对同一个数据库.这显然不是很好,我们想评估我们的选择.据我所知,我们必须做出选择:

>复制数据库并使用复制等使它们同步
>在数据库和10-15应用程序之间创建一个新的应用程序.
>其他?

我非常想听听你对此的看法.我相信第二个选择是要走的路,这也为我们提供了一个实现缓存的有效层.但是,您如何为所有应用程序公开此图层? Web服务/休息是否可行,或者还有其他更好的方法吗?

解决方法

我认为流行语的答案是“面向服务的架构” – 这确实是选项2.

这是一项大规模的工作,需要探索许多令人兴奋的死角 – 但基本上,不要考虑数据库和表格,而应考虑这15个应用程序所需的服务.有些可能是共享的,有些可能是特定于一个应用程序.找到一种向应用程序公开这些服务的方法 – 但请记住,Web服务调用可能比等效的直接数据库调用慢得多,因此不要将“面向服务的体系结构”视为必须在所有地方引入Web服务 – 它更像是一种思维方式而非产品规格.

复制和同步 – 根据我的经验 – 创建非常脆弱的系统,其故障模式会伤害大脑甚至思考.

其他 – 好吧,你实际上并没有说出你要解决的具体问题是什么.如果它的性能解决性能问题最便宜的方法就是抛出硬件问题.如果它是可管理性 – SOA可以帮助解决这个问题 – 但它通常还会在混合中引入额外的基础架构,这也需要维护.确保你真正清楚你的架构选择是什么,因为没有单一的“最佳”解决方案 – 所有这些都是关于权衡.

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...