我对Google应用引擎如何通过虚拟化实现可扩展性提出疑问。例如，当我们将云应用程序部署到Goodle应用程序引擎时，到我们应用程序的用户数量增加时，我认为Google会自动生成一个新的虚拟服务器来处理用户请求。云应用程序第一次在一个虚拟服务器上运行，现在它在两个虚拟服务器上运行。谷歌实现了 通过虚拟化实现可扩展性，以便谷歌中的任何一个系统 基础架构可以运行应用程序的代码 - 甚至连续两次 发布到同一应用程序的请求可能不会转到同一服务器
有谁知道应用程序如何在Google上的两个虚拟服务器上运行。它如何向两个虚拟服务器发送请求并同步数据，使用CPU资源，......？
Google是否有任何文件指出此问题和虚拟化工具？
答案 0 :(得分：1)
现在这是一个具体的答案，因为我们不知道Google是如何做到这一点的。但我可以解释一个负载均衡器如何在Apache中运行，它运行在类似的概念上。哎呀，也许Google正在使用Apache负载均衡变量。 Read more here.
基本上，简单的Apache负载均衡结构至少包含3台服务器：1个负载均衡器和1个负载均衡器。 2个镜像服务器。负载均衡器基本上是外部世界流量的交通警察。对使用负载平衡的网站发出的任何公开请求实际上都会请求“头”机器。
在该负载平衡机上，配置选项基本上确定幕后哪些从属服务器将内容发送回负载均衡器以进行传递。这些“奴隶”机器基本上是常规的Apache Web服务器，可能是IP限制的，只能将内容传送到主头负载均衡器机器。
因此假设负载均衡结构中的两个从属服务器都是100％相同。负载均衡器将随机选择一个来从＆amp;如果它可以在合理的时间内抓取内容，“奴隶”现在成为源。如果由于某种原因从机慢，负载平衡器然后决定“太慢，继续前进！”并转到下一台机器。它基本上就每个请求做出类似的决定。
最终结果是更快＆amp;更容易访问的服务器是首先服务的。但由于内容全部代表负载均衡器后面的公共访问，外界没有人知道差异。
现在让我们假设负载均衡器背后的网站流量非常大，需要将更多服务器添加到群集中。没问题！只需将现有的从站设置克隆到尽可能多的新机器，调整负载均衡器即可知道这些从站存在并且让它管理代理。
现在困难的部分是让所有机器保持同步。这完全取决于网站的需求和用法。因此，DB重型网站可能会为每台计算机上的每个数据库使用MySQL镜像。或者可能有一个完全独立的数据库服务器本身可能正在镜像＆amp;集群到其他数据库。
所有这一切都表明，Google成功的关键在于平衡其负载平衡基础架构的工作方式。这并不容易我不知道他们做了什么。但我确信上面概述的基本概念在某种程度上得到应用。