负载均衡这个词，由两个词组成：负载、均衡。这两个词的概念是什么呢？
负载：负荷，压力
均衡：平衡，尤其是某一方面的平衡
那么联起来就是：将压力以某种规则"平均"的分配，目的是为了提升整体的抗压能力。
本文及后续文章所说的负载均衡，指的都是 负载均衡服务器（设备），而不是广义上的负载均衡。
比如你是研发组长，面对上级下达的一堆任务，你需要根据组内成员的实际情况去分配，比如个人能力、当前研发任务量等等。在此种环境下，你就是负载均衡，所以负载均衡实际上更准确的概念应该是叫做：
任务分发器
从基本概念出发，我们可以看出负载均衡有两个核心点，即：
- 分配规则的制定
- 分配规则的执行
在网络世界中，负载均衡就是将来自网络的请求分配给后面真正执行处理的服务器，如下图：
仔细想一下，图中是存在一定风险的：
- 负载均衡本身会不会成为系统性能瓶颈？
- 负载均衡本身如何处理单点故障，即负载均衡挂了怎么办？研发组长生病了，新任务进来如何分配。
这里风险如何处理也是需要考虑到的，不然只能是实验产品。
现在，再回到起源，宏观来看，我们面对的矛盾是：
个体处理压力的能力有限 和 整体需要处理大量压力 之间的矛盾
解决这个矛盾不外乎两个方面：
- 提升个体的处理能力
- 增加个体数量
个体处理能力的提升再高也有上限，且无法避免单点故障。所以必须要群策群力。
那么个体数量增加以后，整个系统就变成 任务分发系统 + 任务处理群，如图：
当我们考量任务分发系统时，负载均衡可以独立作为一个任务分发系统，也可以作为子部件构成这样的系统，还有没有其他形式的方案来构建任务分发系统呢？
答案当然是有的。
总结
综合上述分析，当我们面对负载均衡这样一种事物时，我们要探讨的问题如下：
- 负载均衡服务器的分配规则有哪些？既然是规则，其实是和实现无关的，我们要看看通用规则有什么，并且这些规则肯定是基于某个应用场景的。
- 负载均衡基于这些规则如何进行转发？因为是基于TCP/IP协议栈的，所以转发必然涉及到协议层面的处理。
- 系统中引入负载均衡解决了系统原本的单点故障并且提升了性能，凡是都有利弊，引入负载均衡后带来了哪些新的问题？面对这些问题，负载均衡又是如何处理的？
- 当我们把整体系统抽象成：任务分发+任务执行 后，我们就可以想到，任务的分发不一定只能通过负载均衡服务器来实现，也可以有其他的方案，那么其他方案是什么呢？
思考脉络和问题梳理清楚了，我们才可以带着问题去学习，通过在学习中解决问题，这样收获才最大。
后续章节，就按照问题列表一 一学习。
