在APP开发项目中,服务器架构是关系到整个系统的性能的关键因素。无论是自己买的服务器,还是用云服务器,负载均衡都是提高系统性能的主要方式。


如果你是早期的云计算服务提供商,你可以使用一个单独的客户 web 服务器,为它分配一个 IP 地址,并配置一个 DNS(域名系统)记录来将它与一个易读的名字关联起来,之后通过 BGP(边界网关协议)来传播 IP 地址,这是种在网络间交换路由信息的标准方式。


在冗余的网络路径上分发流量,在不可用的基础设施周围进行路由来提高可用性(会导致不对称路由等现象),这些从本质上讲并不是负载均衡。


随着客户服务流量的增长,业务方希望获得更高的可用性。你添加了另一个具有公网 IP 地址的 web 服务器,并更新了 DNS 记录来将用户引导到这两个 web 服务器(希望稍微公平一些)。直到某一个 web 服务器意外宕机前,这种方法都是可行的。假设你快速检测到故障,可以通过更新 DNS 配置(手动方式或使用软件)来停止引用损坏的服务器。


遗憾的是,由于 DNS 记录是有缓存的,这些缓存记录可能会在客户端或者 DNS 层次结构中的其他名称服务器中,在它们过期之前,大约有 50% 的请求仍然可能失败。DNS 记录的 TTL(time to live,生存时间)通常为几分钟或更长,因此这会对系统的可用性造成重大影响。


更糟糕的是一些客户端完全忽略了 TTL,所以一些请求将在一段时间内被定向到已经宕机的 web 服务器上。设置非常短的 DNS TTL 也不是什么好主意;这意味着 DNS 服务的负载增加,延迟增加,因为客户端不得不更加频繁地执行 DNS 查找。如果你的 DNS 服务不可用,那么使用更短的 TTL 访问服务将更快地降级,因为缓存服务 IP 地址的客户端更少。


为了解决这个问题,你可以添加一对冗余的 4 层(Layer 4)网络均衡器,并在相同的虚拟 IP(VIP)地址提供服务。它们可以是硬件设备,或者像 HAProxy 这样的软件均衡器。这意味着 DNS 记录仅仅指向虚拟 IP 而不再做负载均衡。

4 层均衡器将来自因特网的流量均衡地引导至后端服务器。这通常是基于每个 IP 包的 5 元组的哈希(一个数学函数)完成的:源 IP 地址和目标 IP 地址,以及端口加上协议(如 TCP 或 UDP)。这种方式快速、高效(并且仍然维持了 TCP 的基本属性),并且不需要均衡器维护每个连接的状态。


4 层均衡器可以进行健康检查,并仅仅向那些通过检查的 web 服务器发送流量。与 DNS 均衡不同的是,如果一个 web 服务器崩溃,将流量重定向到另一个 web 服务器上的延迟很小,尽管现有连接将被重置。


4 层均衡器可以做加权平均,处理不同容量的后端,它为运维人员提供了强大的能力和灵活性,同时在计算能力方面相对便宜。

稳定

产品高可用性高并发

贴心

项目群及时沟通

专业

产品经理1v1支持

快速

MVP模式小步快跑

承诺

我们选择声誉

坚持

10年专注高端品质开发
  • 返回顶部