设计负载均衡器
需求分析
互联网服务往往要处理来自全世界的流量,但是,一 个服务器只能够同时服务有限数量的请求。因此,通常我们会有一个服务器集群来共同处理这些流量。那么问题来了,怎样才能够让这些流量均匀地分布到不同的服务器上呢?
从用户到服务器,会经过很多的节点和不同层级的负载均衡器。具体来讲,我们这次设计的需求是:
- 设计第7层的负载均衡器,位于数据中心的内部。
- 利用来自后端实时的负载信息。
- 服务每秒千万级的流量以及10 TB每秒级别的吞吐量。
补充:如果服务 A 依赖服务 B,那我们称 A 是 B 的下游服务,而 B 是 A 的上游服务。
挑战
为什么负载均衡会很难做?答案是很难收集准确的负载分布数据。
按照数量分布 ≠ 按照负载分布
最简单的做法是根据请求的数量,随机地或者循环地分布流量。然而,实际的负载并不是根据请求的数量来算的,比如有些请求很重很耗CPU,有些请求很轻量级。
为了更加准确地衡量负载 ,负载均衡器得保持一些本地状态 —— 比如,存当前的请求数、连接数、请求处理的延迟。基于这些状态,我们能够使用相应的负载均衡的算法 —— 最少连接、最少延迟、随机 N 取一。
最少连接:请求会被导向当前连接数最小的服务器。
最少延迟:请求会被导向最少平均反应时长且最少连接数的服务器。还可以给服务器加权重。
随机 N 取一 (N 通常是 2,所以我们也可以称之为二选一的力量):随机的选两个服务器,取两者之中最好的,能够避免最坏的情况。
分布式的环境
在分布式的环境中,本地的负载均衡器难移了解上下游服务完整的状态,包括
- 上游服务的负载
- 上游服务可能超级大,因此很难选择一个合适的子集接入负载均衡器
- 下游服务的负载
- 不同种类的请求的具体处理时间很难预测