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