架构设计(一):从单服务器模式到负载均衡设计

架构设计,服务器,模式,负载,均衡,设计 · 浏览次数 : 560

小编点评

**架构设计(一):从单服务器模式到负载均衡设计** **单服务器模型** * 最简单的架构,用户直接连接到网络服务器进行访问。 * 用户访问 URL,DNS 服务器解析域名,返回客户端一个 IP 地址。 * 用户通过 IP 地址访问到真正的服务,服务返回对应的 HTML 页面。 **负载均衡模型** * 将多个服务器部署到一个集群中,并配置负载均衡器。 * 用户访问 URL,请求发送给集群中的任何一个服务器。 * 负载均衡器根据请求的类型和资源分配,将请求转发给相应的服务器。 **负载均衡器的功能** * 提高网站的可用性,降低响应时间。 * 减少服务器的负载,延长服务提供时间。 * 降低数据库连接的压力,提高数据库性能。 **负载均衡器的类型** * **水平扩展:**在服务器上增加配置,如 CPU、内存 等资源。 * **垂直扩展:**在一台服务器上增加配置,例如 CPU 和内存。 **负载均衡器的优点** * 提高网站的可用性。 * 降低服务器的负载。 * 降低数据库连接的压力。

正文

架构设计(一):从单服务器模式到负载均衡设计

作者:Grey

原文地址:

博客园:架构设计(一):从单服务器模式到负载均衡设计

CSDN:架构设计(一):从单服务器模式到负载均衡设计

单服务器模型是最简单的一种架构,参考如下图
img

用户访问一个 URL,URL 会先到 DNS 服务器进行域名解析,然后返回给客户端一个 IP 地址,客户端会通过这个 IP 地址访问到真正的服务,服务接收到客户端请求以后,返回对应的 HTML 页面,就完成了整个过程。

当然,以上是静态页面,相对复杂的应用会配置数据库,架构如下

img

在选择数据库的时候,会涉及数据库选型问题,有两类比较主流的数据库可以选择,即关系型数据库非关系型数据库

关系型数据库也被称为关系型数据库管理系统(RDBMS),关系型数据库以表和行来表示和存储数据。其优势是你可以使用 SQL 语句在不同的数据库表中执行连接操作。

非关系型数据库也被称为 NoSQL 数据库。 一般被归纳为四类:键值存储、图形存储、列存储和文档存储。非关系型数据库一般不支持连接操作。

对于大多数开发者来说,关系型数据库是最好的选择,因为它们已经存在了40多年且一直运行良好;然而,如果关系型数据库不适合你的特定用例,

比如

  • 应用需要超低的延迟。

  • 数据是非结构化的,或者你没有任何关系型数据。

  • 只需要对数据进行序列化和反序列化(JSON、XML、YAML等)。

  • 需要存储大量的数据

则非关系型数据库可能是正确的选择。

关系型和非关系型数据库的选型可以参考这个网站:DB-Engines Ranking

随着用户数量增多,单服务架构的设计可能会导致一些问题,比如:

用户是直接连接到网络服务器的。如果网络服务器离线,用户将无法访问网站,在另一种情况下,如果许多用户同时访问网络服务器,并达到网络服务器的负载极限,用户一般会遇到较慢的响应或无法连接到服务器。

针对这些问题,有两种主要的思路,分别是:水平扩展垂直扩展

垂直扩展,简言之就是在你的服务器上增加更多的配置,比如 CPU、内存 等资源。

水平扩展,简言之就是增加更多的服务实例来扩展的服务能力。

当流量较低时,垂直扩展是一个很好的选择,简单直接。但是垂直扩展也有严重的局限性,因为

  • 不可能在一台服务器上增加无限的 CPU 和内存。

  • 垂直扩展不具备故障转移和冗余功能。如果一台服务器瘫痪了,整个网站/应用程序就会完全瘫痪。

由于垂直扩展的局限性,水平扩展对于大规模的应用来说是比较理想的。

水平扩展的一个技术就是负载均衡。可以比较好的解决这个问题。架构如下

img

如图所示,用户直接连接到负载均衡器的公共 IP。在这种设置下,网络服务器已经无法被客户直接访问。为了提高安全性,服务器之间的通信使用了私有 IP。私有 IP 是一个只能在同一网络中的服务器之间到达的 IP 地址;但是,它在互联网上是无法到达的。负载均衡器通过私有 IP 与网络服务器进行通信。
在图中,在添加了一个负载均衡服务器和第二个 Web 服务器后,我们成功地解决了没有故障转移的问题,并提高了Web层的可用性。

  • 如果服务器1离线,所有的流量将被路由到服务器2。这可以防止网站脱机。我们还将在服务器池中添加一个新的健康的Web服务器,以平衡负载。

  • 如果网站流量迅速增长,而两台服务器不足以处理这些流量,负载均衡器可以优雅地处理这个问题。你只需要向网络服务器池添加更多的服务器,负载平衡器就会自动开始向它们发送请求。

说明

本文的所有图例见:从单服务器模式到负载均衡设计

参考资料

System Design Interview

与架构设计(一):从单服务器模式到负载均衡设计相似的内容:

架构设计(一):从单服务器模式到负载均衡设计

# 架构设计(一):从单服务器模式到负载均衡设计 作者:[Grey](https://www.cnblogs.com/greyzeng/) 原文地址: [博客园:架构设计(一):从单服务器模式到负载均衡设计](https://www.cnblogs.com/greyzeng/p/16980532.h

架构设计(二):数据库复制

架构设计(二):数据库复制 作者:Grey 原文地址: 博客园:架构设计(二):数据库复制 CSDN:架构设计(二):数据库复制 在架构设计(一):从单服务器模式到负载均衡设计中提到了数据库类型的选择, 针对大数据量,高可用的场景,数据库复制是一种比较好的方式,其中多个数据库实例之间可以是主/从关系

[转帖]Nginx(2):架构设计与工作流程

https://cloud.tencent.com/developer/article/1886166?areaSource=&traceId= 这些天呐,实在是给我看晕了。起因自然还是对 nginx 不是很了解哈。那我是来看什么的?一开始就从细节出发,有点管中窥豹,不得全貌了。 图来自网络 架构设

一次redis主从切换导致的数据丢失与陷入只读状态故障

## 背景 最近一组业务redis数据不断增长需要扩容内存,而扩容内存则需要重启云主机,在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障,这里记录分享一下。 ## 业务redis高可用架构 该组业务redis使用的是一主一从,通过sentinel集群实现故障时的自动主

从“一云多芯”支持,看多元算力的全栈云方案

摘要:华为云Stack如何在不同CPU架构下,构建信创云平台多元算力的全栈解决方案?本文将为你具体阐释。 本文分享自华为云社区《从“一云多芯”支持,看多元算力的全栈云方案》,作者:徐安 华为云Stack资深架构师。 背景 华为云Stack作为华为云在政企市场的品牌,是政企客户智能升级的首选平台。随着

2024-04-27:用go语言,在一个下标从 1 开始的 8 x 8 棋盘上,有三个棋子,分别是白色车、白色象和黑色皇后。 给定这三个棋子的位置,请计算出要捕获黑色皇后所需的最少移动次数。 需要注意

2024-04-27:用go语言,在一个下标从 1 开始的 8 x 8 棋盘上,有三个棋子,分别是白色车、白色象和黑色皇后。 给定这三个棋子的位置,请计算出要捕获黑色皇后所需的最少移动次数。 需要注意的是,白色车可以垂直或水平移动,而白色象可以沿对角线移动,它们不能跳过其他棋子。 如果白色车或白色象

2024-06-15:用go语言,Alice 和 Bob 在一个环形草地上玩一个回合制游戏。 草地上分布着一些鲜花,其中 Alice 到 Bob 之间顺时针方向有 x 朵鲜花,逆时针方向有 y 朵鲜花

2024-06-15:用go语言,Alice 和 Bob 在一个环形草地上玩一个回合制游戏。 草地上分布着一些鲜花,其中 Alice 到 Bob 之间顺时针方向有 x 朵鲜花,逆时针方向有 y 朵鲜花。 游戏规则如下: 1.游戏从 Alice 开始。 2.每个回合中,当前玩家必须选择顺时针或逆时针,

2024-06-05:用go语言,给定三个正整数 n、x 和 y, 描述一个城市中由 n 个房屋和 n 条街道连接的情况。 城市中存在一条额外的街道连接房屋 x 和房屋 y。 需要计算对于每个街道数(

2024-06-05:用go语言,给定三个正整数 n、x 和 y, 描述一个城市中由 n 个房屋和 n 条街道连接的情况。 城市中存在一条额外的街道连接房屋 x 和房屋 y。 需要计算对于每个街道数(从 1 到 n), 有多少房屋对满足从一个房屋到另一个房屋经过的街道数正好为该街道数。 在结果数组中

实践篇(三):如何有效评审软件架构图?

设计意图的传达是架构可视化关注的重要维度,在技术方案评审过程中不可避免的会出现各种各样的架构图或设计图,这些图形化表述在设计意图传达效果层面表现不一,本文从图形化的视角为软件架构图的评审关注点提供了参考。

我对《RAG/大模型/非结构化数据知识库类产品》技术架构的思考、杂谈

1、前言 在6.28/29的稀土掘金开发者大会RAG专场上,我们公司CEO员外代表TorchV分享了我们在《RAG在企业应用中落地的难点与创新》 其中最后分享了两个观点: AI在应用场景落地时有三个特点:功能小、质量高、价值大 如果说做产品是把一横做好的话,那么去做企业落地服务就是一竖,从需求和方案