Seaside 被称为“异端网络框架”。使它成为异端的原因之一是它有很多共享状态。然而,在我目前的理解中,这会阻碍轻松扩展。
另一方面,Ruby on rails 共享尽可能少的状态。众所周知,它可以很好地扩展,即使与现代 smalltalk vms 相比它的速度很慢。flickr 使用 php 并且已经扩展到一个非常大的基础设施......
那么有人对Seaside的扩展有一些经验吗?
Seaside 被称为“异端网络框架”。使它成为异端的原因之一是它有很多共享状态。然而,在我目前的理解中,这会阻碍轻松扩展。
另一方面,Ruby on rails 共享尽可能少的状态。众所周知,它可以很好地扩展,即使与现代 smalltalk vms 相比它的速度很慢。flickr 使用 php 并且已经扩展到一个非常大的基础设施......
那么有人对Seaside的扩展有一些经验吗?
Ramon Leon 在他的(优秀的)博客上分享了他在升级海边的一些经验。您可以通过示例代码阅读有关配置和调整 seaside 的非常具体的想法。
享受 :-)
http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing http://onsmalltalk.com/scaling-seaside-redux-enter-the-penguin http://onsmalltalk.com/无国籍站点地图在海边
简短的回答: 你可以像地狱一样扩展 Seaside 应用程序
长答案: 在 IT 领域,扩展是一回事,但它有两个维度:
几乎每个人都想过在垂直维度上进行缩放。直到英特尔和朋友们遇到了一些物理障碍并开始添加内核以弥补当前无法添加 MHz 的情况。
就在那时,我们开始更加意识到水平缩放是要走的路。
我为什么要告诉你这些?
因为 Seaside 是一个运行在 VM 中的 smalltalk 映像,这与单核处理器的服务器中的系统情况大致相同。
以此为基础,您可以通过创建服务器集群来扩展 Web 应用程序。这是自然的事情,是容错的事情,是拓扑智能的事情,是灵活的事情,我想你明白了......
所以,如果为了扩展,你和 intel & friends 一样,你会采用横向的方式。并且它甚至比垂直方式更便宜(这将引导您使用与昂贵一样好的 IBM 和 Sun 服务器)。
RoR 应用程序通常水平扩展。谷歌有无数便宜的服务器来做他们的事。无论人们多么想给你留下深刻印象,向你扔一堆令人难忘的推特鲸鱼,它都可以正常工作。
如果他们和你谈论这件事,你只需要有礼貌,听听他们说的话,但要记住这一点:
顺便说一句,亚马逊也做了类似的事情(它有点像一对夫妇的地理位置,所以他们增加了用离你最近的集群来处理你的请求的机会)。
另一方面,Avi 扩展 dabbledb(Twitter 收购的基于 Seaside 的 Web 应用程序公司)的方式是每个客户帐户使用一个虚拟机(按需启动和关闭这些虚拟机)。
图像中有很多状态并不会使缩放变得不可能也不复杂。
只是不同。
可行的方法是使用使用粘性会话的负载均衡器,这样您就可以让一个图像关注用户会话的所有请求。你做的事情是负载均衡器后面的任何工作映像都可以参与给定应用程序的任何用户。差不多就是这样。
为了能够做到这一点,您需要在工作人员之间共享持久对象。所有用户数据库都需要工作人员随时可以访问,并且需要很好地处理并发性。
我们以这种方式设计了可扩展的气流。
它在经济上也很方便,因为您可以从非常小的 N 开始(取决于您的第一台服务器的 RAM)并按需增加它,直到达到硬件限制。
一旦达到硬件限制,您只需将另一台主机添加到集群并重新配置平衡器(以及对数据库的访问)。
简单、经济、优雅。
http://dabbledb.com/似乎可以很好地扩展。此外,还可以使用GemStone GLASS来运行 Seaside。
在这次采访中,Seaside 的创建者和联合创始人 DabbleDB 的 Avi Bryant 解释了他们如何使其规模化。
据我了解:
每个客户都有自己的 Squeak Image。
当客户来时,Apache 根据用户名决定将其发送到哪个端口。
它基于端口启动客户的 Squeak Image。
这样它就可以增长到无限数量的服务器。
我认为这个解决方案适用于他们基于他们的应用程序的细节每个客户不需要在他们之间共享信息。所以不需要集中式数据库。
无论如何,最好看采访而不是我的半成品总结。
是的,Seaside 的规模缩小得惊人。单个开发人员可以很好地为小组创建和维护复杂的应用程序。
[几年后回到这个问题]这实际上比扩大规模重要得多。计算机速度仍然有很大的提高,现在 99% 的应用程序都可以在一台机器上运行。开发速度,尤其是维护现在完全支配了 TCO。
我将您的问题稍微改写为:Seaside 是否会阻止/阻止您创建可扩展的应用程序?我通常会说不。Seaside 没有存储数据的默认方式(就像 php 没有,尽管 Seaside 为您提供了一些额外的选项),我的印象是与您的数据交互往往是扩展时的最大障碍.
如果您想将数据存储在单一的 SQL 数据库中,例如使用 rails,您可以这样做。或者您可以使用对象数据库。或者您可以为每个用户使用单独的对象数据库,或为每个项目使用单独的数据库,或者为每个用户和项目使用单独的数据库。或者,您可以将所有内容存储在一系列平面文件中,或者您可以将数据作为对象存储在 VM 的内存中。
并且由于延续,您不需要在每次网页调用时从数据存储中重新获取数据。当您使用桌面应用程序时,您可以在用户开始与之交互时从数据存储中提取数据,设置适当的变量,然后在网络调用之间使用这些变量,直到用户完成数据,此时您可以更新数据存储。当您不共享状态时,您必须在每次网络通话时访问数据存储区。
当然,这并不意味着扩展是免费的,它只是意味着您有一个更大的域来搜索扩展解决方案。
综上所述,对于许多应用程序来说,rails 将更容易扩展,因为存在用于 rails(和 php)的大型托管解决方案,可以为您提供大量资源,而无需租用和设置自定义盒子。
这些只是我阅读和与人交谈的印象。
我刚刚提醒,Pharo 的成功案例有一个链接:一个拥有多达 1000 个并发用户的 Seaside Web 应用程序,用于阿根廷的大型健康保险。
Issys 跟踪:
从维基百科的文章来看,它是一头猪。在此之前,它还没有扩展到我听说过的地步。:)