如果把Web服务器集群比作一座城池，那么负载均衡器则相当于城门，重要性不言而喻。2016年4月14-15日，由51CTO主办的WOT2016互联网运维与开发者大会在北京珠三角JW万豪酒店召开。会上，UCloud基础云计算研发中心总监俞圆圆从负载均衡的发展及运营中的痛点，剖析了软件负载均衡ULB架构的演进之路。
俞圆圆，UCloud基础云计算研发中心总监，负责大规模的虚拟网络及下一代NFV产品架构设计和研发。在大规模、企业级分布式系统、面向服务架构、TCP/IP协议栈、数据中心网络、云计算平台的研发方面积累了大量的实战经验。曾经分别供职于Microsoft Windows Azure和Amazon AWS EC2，历任研发工程师，高级研发主管，***软件开发经理，组建和带领过实战能力极强的研发团队。
资深的运维、开发人员都了解到，LVS作为目前互联网时代最知名的负载均衡软件，在性能和成本控制上结合的非常好。那为什么UCloud要坚持研发Vortex来作为其负载均衡产品ULB的核心引擎？
会上，俞圆圆曾表示，用户使用负载均衡器最重要的需求是“High Availability”和“Scalability”。这也是由于随着互联网技术的飞速发展，不同企业业务的特点及复杂度催生了人们对负载均衡的可靠性和收缩性的要求越来越高。
负载均衡的痛点
俞圆圆认为，负载均衡作为一个网络设备或者网络功能已经存在很长的一段时间。例如，主流负载均衡解决方案中，硬件厂商以1996年成立的F5为代表，软件主要为Nginx与LVS。对于用户来说，如果有一个应用需要承担大量的并发请求或者新建连接，面对这么大的请求压力，完全依靠一台服务器不断堆积硬件能力是无法承担的，这就需要靠水平扩展来提升性能。但是，对于一般的用户来说，硬件负载均衡产品的价格昂贵，很难承受这样的负担。当硬件出现问题或者bug的时候，需要联系厂商解决，时间很难把控，新特性迭代缓慢且需资深人员维护升级，也是变相增加昂贵的人力成本。
软件方面，LVS作为目前互联网时代最知名的负载均衡软件的代表，其最常用的NAT、DR、FULLNAT三种转发模式中都有其优点和缺点，***的问题就是其复杂性。如下图：
俞圆圆还认为，更让人雪上加霜的是还需要考虑LVS的性能扩展和容灾方法，这使得整个方案更加的复杂。常见的有基于Keepalived的主备方式和ECMP两种。Keepalived主备模式设备利用率低；不能横向扩展；VRRP协议，有脑裂的风险。而ECMP的方式需要了解动态路由协议，LVS和交换机均需要较复杂配置；交换机的HASH算法一般比较简单，增加删除节点会造成HASH重分布，可能导致当前TCP连接全部中断；部分交换机的ECMP在处理分片包时会有BUG。
在这种情况下，俞圆圆认为，Vortex的架构设计重心就是满足用户需求，提供***的“可靠性”和“可收缩性”，而在这两者之间他们又把“可靠性”放在更重要的位置。
ULB2.0的多维度设计
俞圆圆告诉记者，这次发布的ULB2.0是1.0基础上的迭代，把整个四层负载均衡和七层负载均衡的能力进行了组合。不管是在API上还是在界面上，不同的用户有着不同的应用场景，有的可能需要七层的负载平台转发，有的需要比较多的转发策略，有的则需要更加定制化的一些规则等；而四层负载均衡很多的时候是纯粹性能上的提升。这次ULB 2.0是基于DPDK重新开发了四层负载均衡转发的核心，利用DPDK提供的高性能用户空间 (user space) 网卡驱动、高效无锁数据结构成功的将单机性能提升到转发14M PPS（10G, 64字节线速），新建连接200K CPS以上。
谈及系统的设计与实现，俞圆圆告诉记者整个设计其实参考了之前已存在的、包括Nginx以及LVS所支持的不同的转发模式和工作模式，基本上参考了所有已存的方案，综合考虑了之后重新设计了整个系统架构。其中，比较重要的两个设计特点如下：
1. ***，通过ECMP和一致性哈希水平扩展处理能力，这样单台服务器不够可以通过水平扩展，理论上可以***延伸整个集群的负载能力。
2. 第二，通过DPDK垂直扩展单台服务器的处理能力，尽量发挥出每一个CPU核的处理能力。
所以，ULB2.0通过引入一致性Hash算法，并结合ECMP与DPDK的服务架构，解决了利用commodity server实现［high availability + high scalability］的高性能软件负载均衡集群的课题，从而满足了这一时期人们对高可用及高性能的需求。在单机性能远超LVS，甚至超过了Google Maglev的水平。
不同场景下的可靠性保障
俞圆圆表示，UCloud网络团队在可靠性上做了很多工作，以保证不管在负载中心集群发生服务器变化的时候、还是后端的用户应用服务器发生状态变化的时候，都能够尽量减少对整个用户应用的影响。比如，一台服务器宕机，只有该台服务器上的已有连接将会受到影响，当前其他服务器上的连接不会受到任何影响，而宕机的服务器上受影响的连接会被均衡分散到剩余的服务器上，最小化对用户应用的影响。
如图，四层负载均衡器的主要功能是将收到的数据包转发给不同的后端服务器，但必须保证将五元组相同的数据包发送到同一台后端服务器，否则后端服务器将无法正确处理该数据包。以常见的HTTP连接为例，如果报文没有被发送到同一台后端服务器，操作系统的TCP协议栈无法找到对应的TCP连接或者是验证TCP序列号错误将会无声无息的丢弃报文，发送端不会得到任何的通知。如果应用层没有超时机制的话，服务将会长期不可用。Vortex的可靠性设计面临的***问题就是如何在任何情况下避免该情况发生。Vortex通过ECMP集群和一致性哈希来实现***程度的可靠性。
Vortex服务器的一致性哈希算法能够保证即使是不同的Vortex服务器收到了数据包，仍然能够将该数据包转发到同一台后端服务器，从而保证客户应用对此类变化无感知，业务不受任何影响。
对于负载均衡服务器和后端服务器集群同时变化的场景，Vortex能够保证大多数活动连接不受影响，少数活动连接被送往错误的后端服务器且上层应用不会得到任何通知。并且大多数新建连接与后端服务器的映射关系保持不变，只有最少数量的映射关系发生变化。
ULB的后期规划
***谈及ULB后期规划时，俞圆圆表示，目前ULB2.0***期只是推出了内网负载均衡，外网负载均衡已经在开发中。因为整个软件是自研的，所以会根据用户的反馈很快地进行迭代。从七层方面来说，用户对功能的需求大同小异，只是不同用户场景下的偏重，有的需要更好的文件压缩能力，有的需要日志服务，这些都会在下一阶段的产品中加以考虑。
从性能上来，俞圆圆还表示，七层用户重点关注的问题我们目前已经在研究，如怎么样利用专用的硬件加速卡对SSL做offloading等。对于四层处理，我们也会添加更多的转发策略方面的支持。此外，我们会同时把支持的协议栈再向三层拓展，有的协议只是基于网络IP层，并没有TCP层的属性，比如像GRE这样的协议我们也打算支持。
