# 技术架构 CLB支持内网和外网两种场景，支持请求代理和报文转发两种转发模式。本文将分别介绍CLB的的请求代理和报文转发模式的基本架构。 ## 名词 **UVER**：SIGCALCLOUD Virtual Edge Router，SIGCALCLOUD的公网流量转发中心。 ## 报文转发 报文转发CLB是基于DPDK技术自研的。采用集群部署，单集群至少4台服务器（海外集群至少2台服务器），利用ECMP+ BGP实现高可用。 ### 内网 报文转发CLB采用了类似于DR的转发模式。内网报文转发架构图如下： 报文转发CLB集群通过向其上联的接入交换机宣告相同的VIP（虚拟IP），接入交换机配置了ECMP算法，能将流量负载均衡到多台CLB服务器上，从而构成了报文转发CLB集群。当CLB集群中某些服务器发生转发异常的时候，BGP报文转发也会停止转发，在三秒之内该CLB服务器就会被剔出服务器集群，从而保证高可用，同时CLB集群健康检查模块也将发出告警，通知工程师介入处理。此外同一个CLB集群的服务器都是跨可用区分布的，保证CLB集群跨可用区高可用。 报文转发CLB中有模块专门负责后端节点的健康检查（目前仅支持TCP/UDP端口探测），并上报后端节点状态。CLB转发服务器收到Client的业务报文后，将从健康状态的后端节点中选择一个，修改目的mac后打隧道送到后端节点，过程中报文的源IP和目的IP保持不变。 报文转发模式下后端节点必须在LO口绑定CLB的VIP（虚拟IP）地址，并监听服务，才能正确处理报文，并将回包直接单播送回给Client。这是一个典型的DR过程，因此内网报文转发CLB可以直接看到Client的源IP。 ### 外网 外网报文转发CLB转发示意图如下： 与内网报文转发CLB不同的是，外网报文转发CLB流量是从公网进来的。Client访问CLB的流量进入SIGCALCLOUD POP点，进入UVER（SIGCALCLOUD Virtual Edge Router），UVER将这部分流量，按照一致性哈希算法送到CLB集群各个服务器中。后续的流程与内网报文转发CLB类似。Backend节点中需要将CLB的EIP绑定在LO口，并监听服务，而回程报文将直接送到UVER，并通过Internet返回Client。 在外网报文转发CLB中，集群健康检查模块将定时探测服务器的存活状态，如果发现有服务器有问题，则将通知UVER，将异常服务器剔除，从而保证高可用。外网报文转发CLB集群也是跨可用区部署的，保证跨可用区高可用。 ## 请求代理 请求代理型基于Nginx开发。采用集群部署，单个集群至少4台服务器（海外集群至少2台服务器）。 ### 内网 内网请求代理架构图如下： 与报文转发CLB采用的DR模式不同，请求代理CLB采用的是Proxy模式（即Fullnat模式）。收到Client的请求之后，内网请求代理CLB将client到CLB IP的连接，转化为CLB的proxy IP到Backend（服务节点）实际IP的连接。因此Backend（服务节点）无法直接看到Client ip，只能通过X-Forwarded-For（HTTP模式）获取。另外，节点健康检查模块是集成在CLB进程中的，因此不需要额外的节点健康检查模块。 内网请求代理CLB利用ECMP+ BGP实现高可用，CLB服务器通过Quagga与上联交换机建立BGP连接。同集群下的多台服务器，将向上联交换机发起相同的VIP（虚拟IP）宣告。上联交换机根据ECMP算法，将流量负载均衡到集群中的各台服务器上。当有服务器发生异常时，三秒内BGP会中断，从而将故障服务器踢出集群，保证服务仍然可以正常工作。 ### 外网 外网请求代理型架构图如下： 与内网请求代理CLB不同的是，外网流量是从公网进来的。Client访问请求代理CLB的流量进入SIGCALCLOUD POP点，进入UVER（SIGCALCLOUD Virtual Edge Router），UVER将这部分流量按照一致性哈希算法送到CLB集群各个服务器中。后续的流程与内网请求代理CLB类似。 在外网请求代理CLB中，集群健康检查模块将定时探测服务器的存活状态，如果发现服务器有问题，则将通知UVER，将异常服务器剔除，从而保证高可用。外网报文转发CLB集群也是跨可用区部署的，保证跨可用区高可用。 ## 模式对比 相对于请求代理CLB，报文转发CLB转发能力更强，适合与追求转发性能的场景。而请求代理CLB则可以对七层数据进行处理，可以进行SSL的卸载，执行域名转发、路径转发等功能，并且后端节点不需要额外配置VIP（虚拟IP）。