我一直负责研究如何为高可用性，高stream量，dynamic，基于Flash的Web应用程序进行大规模部署。 这个应用程序很有可能会增长到200万用户或者更多。
当然，到了真正做到这一点的时候，我可能会引进一位专家来帮助我。 现在，这是全部的理论，我只想得到一个好主意，如何做到这一点。
这是我目前的想法：
我的工作主要是找出硬件，以及如何部署和维护硬件。
至于维护这个野兽，我正在研究Slack，Rightscale，Landscape，VMware。
我也在考虑将其部署在亚马逊EC2上，但是我更愿意自己来架设，因为从长远来看，它会更便宜。 我可以从这个机架开始，并添加EC2实例，如果需要更多的。
你觉得怎么样，这是矫枉过正？ 不够？ 我有没有想到，有什么我失踪？
感谢任何阅读和回应的人！
在EC2上开发它。 如果/当你想在内部移动它时，build立你自己的Eucalyptus集群并将它移到那里，这很容易，因为Eucalyptus是一个开源的EC2基础设施克隆。
从我读过的高扩展性的angular度来看，您最好的策略是简单地解决当前的瓶颈问题，并开始规划下一个瓶颈。 除非您使用的软件和硬件与已经使用过的软件和硬件完全相同，并且除非使用模式与缩放比例相同，否则现在无法计划您的整个增长。 你需要计划当前阶段和下一个阶段，而不是200万用户的标记。
我认为你已经严重高估了你的要求。 作为一个参考点，运行nginx +龙卷风的双核四核处理器前面的一个2 ipvs主/主进程处理iframe中的7个元素的2.86亿〜2400字节的iframe adblocks和完整的adstream日志logging。 每个节点的利用率<40％（允许单个节点发生故障而不会“过载”）
您所说的第二个问题是dynamic的“基于闪存”，这意味着您的大部分带宽将用于初始闪存应用程序 – CDN或caching的候选者。
您的dynamicFlash应用程序可能会使用gevent或某些类似的技术来回发送小的消息。 这些消息可能很小。 您的应用程序的情报将可能不得不parsing，login和回应这些，但是，每天有200万用户，每80个互动是1.6亿互动。 在高峰时间，你可能要处理3600吨。 如果你需要300台服务器来处理，你需要重写你的代码。
如上所述虚拟化您的networking服务器可能会浪费性能。 即使是最轻的虚拟化也不会像裸机一样快。
但是，在不了解您的架构或系统devise的情况下，给出的任何意见都是猜测，因为这些要求是松散的。
你为什么要把你的Web服务器放在VM环境中？ 它只会导致你不需要的开销，它们都应该提供来自同一个存储的数据，并且具有相同的configuration。
我可以回复haproxy服务器的大小。 使用最新的Linux内核（> = 2.6.27）可以从TCP拼接function中受益，这将为您节省大量的CPU带宽。 使用可以find的CPU的最高频率。 不需要多核心，更好地发现一个3.6 GHz的双核比2 GHz的8核心。 对于RAM，每20K并发连接计数1GB。 将两个VIP用于由Keepalived守护进程pipe理的LB（主动/主动），并在DNS中通告它们。 这样，你的两个LB会同时工作，如果两个LB都失败了，另一个接pipe它的IP。 我知道一个非常大的网站，在两个经过适当调整的LB上运行了超过30万个并发连接，并有相当的余量。
不要小看网卡。 与其他解决scheme（1或10 GbE）相比，Myricom的Myri10GE网卡等一些网卡的延迟较低，可以极大地节省数据包处理成本和服务器上并发连接的数量。
关于Apache服务器，haproxy可以将传入的连接集中到更less的传出，从而减less服务器的数量，并保护它们免受stream量激增。 但是，这可用于短连接。 不要依靠长轮询请求，聊天或大file upload/下载。
看看systemimager
就这个话题阅读，我强烈推荐Theo Schlossnagle的Scalable Internet Architectures 。 它涵盖了高可用性部署和横向可扩展性的细节。
http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
此外， 高性能网站和云应用程序体系结构可能值得一看，但后者可能稍微过时。