海边有磅秤吗?

简短回答: 你可以扩展像Hell Yah这样的海边应用程序

长回答: 在IT领域,缩放是一回事,但它有两个维度:

1. 雌雄异体的
2. 垂直的

几乎每个人都在考虑垂直尺寸的缩放。直到英特尔和朋友们遇到了一些物理障碍,开始添加内核以弥补目前无法添加兆赫的情况。

这时,我们开始更加意识到水平缩放是一种可行的方法。

我为什么要告诉你这个?

因为seaside是一个运行在VM中的smalltalk映像,这与单核处理器服务器中系统的情况大致相同。

以此为基础,你可以通过制作服务器集群来扩展Web应用程序。这是自然的事情,这是容错的事情,是拓扑智能的事情,是灵活的事情,我想你得到了这个想法……

因此,如果在扩展方面,您与Intel&Friends的做法相同,则采用水平方式。垂直方式更便宜(这将引导您使用和昂贵一样好的IBM和Sun服务器)。

ROR应用程序通常是水平缩放的。谷歌有无数便宜的服务器来做他们的事情。不管人们多么戏剧化地想给你留下深刻印象,向你扔下一堆健忘的Twitter鲸鱼,它都是完美的。

如果他们和你谈论这件事,你只是礼貌地听他们说什么,但记住这一点:

1. 完美是善的敌人。
2. 未完成的完美永远不会像做好事那样有价值。

顺便说一句,Amazon也做了类似的事情(而且它有点结合了地理位置,所以它们可以增加通过离您最近的集群处理请求的机会)。

另一方面,avi扩展dabbledb(twitter收购的基于海边的网络应用公司)的方式是每个客户帐户使用一个虚拟机(启动和关闭那些按需运行的应用程序)。

在图像中有大量的状态并不会使缩放变得不可能或复杂。

只是不同而已。

方法是使用一个使用粘性会话的负载均衡器,这样您就可以有一个映像来关注用户会话的所有请求。这样,负载均衡器后面的任何工作者图像都可以访问给定应用程序的任何用户。差不多就是这样。

要做到这一点,您需要在工作人员之间共享持久对象。所有用户数据库都需要工作人员随时访问,并且需要处理好并发性。

我们以这种方式设计了可伸缩的空运。

它在经济上也很方便,因为您可以从非常小的N开始(取决于第一台服务器的RAM),并根据需要增加它,直到达到硬件限制。

一旦达到硬件限制,只需向集群中添加另一台主机并重新配置平衡器(以及对数据库的访问)。

简单、经济、优雅。

雷蒙·莱昂在他的(优秀的)博客上分享了他在海边度假的一些经历。您可以阅读关于配置和调优Seaside的示例代码的非常具体的想法。

享受:-

http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing http://onsmalltalk.com/scaling-seaside-redux-enter-the-penguin http://onsmalltalk.com/stateless-sitemap-in-seaside

http://dabbledb.com/ 规模似乎相当大。此外,一个人可以使用 GemStone GLASS 经营海滨

关于这个 interview Avi Bryant,海边的创建者和联合创始人Dabbledb 解释它们如何使其具有规模。

据我所知:

• 每个客户都有自己的吱吱声 图像。

• 当客户到来时,Apache会根据用户名来决定将其发送到哪个端口。

• 基于端口,它启动客户的吱吱声图像。

• 这样它就可以增长到无限多的服务器。

我认为这个解决方案是基于他们的应用程序的具体情况为他们工作的,每个客户不需要在他们之间共享信息。所以不需要集中式数据库。

不管怎样,最好是看面试,而不是看我那一半做的总结。

是的,海边的比例下降得出奇。单个开发人员可以很好地为小团队创建和维护复杂的应用程序。

[几年后再回到这里] 这实际上比放大更重要。计算机速度仍在增长,99%的应用程序现在可以在一台机器上运行。开发速度,尤其是维护速度现在完全控制了TCO。

我会将您的问题稍微改为:Seaside是否阻止/阻止您创建可扩展的应用程序?我通常会说没有。Seaside没有默认的方法来存储您的数据(就像它上面的PHP没有一样,尽管Seaside给了您一些额外的选项),而我的印象是与您的数据交互往往是扩展时最大的障碍。

如果您想像使用Rails一样将数据存储在一个整体的SQL数据库中,那么您可以这样做。也可以使用对象数据库。或者,您可以为每个用户使用单独的对象数据库,或者为每个项目使用单独的数据库,或者为每个用户和项目使用单独的数据库。或者可以将所有内容存储在一系列平面文件中,也可以将数据作为对象存储在虚拟机的内存中。

而且由于连续性,您不需要在每次网页调用时从数据存储中重新提取数据。当您使用桌面应用程序时,您可以在用户开始与它交互时从数据存储中提取数据,设置适当的变量,然后在Web调用之间使用这些变量,直到用户完成数据的处理,此时您可以更新数据存储。当你不共享状态时,你必须在每个网络电话上访问数据存储。

当然,这并不意味着缩放是免费的,它只是意味着你有一个更大的领域来搜索缩放解决方案。

综上所述,对于许多应用程序来说,Rails的扩展要容易得多,因为存在大型的Rails托管解决方案(以及相关的PHP),它可以为您提供大量的资源,而无需租用和设置自定义框。

这些只是我从阅读和与人交谈中得到的印象。

我只是提醒大家,在法罗的成功案例中有一个链接:一个海边的Web应用程序,在阿根廷有多达1000个并发用户,可以购买大型医疗保险。

Pharo success stories

ISSIS跟踪:

• 负载平衡:Apache作为代理/平衡器(带会话的循环 亲和性)
• 服务器设置:3台不同服务器上的5个Pharo映像(Linux和Windows 2003)
• 图形用户界面:非常基于Ajax。所有代码都是用smalltak:seaside 3.0、seaside jquery集成和jqwidgetbox编写的。
• 持久性:glorp(或mapper)和opendbx(db client)
• 数据库:大型PostgreSQL和MS SQL Server DBS

从维基百科的文章来看,这是一头猪。在此之前,它还没有达到我听说过的程度。:)