我记得与那些到目前为止使用Ruby on Rails的人交谈,然后在他们达到极限时不得不放弃它,或者发现它最终过于僵化.我忘记了细节,但它可能与使用多个数据库有关.
所以我想要知道的是Ruby on Rails之外的特性/要求是什么,或者至少需要这样的扭曲,以便使用另一个更灵活的框架更好,即使你可能不得不失去一些优雅或额外写样板代码.
Rails(不是ruby本身)很自豪能成为"Opinionated Software".
这在实践中的意义在于,rails的作者有一定的目标受众(他们自己基本上)并且专门针对那个目标.如果目标受众不需要X功能,则不会添加.
在我的头脑中,显然不支持人们可能关心的事情:
数据库中的外键
一次连接到多个DB
SOAP Web服务(自rails 2.0起)
连接到多个数据库服务器一次
也就是说,使用插件扩展rails非常容易,并且有一些插件可以将所有上述功能添加到rails中,还有更多,所以我不会将这些作为限制.
另一个需要注意的是,rails是围绕使用MVC创建CRUD Web应用程序的想法而构建的.如果你正在尝试做一些不是CRUD网络应用程序的东西(比如twitter,它实际上是一个消息传递系统,或者你是疯了,想要使用像ASP.NET网页这样的模型)那么你也会遇到问题.在这种情况下,你最好不要使用铁轨,因为你基本上是试图用自行车零件建造船.
很可能,你遇到的问题不仅可以通过快速插件或一天或两天的编码来修复,这些问题都是底层C Ruby运行时的固有问题(内存泄漏,绿色线程,废话性能等) .
Ruby on Rails不支持开箱即用的两阶段提交,如果您的数据库支持的应用程序需要保证立即一致性并且您需要使用两个或更多数据库模式,则可能需要这样做.
对于许多Web应用程序,我冒昧地认为这不是一个常见的用例.人们可以很好地支持与两个或更多数据库的最终一致性.或者可以支持与一个数据库模式的立即一致性.如果您的应用程序必须支持mondo数量的交易,那么前一种情况是一个很大的问题(请注意技术术语:).后一种情况更典型,Rails也没问题.
坦率地说,在您遇到真正的可伸缩性问题之前,我不会担心使用Ruby on Rails(或任何框架)的限制.建立一个杀手级应用第一,然后再担心可扩展性.
澄清:我正在考虑Rails会有一个难以支持的事情,因为它可能需要从架构的根本转变.我将慷慨并包含一些属于gem/plugin生态系统的东西,例如外键实施或SOAP服务.
通过两阶段提交,我的意思是尝试在一个事务上下文中对物理上不同的服务器进行两次提交.
用例#1用于两阶段提交:您已对数据库进行了群集,因此您有两个或更多数据库服务器,并且您的架构分布在两个服务器上.您可能希望提交两个服务器,因为您希望允许ActiveRecord认为执行遍历不同服务器的"外键映射".
用例#2用于两阶段提交:您正在尝试实现消息传递解决方案(抱歉,我是白天的J2EE开发人员).消息生成器提交到消息传递代理(一个服务器)和数据库(另一个服务器).
京公网安备 11010802040832号 | 京ICP备19059560号-6 