【问题标题】:What would be better architecture out of these, to scale a system?什么是更好的架构来扩展系统?
【发布时间】:2017-08-27 11:14:49
【问题描述】:

假设,我正在运行一台运行 nodejs、websocket 服务和 redis 服务的机器。我想从规模的角度来分配系统,这两种方法哪个更好:

  1. 在不同的机器上运行每个服务。所以两台机器用于负载均衡器后面的 Websocket 服务,一台机器用于 nodejs,三台机器用于 Redis。

  2. 继续在同一台机器上运行所有服务,现在将这台机器克隆到另外五台机器上,并在负载均衡器后面运行它们。

我一直致力于/看到第一个架构。但是一位经验丰富的开发运营人员建议我采用第二种方法,他说这种方法易于管理并且可以更好地扩展。

另外,这并不特定于 nodejs、redis 等。我提到它们是为了更好地解释。总的来说,我想知道哪种架构更好。

【问题讨论】:

  • 没有更好的通用架构。这取决于您的非功能性要求,例如可用性、数据一致性、响应时间、(峰值)负载、业务逻辑的复杂性、机器数量(复制数量)、用例......

标签: architecture server scalability


【解决方案1】:

第二种方法通常更好,特别是如果您可以配置负载均衡器以将流量路由到具有处理请求所需的所有数据的节点。这种类型的架构称为Shared Nothing Architecture,因为不同的节点是完全隔离的,一个节点的故障不会影响另一个节点。这种类型的架构几乎是线性扩展的(不是线性的,因为您仍然需要复制数据以实现高可用性,但如果可能的话,这也可以异步完成)。

或者,您可以在所有节点中拥有所有数据...但这可能会很昂贵,并且复制可能会成为一个问题,尤其是在您需要同步复制的情况下。

【讨论】:

    【解决方案2】:

    查看此问题的一种方法是通过The Art of Scalability 一书中提出的 AKF 可扩展性立方体。它是一个使用立方体来查看可伸缩性的框架,其中 3 个轴中的每一个都代表不同的伸缩方式。

    x 轴:克隆服务和数据,以便可以轻松地跨实例分配工作。 y 轴:按数据或工作划分工作职责。或者是数据和工作的结合。提供故障隔离。 z 轴:基于请求/客户的工作分离。能够按地理位置拆分服务

    理想的情况是组合 1 个或多个秤 - 取决于您的需要。随着您的需要,您可以开始沿所有 3 个维度进行缩放。这将为您提供几乎无限的规模。

    【讨论】:

      猜你喜欢
      • 2012-07-22
      • 1970-01-01
      • 2017-10-26
      • 2012-03-09
      • 2010-09-05
      • 2010-11-01
      • 2012-10-29
      • 1970-01-01
      • 2010-12-28
      相关资源
      最近更新 更多