专利名称：分布式电信平台中的负载平衡的制作方法
技术领域：
本发明涉及分布式IP系统和电信系统，且更明确地说涉及一种具有经由分布式IP结构互动的地域上分散的组件的多功能电信系统。
背景技术：
在过去的数十年中，语音邮件已持续发展并成为大多数企业成功运作的关键因素。如今典型的语音邮件系统可呈现多种形式，包含可在连接到企业电话系统的个人计算机内操作的计算机卡，或者直接集成到企业电话系统中的计算机卡或组件，或者作为由电信公司提供的服务。
如今可用的语音邮件系统的每一者的共同要素是，组成语音邮件系统的组件必须彼此通信，且因此必须协同定位。这对于具有地域上分散的办公室的公司来说可能是一个很大的缺点。
在如今的全球经济中，即使小型企业也可能为了为客户服务、与卖主互动或各种其它原因而需要多个办公室。因特网、电子邮件和视频会议的出现有助于使得这些分散的操作显得更加无缝。然而，分散的办公室仍然存在的显著问题是具有作为单一协同定位系统操作但满足各个办公室的需要的共用电话系统。一般来说，每一办公室购买并维护其自身的电话系统而在各个办公室的电话系统之间没有任何直接介接且没有任何中央控制。这可能是花费较大的做法，因为必须购买重复的硬件并在每一地点进行维护。另外，办公室间通信的后勤工作(例如，呼叫转移、语音邮件检索等)可能较复杂。因此，此项技术中需要一种允许远程定位的办公室实现无缝集成的电信系统。
在大多数分布式系统中，一种已出现且必须解决的共同问题是在各个组件之间分配处理。在分布式系统中，组件的一个子集可能由于处理任务而负担过重，而其它组件闲置或利用不足。此种状况可导致系统的效率和处理量出现极大的且不必要的减小。举例来说，如果可将负载从负担过重的组件分配到利用不足的组件，那么系统可更加有效地处理处理要求。存在许多已被提议并实施以求能够平衡分布式系统中的处理要求的此类技术。然而，此类技术不足以满足本文描述的分布式电信平台中的需求。举例来说，当一个或一个以上组件(例如)在创建动态VoiceXML页面时利用JAVA 2企业版(JAVA 2Enterprise Edition，J2EE)环境和JAVA服务器页面(JAVA Server Page，JSP)时，可出现额外的问题。在此种组件中，JAVA引擎在执行此项技术中称为垃圾收集的操作的同时对存储器进行分配和解除分配。这是Java的关键特征，其负责释放被动态分配的不再被参考的存储器。因为堆阵被进行了垃圾收集，所以Java编程人员不必明确地释放所分配的存储器。然而，当垃圾收集处理开始时，可能需要大量处理时间，这直接影响了系统性能。因此，此项技术中需要一种分布式系统，其允许以避免或减轻Java垃圾收集处理以及其它处理要求的影响的方式对资源进行再分配。
发明内容
本发明提供一种用于平衡分布式电信系统内的处理负载的技术。一般来说，在两个级处分配处理---组件级和处理级。在所述组件级处，使用虚拟交换机将服务请求路由到一组经配置以处理所述服务请求的组件中的一个组件。可由所述虚拟交换机自发地或完全基于所述组件提供的信息乃至通过两者的组合来作出决定。在所述处理级处，每一组件建立服务处理的多个实例并接着选择一个实例以处理所述服务请求。所述组件监视所述处理的所述实例的处理负担，且如果预期性能上有降级，那么所述组件选择所述服务处理的替代实例以处理后续请求。
在本发明的示范性实施例中，使用虚拟交换机在一组应用程序服务器之间进行选择以便处理电信服务请求。应用程序服务器利用包含垃圾收集处理的J2EE平台。如果使用服务处理的单一实例，那么垃圾收集处理最终将需要较高执行优先权，且此时，电信系统的用户将体验到性能降级。多个实例允许垃圾收集处理在不影响用户所体验到的性能的情况下离线操作。
图1是说明其中可利用本发明的各个方面和特征的示范性下一代通信平台的组件和连接性的系统图。
图2是说明根据本发明一种用于提供负载平衡的可能配置的方框图。
图3是说明本发明的各个方面的流程图。
具体实施例方式
图1是说明其中可利用本发明的各个方面和特征的示范性下一代通信平台的组件和连接性的系统图。所说明的系统包含用于电信设备的分布式的基于IP的结构，其尤其可提供例如语音邮件、呼叫转接和其它电信特征的电信服务。在所说明的环境中，下一代通信平台100具有分布式IP结构且连接到公共交换电话网络(PSTN)110。通信平台100说明为包含信令网关功能(SGF)120、一个或一个以上媒体服务器(MS)130、一个或一个以上系统管理单元(SMU)140、一个或一个以上应用程序服务器(AS)150和一个或一个以上中央数据和消息存储器(CDMS)160。应了解，图中所说明且描述的功能性分布尽管本身具有新颖的方面，但并非唯一可接受的配置，且本发明的各方面可并入到包含更少或更多组件以及组件之间的不同功能性配置的系统中。
一般来说，SGF120充当与PSTN110的7号信令系统(SS7)接口，并允许一个或一个以上组件或子系统共享同一点编码，藉此减少对于目的地点编码(DPC)和用于呼叫控制的信令链路的需求。这使电话系统在网络中表现为单一中继线群组。媒体服务器130经由多接口设计终止来自PSTN的IP和/或电路交换通信量，且负责中继和呼叫控制。应用程序服务器模块150为各种应用程序产生动态VoiceXML页面并通过媒体服务器130提交所述页面，且经由网络应用程序服务器配置提供外部接口。SMU140是管理入口，其使服务提供商能够提供并维护订户帐户，且管理来自集中式网络接口的网络元件。CDMS160存储语音消息、订户记录，并管理包含通知在内的特定应用程序功能。下文更详细地描述这些子系统中的每一者。
下一代通信平台中的组件的每一者可独立地调整并独立地互连到IP网络上。因此，所述组件可在地域上为分布式的，但仍然作为单一通信平台而操作，只要其可经由IP网络彼此通信。这是本发明的一个显著优点，其在现有技术水平的通信系统中无法实现。
信令网关功能(SGF)SGF120提供整合的信令接口，其为下一代通信平台创建单一虚拟SS7信令点。SS7提供网络所需要的额外马力，不论所述马力是大是小。经由SGF120支持与多功能媒体服务器130以及IP代理功能的SIGTRAN接口(经由IP的IETF SS7电话信令)。将SS7整合到下一代通信平台的单一组件(在此情况下为SGF120)中提供了以下益处点编码减少，其它组件的设计的成本效益较好，且更易于维护。
SS7网络中的每一信令点由数字点编码唯一地识别。在信令点之间交换的信令消息中载运点编码，以识别每一消息的来源和目的地。每一信令点使用路由表来为每一消息选择适当的信令路径。
SS7网络中存在三种信令点SSP(服务交换点)、STP(信号转移点)和SCP(服务控制点)。SSP是发起、终止或串接呼叫的交换机。SSP将信令消息发送到其它SSP以设置、管理并释放完成呼叫所需的语音线路。SSP也可向集中式数据库(-SCP)发送查询消息以确定如何路由呼叫(例如，北美洲的免费1-800/888呼叫)。SCP向发起的SSP发送含有与所拨号码关联的路由号码的响应。如果主号码正忙或呼叫在指定时间内未被接听，那么SSP可使用替代的路由号码。实际的呼叫特征根据不同网络和不同装置而不同。
信令点之间的网络通信量可经由称为服务转移点或STP的分组交换机而被路由。STP基于包含在SS7消息中的路由信息将每一传入消息路由到传出信令链路。因为STP充当网络集线器，所以其通过消除对于信令点之间直接链路的需要来提供对SS7网络的改进的利用。STP可执行全局标题翻译，通过此程序根据信令消息中存在的数字(例如，所拨的800号码、主叫卡号码或移动订户识别号码)确定目的地信令点。
STP也可充当“防火墙”以筛选与其它网络交换的SS7消息。因为SS7网络对于呼叫处理至关重要，所以SCP和STP通常以配对配置部署在单独的物理位置中，以在故障被隔离的情况下确保整个网络范围的服务。信令点之间的链路也是成对提供的。链路组中的所有链路共享通信量。如果所述链路之一发生故障，那么经由链路组中的另一链路重新路由信令通信量。SS7协议提供错误校正和重新传输能力两者以允许在信令点或链路发生故障的情况下持续服务。
点编码的可用性通常有限。信令链路的整合减轻了对这些资源的压力或完全消除对于额外点编码的需要。因此，SGF120中的整合信令接口提供了直接的网络简化和成本节省。SGF120经由消息传递网络的单一“虚拟”点编码向SS7网络呈现单一身份的外观，并以透明方式辨认和处理消息。SGF120可潜在地将一些情况下需要的点编码的最大数目从50个减少为仅四个。
从联网的角度来看，SGF120对于网络的其余部分而言看上去如同STP，其通过使用虚拟点编码提供对下一代通信平台的各个组件的访问。根据本发明的分布式方面，可将多个SGF并入到系统中。在此配置中，到达下一代通信平台的各个组件的多个路径为可用的。
每一SGF120包含用于访问通信平台中各个组件的虚拟点编码。整个通信平台仅必需一个目的地点编码。SGF彼此通信以对用于媒体服务器和集成到通信平台中的其它组件的虚拟点编码进行同步。因此，如果一个SGF发生故障，那么通过另一SGF容易地提供对通信平台的访问。
这显著不同于且优于下一代通信平台中看似同步的SS7堆栈的组件的每一者。
在一示范性实施中，SGF120服务器支持N+1个故障修复冗余方案和负载共享配置，且建立在Intel服务器上。推荐最少两个SGF用于负载共享和冗余目的以获得增加的可用性。对于所有平台组件，均产生SNMP报警、记录和交易细节记录。SGF的特征、优点和益处包含允许多个媒体服务器共享信令链路和点编码，从而提供显著的成本节省；提供集中式SS7信令链路；可在多个多功能媒体服务器上提供一个中继线群组；SGF120需要较少SS7链路，从而导致每月连接费用减少；和SGF120在实施通信平台的IP分布式结构的能力方面是关键组件。
媒体服务器(MS)MS130终止来自SGF120的IP通信量和来自PSTN110的电路交换通信量。MS130负责平台结构内的呼叫建立和控制。MS130处理来自用户的语音、DTMF格式或其它信令方案的输入(非常类似于网络客户端从用户处搜集键盘和鼠标点击输入)。MS130接着将内容以语音形式呈现回给用户(原理上类似于将图形和文本显示回给PC客户端上的用户)。此客户端/服务器方法在平台结构中是重要的，因为其准许快速创建新的应用程序并快速利用环球网上可用的内容。
MS130优选地经由使用HTTP对AS150的请求来处理来电。负载平衡器优选地将到达多功能MS130的通信量引导到复数个AS150中的一者。这一功能性确保了在活动服务器之间平均分配通信量。。多功能MS130以与像Netscape这样的客户端为PC上的HTML用户工作的几乎相同的方式来作为VoiceXML客户端为最终用户工作。驻存在多功能媒体服务器上的VoiceXML或呼叫控制XML(CCXML)浏览器翻译VoiceXML文档以便呈现给用户。
VoiceXML是用于开发语音允用软件应用程序的基于标准的脚本语言。这意味着开发人员在开发基于语音的电话应用程序时要使用并补充基于网络的(HTML)开发技术。
应用程序服务器(AS)下一代通信平台的模块化设计具有以下增加的优点容易部署增强的服务，例如语音拨号和语音导航、统一通信解决方案、多媒体消息传递服务和存在与可用性管理应用程序。经由将标准应用程序服务器150添加到共用平台来实现将应用程序添加到平台。
每一应用程序服务器150响应于经由内部以太网而来自媒体服务器130的请求而产生应用程序文档(VoiceXML页面)。应用程序服务器150补充网络应用程序基础结构以便与后端数据存储器(消息存储器、用户概要数据库、内容服务器)介接，以产生基于VoiceXML的文档。
总体网络应用程序基础结构将核心服务逻辑(即，提供业务逻辑)与呈现细节(VoiceXML、CCXML、SALT、XHTML、WML)分离以提供更加可扩展的应用程序结构。应用程序服务器150利用Java2企业版(J2EE)环境和Java服务器页面(JSP)来为多功能媒体服务器创建动态VoiceXML页面。将这些技术组合起来，便使得语音应用程序语言标记符(SALT)可快速合并以提供例如WAP、HTML、XHTML的应用程序与语音之间的互操作性(多模式的)，从而允许最终用户同时经由语音命令输入数据并经由WAP或HTML接收呈现内容。
为了创建便利于应用程序开发的环境，应用程序服务器150优选地支持Template+JSP。使用API在JSP中实施应用程序以便访问消息传递功能。这些JSP可容易修改，使得应用程序行为的改变和新应用程序的产生极为容易。
媒体服务器130与应用程序服务器150的协作允许向特定的订户提供某些特征的定制。举例来说，如果一家公司在西海岸有一个办公室且在东海岸有另一个办公室，那么每一办公室对电话系统(特别是媒体服务器130和应用程序服务器150)的操作可能相当不同。举例来说，语音邮件系统和自动话务员可在东部时间下午6:00在东海岸办公室且在太平洋时间下午6:00在西海岸办公室进入夜间模式。另外，各个办公室提供的菜单结构和提示可能实质上不同。举例来说，按照姓名拨号的目录将包含不同的职员。利用本发明，单独媒体服务器可位于两个办公室，且可提交不同的通信服务。可从与媒体服务器130协同定位的不同的应用程序服务器150或者通过可基于媒体服务器130的位置或ID来服务通信服务应用程序的共用的应用程序服务器来提交不同的通信服务。
另外，远程定位的媒体服务器130可向各个订户和呼叫者提供共同功能性，以及提供电话系统的从订户与用户的角度来看，均是无缝的集成。一公司可能希望提供无缝地服务公司的所有位置的语音邮件与自动话务员接口。本发明可用于提供此功能性。应用程序150可提交分层的按姓名或菜单选择拨号的功能，其首先允许呼叫者选择一办公室，且接着应用程序服务器150和/或媒体服务器130调用一特定功能来为所述特定的办公室提供按姓名拨号服务。或者，应用程序服务器150可维持对于单一CDMS160或包含公司所有办公室的所有订户信息的多个CDMS160的访问。应用程序服务器150接着可提供整个公司范围内按姓名拨号的目录的单级菜单结构。
共用数据库和消息存储器(CDMS)
下一代通信平台使用CDMS160来存储语音/音频消息、订户记录，并管理例如通知调度的某些应用程序功能。CDMS160优选地设计为具有完全冗余组件，并利用反射存储器和独立磁盘冗余阵列(Redundant Array of Independent Disk，RAID)技术以用于容错、立即故障修复和恢复。这确保对于系统即使在不利情况期间也将可用具有较高程度的确定性。基本磁盘驱动器和RAID控制器组件优选地为“可热交换的”，从而不需要对系统断电来进行更换。利用CDMS160，针对语音消息传递的独特特性而优化性能，从而消除性能降级、由于对电子邮件存储器的搜索和分类而带来的不必要的电子邮件中心数据库功能性。
CDMS160可利用标准的成品电子邮件存储系统。通过使用允许消息存储器的选择对应用程序来说透明的Java中间件来使消息存储器抽象化，从而准许将每一消息类型存储在可能的最有效的存储器中。
系统管理单元(SMU)SMU140为服务提供者提供集中点以管理所有网络元件，从而提供远程访问、维护和备份功能性。SMU140提供用于提供、报警、报告和订户迁移的单一接口。SMU140用新元件和应用程序来集成并定制系统，且为体验快速成长的网络和激增的通信量的运营商提供操作支持和网络管理功能。SMU组件的核心特征包含元件自动发现-当服务提供商添加新的网络元件时，SMU自动辨认所述网络元件并将新元件包含在图形化网络地图中。
图形化网络图-网络/群集图和图编辑器提供整个网络或群集的快照并有助于快速问题识别和解决。
时问同步-中央时间源确保所有网络组件在整个消息传递网络上维持统一时间基准-对于任何分布式结构均较重要。
集中式网络记录-针对整个消息传递网络的记录集中在SMU140上。
SMU140使用双处理器计算机并允许远程拨入以便经由远程通信网(Telnet)访问SMU140服务器以及系统中所有其它服务器。系统配置和其它关键数据的备份也可经由SMU实现。
有利地，所描述的下一代通信平台允许快速且具成本效益地部署全部来自单一结构来源的多种应用程序。利用开放式来源的基于Java的应用程序创建环境使此高度灵活性成为可能。通过利用通信平台，操作者可创建引人瞩目的同类中最优的消息传递和通信服务的程序包，从基本呼叫应答到例如多媒体消息传递和在线状态允用解决方案的前瞻性应用程序。为了进一步有助于用户体验，下一代通信平台也可为订户提供网络接口，以便在“自助”的基础上添加和修改其偏好和特征。此能力增加消费者的使用，改进消费者忠诚度，并且还通过较少例行服务呼叫而减少服务提供商操作成本。
通信平台的另一优点是包含并合并多种应用程序的能力。不管应用程序为平台上原有的或来源于第三方销售商，所述应用程序均允许针对各种消费者需求和产品差异来定制通信平台。可容易地合并到通信平台中的一些应用程序包含(但不限于)以下应用程序语音邮件-为订户提供围绕语音消息内容的交换而设计的多种特征，包含语音消息记录和存储、转发、远程检索等。
未接呼叫通知-这是无线或蜂窝式电话领域频繁使用的呼叫者ID的扩展。只有在无线电话开机并处于网络覆盖区域时，呼叫者ID服务才会提供来电号码。然而，未接呼叫通知提供连续的基于网络的服务，所述服务向订户提供在用户远离蜂窝式电话或蜂窝式电话关机时向蜂窝式电话号码发出的呼叫的列表。因此，未接呼叫通知服务将俘获并存储来电信息，直到蜂窝式电话开机并注册为止。此时，将含有所有未接呼叫的列表的短消息服务消息(SMS消息)发送给订户，从而允许订户在其方便时回电。
多媒体消息传递服务-MMS允许订户用例如照片和音乐的最新多媒体内容使其通信个人化，以创建打破传统通信的约束的消息传递。此应用程序通过使用例如消息编辑器、相册和问候卡的特征而增强以允许订户在其支持MMS的移动手机、PDA和PC上发送并接收动态多媒体内容。订户也可经由因特网将多媒体内容发送给非MMS订户，从而将通信量驱动到操作者的网站，藉此增加订户使用。
统一化通信-针对特定订户的需求而定制的完整服务包，包含语音、传真和电子邮件消息传递、用于所有消息类型的单一邮箱、集成的地址簿，和特殊在线管理及个人化工具。
多方个人会议服务-此应用程序给予订户发起与朋友/亲属进行即时会议的能力。
语音允用消息传递服务-此应用程序是功能强大的语音控制电话服务。订户通过其自身的个人联系号码和以自然语言辨认和任选文本到语音能力为特征的易于使用的语音接口来访问一批服务。语音允用消息传递组共同的特征包含经由在与业界标准(VoiceXML和SALT)兼容的基于IP的结构上传递的语音命令、语音拨号和语音控制地址簿进行语音邮件的导航。
语音MMS-此应用程序通过允许将新存入的语音邮件消息以音频素材的形式传递到支持MMS的手机或电子邮件箱而使订户能够通过其通信信道具有较大访问权和控制权。订户也可经由电子邮件共享语音消息并将语音消息转发到其语音邮件系统外部的目的地。
本发明的另一方面是用于传递和控制数据的交易工具。利用如先前所述的相同SGF120组件，提供以SS7协议的TCAP组件为中心的交易工具。更明确地说，可利用SS7协议的TCAP组件在下一代通信平台的分布式结构内提供短消息传递服务。短消息的发送者经由IP网络建立与媒体服务器130的通信。发送者使媒体服务器130请求SGF120发送SS7TCAP消息以便传递短消息。这项技术将上文针对用于呼叫处理的SGF的STP接口描述的单点访问节点用于交易处理。
因此，示范性电信平台的分布式结构允许电信平台的各种功能在地域上是分布式的，但仍然如同无缝集成的系统一样工作。此分布式系统中出现的问题是系统内资源的共享。可出现多个组件可能用服务请求来过分增加某些其它组件的负担的许多状况。另外，某些组件可能在某些时间对处理请求较有弹性，且在其它时间弹性较小。此状况的实例在组件的一者或一者以上包含Java2企业版环境并利用垃圾收集的用途来重新获得未使用的存储器时发生。
JAVA垃圾收集如先前所提及，应用程序服务器150利用JAVA2企业版(J2EE)环境和Java服务器页面(JSP)来为多功能媒体服务器创建动态VoiceXML页面。Java的关键特征是其进行了垃圾收集的堆阵，其负责释放动态分配的不再被涉及的存储器。因为堆阵被进行了垃圾收集，所以Java编程人员不必明确地释放经过分配的存储器。一般来说，当垃圾收集处理插进时，应用程序服务器150不可由任何其它处理使用或至少其使用性减少。如果应用程序服务器150用于对等待时间敏感的环境(例如语音邮件平台或电话系统)中，那么应用程序服务器150进入垃圾收集处理可造成等待时间问题。因此，在电话呼叫过程中，参与者将在垃圾收集处理期间听到停滞空气。
更明确地说，J2EE服务器/网络容器是用于支持支持来自客户端的请求的服务器应用程序的软件组件。一些J2EE服务器/网络容器应用程序具有无法导致由Java虚拟机(JVM)的垃圾收集活动(例如，主要垃圾收集)造成的性能额外开销的服务要求。对于这些应用程序，存在一初始周期，在所述初始周期中性能在发生影响服务的垃圾收集活动之前是可接受的。
JVM的堆阵存储正执行的Java程序创建的所有对象。Java的处理创建对象，且在运行时间在堆阵上分配针对新对象的存储器。垃圾收集是自动释放不再由程序参考的对象的过程。名称“垃圾收集”暗示程序不再需要的对象为“垃圾”且可被抛出。当一对象不再由程序参考时，其所占据的堆阵空间必须重复利用使得所述空间可用于后续新对象。垃圾收集程序必须以某种方式确定哪些对象不再由程序参考并使由所述不被参考的对象占据的堆阵空间可用。
除了释放不被参考的对象外，垃圾收集程序也可防止堆阵存储残片(fragmentation)。堆阵存储残片在正常程序执行的过程中发生。分配新的对象，且释放不被参考的对象，结果堆阵存储器的空闲区块留在由有效对象占据的区块之间。尽管现有堆阵中存在足够的总体未使用空间，但可能必须通过扩大堆阵尺寸来满足分配新对象的请求。这将在没有可向其中适配新对象的足够的连续空闲堆阵空间时发生。在虚拟存储器系统上，服务不断增长的堆阵所需的额外分页可使正执行的程序性能降级。
可根据应用和编程技术在Java平台上利用若干种垃圾收集技术。不管利用何种方法，与处理关联的等待时间问题均将很有可能实现。过去只能给予垃圾收集机制提示，这使得非常难以调节处理，因此需要我们的反复利用解决方法。
垃圾收集算法必须执行两件基本任务。首先，其必须检测垃圾对象。第二，其必须收回由垃圾对象使用的堆阵空间并使所述堆阵空间可用于程序。垃圾检测通常通过界定根目录集合并确定从根目录的可到达性来实现。如果有来自根目录的正执行的程序可借以访问对象的某一参考路径，那么所述对象为可到达的。根目录始终可由程序访问。任何可从根目录到达的对象均被认为是有效的。不可到达的对象被认为是垃圾，因为其不可再影响程序执行的未来过程。
本发明的一方面是允许J2EE服务器或网络容器(例如，Resin、Apache Tomcat、BEAWebLogic、IBM WebSphere)仅在发生影响服务的垃圾收集活动之前的可配置周期内处理请求。总体设计方法是主机上存在网络容器/服务器的一个以上实例，其中所述容器/服务器中仅有一者被认为是现役的且处理新会话请求。可配置周期之后且为了避免影响服务的垃圾收集活动，活动容器/服务器接着停顿并降级为备用状态，此时针对新提升的活动容器/服务器发出新会话请求。得到初始新会话请求的负载分配组件将请求分配给当前活动的容器/服务器。在容器/服务器从活动模式提升到备用模式之后，负载分配组件将新会话请求发送给新提升的容器/服务器。只要主机是活动的，则此过程持续。
尽管所述机制希望每次支持两个以上容器/服务器，但为了论述的目的，假定两个容器/服务器驻存在单一主机上。在任何时间，所述容器/服务器中仅有一个处于活动模式(接收来自新客户端的请求)；另一者处于备用模式。只有活动容器/服务器可接受来自新客户端的请求(创建新会话)。在可配置时段(其可基于经验数据而获得或者被编程为默认值或既定值)之后，备用容器/服务器被提升并开始接收新会话请求，而之前活动的容器/服务器不接收新会话请求但继续处理对于现有会话的请求，且接着在可配置周期之后停顿。停顿的容器/服务器停机并重新启动(这清除任何垃圾并提供“清白历史”)，此后其保持处于后备用模式直到其在可配置时段之后再次被提升到活动模式为止。只要主机经配置以接受请求，则重复此过程。因此，针对同一主机上的活动网络容器/服务器发出新请求，且因此对所述主机的网络请求被透明地且成功地处理而不会导致影响服务的JVM垃圾收集的额外开销。使用相同机制来支持两个以上容器/服务器。
图2是说明根据本发明一种用于提供负载平衡的可能配置的方框图。所说明的配置包含四个媒体服务器130和两个应用程序服务器150。媒体服务器130的每一者可通过两个虚拟交换机210中的一者来访问所述应用程序服务器中的任一者。虚拟交换机的一个实施例可为第4层负载平衡器的冗余对。虚拟交换机210可为操作以将来自多个请求者的服务请求重定向到多个接收者的多种组件中的任一者。一个此种组件可为Linux虚拟服务器(LVS)。LVS是建立在真实服务器群集上的高度可调整且高度可用的服务器，其中有一负载平衡器在Linux操作系统上运行。
当请求从媒体服务器130到达虚拟交换机210时，虚拟交换机210基于由虚拟交换机210服务的应用程序服务器150的当前负载和可用性将请求路由到应用程序服务器150。因此，媒体服务器130将消息邮递到虚拟交换机210。虚拟交换机确定将使用哪个应用程序服务器150来响应所述请求并通知该应用程序服务器150。应用程序服务器150接着回应发出请求的媒体服务器130。
应用程序服务器150的每一者包含一端口。虚拟交换机210通过将请求发送到适当端口而将请求路由到应用程序服务器150。虚拟交换机210以至少两种方式提供负载平衡。在一个实例中，虚拟交换机210可监视已路由到特定应用程序服务器150的请求的数目，并在虚拟交换机210推断所述应用程序服务器150被过分利用时将请求重定向到另一应用程序服务器150。虚拟交换机210可使用加权处理来作出此确定。将权重分配给每一主机和到达主机的当前数目的连接。使用称为加权最少连接(weightedleast-connection)的算法作为作出此确定的基础。举例来说，虚拟交换机210可将一个百分比的通信量路由到第一应用程序服务器150并将剩余百分比的通信量路由到一个或一个以上其它应用程序服务器150。在另一实例中，应用程序服务器150可积极地指示虚拟交换机210利用不同的应用程序服务器150。举例来说，如果第一应用程序服务器太忙，那么应用程序服务器150可指示虚拟交换机210将另外的请求路由到不同的应用程序服务器。这可在无限期基础上完成(即，直到应用程序服务器150指示虚拟交换机210其再次可用为止)，或这可在临时基础上完成(即，在某一时段期间或在特定通信量期间)。因此，虚拟交换机210操作以在电信平台内提供负载平衡。
LVS可基于应用程序服务器主机150上的反馈机制提供的个别组件负载信息来进行平衡。举例来说，应用程序服务器内的应用程序服务器容器也具有指示例如“可用”或“不可用”的状态的能力。应用程序服务器也可提供百分比占用状态，例如“占用n％”。此状态信息接着可用作LVS所作出的请求调度决定的输入。
也以另一种方式——垃圾收集——在应用程序服务器级上提供负载平衡。本发明的针对垃圾收集的性能的一个方面是创建虚拟机的两个实例以便服务请求。虚拟机的每一实例包含其自身的垃圾收集处理。一般来说，虚拟交换机210在某一时段内将请求路由到应用程序服务器150内的第一虚拟机，且接着在第一虚拟机执行垃圾收集的同时将另外的请求路由到第二虚拟机。虚拟机之间的交换决定可基于多种因素，且本发明不限于任何特定方案。举例来说，在一个实施例中，可在周期基础上(即，每30分钟)来执行所述转换。在其它实施例中，可能基于已发送到虚拟机的请求的数目、虚拟机可用的存储器量、正由虚拟机处理的线程数目或类似因素来执行所述转换。
在每一虚拟机内，垃圾收集处理通常是最低或非常低优先权任务。因此，随着应用程序服务器150被利用，垃圾收集要求随着时间而累积。在某一时间点，通常当可用存储器不足时，必须将垃圾收集处理移动到较高优先权。如果垃圾收集处理在活动处理正由应用程序服务器150服务时插进，那么系统用户将经历停滞时间或等待时间。
本发明操作以在遭遇此临界接合点之前在虚拟机之间进行交换。因此，在一个虚拟机的垃圾堆阵变得严重以致于必须将垃圾收集处理移动到较高优先权从而使系统性能降级之前，将对服务的另外的请求路由到另一虚拟机。有利地，这允许第一虚拟机继续服务当前活动处理，且垃圾收集处理将由于可能需要存储器的新处理的引入而不被给予较高优先权。一旦将请求路由到另一虚拟机，可以两种方式之一清除垃圾。虚拟机可重新启动，这自动调用了垃圾收集处理。然而，当前正被服务的处理将导致被终止。因此，更能经受检验的技术是允许当前活动的处理继续，且随着处理资源变得可用或在最后处理终止之后，实行垃圾收集处理。因为将新请求路由到另一虚拟机，所以在可调用垃圾收集处理之前只是时间的问题。一旦调用垃圾收集处理，第一虚拟机就可变为可用于处理将来的请求。另外，JVM处理可重新启动，这导致释放JMV处理拥有的所有堆阵存储器，且藉此完全避免垃圾收集处理。
应了解，尽管将本发明的这一方面描述为包含两个虚拟机，但也可使用任何数目的虚拟机，且将请求路由到虚拟机可以循环方式或另外的方式实行。
因此，本发明操作以便以至少两种方式提供负载平衡。在一个级处，虚拟交换机平衡导向应用程序服务器150的负载。在另一级处，应用程序服务器150以避免由于垃圾收集造成的等待时间问题的方式在两个或两个以上虚拟机之间分配请求的处理。
图3是说明本发明的各个方面的流程图。所述流程图说明经由虚拟交换机210与一个或一个以上应用程序服务器150通信的媒体服务器130。尽管仅说明一个媒体服务器130和一个虚拟交换机210和两个应用程序服务器150，但应了解，本发明的各个方面不限于此配置。如先前所述，本发明以至少两种方式提供分布式电信平台中的负载平衡平衡应用程序服务器之间的负载和平衡应用程序服务器内的负载。首先，媒体服务器130将服务请求310提供到虚拟交换机210。此时，虚拟交换机210作出关于哪一应用程序服务器适于处理服务请求310的确定(315)。此确定可以多种方式执行由虚拟交换机自发执行、由虚拟交换机辅助应用程序服务器执行，或由这两个极端的任何组合执行。举例来说，虚拟交换机可监视请求的数目、对所述请求的处理要求，和应用程序服务器作出关于应用程序服务器接受和处理额外请求的能力的确定的能力。或者，应用程序服务器可将状态信息发送到虚拟交换机以指示其当前处理负载及其接受和处理额外请求的能力。因此，虚拟交换机210可(1)自发地，(2)基于来自应用程序服务器的控制/状态信息，或(3)基于虚拟交换机搜集的信息结合从应用程序服务器接收的信息来作出负载分配决定。
一旦选择了期望的应用程序服务器150，虚拟交换机210就将服务请求转发到选定的应用程序服务器150(320)。最后，应用程序服务器150将经由虚拟交换机210或直接利用媒体服务器130来响应服务请求(350)。然而，应用程序服务器150也可实行关于应用程序服务器150的处理分配的额外步骤。一个此类过程涉及创建用于处理传入服务请求的服务处理的各种实例。如先前所述，本发明的此方面有利地允许实施J2EE环境而不会导致垃圾收集处理期间性能降级。因此在接收服务请求之前或之后，应用程序服务器150可操作以创建服务处理的多个实例，并接着识别特定实例来处理当前服务请求(325)。在操作期间，应用程序服务器150可通过使用服务处理的不同实例来分配处理负载。这可以多种方式实现，其中一些方式本文已揭示，其它方式未揭示但仍由本发明所预期。不管选定的方式如何，应用程序服务器150确定服务处理的实例是否负担过重(330)，且如果是，那么应用程序服务器150操作以允许负担过重的实例恢复(335)。举例来说，在一个实施例中，本发明操作以确定垃圾收集处理将需要被移动到较高优先权的最佳点，且接着将额外服务请求导向替代实例以避免由于垃圾收集处理而造成的性能降级。
应用程序服务器150也可收集、分析信息并将信息报告回虚拟服务器210以控制或支持对选择应用程序服务器的控制。这由应用程序服务器150通过周期性地确定其自身状态(340)并接着向虚拟交换机210报告(345)此信息来执行。因此，虚拟交换机接着可利用此信息来确定额外服务请求应被路由到哪一应用程序服务器150。
已使用对本发明实施例的详细描述来描述本发明，本发明实施例是以举例的方式提供且不希望限定本发明的范围。所描述的实施例包括不同特征，本发明实施例中并不需要所述特征中的全部特征。本发明的一些实施例仅利用所述特征中的一些特征或所述特征的可能的组合。所属领域的技术人员将了解所描述的本发明实施例和包括所描述的实施例中表明的特征的不同组合的本发明实施例的变化形式。本发明的范围仅由所附权利要求书限定。
权利要求
1.一种用于在一分布式系统中提供两级负载平衡的方法，其中复数个第一类组件必须共享复数个第二类组件的资源，且其中所述第一类组件经由一个或一个以上交换系统而介接到所述第二类组件，所述方法包括以下步骤在所述交换系统中的一者处从所述复数个第一类组件中的一者接收一服务请求；所述交换系统识别复数个第二类组件中的一者以便处理所述请求；将所述请求转发到所述经识别的第二类组件，所述经识别的第二类组件可操作以建立一服务处理的至少两个实例以便处理所述请求；在所述经识别的第二类组件处接收所述请求；和将所述请求分配到所述服务处理的所述至少两个实例中的一者以便处理所述请求，所述分配至少部分地基于所述处理的所述至少两个实例的当前处理要求。
2.根据权利要求1所述的方法，其中所述经识别的第二类组件中所述服务处理的每一实例包含一用于释放未使用的存储器的垃圾收集处理，且如果进一步基于正在所述服务处理实例内操作的所述垃圾收集处理的状态，那么包含所述将所述请求分配到所述服务处理的所述至少两个实例中的一者的步骤。
3.根据权利要求1所述的方法，其中所述经识别的第二类组件中的所述服务处理的每一实例包含一用于释放未使用的存储器的垃圾收集处理，且如果进一步基于给予所述服务处理实例内的所述垃圾收集处理的操作优先权的必要性，那么包含所述将所述请求分配到所述服务处理的所述至少两个实例中的一者的步骤。
4.根据权利要求1所述的方法，其中所述经识别的第二类组件中的所述服务处理的每一实例包含一垃圾收集处理，所述垃圾收集处理作为一低优先权后台任务操作以释放未使用的存储器，且通过将所述请求分配到所述服务处理的一第一实例直到有必要增加所述第一实例的所述垃圾收集处理的所述优先权为止并接着将后续请求分配到所述服务处理的另一实例来执行所述将所述请求分配到所述服务处理的所述至少两个实例中的一者的步骤。
5.根据权利要求1所述的方法，其中所述经识别的第二类组件中的所述服务处理的每一实例包含一垃圾收集处理，所述垃圾收集处理作为一低优先权后台任务操作以释放未使用的存储器，且通过在一特定时段内将所述请求分配到所述服务处理的一第一实例并接着将后续请求分配到所述服务处理的另一实例来执行所述将所述请求分配到所述服务处理的所述至少两个实例中的一者的步骤，其中所述特定时段足以防止所述第一实例的负担过重。
6.根据权利要求1所述的方法，其中所述经识别的第二类组件中的所述服务处理的每一实例包含一垃圾收集处理，所述垃圾收集处理作为一低优先权后台任务操作以释放未使用的存储器，且通过将所述请求分配到所述服务处理的一第一实例直到达到一第一阈值存储器利用率为止并接着将后续请求分配到所述服务处理的另一实例来执行所述将所述请求分配到所述服务处理的所述至少两个实例中的一者的步骤。
7.根据权利要求6所述的方法，其中一旦所述服务处理的所述第一实例中的存储器利用率降低到一第二阈值以下，就将所述服务请求的分配返回给所述服务处理的所述第一实例。
8.根据权利要求1所述的方法，其中所述经识别的第二类组件中的所述服务处理的每一实例包含一垃圾收集处理，所述垃圾收集处理作为一低优先权后台任务操作以释放未使用的存储器，且通过将所述请求分配到所述服务处理的一第一实例直到一第一阈值数目的服务请求已发送到所述第一实例为止，并接着将后续请求分配到所述服务处理的另一实例，来执行所述将所述请求分配到所述服务处理的所述至少两个实例中的一者的步骤。
9.根据权利要求1所述的方法，其中所述交换系统识别复数个第二类组件中的一者以便处理所述请求的所述步骤进一步包括识别一第一组件以便处理一第一百分比的请求，和识别一第二组件以便处理剩余百分比的请求。
10.根据权利要求1所述的方法，其中所述交换系统识别复数个第二类组件中的一者以便处理所述请求的所述步骤进一步包括识别一第一组件以便处理一第一百分比的请求，和识别一第二组件以便处理剩余百分比的请求。
11.根据权利要求1所述的方法，其中所述交换系统识别复数个第二类组件中的一者以便处理所述请求的所述步骤进一步包括识别一第一组件以便处理一第一阈值数目的请求。
12.根据权利要求1所述的方法，其中所述交换系统识别复数个第二类组件中的一者以便处理所述请求的所述步骤进一步包括从所述复数个第二类组件中的每一者接收一识别所述组件的当前负载的指示；和至少部分地基于所述组件的所述当前负载来选择所述复数个第二类组件中的一者。
13.一种分布式电信系统，其提供负载平衡以便处理服务请求，所述系统包括一媒体服务器，其介接到一电话系统以便提供电信服务；一个或一个以上交换机；两个或两个以上应用程序服务器，其经由所述一个或一个以上交换机而介接到所述媒体服务器；所述应用程序服务器中的每一者可操作以通过以下操作来服务从所述媒体服务器接收到的请求创建一服务处理的多个实例；使用所述服务处理的一第一实例来处理所有服务请求直到所述第一实例达到一阈值负担水平为止；和交换到所述服务处理的另一实例来处理后续服务请求。
14.根据权利要求13所述的分布式电信系统，其中所述应用程序服务器中的每一者利用一JAVA 2企业版环境，其中所述服务处理的每一实例包含一用于释放未使用的存储器的垃圾收集处理，且所述应用程序服务器中的每一者可操作以当所述服务处理的所述第一实例的所述垃圾收集处理需要一较高优先权时交换到所述服务处理的另一实例。
15.根据权利要求13所述的分布式电信系统，其中所述应用程序服务器中的每一者利用一JAVA 2企业版环境，其中所述服务处理的每一实例包含一用于释放未使用的存储器的垃圾收集处理，且所述阈值负担水平由所述第一实例已被用于处理服务请求的时间量确定。
16.根据权利要求13所述的分布式电信系统，其中所述一个或一个以上交换机中的每一者可操作以选择所述两个或两个以上应用程序服务器中的来自所述媒体服务器的一请求被路由到的一应用程序服务器，藉此为所述分布式电信系统提供负载平衡。
17.根据权利要求16所述的分布式电信系统，其中所述一个或一个以上交换机中的每一者可操作以基于正由一应用程序服务器处理的请求的数目来选择所述应用程序服务器。
18.根据权利要求16所述的分布式电信系统，其中所述一个或一个以上交换机中的每一者可操作以基于从所述两个或两个以上应用程序服务器接收到的状态信息来选择一应用程序服务器。
19.根据权利要求13所述的分布式电信系统，其中所述应用程序服务器中的每一者利用一JAVA 2企业版环境，其中所述服务处理的每一实例包含一用于释放未使用的存储器的垃圾收集处理，且所述应用程序服务器中的每一者可操作以当所述服务处理的所述第一实例的所述垃圾收集处理需要一较高优先权时交换到所述服务处理的另一实例，且其中所述一个或一个以上交换机中的每一者可操作以基于正由一应用程序服务器处理的请求的数目来选择所述应用程序服务器。
20.根据权利要求13所述的分布式电信系统，其中所述应用程序服务器中的每一者利用一JAVA 2企业版环境，其中所述服务处理的每一实例包含一用于释放未使用的存储器的垃圾收集处理，且所述应用程序服务器中的每一者可操作以当所述服务处理的所述第一实例的所述垃圾收集处理需要一较高优先权时交换到所述服务处理的另一实例，且其中所述一个或一个以上交换机中的每一者可操作以基于从所述两个或两个以上应用程序服务器接收到的状态信息来选择一应用程序服务器。
全文摘要
在一分布式电信系统(图1)内的两个级处-组件级和处理级(120、130、140、150、160)分配处理。在所述组件级处，使用一虚拟交换机将服务请求路由到一组经配置以处理所述服务请求的组件中的一个组件。可由所述虚拟交换机自发地或完全基于所述组件提供的信息甚至通过两者的一组合来作出决定。在所述处理级处，每一组件等级建立服务处理的多个实例并接着选择一个实例来处理所述服务请求。所述组件监视所述处理的所述实例的处理负担，且如果预期性能上有一降级，那么所述组件选择所述服务处理的一替代实例来处理后续请求。
文档编号H04L12/56GK101015171SQ200580021917
公开日2007年8月8日 申请日期2005年6月30日 优先权日2004年6月30日
发明者阿彻·R·小沙夫特, 马利塔·D·弗洛林, 伊恩·M·莫赖斯, 基思·埃林·迈耶斯, 保罗·E·鲁本斯坦 申请人:建利尔电子公司