优刻得负载均衡ULB（UCloud Load Balancer）技术架构

作为UCloud优刻得一款提供给用户免费使用的产品，负载均衡ULB（UCloud Load Balancer），其技术架构如何呢？前文老刘博客《UCloud负载均衡服务ULB产品简介及功能概览》带大家初识负载均衡ULB，今天我们更深入地“探访”该产品背后的负载均衡技术架构奥秘。实操UCloud优刻得负载均衡产品参见《实验：通过负载均衡实现Web服务器高可用》。

ULB（UCloud Load Balancer）提供流量分发的能力，保证业务可扩展和高可用。支持内网和外网两种场景，支持请求代理和报文转发两种转发模式。ULB产品本身不收费，网络设置收取IP费用，其中内网免费，外网按带宽或流量计费，最大800M BGP带宽。下文将分别介绍ULB的的请求代理（下简称ULB7）和报文转发模式（下简称ULB4）的基本架构。

首先我们先来认识一个名词：UVER，这在下面描述中将会提及。UVER，即UCloud Virtual Edge Router，UCloud的公网流量转发中心。UVER从业务库中获取所有EIP的下一跳信息，并将EIP的流量进行封装转发。

内网报文转发ULB4

内网报文转发ULB4是基于DPDK技术自研的。单台服务器可以提供超过3000万并发连接，1000万 pps，10G线速转发能力。采用集群部署，单个集群至少4台服务器。利用ECMP+ BGP实现高可用。

内网报文转发ULB4采用了类似于DR的转发模式。内网负载均衡转发示意图如下：

如上图，报文转发ULB4集群通过向其上联的接入交换机宣告相同的VIP（虚拟IP），接入交换机配置了ECMP算法，能将流量负载均衡到多台ULB服务器上，从而构成了报文转发ULB4集群。当报文转发ULB4集群中某些服务器发生转发异常的时候，BGP报文转发也会停止转发，在三秒之内该报文转发ULB4服务器就会被剔出服务器集群，从而保证高可用，同时报文转发ULB4集群健康检查模块也将发出告警，使得工程师介入处理。此外同一个报文转发ULB4集群的服务器都是跨可用区分布的，保证报文转发ULB4集群跨可用区高可用。

报文转发ULB4中有模块专门负责后端节点的健康检查（目前仅支持TCP/UDP端口探测），并上报给报文转发ULB4Manager和ULB4转发服务器。报文转发ULB4转发服务器收到Client的业务报文后，将从状态正常的后端节点中选择一个，修改目的mac后打隧道送到后端节点，过程中其中的源IP和目的IP保持不变。报文转发ULB4模式下后端节点必须在LO口绑定报文转发ULB4的VIP（虚拟IP）地址，并监听服务，才能正确处理报文，并将回包直接单播送回给Client。这是一个典型的DR过程，因此内网报文转发ULB4可以直接看到Client的源IP。

外网报文转发ULB4

外网报文转发ULB4与内网报文转发ULB4类似，同样是基于DPDK技术自研的。单台服务器可以提供超过3000万并发连接，1000万 pps，10G线速转发能力。采用集群部署，单个集群至少4台服务器。利用ECMP+ BGP实现高可用。同样的，它采用了类似于DR的转发模式。外网负载均衡转发示意图如下：

与内网报文转发ULB4不同的是，外网流量是从公网进来的。Client访问报文转发ULB4的流量进入UCloud POP点，进入UVER（UCloud Virtual Edge Router）。UVER是UCloud自研的公网流量计算中心，能够从业务库中获知所有的EIP的下一跳信息，通过BGP引流后，将EIP的流量建立隧道送到相应的下一跳。一个报文转发ULB4的EIP会落到报文转发报文转发ULB4集群中的所有服务器上，因此UVER将这部分流量，按照一致性哈希算法送到报文转发ULB4集群各个服务器中。后续的流程与内网报文转发ULB4类似。Backend节点中需要将报文转发ULB的EIP绑定在LO口，并监听服务，而回程报文将直接送到UVER，并通过internet返回Client。

在外网报文转发ULB4中，集群健康检查模块将定时探测服务器的存活状态，如果发现有服务器有问题，则将通知UVER，将异常服务器剔除，从而保证高可用。同样的，外网报文转发ULB4集群也是跨可用区高可用的。

内网请求代理ULB7

请求代理ULB7基于Haproxy开发，单个实例可以支持超过40w pps，2Gbps，以及至少40万并发连接。架构如下图：

内网请求代理ULB7采用集群部署，单个集群至少4台服务器。租户底层共用服务器，但是采用Docker进行资源隔离和CPU的隔离。与报文转发ULB4采用的DR模式不同，请求代理ULB7采用的是Proxy模式（即Fullnat模式）。收到Client的请求之后，内网请求代理ULB7将client到请求代理ULB7 IP的连接，转化为请求代理ULB7的proxy IP到Backend（服务节点）实际IP的连接。因此Backend（服务节点）无法直接看到Client ip，只能通过X-Forwarded-For（HTTP模式）获取。

内网请求代理ULB7利用ECMP+ BGP实现高可用，内网请求代理ULB7服务器通过Quagga与上联交换机建立BGP连接。同集群下的多台服务器，将向上联交换机发起相同的VIP（虚拟IP）宣告。这样上联交换机会根据ECMP算法，将流量负载均衡到集群中的各台服务器上。当有服务器发生异常时，三秒内BGP会中断，从而将故障服务器踢出集群，保证服务仍然可以正常工作。

外网请求代理ULB7

请求代理ULB7基于Haproxy开发，单个实例可以支持超过40w pps，2Gbps，以及至少40万并发连接。ULB利用CPU的亲和性，实现核的隔离和资源控制。

与报文转发ULB4采用的DR模式不同，请求代理ULB7采用的是Proxy模式，也就是Fullnat模式。收到Client的请求之后，请求代理ULB7将client到请求代理ULB7 EIP的连接，转化为请求代理ULB7的proxy ip（代理IP）与Backend（服务节点）实际ip的连接。因此Backend无法直接看到Client ip。另外，节点健康检查模块是集成在请求代理ULB7进程中的，因此不需要额外的节点健康检查模块。

同样的，在外网请求代理ULB7中，集群健康检查模块将定时探测服务器的存活状态，如果发现服务器有问题，则将通知UVER，将异常服务器剔除，从而保证高可用。同样的，外网请求代理ULB7集群也是跨可用区高可用的。

请求代理和报文转发模式比对

相对于请求代理ULB7，报文转发ULB4转发能力更强，适合与追求转发性能的场景。而请求代理ULB7则可以对七层数据进行处理，可以进行SSL的卸载，执行域名转发、路径转发等功能，并且后端节点不需要额外配置VIP（虚拟IP）。