许式伟的架构课
许式伟
七牛云CEO
立即订阅
20090 人已学习
课程目录
已更新 72 讲 / 共 77 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师？
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石：无生有，有生万物
03 | 汇编：编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读：如何实现可自我迭代的计算机？
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备：交互的演进
11 | 多任务：进程、线程与协程
12 | 进程内协同：同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络：连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理：数字世界的守护
17 | 架构：需求分析 (上)
18 | 架构：需求分析 (下) · 实战案例
19 | 基础平台篇：回顾与总结
加餐 | 我看Facebook发币（上）：区块链、比特币与Libra币
加餐 | 我看Facebook发币（下）：深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发：浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战（一）：怎么设计一个“画图”程序？
27 | 实战（二）：怎么设计一个“画图”程序？
28 | 实战（三）：怎么设计一个“画图”程序？
29 | 实战（四）：怎么设计一个“画图”程序？
30 | 实战（五）：怎么设计一个“画图”程序？
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师，我需要成为“全才”吗？
32 | 架构：系统的概要设计
33 | 桌面开发篇：回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战（一）：“画图”程序后端实战
42 | 实战（二）：“画图”程序后端实战
43 | 实战（三）：“画图”程序后端实战
44 | 实战（四）：“画图”程序后端实战
45 | 架构：怎么做详细设计？
46 | 服务端开发篇：回顾与总结
加餐 | 如何做HTTP服务的测试？
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程：什么是工程师思维？
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量？
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇：回顾与总结
架构思维篇 (9讲)
57 | 心性：架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣？
59 | 少谈点框架，多谈点业务
60 | 架构分解：边界，不断重新审视边界
加餐 | 实战：“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
许式伟的架构课
登录|注册
35 | 流量调度与负载均衡
许式伟 2019-08-23
你好，我是七牛云许式伟。
相比桌面程序而言，服务端程序依赖的基础软件不只是操作系统和编程语言，还多了两类：
负载均衡（Load Balance）；
数据库或其他形式的存储（DB/Storage）。
为什么会需要负载均衡（Load Balance）？今天我们就聊一下有关于流量调度与负载均衡的那些事情。
上一讲我们画了服务端程序的体系架构图，如下：
什么是 “流量调度”？我们首先要了解这样几个常见的服务端程序运行实例（进程）相关的概念：
连接数；
IOPS；
流量，入向流量和出向流量。
我们知道，一个基本的服务端程序的服务请求，通常是由一个请求包（Request）和一个应答包（Response）构成。这样一问一答就是一次完整的服务。
连接数，有时候也会被称为并发数，指的是同时在服务中的请求数。也就是那些已经发送请求（Request），但是还没有收完应答（Response）的请求数量。
IOPS，指的是平均每秒完成的请求（一问一答）的数量。它可以用来判断服务端程序的做事效率。
流量分入向流量和出向流量。入向流量可以这么估算：
平均每秒收到的请求包（Request）数量 * 请求包平均大小。
同样的，出向流量可以这么估算：
平均每秒返回的应答包（Response）数量 * 应答包平均大小。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(21)
- Geek_4b2920讲到lvs时说到"有办法避免出现这种请求失败的情况吗？"，接着就说nginx是怎么去做的，感觉这里不太衔接呢，lvs不能做服务端重试？还是什么原因？没太明白
作者回复: lvs 不太好做，在 VS/DR 模式下应答包（response）根本就不经过它，所以它连请求包（request）是否已经应答都不知道，就别提失败后重试了。如果在 VS/NAT 模式下，它也需要理解应用层的协议后才能重试，那它就不是网络层负载均衡，而是应用层负载均衡了。
2019-08-24 6 
leslie老师今天说的都是前端的：可是好像负载均衡不止这些吧，软件一旦并发高了不是从整体的去做均衡么，不仅仅是这些吧？就像数据库方面我经常会去做一主多从、读写分离，甚至说软硬件很多时候都会做相应的事情，可是总觉得这个如何去整体的把握这种均衡确实觉得不容易把握。
老师的课程一路断断续续努力学到现在整体的收获还是让我感觉不一样：如果可以的话，希望老师对于负载均衡这个问题进行适当的扩展，可能这是大多从业到一定年份的IT从业者会碰到的一个困惑问题，这个合理性确实有时很难整体合理的把握。作者回复: 存储的扩展不是基于负载均衡，这个下一讲就会有所涉及。
2019-08-23 1 3
Void_seT1、首先，因为绝大多数情况下负载均衡服务器的简单转发消耗的系统资源更少，而业务逻辑的处理往往需要更多的系统资源，那么，在服务器配置相当的情况下，负载均衡服务器就比业务处理服务器能处理更多的请求；
2、如果，负载均衡服务器的处理能力与业务处理服务器的处理能力相当，那这种依靠负载均衡服务器来做负载均衡的方式效率就极低（约为50%），资源使用率也很低（约为50%），那么，在架构演进的过程中，这种负载均衡方式一定会被淘汰，取而代之的会有目前httpdns等其他的负载均衡方式。2019-08-23 2- CoderLim负载均衡软件的抗压能力往往比业务服务器强很多，为什么？
负载均衡的功能只是转发，相对简单，没有耗时操作，主要的瓶颈应该是最大连接数和内存2019-08-23 2 
williamcailvs调度器和业务服务器都用vip，请求过来了，它怎么通过vip找到的是调度器，而不是业务服务器作者回复: 文章中有解释，arp 协议是通过 ip 得到 mac，这时只有调度器响应 arp。也就是说，在全局，vip 是被认为绑在调度器上。只有各个业务服务器自己以为自己也绑了vip。
2019-08-27 1 1
humorlvs调度器怎么做到只是修改了mac地址就能找到要转发的业务服务器的呢？我理解的网络层的转发是要先通过mac拿到ip，才能找到对应的机器的作者回复: 反过来了，是通过ip拿到mac。
2019-08-26 1 1
许童童老师这一节讲得很好，服务优雅升级配合负载均衡确实是很不错的解决方案。2019-08-23 1
业余爱好者负载均衡软件就是为了流量调度而生的，它主要是将请求路由到应用服务器，相比而言，应用服务器多了负载的业务处理这一步，所以抗压能力不如负载均衡软件。2019-08-23 1
杜建平https://mp.weixin.qq.com/s/y8AkMDFkA_vyOcRnbS0Fyg
补充2019-12-01
科春第 1 步，客户端发起请求，其 IP 报文中，源 IP 为用CIP ，目标IP是VIP，源MAC地址是CMAC，目的mac地址是DMAC。
我任务在真实环境中，MAC层是会在三层设备上重写的。也就是说在这个场景里，CMAC报文在经过路由器后，CMAC会变成路由器连接交换机接口的MAC地址。同样DMAC在数据包发送初期，是路由器连接C端的接口的MAC不会是LVS服务器的MAC。2019-10-04 1- Geek_88604f如果负载均衡策略选择的是根据ip地址做hash，那么当某个后台服务器故障了，怎么做故障迁移？
作者回复: 一般用的多个hash函数，一个不行用另一个。当然简单+1试下一个服务器也可以。
2019-08-29 1 - 兢看了一些文章，有提到QPS和TPS的概念，之前就对这两个概念非常混淆，现在又学到一个IOPS，感觉这几个概念说的是不同的东西，但又觉得是一个东西，请问他们之间细微的差别再哪里
作者回复: QPS是Queries per second，TPS是Transactions per second，IOPS是Input/Output per second。每秒测量的东西有所不同。
2019-08-28 
居培波中小型产品(项目)用Nginx+Tomcat完成简单负载均衡部署，nginx不需要处理产品业务需求，只需转发客户端请求即可。利用Nginx高并发、轻量级等特征满足一定用户量的增长。2019-08-28
黄伟洪Docker是基于应用层的负载均衡？作者回复: 我猜想你说的docker应该是指k8s。k8s应该是四层（传输层）和七层（应用层）。我们这里谈的是三层（网络层）和七层。
2019-08-23
Aaron Cheung学习了 业务流量不大……肿么办2019-08-23 1
觉一门深入 长时薰修2019-08-23
Jxin1.课后题：假如网关层负载率小于应用层，同时本次请求是需要rsp的。那么网关层该干嘛还是能干嘛，问题是整个应用集群的负载量将受到网关层的约束，也就是说水平扩容无状态应用服务并无法增长负载量。（单机瓶颈依然存在，java现流行的可编程网关负载感觉就会存在这方面问题）
2.存储请求和计算请求是两码事。存储请求的请求分发往往意味着业务数据模型的拆分（分布式数据一致性）。存上面是分流了，但除非整个业务拆分贯穿全链路，不然查时就头疼了（比如根据地区将整个业务数据拆分存储）。而计算请求基本都是可以水平扩的。2019-08-23 1
Charles从文章的描述，负载均衡软件之所以性能高，是因为相对业务服务器，少了高级语言层面的编译解析执行、复杂业务逻辑处理、IO读写存储、以及响应过程的处理，而是直接通过网络层以及CPU和内存解决了一切需求2019-08-23
歌在云端请问一下多机房的是怎么处理的，比方说在深圳，上海，北京各部署对应的服务，怎么保证广东那边的请求优先进入到深圳的机房里面去啊？是通过DNS吗。还有假如客户端增加，是不是可以三种均衡一起弄作者回复: 1、是通过dns；2、三个均衡方式是可以一起的
2019-08-23 2- 借我一生1，在硬件层做负载均衡，比如F5 也是一种常见且高性能的做法。
2，要避免最外接入层单点，且需要解决超高并发下单台负载均衡服务器性能瓶颈，只能上DNS轮询技术2019-08-23
收起评论