【IT168 技术文档】

    引言 

    在本系列第 4 部分“使用 Rational 开发工具构建 SOA 中间件应用程序”（请参阅参考资料）一文中，我讲解了如何使用 Web 开发工具创建 SOA 中间件应用程序。在本系列第 5 部分“使用 WebSphere Business Integration 工具优化 Web 服务应用程序”（请参阅参考资料）一文中，我讲解了如何使用业务流程工具集成和优化 Web 服务应用程序。在第 5 部分，我还讲解了减少 Web 请求数量、执行时间、访问时间和带宽量的方法，这些方法都可以用来优化 Web 服务应用程序。 

    在本文中，我介绍了负载应用程序的某些问题如何影响了 Web 服务应用程序间的互操作方式。文中包含了一个流量瓶颈的实例，导致该瓶颈的原因是：在特定期间有太多的访问者基于业务流程发送了太多的请求到一个 Web 服务应用程序。接着又讲了如何从负载平衡技术中获益。 

    请记住，Web 请求与访问者的请求是不同的。Web 请求的数量不仅依赖于访问者的请求数量，也依赖于由访问者请求生成的、已优化的 Web 请求的类型和内容。 

    响应迟缓 

    为了更好地认清这种差异，请看接下来的这个实例。如果某个访问者在将请求通过 Web 服务发送到一台服务器后等了很久才得到回复，那么该访问者很可能为了获得更快的响应时间而转向使用另一种 Web 服务或网站。该始发端 Web 服务将处理传入的访问者请求，以生成并优化传输到目标 Web 服务的 Web 请求。 

    始发端 Web 服务响应迟缓，可能表明目标服务器繁忙，或是没有足够的系统空间来处理多个访问者请求（多线程处理）。处理这种负载问题的方法之一是平衡服务器间的负载，这样访问者就不会为得到答复而等待太久。这种技术称为负载平衡。 

    加快响应 

    平衡服务器间负载要优于外包 Web 服务，负载平衡技术不仅全面考虑到增加的服务器容量、改善的站点设计和使用独立磁盘冗余阵列（Redundant Array of Independent Disk，RAID）的能力，而且也提供了处理预期高峰流量所需的带宽。在服务器的长期运行中，它们会消耗更多的服务器资源。通过使用负载平衡技术，我们有更好的机会来提高服务器的性能和可靠性，并同时减少带宽量、执行时间和访问时间（假定服务器中包含故障转移机制 ）。 

    由于上述原因，负载平衡技术成为了大多数公司在处理大流量时（尤其在高峰流量期间经受服务器停滞时）的首选技术。这些公司希望更快地响应用户需求，从而在较短的时间内完成更多的工作任务。 

    您可以将负载路由到域名系统中不同的服务器主机地址，或者将一台服务器要处理的工作总量分摊到两台或多台服务器上。您不仅需要使用另外一台服务器智能化地选择出将工作分配给哪台服务器，还需要使用故障转移和备份服务将这些服务器联合到一起，以防某台服务器出现故障（尤其当服务器集散于不同地理位置时）。 

    类比购物车 

    作为一个类比，请把负载平衡服务器看为超市的 4 个付款台。让我们瞧瞧超市是如何在 4 个付款台间实现“负载平衡”的。 

    假设您排在 1 号付款台前的长队中，您可以粗略地估算出大概需要多久时间才能排到自己付款。如果您发现这条队伍移动缓慢，而且此时看到一名收银员走向 4 号付款台打开机器准备工作，那您一定会推着购物车快速地跑到 4 号付款台（请参见图 1）。 

    接着又有一名收银员打开了 3 号付款台，并挥手示意第一队排在您前面的购物者到 3 号付款台排队。这些购物者当然会移到 3 号付款台。2 号付款台此时仍然保持关闭状态。 


    图 1： 购物车的负载平衡 

    减少服务时间 

    让我们看看另一种负载平衡方式。如果您推着一辆满满的购物车，里面装着您一家十口一个月的杂货，您可能希望将货物分给多个付款台结帐。在没有家人陪同的情况下，这种想法尤为强烈。您可以将购物车中的物品分为几份，然后分从几个清闲可用的付款台结帐，这样就减少了付款时间。 

    虽然这在实际生活中是不可能的，但您可以使用负载平衡器实现类似的目的，它能把在线购物车（Web 服务应用程序）的请求从繁忙的服务器上转移到其他清闲可用的服务器上（请参见图 2）。如果其他服务器通过优化可以满足服务需求，就没必要再启用新服务器。 


    图 2：在线购物车请求的负载平衡 

    问题 

    您该怎样解决该问题？更快地跑到付款台前（增加带宽）？增加付款台数量（增加服务器容量）？找其他人帮您买（外包）？这些方法都不适用。 

    请您回答以下这些问题： 

    您将要平衡哪种应用程序的负载？ 
    在整个分布式网络中，该应用程序是否为长期运行？ 
    一台服务器或一个服务器集群超时接收了多少请求？ 
    在高峰流量期间，需要多少流量和带宽量？ 
    怎样利用服务器平衡应用程序负载？ 
    在不同时段，预计有多少访问者？ 
    访问者最多能够发送多少请求？ 

    在您答完这些问题后，请与一名网络管理员或系统管理员检查和整理这些答案，以促进相互了解。然后使用某种算法、技术或工具开发一个负载平衡程序，实现将繁忙的服务器上的访问者和 Web 请求重定向到清闲可用的服务器上。 

    负载平衡技术 

    负载平衡技术包括以下几种： 

    简单路由 
    DNS Round Robin 
    复杂算法 
    智能路由 

    由于实际工作中的流量需要按优先级处理，所以在开发 Web 服务应用程序时，请考虑上述技术中的最后两种技术。因为包含要求更快响应的服务器和访问者的分布式网络正在不断地扩张。由于前两种技术不需要按流量的优先级进行处理，所以我们将不在有关流量瓶颈的问题中讨论它们。 

    当您使用复杂算法时，分发请求是基于服务器性能、服务器使用的硬件种类和处理客户优先级的方法等等。这表明，最快的服务器将获得更多具有最高客户优先级的请求。智能路由基于请求的内容和（在始发端服务器发生故障时）流量重定向到另一台服务器的方式。 

    基于服务器的软件 

    虽然您可以使用软件、硬件或两者来达到负载平衡，但您最好还是在应用程序服务器集群上使用基于服务器的软件。基于服务器的软件的价格要远低于基于硬件的专用服务器。硬件升级的价格要远高于相应软件升级的价格。 

    在将基于服务器的软件添加到网络中之前，请检查网络是否配置正确，负载平衡器是否“灵活”。“灵活”在这里的解释是：虽然负载平衡器可能已为目前的 Web 服务应用程序做好了充分的配置，但它还必须能够通过扩展满足未来应用程序的需求。 

    IBM WebSphere Application Server 就是一款基于服务器的软件，它在负载平衡和故障转移中同时使用了复杂算法和智能