时间戳

首页 > 解决方案 > 为什么要将应用服务器拆分为读写服务器？

distributed-system - 为什么要将应用服务器拆分为读写服务器？

问题描述

我正在准备系统设计面试，在查看示例时，我看到类似这样的句子：“因为写操作需要大量时间来处理，这会使服务器端口保持忙碌，我们应该将我们的应用服务器拆分为读写节点。这应该提高我们系统的性能”。我无法接受这个决定。 这是最终的架构

我们有一个 Web 服务器，它将请求重定向到写入或读取节点。它仍然在等待写入节点处理请求，因此端口很忙。所以这意味着我们应该有单独的网络服务器来读写。因此我们需要两个域名：app.com和write-app.com。子域由与处理对主域的请求相同的服务器处理。所以引入一个像write.app.com这样的子域不是一种选择。对于这个解决方案，我们需要购买一个额外的域，设置一个 DNS 负载平衡器，一组 Web 服务器，在不同的节点上维护两个相关的功能（读/写）。在同一个节点上保留一个读/写 API 似乎更简单，但有更多的 Web 服务器和更多可用的实例。这样系统将不那么复杂。

当将读取和写入 API 拆分到不同节点有意义时：

  1. 更高效地处理写入请求的机器。它具有更强大（更昂贵）的 CPU，可以在写入操作受 CPU 限制而不是 IO 限制的情况下进行更快的计算。读取节点功能不那么强大（更便宜），但足以从数据库中查询数据、执行表示逻辑并发回 HTML。
  2. 写操作非常耗费资源：占用大量内存、占用 CPU 时间、大量访问磁盘。所以这台服务器上的所有读取请求都会降级。
  3. 我们的软件仅针对一定数量的节点获得许可，因此我们将使用该软件的机器隔离到单独的节点中。

您将应用服务器拆分为读写服务器的原因是什么？

标签： distributed-systemsystem-design

解决方案

分离为读取和写入 api 允许我们以独立的速率扩展我们的读取基础设施和写入基础设施。

对于读取繁重的系统，我们希望能够设置 100 倍于读取的基础设施，就像我们为写入所做的那样。将 api 分开允许它们在单独的实例中运行并单独扩展。

关于购买额外的域名。这在技术上是不必要的。例如：单个域可以指向可以根据 URI 路由到正确 api 实例的 apigw 或负载均衡器。例如：

app.com/write -> 编写 api

app.com/read -> 读取 api

推荐阅读