太一星晨：应用交付技术哥讲述负载均衡“血泪史”

每当大型企事业单位的网络系统业务发生诸如流量堵塞、效率缓慢、运行不畅等症状时，IT经理们首先都会想到是否要再上一套负载均衡设备。诚然，作为网络优化的一件重大设备，负载均衡的确有很多突出的特性，但是否上了负载均衡业务就能高枕无忧了呢？

答案是：未必！

国内知名应用交付厂商太一星晨的一位资深技术哥，在经历大量项目实践后，对于负载均衡总结出来一套“心经”。他指出，因为负载均衡和业务之间的调整息息相关，如果调整不好，有时上了负载的业务，反而会让效率降低，甚至比原来更慢。

接下来，不妨以对业务要求最高的金融联机交易系统为例，来看看上负载均衡的时候，问题都发生在哪些方面。

状况一：同一服务端口开启多个通信方式

金融联机交易系统选择应用交付多数是为了利用负载实现业务的高性能扩展和高可用。例如：

为了上负载，太一星晨技术哥建议将应用设备服务器设置为两台，端口分别为：10.112.57.21:8001、10.112.57.22:8001，两台服务器上都实现了两种通信方式HTTP、JMS。

该业务模式如下：

HTTP连接采用短连接方式进行通信，每次请求都会重新建立连接；

JMS连接采用长连接进行通信，只建立一次连接。而且对该系统发送请求的客户端是比较固定的，多为部署在分行的前置服务器，每个分行部署1-2台。

部署完毕后，貌似完美！但好日子还没过几天厂商的电话就来了：负载均衡根本没起作用！

通过对两台服务器系统资源的监控，技术哥迅速发现是因为两台服务器明显负载不均衡，所以才没达到预期效果。

追本溯源，原来在做系统设计时，为了让服务操作更简单，就将对外服务端口统一为一个端口——这样的方式对于关联系统来说，是非常方便调用的设计。但也正因为如此，上了负载以后，负载根据端口平均分配任务——实际上两种业务的类型是不一样的：一种连接数很少，一种连接数很多。如此这般，经过负载的分配，自然就导致了业务分配不均匀，从而造成了单台服务器压力过大。 

经过冷静分析，技术哥尝试了将JMS协议调整为HTTP协议，以及将JMS协议部署到一个新的端口，发现都能达到负载均衡的效果。最后选用了将协议统一调整为HTTP协议的方式，业务的效率“噌噌”地又上去了！

状况二：压力过大

有一次，太一星晨技术哥为某金融机构部署负载均衡。在没部署之前，调试没有任何问题，也通过了压力测试，而且能达到3000/秒的用户数。但是就在技术哥上了负载产品后，一开始还能达到4000/秒左右，转眼却如洪水倾泻，用户数急速降低，甚至还不如没上负载前。

“本来我们网络没有这么慢，现在加了负载均衡却变慢了，是不是你们负载产品有问题啊？”用户提出了尖锐的质疑。

经过仔细观察发现：压力下，负载工作很正常，CPU也很低。但没上负载前，后台数据库的CPU工作在85%左右，加了负载均衡之后，数据库反而瞬间达到了百分之九十多，然后就居高不下了……

问题原因究竟在哪儿？

细究之下发现，原来这个机构的数据库平台在设计之初，没有考虑到以后需要在负载的情况下应用，现在经过负载，给数据库的压力增加了，数据库中某个表查询过慢，反而导致了整个数据库查询效率降低，进而影响了整个系统。

所以，综上案例可以发现，负载设备和客户的应用业务是息息相关的，要想成功的部署负载均衡，并使其发挥预期的效果，除了要了解客户需求，更要应地制宜，知己知彼才能让负载均衡产品发挥出它该有的作用。