Appengine / Amazon / Heroku实例如何工作?

时间:2012-11-17 09:11:54

标签: google-app-engine heroku amazon-s3 cluster-computing

我知道有很多关于这个主题的文档,但我只是在寻找一个简单的解释,Appengine或其他一些提供的实例是如何工作的。

如果应用软件并不复杂,我知道它是如何工作的,但我对以下情况感兴趣。

假设我写了一个程序来监听端口8888上的传入连接?如果我在普通服务器上运行该服务器,它将打开端口8888并开始监听,但理论上它只能接受65.535连接(因为任何系统上只有可用的端口)。在实践中,这个数字相当低,但让我们谈谈理论。如果我想扩展该应用程序,我需要在局域网中添加另一台计算机,并提供一个负载均衡器,可以在两台计算机上均匀地加载传入连接。但问题并不止于此:如果传入的客户端需要访问彼此的数据,这意味着我还需要在后台同步数据库,因此两个服务器都保存数据库中所有数据的副本(无论这个数据库是什么)。这可能还需要额外配置服务器并编写一段额外的代码以添加到服务器程序中。我们刚刚遇到了无数问题,但让我们再次概述它们:

  1. 将另一台服务器添加到LAN中。
  2. 配置两台服务器以支持群集。
  3. 在服务器进程中编写其他代码,以了解正在进行的群集。
  4. 负载均衡传入连接。
  5. 复制后端数据库中的数据。
  6. 但这还不是整个故事。如果我需要在两个用户需要实时聊天的情况下实现具有群集功能的双通信聊天服务器,该怎么办?如果第一个用户连接到第一个服务器而第二个用户连接到第二个服务器,如何将数据从第一个发送到第二个,反之亦然,这是非常复杂的问题。这给表增加了另一个问题:

    1. 连接到不同服务器的用户之间的实时通信。
    2. 上述问题非常复杂,无法轻易解决。我们需要无数个小时来思考它,并逐一解决它。但像Appengine / Amazon / Heroku这样的解决方案表示他们会关注这一切。所以这是我的问题。

      1. 各种实例如何真正起作用,我对以下三个感兴趣:

        • 应用服务引擎
        • 亚马逊
        • 的Heroku
      2. 他们如何扩展服务器应用程序,以便它同时支持超过65,000个连接用户?

      3. 他们如何能够确保即使有更多实例正在运行,无论哪个实例从数据库中提取数据,后端数据库中的数据都是相同的?

      4. 连接到不同实例的用户之间的实时通信是否真的能够按照应有的方式运行?

      5. 如果所有软件都在某种硬件上运行,那么它们如何实现相同数量的实例才能协同工作,这通常需要10个硬件服务器才能连接到集群。

        < / LI>

        我想上述问题的解释可以真正帮助开发人员/程序员/管理员更好地理解实例的真正工作方式。如果我们不知道它是如何工作的,我想我们无法真正决定使用哪种产品。

        谢谢

1 个答案:

答案 0 :(得分:3)

  1. 各种实例如何真正起作用?

    Appengine:像流程基础一样工作。你没有真正的服务器。 App Engine将尝试使用云架构师为您的Web服务提供服务,并计算您使用的资源数量,例如cpu时间,数据库查询,Web请求等等。您无需进行任何扩展或扩展。

    亚马逊(EC2实例):您创建并运行实例,然后像普通物理服务器一样使用它。扩展和架构像物理服务器。您可能需要Amazon S3存储和Amazon RDS数据库。

    Heroku:Heroku实例调用dyno。每个dyno服务于每个工作服务,例如Web进程,后台进程,调度程序进程。例如,如果您创建1个web dyno,就像您有1个apache Web服务器,其中1个进程正在运行以服务您的网站。每个服务请求需要在处理下一个请求之前完成,并且队列请求超时是30秒。您可以根据需要创建任意数量的dyno。 Heroku附带了postgresql,你需要为缓存大小付费。

  2. 为了扩展,我已经提到了如何在之前的答案中进行扩展。

    支持超过65k的连接。您可以根据需要为任何连接创建任意数量的实例。

  3. 数据库存储在单独的系统中。根据您的描述,我认为您的应用程序在每台服务器上都有单独的数据但是当你转向PaaS时,它就像你在后端有一个数据库。每个实例都将连接到同一个数据库,确保无论用户连接到何处,都可以获得相同的数据。

  4. 这取决于您如何构建应用程序。例如,如果您使用以下流程创建聊天应用程序:

    • 发件人

      1. 发件人客户端向聊天服务器发送消息
      2. 聊天服务器存储消息到数据库
    • Reciever

      1. 接收客户端从聊天服务器提取更新消息
      2. 聊天服务器从DB获取更新消息
      3. 聊天服务器向接收方发送更新消息

    通过以上流程,您无需担心每个用户连接到哪个实例,因为每个用户总是从同一个数据库获取相同的数据(可能是对数据库的延迟读/写,但最终用户将获得同样的消息)。

  5. 您不需要这样做,因为您有一个单一的数据库。在后端,您可以根据需要扩展数据库,但前端到应用程序将是相同的。