负载均衡与服务器架构

news/2024/11/19 19:45:10/

2.5 WebServer、负载均衡、服务器架构

Nginx 与负载均衡

  • 反向代理

    1. 将用户请求转发给内部服务器，保护内网拓扑结构

                      / static file              /cache hit─>Redis/NoSQL/                          //       /Gunicorn + Django-1─>cache miss─>MySQL/PgSQL
client─>NginX─>HaProxy─Gunicorn + Django-2\Gunicorn + Django-3

    2. 可以解析用户请求，代理静态文件

  • NginX负载均衡

    • 轮询:

      upstream backserver { server 192.168.0.14; server 192.168.0.15; 
} 

    - 权重: weight```upstream backserver { server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; } ```- IP哈希: ip_hash```upstream backserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; } ```- fair```upstream backserver { server server1; server server2; fair; } ```- url_hash```upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; } ```- 最小连接数: least_conn

  • 其他负载均衡

    • F5: 硬件负载均衡设备, 性能最好, 价格昂贵(30-50一个，买一对)
    • LVS: 工作在 2层 到 4层 的专业负载均衡软件, 只有 3 种负载均衡方式, 配置简单，中国人（章文嵩）开发
      • 七层网络模型：ISO标准
      • 四层网络模型：TCP工业实现

  • HAProxy: 工作在 4层 到 7层 的专业负载均衡软件, 支持的负载均衡算法丰富

    • 性能比较: F5 > LVS > HAProxy > Nginx

  • LVS 的优势

    • 常规负载均衡

      进出都要经过负载均衡服务器. 响应报文较大, 面对大量请求时负载均衡节点本身可能会成为瓶颈

      发送请求: User -> LoadBalancer -> Server
接收响应: User <- LoadBalancer <- Server

    • LVS DR 模式

      LoadBalancer 与 Server 同在一个网段, 共享同一个公网 IP, 响应报文可以由 Server 直达 User

      发送请求: User -> LoadBalancer -> Server
接收响应: User <───────────────── Server

  • 可以不使用 Nginx, 直接用 gunicorn 吗？

    • 测试可以，正式不可以。

  • Nginx 相对于 Gunicorn 来说更安全

    • Nginx 可以用作负载均衡.

  • 处理静态文件相关配置

    location /statics/ {root   /project/bbs/;expires 30d;access_log off;
}location /medias/ {root   /project/bbs/;expires 30d;access_log off;
}

  • 面试题：

    • Nginx如何做负载均衡？
## 服务器架构

  1. 架构研究的 5 个方面

    • 高性能：请求再多，也能服务
    • 高可用：情况再糟，也能服务
    • 可伸缩：请求多了能服务，请求少了也能节省下来资源
    • 可扩展：能不断的加新的服务
    • 安全性：完成以上能力的前提是，不出安全问题

  2. 简单、实用的服务器架构图

    • 分层结构: 功能模块解耦合
    • 每层多台机器: 有效避免单点故障
    • 每层均可扩容: 能通过简单的方式提升服务器的性能、可用性、扛并发能力
                   User Request    cli_ip(12.23.34.45) -> ip_hash: 3|    |    |    |V    V    V    Vwww.example.com                ---> 第一层云服务负载均衡Nginx         Nginx							---> 云 115.2.3.11     115.2.3.12           /    |     \   /     |    \/     |       X       |     \V      V     V   V     V      V
AppServer  AppServer  AppServer  AppServer  ---> Gunicorn + Django
10.0.0.1   10.0.0.2   10.0.0.3   10.0.0.4   ---> AppServer 绑定内网 IP
weight:10  weight:20  weight:20  weight:20  ---> 权重|         |          |           |V         V          V           V
+------------------------------------------+
|           缓存层   主机 <--> 从机          |
+------------------------------------------+|         |          |           |V         V          V           V
+------------------------------------------+
|           数据库  主机 <--> 从机           |
+------------------------------------------+

服务器架构的发展

  • 早期服务器, 所有服务在一台机器

    [外链图片转存失败(img-2uD2dXPo-1566997409769)(./img/arch-1.jpg)]

  • 服务拆分, 应用、数据、文件等服务分开部署

    [外链图片转存失败(img-R2UBBZjs-1566997409770)(./img/arch-2.jpg)]

  • 利用缓存提升性能

    [外链图片转存失败(img-EZMFQXpX-1566997409771)(./img/arch-3.jpg)]

  • 应用服务器分布式部署, 提升网站并发量和吞吐量

    [外链图片转存失败(img-qhqAimF1-1566997409772)(./img/arch-4.jpg)]

  • 通过读写分离读写分离提升数据库性能和数据可靠性

    [外链图片转存失败(img-T8RLwfz5-1566997409773)(./img/arch-5.jpg)]

  • 使用反向代理、CDN、云存储等技术提升静态资源访问速度, 并能有效提升不同地域的访问体验

    [外链图片转存失败(img-1i3S2DlV-1566997409774)(./img/arch-6.jpg)]

  • 通过分布式数据库和分布式文件系统满足数据和文件海量存储需求, 并进一步提升数据可靠性

    [外链图片转存失败(img-W3AoAxnY-1566997409775)(./img/arch-7.jpg)]

  • 增加搜索引擎 和 NoSQL

    [外链图片转存失败(img-dZ33MaZR-1566997409776)(./img/arch-8.jpg)]

  • 增加消息队列服务器, 让请求处理异步化

    [外链图片转存失败(img-edHfdWHX-1566997409777)(./img/arch-9.jpg)]

  • 拆分应用服务器与内部服务

    [外链图片转存失败(img-VINsSSK2-1566997409778)(./img/arch-10.jpg)]

  • 微服务
    • flask restful

服务器计算

  • 费米预测

  • 服务器性能预估

    1. 首先需知道网站日活跃 (DAU) 数据

    2. 按每个活跃用户产生 100 个请求计算出 “每日总请求量”

      不同类型的网站请求量差异会很大, 可以自行调整一个用户产生的请求数

      每日总请求量 = DAU x 单个用户请求量

    3. 有了总请求量便可计算 “每日峰值流量”, 流量一般单位为 rps (requests per second)

      根据经验可知: 每天 80% 的请求会在 20% 的时间内到达

      由此可知:

                      每日总请求量 x 80%
每日峰值流量 = ───────────────────────86400 x 20%

    4. 一般带负载的 web 服务器吞吐量约为 300rps, 所以:

      WebServer 数量 = 每日峰值流量 / 300

    5. 得到 WebServer 数量以后, 再根据用户规模和请求量估算 Nginx、Cache、Database 等服务器的数量

  • 真实工作中服务器分配情况

    • 业务类型：
      1. 新闻网站：单用户产生请求：30 - 50
      2. 游戏网站：单用户请求可能：100 - 200
      3. 社区网站：单用户请求可能：50 - 100
      4. 平均可以取 100
    • 每日总请求 = DAU * 单用户每日请求
      1. DAU 20万：200000 * 100 = 20,000,000 两千万
      2. DAU 50万：5000 万
      3. DAU 100万：1亿
      4. DAU 200万：2亿
    • 峰值请求：
      1. 按经验所有请求在10小时内发生
        1. 峰值请求 = 每日总请求 / 10 / 3600
          1. 20万：20000000 / (10 * 3600) = 556
          2. 100万：556 * 5
          3. 200万：
      2. 按80%的请求在20%的时间内发生
        1. 峰值请求 = 每日总请求 * 80% / (24 * 20%)
          1. 20万DAU：926次/秒
    • 服务器预估
      1. 单 Web 服务器并发 500 rps
        1. 20万：峰值请求 / 500 = 2台
        2. 100万：556 * 5 / 500 = 6台
    • 相册服务
      1. 业务限制用户照片，或者等用户上传后自动帮用户压缩
        1. 5M = 500kB
      2. 预估每个用户多少张照片：
        1. 500张
        2. 2000张
      3. 每张照片多大 2-9
        1. 平均5M
      4. 一个用户总空间多少？
        1. 500 * 5MB = 2500MB = 2.5GB
        2. 2000 * 5MB = 10GB
      5. 每个服务器存多少张照片
        1. 10TB = 1000GB = 1000个用户
        2. 20万 200台服务器
      6. 用户20万
      7. 用户100万
      8. 用户200万

  • 面试题：

    • 你们有多少用户？
    • 多少日活？
    • 多少服务器？
    • 服务器并发有多高？

http://www.ppmy.cn/news/377748.html

相关文章

英伟达显卡不同架构_架构定输赢！盘点历代英伟达显卡能够成功亥市的根源

英伟达显卡不同架构_架构定输赢！盘点历代英伟达显卡能够成功亥市的根源

当我们评定一款显卡性能如何的时候&#xff0c;一般从核心频率、流处理器数量、显存、位宽、功耗等角度去衡量&#xff0c;但是在它们的背后&#xff0c;隐藏着真正的大boss&#xff0c;那就是显卡架构。无论英伟达还是AMD&#xff0c;每一代显卡都会及时对架构进行更新&#x…
阅读更多...
GPU架构变迁之AI系统视角：从费米到安培

GPU架构变迁之AI系统视角：从费米到安培

撰文 | 杨军 ‍每一代NV GPU的发布都会给业界带来新的想象空间。作为AI系统&#xff08;这里主要代指深度学习系统&#xff09;方向的从业者&#xff0c;最关心的自然是每一代GPU能够为AI系统领域带来哪些新的变量。 从之前NV GPU的甲方消费者&#xff0c;转变为现在的乙方提供…
阅读更多...
NVIDIA GPU 架构梳理

NVIDIA GPU 架构梳理

文中图片大部分来自NVIDIA 产品白皮书 TODO&#xff1a;英伟达显卡型号梳理 目录&#xff1a; 一、NVIDIA GPU的架构演变历史 二、Tesla 架构 三、Fermi架构 四、Kepler架构 五、Maxwell架构 六、Pascal架构 七、Volta架构 八、Turing架构 九、Ampere架构 十、Hopper架构 一、N…
阅读更多...
GPU架构演进十年，从费米到安培

GPU架构演进十年，从费米到安培

撰文 | Will Zhang 随着软件从1.0进化到2.0&#xff0c;即从图灵机演进到类深度学习算法。计算用的硬件也在加速从CPU到GPU等迁移。本文试图整理从2010年到2020年这十年间的英伟达GPU架构演进史。 1 CPU and GPU 我们先对GPU有一个直观的认识&#xff0c;如下图&#xff1a; 众…
阅读更多...
NVIDIA GPU硬件架构发展(截至2022年)

NVIDIA GPU硬件架构发展(截至2022年)

英伟达的GPU架构在近几年有了几次调整演进，如下所示 Fermi费米微架构 CUDA CORE是一种算术逻辑单元(ALU)，他的内部不包含光栅单元和纹理单元，CUDA CORE也就是流处理器sp(streaming processor)，是最基本的处理单元，具体的指令和任务
阅读更多...
NVIDIA GPU的架构代号

NVIDIA GPU的架构代号

NVIDIA GPU的架构代号 NVIDIA GPU的架构代号什么时候用gencode&#xff0c;什么时候用arch呢SM_num和gencode变量费米 Fermi&#xff08;cuda 3.2~cuda 8&#xff09;开普勒 Kepler&#xff08;cuda 5~cuda 10&#xff09;麦克斯韦 Maxwell&#xff08;CUDA 6~CUDA 11&#xff…
阅读更多...
Nvidia GPU Architecture--Fermi架构笔记

Nvidia GPU Architecture--Fermi架构笔记

1. GPU计算简介 Nvidia在1999年研发了图形处理器GPU。GPU在算术吞吐量和内存带宽上超过CPU。 尽管通用GPU模型展示了巨大的加速度&#xff0c;但是它也存在着几个缺点&#xff1a; &#xff08;1&#xff09;要求程序员需要图形API和GPU架构知识&#xff1b; &#xff08;2…
阅读更多...
改变翻天覆地 史上最全Fermi架构解读

改变翻天覆地 史上最全Fermi架构解读

前言&#xff1a;在经过漫长的4年开发期之后&#xff0c;众望所归的Fermi“费米”架构GPU终于诞生&#xff0c;这款GPU身上凝聚了众多“第一”&#xff0c;打破了很多芯片设计的世界记录。而更为深远的意义在于&#xff0c;代号GF100的Fermi架构GPU产品&#xff0c;在保持图形性…
阅读更多...
最新文章

Copyright @ 2022~2023