对于绝大多数的互联网企业来说，负载均衡已经成为其系统网络架构中不可或缺的组成部分。负载均衡技术是终端用户与业务系统之间沟通的桥梁，也是实现系统处理能力快速扩展的最佳技术。实现负载均衡的方式很多，有很多开源的负载均衡软件，如：LVS、HAProxy、nginx等，也有很多公司推出独立的负载均衡产品，如：F5的BIG-IP，A10的Thunder，Citrix的NetScaler等等。
开源软件的获取容易，投资成本比较低。对于国内绝大多数的初创互联网企业来说，尽管其配置管理比较复杂，仍然成为实现应用系统负载均衡功能的首选。随着企业业务的快速发展和增长，网站的访问量和流量也会快速增长，这时候，开源的负载均衡软件的弱点就暴露出来了。
LVS处理性能较强，但只能做简单的四层处理，并且配置和实施比较复杂，除了要配置LVS之外，应用服务器本身也要做相应的配置。如果后端的应用的种类比较多，会消耗大量的公网IP地址。这对于公网IP地址都不太富裕的中小企业来说，LVS基本成为不可能选择的方案。
HAProxy和nginx类似，能够做Web应用的七层处理，这就能够解决多个Web应用映射到同一个公网IP的需求，而且能够做比较复杂的逻辑处理。但是，受限于Linux本身，其处理性能又是其软肋。
尽管这类开源的负载均衡软件部署成本比较低，当企业的网站访问量达到一定规模后，性能处理不足的弊端会凸显出来。这时候，企业会考虑采用商业的负载均衡产品来处理不断增长的Web流量。
相较于开源软件，商业的负载均衡产品投资成本比较高。对于初创企业来说，并不是特别好的选择，但是，为了实现业务的快速增长，支撑不断增长的业务流量，商业负载均衡却成为企业不得不考虑的选择。
由于采用了专用的硬件和系统设计，商业负载均衡从性能、功能、安全性、可靠性上，都比开源负载均衡软件要强大很多。如A10 Networks的Thunder 6430单机处理能力高达160Gbps，而体积却只有1U大小。但如果所有的流量都通过商业负载均衡产品处理，投资成本也是互联网企业不得不慎重考虑的因素。
实际上，商业负载均衡和开源的负载均衡软件，在网站的整体架构中并不是对立的两面。充分发挥各自的专长，不仅能够降低网站的投资和运维成本，也能够实现网站性能的高扩展。
举一个例子，1号店的网络系统架构中就充分利用了商业和开源负载均衡各自的特点和优势，从架构上进行整合，不仅提高了整体网站的性能扩展能力，也大大降低了原有负载均衡的管理复杂度。从开源负载均衡软件到商业的负载均衡设备，再到开源和商业负载均衡的融合，1号店摸索出了一套自己的方式。
和大多数的互联网公司一样，在发展初期，为了降低整个网站的投资成本，整个网络中大量部署了HAProxy。随着公司业务的快速发展，HAProxy成为网络架构中的瓶颈。单台HAProxy的处理能力不足，导致关键业务时常出现问题。如果部署多套HAProxy，网络出口又没有足够的公网IP地址。当网站进行促销或遭受到攻击时，HAProxy会成为第一个趴下的节点。
在这种情况下，1号店考察了A10 Networks的负载均衡产品，并在现网进行了一些测试。测试结果发现，商业的负载均衡的确有不俗的表现：
性能强大，原来HAProxy顶不住的流量，在商业负载均衡上能够极为轻松的应对。
管理和配置简单，直观的命令行和GUI页面展示，大大降低了原有的管理难度。
一些针对Web应用的高级功能，如：压缩、SSL卸载、连接复用等，有效的降低了后端服务器的负载。
安全防护功能能够轻松有效的应对经常发生的DDoS攻击。
由于专业的负载均衡产品具有诸多的优点，运维人员很快将所有应用的负载均衡功能都迁移到A10 Networks的负载均衡设备上。利用A10负载均衡具有的可自定义脚本功能，运维人员又写了若干脚本，解决诸如URL跳转、URL变换、攻击源阻止等等问题。
然而，随着业务的发展，麻烦事又出现了。
原来的运维人员离职了，新接手的工程师对A10 Networks负载均衡的配置不太熟悉。再加上历史上为了处理一些特殊问题添加的脚本、配置，导致运维工程师不敢对原有的配置进行任何调整。因此，1号店决定对负载均衡的架构重新进行调整。新的架构中，重新引入了HAProxy，并最大限度的发挥商业负载均衡和开源负载均衡各自的特点。调整主要包括以下几个方面：
商业负载均衡性能出色，部署整个网络出口，负责处理来自互联网客户端的访问请求。主要实现基于域名的转发、防DDoS攻击、SSL卸载和高性能的请求转发。
HAProxy成本低廉，用于内部应用之间的API调用
所有复杂的URL变换、目录改写、缓存、压缩等工作，交由HAProxy或nginx来处理。如果单台HAProxy或nginx的处理性能不足，则部署多台，前端通过A10的负载均衡实现HAProxy的负载均衡。
利用A10负载均衡的API功能，建立基于应用业务的性能监控和配置管理平台，使负载均衡的配置管理模块化、流程化。
经过调整之后，整个系统架构中，负载均衡的定位更加清晰，使用方式相对固化，也更加简单。运维工程师对负载均衡的管理复杂度也大大降低，出现问题后的故障定位也变得更加简单。新的架构调整，充分发挥了商业和开源负载均衡各自的优势，在降低总体投资成本的同时，也提高了原有系统的处理能力和扩展的灵活性。
