一种互联网大规模应用环境的商用服务系统及其工作方法

专利名称：一种互联网大规模应用环境的商用服务系统及其工作方法
技术领域：
本发明涉及一种商用服务系统及其工作方法，尤其关注一种互联网大规模应用环境的 商用服务系统及其工作方法，属于分布式技术在企业软件上的应用，其主要涉及的领域包 括商用服务器、多播技术、数据库技术以及集群技术等。
背景技术：
计算技术在企业当中的应用已经非常普遍。本发明涉及的商用服务器并不是泛指任何 用于企业应用的服务器系统，而是特指在整个计算过程中以轻量级数据和商业逻辑计算为 特征基于互联网技术的商用服务器。当前商用服务器的主要技术以及相关问题如下。
(1) 当前商用服务器都是在计算资源极端受限条件下运行的。企业应用系统区别于 非企业应用主要在于企业应用要求绝对正确和安全。在这样的需求下，系统宁可牺牲性能 也要保证商业过程不出差错。传统的商业应用环境一般是在企业内部进行的；这样计算资 源以及相关参与者都在严格管理之下，要达到上述目的就相对简单。因此，在这样的环境 中系统可以有更多的设计方式可以选择，不必过于严格地受制于管理问题。比如，服务器 可以不必承受过多的计算压力，可以在客户端上安排一些计算；甚至客户端之间也可以相 互协作而形成比客户服务器更有效的拓扑结构。在互联网技术逐渐普及后，企业应用逐渐 转向与互联网结合；这样商业应用的环境就由相对封闭转变为开放。在这个开放环境中， 正确性和安全性的维护就需要付出更高的代价；如果完全按照企业内部的方式处理，上述 两个原则就无法保证。因此，当前商用服务器采取了所有计算都在服务器上进行，而客户 端只负责提供计算中必要的参数不参与任何实际计算。这个方式对保证商业系统的正确和 安全有利，却不得不对服务器有过度依赖。这时候服务器将承载全部商业计算的压力。当 客户端规模迅速扩大时，服务器端的资源会越来越有限。为此，服务器端设计代价会显著 提高，不得不采取复杂的调度算法来有效使用有限计算资源。当客户访问达到高峰时，即 使调度算法做到极致，也由于计算资源的不足，造成用户等待时间过长，甚至系统崩溃。
(2) 当前商用服务器性价比低。为了支持潜在的大量用户，基于互联网的商业应用 系统必须以高投入的方式保证计算资源的充足。 一般采取的方式包括租用高带宽、购置高 性能服务器、采用复杂的集群技术和布置缓存设备等等。除此之外，相应的软件设计技术也需要高投入，尽量在有限计算资源条件下保证尽可能多的用户访问。这样的商业系统在 获得高性能的背后是大量计算资源开销，形成了性价比过低的现实。这种现象是与传统基 于企业内部灵活设计构造的系统相比较而言的；当然，与本发明的解决方案相比，当前商 用服务器性价比也要低很多。
(3) 当前商用服务器存在对计算资源严重浪费现象。当前商用系统主要的问题由于 其特殊的结构集中体现在商用服务器上。但在计算资源有限的同时，当前商用服务器还存 在计算资源浪费的矛盾现象。这主要是因为当前商用服务器在设计时考虑的是高访问量甚 至是极端情况下对服务器造成的压力。这种情况在大多数时候发生几率并不高。这造成了 大量投入只为应对小概率事件的弊端。而通常极端情况的发生又不易估量，真正出现高访 问量时应付又有困难。 一般采取的办法是适应平均访问量； 一旦出现高访问量时，在增加 计算资源或调整算法相关参数。当访问量增加迅速时，这个过程不能保证动态适应；用户 访问在此时不得不延迟甚至失效。当前商业服务器在适应计算系统规模变化上达不到强伸 縮性。这也是本发明所要力图解决的问题之一。
(4) 基于当前商用服务器的个性化服务能力弱。作为拥有大量用户和大量数据的商 业系统，有必要为用户提供个性化服务，使之从庞大系统中尽快找到满足其个性需求的商 业服务。然而，由于对用户集体需求只能通过对之前用户的历史记录进行分析，使得完成 这个目标的依据不充分；其次，这种分析又是建立在不成熟的机器算法上，导致结果准确 率低；当大量用户都以不同的需求同时登陆系统时，系统不得不为此付出更高的计算资源， 使得系统难于承受。
(5) 当前商用服务器管理优势也逐渐在消失。对于大型商业应用系统来说，其服务 器规模逐渐扩大，导致管理上代价增加，如一致性维护、容错性维护、性能保证、安全性、 状态及事务管理等等。当系统规模不大时，这个管理代价要小得多；当系统规模扩大后， 众多计算节点被分布在多处。管理任务逐渐由统一管理变成了分布式管理。另外，随着计
算设备、通信技术以及相关软件技术的提高，商业服务器和客户端之间的网络连接以及交 互越来越便捷，客户端的计算能力也越来越强大，建立在这些设备之上的应用系统趋于相 对稳定。如果可能在这样的系统上进行商业计算，其代价已经远小于过去。这也是本发明 所关注的地方。
(6) 当前商用服务器也面临重量级数据的压力。大多数商业系统都是以轻量级应用 为主。但随着系统规模的扩大以及用户对服务质量要求的提高，商业系统也面临着重量级 数据应用的压力。这个压力一方面来自商业数据本身，另一方面也来自基于媒体数据的商业服务。由此而产生的计算压力，更使得商业系统不堪重负。

发明内容
本发明的目的在于提出一个降低当前商业服务器相对投入、同时保证性能上显著提高 商业计算系统。这个新系统将具备强伸缩性、高性价比、个性化服务、管理相对方便以及 处理重量级数据的能力。除了为大型商业系统节省投入外，还可以为中小型企业提供廉价 的商业计算环境。
一种互联网大规模应用环境的商用服务系统，包括服务器端和客户端，其特征在于所 述服务器端部署商业逻辑解释器、商业逻辑和商业数据；所述客户端部署有商业逻辑解释 器；所述服务器端和所述客户端通过网络连接。
一种互联网大规模应用环境的商用服务系统工作方法，其步骤为
1) 采用TCP/IP对等协议模式使计算节点具有接收请求和发送请求的能力；
2) 服务器端接收客户端的商业请求并把商业逻辑迁移到该客户端；
3) 服务器端根据该客户端的请求传输商业数据；
4) 服务器端根据客户端的商业服务类别建立动态集群；所述动态集群为一组具有共同 商业数据的客户端；
5) 在上述动态集群中通过多播进行状态维护和商业事务管理。 所述方法中采用SSL方法将所述商业逻辑迁移到客户端。
所述传输商业数据的传输方法为采用缓存的方法逐步将商业数据从服务器端迁移到 客户端。
所述方法中根据流网协议建立所述动态集群；所述动态集群中采用帕累托最优原则进
行节点之间的配合。
所述动态集群中的多播方法为基于改进BT协议的轻量级多播，其方法为
1) 使用跟踪器监测动态集群节点状态；所述状态包括节点是否处于系统中、节点是否 对某个数据关注、节点是否为超级节点、节点是否已获得该数据；
2) 跟踪器根据检测获得的状态均衡分配多播任务，其方法为
a)跟踪器根据节点在线时间长度所形成的历史信息确定适当数量的节点为超级节 点；b)让这些超级节点首先从轻量级数据产生节点得到数据；
C)所述超级节点平均分担剩余节点的多播任务并把相关状态信息返回给跟踪器。 所述方法中，跟踪器协调所述超级节点进行多播任务，其方法为
1) 当一个超级节点试图发送数据时，首先要向跟踪器发出请求；
2) 跟踪器对集群内所有需要发送数据的节点按照请求先后顺序进行排序；
3) 跟踪器对被排序数据进行顺序编号，然后进行异步发送；
4) 每个节点对获得的数据进行处理时，判断数据是否丢失，如果发现编号不连续，则 和数据源联系来获得相关数据。
所述方法中，所述商业事务管理包括
1) 服务器端将可能发生冲突的并发操作改变为符合时序的串行操作，其方法为首先 节点将自身包含写操作的商业事务执行状态通知服务器端；然后服务器端对事务写 操作状态进行统计，按时序和有共同被写数据的事务进行登记；最后服务器端根据 事务管理时序控制原则，回应相关节点是否可以立刻进行写操作或者延迟等待进一 步通知；
2) 通过事务写操作时序控制以及对节点退出系统的监测完成事务放弃后的恢复，其方 法为在服务器端进行事务登记的节点向其邻居周期性地发送心跳数据，如果在固 定周期内其邻居没有收到心跳数据，这可以认为该节点非正常退出，即放弃事务； 之后，该邻居会主动通知服务器端以完成必要的数据恢复；如果节点正常退出，服 务器端正常执行恢复操作。
所述方法中，当新用户访问服务器时，服务器根据用户请求判断用户关心的商业服务， 再据此把数据转发到相关动态集群，使其得到相关服务。
所述节点包括客户端和服务器端。
本发明的基本思想是建立在利用所有可能的计算资源来完成商业计算。当前商用服务 器提供商业服务的核心是其商业逻辑的描述。这个商业逻辑在当前系统中都是集中位于商 用服务器上无论是解释执行还是编译执行，都是在商业服务器的控制之下。这种在商用 服务器集中管理之下的商业逻辑只能使用其宿主的计算资源来响应用户请求。商业逻辑的 执行需要消耗计算资源并且有一个执行时间。为了提高对用户请求的响应速度，商用服务 器普遍必须采用异步或者并行方式。在并行发生时，管理代价会提高，对计算资源的要求也会更高。当用户访问数量增加过于迅速时，服务器不得不调动更多资源来完成并行运算； 其管理代价也会进一步增加。极端情况下，服务器资源无法应付过多请求，用户等待时间 就会无限延长，甚至导致服务器资源耗尽而崩溃。从以上讨论可以看出，如果可以分散用 户请求到不同的计算设备上，就能够减缓对服务器的资源压力。当前商业计算中分散用户 请求的方式是通过布置多个服务器并租用足够带宽来实现的。对于商业逻辑来说，也必须 被布置到这些服务器上。这个过程完全是人工完成的。上面的解决方法是以服务提供者投 入更多资源为特征来增强商业计算能力。本发明采取了另外一种方式，即赋予商业逻辑可 迁移的能力，从而达到免于人工和在运行状态来完成任务转移的目的；更进一步，本发明 并不需要额外布置服务器，而是把可迁移的商业逻辑自动布置到用户控制的计算设备上。 这样就避免了对商业服务提供者的投入压力。
第一步，选择可解释程序作为迁移方案。要实现商业逻辑的迁移，可以有两种方案。 第一种方案是直接迁移执行程序，即编译后得到的目标代码；第二种方案是只迁移可解释 运行的商业逻辑描述。二者都可以完成对商业逻辑的迁移。
(1) 迁移目标代码需要考虑的问题。第一，目标代码大小要远大于可解释程序，造 成传输时网络代价大。其次，目标代码对迁移宿主机要求绝对和原宿主机相兼容。这个要 求在大规模商业应用中可能无法满足； 一个大型商业系统通常包括众多异质客户端，这会 导致目标代码不能在一些客户端上运行。再次，对于一些需要动态适应的商业逻辑，无论 是原宿主机还是新宿主机都无法对目标代码进行改动；这会造成商业逻辑的无法正常运 行。最后，目标代码不易控制。即使目标代码被迁移至完全兼容的客户端，但是由于目标 代码处于单独运行状态，在与客户端原有系统交互时可选择方式有限；对于目标代码消耗 资源以及相关状态管理是无法干预的。这对客户端釆取灵活算法管理自身资源造成了困 难。迁移目标代码的优点在于商业逻辑的安全性容易得到保证，并且运行效率高。除此之 外，相对于可解释程序，其单独执行的特征也会简化客户端原有系统的设计。
(2) 迁移可解释程序需要考虑的问题。与迁移目标代码相比，可解释程序的迁移具 备以下优势。第一，可解释程序的迁移对网络压力小，这是由于可解释程序是对商业逻辑 的描述，其大小有限，属于轻量级数据。第二，可解释程序可以迁移到任何具备相关解释 器的宿主机上，对于大规模商业应用来说可以形成商业逻辑与底层平台无关的效果。第三, 可解释程序被迁移至客户端后，在一些商业应用中可用来动态修改以适应商业过程中的具 体变化。第四，可解释程序在被迁移后会和原有系统无缝结合，成为原有系统的一部分； 宿主机系统可以采取与对自身资源同样的策略进行管理。然而，可解释程序的迁移也有以下问题。第一，运行效率低。这是由于其逻辑必须解释和执行同时进行造成的；这个解释 过程需要消耗资源和时间。第二，安全性略差。可解释程序无论是在网络上迁移当中、还 是在宿主机上运行时，都会因为其本身是对商业逻辑的描述而造成商业秘密的泄露。第三， 解释器的代价大。虽然可解释程序可以做到与平台无关，但其前提是在任何潜在的客户端 或者宿主机上安装解释器。这个代价相比于可执行程序要大。
(3)对迁移程序的选择。综上所述，无论是目标代码还是可解释程序都有各自的优 势和劣势。由于目标代码迁移有无法克服的困难，如在一些客户端无法运行，对于大型商 业系统这是不能接受的，采取迁移可解释程序是必然的。同时，商业计算通常复杂度不高， 即使可解释程序运行相对慢，其相对效率还是可以接受的。本发明需要对客户端和服务器 端都进行改造，在这个改造中嵌入相关商业逻辑解释器不会让用户付出额外负担。在安全 性问题上，这是分布式商业系统都会面临的问题，可以采取SSL方法(参考SSL 3.0 Specification; http:〃wp.netscape.com/eng/ss13/)保证商业逻辑的安全传输。在解决了迁移可 解释程序的困难并结合可解释程序本身的优点后，选择可解释程序进行迁移就是合理的 了。
第二步，通过完整迁移商业逻辑和缓存商业数据的方式在客户端建立数据与商业逻辑 的对应关系。在商业计算环境中，任何一个商业逻辑都是作用于相关数据。当商业逻辑发 生迁移时，相关数据也必须随之迁移，否则会发生逻辑与数据分处不同物理位置的现象； 由于网络延迟，会使得系统性能下降。这要求对商业计算的任务进行划分，分别把不同的 商业逻辑和数据对应起来，不同任务之间能够尽量做到高内聚低耦合。这是对开发人员在 开发过程中的要求。但一个具备商业逻辑和数据迁移能力的系统不能对开发人员的工作过 分依赖。开发工作本身异常复杂，尽量不要因为迁移的需要给开发带来额外负担。在实际 应用中通常会采取一个可接受的方案即可。首先商业逻辑本身在迁移中的传输代价低，因 此即使完整传输也不会造成系统过多负担。其次，对于相关数据来说，可以采取缓存的方 法，逐步把数据从服务器迁移到客户端，而不是一次把相关数据全部迁移。这种做法开始 会和服务器之间有多次交互，甚至会影响客户端响应速度。但之后，随着相关数据被备份 到客户端，相应速度会逐渐提高；更重要的是，迁移后服务器的压力大大降低。
第三步，建立在互联网商业计算环境下的动态集群。动态集群的建立是本发明一个关 键之一。要建立动态集群计算基础，首先需要使得各个节点在拥有请求数据和服务能力的 同时，也具备响应其他节点请求的能力。实现这个目的并不困难，利用基本网络技术1
就可以做到。困难在于突破互联网上存在的NAT障碍，其方法可以参考2。这个问题的解决，可以使得互联网任何两个节点之间可以相互直接交互。这是产生大规模互联网计 算的前提。其次，这样的节点除了可以请求并且响应以外，还需要提高其吞吐量，即在节 点计算资源的允许条件下，可以并发地和多个节点建立通信连接，并可以在这样的连接上 持续传输数据。这里的重要技术就是线程池的实现3。最后，在实现上述目标后，还 有一个重要工作就是赋予节点以寻找合作节点的能力4。在一个大规模互联网系统中， 任何一个节点只能和有限节点进行连接并配合计算。应该在互联网上众多计算节点中为一 个节点寻找到最适合的节点，从而实现计算资源最大限度的利用。动态集群指的是一个在 运行状态下，由各种可能连接在互联网上的计算设备基于共同计算目的，形成的计算资源 共享集合。这个集合具有以下特征。
(1) 生命周期。动态集群是具有生命周期的。 一个普通的动态集群都要经过产生、 发展、成熟、平稳、萧条以及衰败多个阶段。但并不是所有的动态集群都要经过这些完整 的过程。有些集群在产生后会跨越某些阶段而直接衰败或则会长期处于出产生和衰败之外 的某个阶段。动态集群的产生是通过一个计算节点发起一个计算，导致其他节点的响应， 从而形成集群；当响应节点增多时，集群就处于发展阶段；发展阶段会到达一个极限，这 就是成熟阶段；成熟期过后，集群规模会逐渐趋于平衡，规模不再扩大，也没有明显缩小， 即平稳阶段；随着多数节点完成计算并离开这个集群，集群中的节点逐渐减少，从而引发 萧条阶段的形成；当集群中所有计算节点都离开后，集群消亡，进入衰败阶段。
(2) 共同目的。动态集群形成以及维持的基础是共同计算任务。计算任务指的是提 供数据或者服务过程中发生的传输、交互以及运算活动。 一个动态集群包含多个节点；这 些节点都围绕着一个或多个相关计算任务进行相关计算。它们既是相关数据和服务的享受 者，也是相关数据和服务的间接提供者。
(3) 自由组合。动态集群中的节点具有自由组合的特征。无论集群规模大小如何变 化，集群中的节点都是在对相关计算任务感兴趣的条件下加入的。当节点享受了相关数据 或者服务后，或者失去相关计算提供的数据或服务后，则可以随时离开系统而不受任何限 制。
(4) 高度动态。动态集群的主要特征就是这个集群总是处于不断变化当中。这种变 化既体现在集群本身具有生命周期，也体现在节点不断地加入或者离开，甚至体现在集群 所具有的拓扑结构上的变化。这些动态特征反映出集群即刻的状态；对这些状态的把握能
够为建立于这样集群之上的系统起到重要支持作用。
(5) 网状拓扑。作为分布式技术的一种应用形式，任何集群都会以一种拓扑结构的形式表现出来。对拓扑结构的了解，也会对集群的特征把握得恰当。本发明中的动态集群 表现为网状结构。但这个描述过于粗略。对这个结构的认识可以参考相关文章5。之 所以形成网状结构而非其他拓扑结构，是因为这样的结构可以使得各个节点之间能够最大 限度地分享各自的计算资源，从而在高动态的情况下实现计算性能的最大化。图l表示了 动态集群的即刻拓扑结构。
(6)高度异质。虽然各个节点是基于共同任务组织成集群的，但这个集群中仍然存 在诸多不同。所谓高度异质是由以下几个特点表现出来的。第一，节点资源的异质性。各 个节点之间通常表现出所拥有计算资源的差异；而拥有不同计算资源的节点对系统的潜在 贡献是不同的。应该采取适当算法4， 6既保证整个集群的正常运行，也能使得每个节 点能够得到最大化利用其自身资源基础上的服务。第二，数据或服务的异质性。数据和服 务是维系动态集群生命周期处于稳定状态的根本。在高性能集群当中，这样的数据或服务 可以表现出复杂的形态，如各种格式的数据。数据格式的差异导致节点间交互和配合时会 以不同的方式4， 6处理不同性质的数据，达到计算资源的合理使用。第三，节点物理 位置的异质性。由于动态集群的形成完全决定于数据和服务质量，而非人为事先的定义稳 定系统，这导致集群中可能包括来自物理位置差异大的节点。适当的路由方式7， 8可 以既整个集群的高效率，同时也能保证不同物理位置上节点得到公平服务。第四，节点行 为的异质性。节点在动态集群中的行为也有区别。有些节点会以计算资源贡献者的形式出 现，有些则是索取和贡献兼备，还有些只是单纯索取9。动态集群算法必须考虑到这 些特征，以保证集群的高效率。
在拥有了动态集群所需要的基础以及对大规模互联网中动态集群有了认识后，就可以 把相关节点组织起来以形成动态集群。基于上述动态集群的特征，建立动态集群的方法和 在稳定环境下的集群完全不同。流网协议是其中重要解决方寒，将其简单地归纳如下
建立基于社会网络5的路由算法。这个路由方案是建立在社会网络或者复杂网络5基础上的资源寻找算法。由于社会网络本质上是计算节点通过互联网上用户社会属 性而建立起来的符合互联网资源分配规律的拓扑结构，恰当地利用这个网络就能够完成对 计算资源的有效寻找。在利用社会网络进行路由搜索时，主要涉及结构化和非结构化路由 技术的结合问题。结构化路由技术的突出特点是能够对任何资源(稀缺或者流行)在确定 有限时间内获得路由结果，但是这样的结果是建立在严格约束条件下。而这个条件当前互 联网环境难以得到保证。非结构化路由技术建立在互联网自然形成的拓扑结构(即社会网 络)之上，并没有对存在的互联网环境有任何强制要求。在这样的基础上要保证快速获得搜索结果，必须要求对具体的应用以及相应的拓扑结构有深入认识才可达到。但即使如此， 非结构化搜索在路由公平性的保证仍然不足，同时对路由压力的分担也困难。鉴于上述原 因，可以把上述二者恰当结合。由于社会网络中存在群落，群落代表着相对稳定的计算环 境，接近于结构化路由所要求的条件。这样，可以采取在整个互联网中进行非结构化路由， 而在群落中进行结构化路由。通过上述方法，路由算法就做到了有效寻找流行资源以及保 证对稀缺资源的路由公平。
建立动态集群中的事件驱动机制。动态集群形成的基础之一就是相互之间交互是以事 件驱动为前提的。无论是一个节点请求建立连接、发起数据传输以及关闭连接等等基本行 为都是通过事件驱动机制来完成的。这与传统互联网以投票为主的方式截然不同。而当建 立起动态集群的基础之后，这个事件驱动机制就形成了基本框架。再结合高效的轻量级多 播机制，就可以形成一个基于消息的事件驱动机制。这个机制能够适应互联网动态变化的 特征，保证事件驱动机制在高效稳定可靠大规模环境下工作。这个机制的实现提高了互联 网计算节点之间的交互效率，避免了投票机制给系统增加的压力以及对系统变化迟钝反 应。事件驱动保证了关注者能够在事件发生前不用付出额外代价进行投票；同时，在事件 发生后，能够即刻作出反应。互联网环境下远程事件驱动机制成为了反映互联网变化的基 础。互联网本质上是一个不断变化的系统，但这种变化在没有远程事件驱动机制的支持下， 是无法即时反映到相关计算节点的。为了降低计算负担，当前互联网主要应用中甚至拒绝 对这些变化予以跟踪。本发明有效地解决了这个问题。互联网商业计算环境下的动态集群 有自身特点，需要解决如下问题，即适应互联网动态环境、维护共同商业服务、传输轻量 级数据以及管理商业事务等。
(1) 在共同商业目的基础上建立适应互联网环境的动态集群。动态集群本质上是多 个独立个人或人群控制的计算节点配合计算形成的分布式模型。这样的计算节点可以随时 加入系统也可以随时退出系统。它们组合在一起的分布式系统处于由此而产生的不断颠簸 当中。动态集群技术能够根据其计算具体特征利用节点之间共同商业目的的特征，使得这 个集群保持动态中的相对平衡，从而有效利用各个计算节点上的计算资源，达到高性能的 目的。其中主要涉及对节点之间共同目的的维护、轻量级多播技术、时序无关的大数据多 播技术以及时序相关的大数据多播技术等。这些技术在尊重控制节点的个人或人群需要的 基础上，主要运用了帕累托最优原则进行节点与节点之间的配合，并结合大规模分布式环 境中的具体特点形成动态集群。
(2) 通过对全局状态变化的维护保证共同商业服务的正确性。在面向数据的互联网应用中，动态集群形成的目的在于共同协作完成数据传输，其思想是在此过程中充分分享 和利用节点计算资源。商业计算不同于面向数据互联网应用，除了数据传输以外，还有基 于商业逻辑的计算。由于本发明采取的是全部商业逻辑迁移的方式减轻服务器代价，所以 每个计算节点所拥有的商业逻辑是一样的。虽然如此，每个客户端进行的具体商业计算是 不同的，所涉及的数据也是不同的。当商业逻辑作用于商业数据时，会引起商业状态的变 化；并且这个变化必须即刻转发到各个与此数据相关的节点上，否则会引起商业过程的错 误，造成经济损失。可以看出，为保证分布计算过程的正确性，关键在于全局状态变化在 分布计算节点中的维护。为此，在组成集群时，应该把具有共同商业数据的节点组织起来 形成动态集群；当其中一个节点导致数据发生变化时，其余节点能够在集群的帮助下采用 多播技术迅速得到这样的变化，以避免商业计算错误。商业数据和商业服务之间虽然不能 完全等同，但在大多数实际情形下，共同商业数据就意味着共同商业服务。所以，可以认 为对动态集群中共同商业数据的维护，就是对共同商业服务的维护。
(3) 建立基于BT协议轻量级数据多播方式。当前面向数据的互联网应用越来越向重 量级数据发展。但对于大多数商业计算来说，正确和安全始终是最重要的要求。商业数据 一般都可以用轻量级数据来表达和传输。这与面向数据的互联网应用差别很大，至少在传 输上大部分商业应用不会对系统造成大的压力。在商业计算环境下的动态集群当中，数据 传输对每个节点造成的代价会被有效降低；当数据是轻量级时，在集群中传输代价就会更 低。虽然如此，由于集群的动态特征明显，轻量级数据传输的可靠性就成了最关键的问题； 尤其是对商业计算来说更是如此。为此，本发明采用了基于改进BT协议的轻量级多播系 统。
(4) 建立在轻量级可靠多播协议之上的商业事务管理方式。动态集群以及商业逻辑 数据迁移导致一个整体上紧密相关的计算被分布到多个独立计算节点上。这种条件下，任 何对数据的修改都会导致一致性维护的需求。这里必须在可靠多播协议的支持下，采用恰 当管理方案才可以解决。分布式系统中事务管理成为解决这个问题的关键。但由于与一般 分布式系统不同的动态性，本发明中的事务管理必须进行相应修改。后面会对此进行详细 解释。
第四步，建立基于改进BT协议的轻量级多播系统。针对上述问题，本发明建立了基 于改进BT协议的轻量级多播系统。原始的BT协议本质上是一个重量级数据多播协议； 其运行环境与本发明环境是一致的。针对商业应用系统中商业逻辑基本基于轻量级数据完 成的特征，本发明对其进行了改进，使其更适合轻量级数据的多播。(1) 使用跟踪器监测动态集群节点状态。BT协议中的跟踪器是专门用来收集一个潜 在动态集群中所有节点状态的服务器。在本发明的系统中，这个服务器可以通过布置中心 服务器的方法来实现。对于轻量级多播系统来说，需要监测的状态包括节点是否处于系统 中、节点是否对某个数据关注、节点是否为超级节点、节点是否己获得该数据等。这些状 态都会为事件多播系统的质量起到关键作用。在对系统中节点状态把握之后，才能对轻量 级多播任务压力进行合理分担，提高多播效率和可靠性。对于节点状态的监测在本发明中 可以通过参与商业计算的计算节点主动通知跟踪器的形式来完成。在商业应用中，跟踪器 需要监测的状态相对于重量级应用要少，但表现为更集中。主要需要监测的状态是节点是 否需要某个商业数据及其变化、是否获得相关数据以及是否结束商业服务等。同时，由于 商业数据本身已以轻量级为主，传输效率相对高，这导致在短时间内会有大量集中的状态 变化。
(2) 跟踪器根据检测获得的状态均衡分配多播任务。在BT协议中，跟踪器的职责是 向新加入系统的节点返回正在动态集群中工作的部分节点，从而使新节点能够和这些节点 进行交互并加入集群，从而逐步完成重量级数据的多播。在本发明中，跟踪器主要职责由 为新节点提供集群节点转变成为集群现存节点均衡分配多播任务。由于轻量级数据多播涉 及的状态有限，新节点加入只需在跟踪器上记录需要的数据即可。轻量级数据占用带宽低； 每个节点会快速获得相关数据；这会导致在这个过程中跟踪器上保存的节点状态变化频 繁。为减轻跟踪器对于过于集中状态变化监测的负担，可以采用在所有节点中确定适当数 量的节点，让这些节点首先从轻量级数据产生节点得到数据。对于商业应用来说，这个数 量可以依据集群总规模、即时性要求、具体应用特征以及节点特性等因素来确定。通常在 这样的集群中存在少数超级节点，可以将这些节点设置为优先节点首先从数据源获得轻量 级数据；再由这些节点平均分担剩余节点的多播任务并把相关状态信息返回给跟踪器。
(3) 根据在线时间长度所形成的历史信息确定超级节点。跟踪器作为持久在线的服 务器可以根据节点在线时间长度所形成的历史信息确定超级节点。通常在线时间越长，成 为超级节点的可能性越大。根据复杂网络理论5，少数节点在线的时间长度会显著高 于大多数节点。这些节点就成为了超级节点。超级节点表现出在线时间长、运行稳定以及 计算能力强等多种特征，是分担跟踪器监测代价以及完成多播任务的主要计算资源。
(4) 改变节点自私性为贡献性。在BT协议中，每个节点都被假设为以自私方式工作， 即在获得相关数据后不再关心其他节点状态就会独立离开系统；同时在和其他节点交互过 程中也只是在满足自身要求前提下才会和对方交互；否则，会寻找其他节点进行交互。这样的设计对于动态系统中重量级数据多播是正确的。但是对于给系统压力小的轻量级数据 来说就没有必要了。在商业应用中，要求商业数据能够迅速传播。这时每个节点在获得数 据后，应该主动和由跟踪器上返回的节点进行联系，将数据传送给还没有获得数据的节点。 在从超级节点获得数据后，相对于多数普通节点，它们对于轻量级数据的处理能力上相对 平均，这样多播压力就均衡地分布在每个节点上，同时保证了数据传输的即时性。由于多 播是在无明显拓扑结构中进行的，节点的动态特征对于多播质量的影响被降到最低。
(5)保证轻量级数据在多播过程中的顺序。对于商业数据来说，必须保证商业数据 在传输过程中的顺序以确保商业逻辑的正确完成。在强动态性的互联网上，更需要对数据 之间的顺序进行严格维护。要实现上述目的，跟踪器起到了协调作用。当一个节点试图发 送数据时，首先要向跟踪器发出请求；跟踪器对集群内所有需要发送数据的节点按照请求 先后顺序进行排序；多播按照此先后顺序依次进行，即当确认排在前面的节点数据在整个 集群中发送成功后，排在其后的节点数据再进行发送。这样的做法会导致整个系统由于过 度同步而性能下降。也可以采取对被排序数据进行顺序编号，然后进行异步发送。同时每 个节点对获得的数据进行处理时，如果发现编号不连续，则可以判断有数据没有收到，可 以和数据源联系来获得相关数据。这个方法可以提高效率。
第五步，建立基于分布式独立商业事务管理策略。本发明建立在这样一个前提下，一 个商用服务器所涉及的商业逻辑计算所需资源不多；但在面临大量用户同时访问时，商用 服务器会出现计算资源紧缺而不得不采用本发明的技术。每个访问商用服务器的客户端， 都可以在商业逻辑迁移后，在本地进行解释执行该商业逻辑。另外，每个客户端之间在商 业活动中是彼此独立的，并不存在分布在不同客户端但是共同形成一个商业事务的情况； 这个特征使得传统分布式事务管理方法得到简化，即任何一个商业事务都只存在于一个计 算节点上。在这些条件下，本发明提出了分布式独立商业事务管理策略。这个事务管理方 法除了要满足事务管理本身的需求外，还要保证计算压力的平衡。
(1)原始商用服务器作为事务管理协调者参与事务管理。各个商业事务虽然分别独 立存在于一个计算节点上，但是它们都是基于共同的商业数据，这导致当商业逻辑并发执 行过程中商业结果错误的可能。由于各个节点都在并发独立基于共同数据执行商业逻辑， 这就要求这些独立的计算节点具有共同状态。这个共同状态就是时序。对于事务的维护， 基本原则就是使得可能发生冲突的并发操作改变为符合时序的串行操作。在分布式系统 中，各个计算节点的时序是不统一的。为此，原始商用服务器就可以充当这个协调者的角 色以保证时序统一。除此之外，原始商用服务器还涉及一些其他工作，如进入包含写操作商业事务节点统计等。由于计算节点已经分担了大量商业计算以及事务管理的压力，作为协调者来说完成上述工作的计算压力会小， 一般计算设备都可以承受。
(2) 为减轻商用服务器作为协调者参与事务管理代价，通过只监测事务写操作縮小时序管理范围。事务管理的本质就是保证商业逻辑正确执行中数据一致性。但如果在让原始服务器承担过多事务管理压力，就会造成网络延迟增加，系统性能下降。为此，必须设法縮小事务管理范围。通过对大量用户参与为特征商业逻辑的认识，可以得到下述现象，大量用户的商业事务以中并不包含写操作。此外，作为大规模商用系统，即使有写操作，它们在同一时刻面对的共同数据机会也小。这样，原始服务器只需在相对小的范围内进行
事务管理只需要每个节点把自身包含写操作的商业事务执行状态通知原始商用服务器。同时，原始商用服务器对这些状态进行统计，按时序和有共同被写数据的事务进行登记，这样就保留了所有可能发生事务冲突的计算节点。当一个计算节点就要进行写操作时，可以通知原始商业服务器；原始服务器根据事务管理时序控制原则，回应相关节点是否可以立刻进行写或者延迟等待进一步通知。
(3) 通过事务写操作时序控制以及对节点退出系统的监测完成事务放弃后的恢复。根据事务管理的原则可以明确，只要一个事务的写操作在早于其发生的事务承诺或者放弃之后进行，当它放弃时才可以根据历史记录恢复数据到其放弃前的状态。由于原始商用服务器严格把握了包含各节点写操作事务的状态，这就保证了当有事务发生放弃时，仍然能够恢复并且保持数据一致和商业计算的正确。由于本发明基于个人控制的客户端进行商业服务，所以动态性要远远高于传统商用系统。为此，判断一个计算节点是否离开系统就成了保证事务可回复的关键技术。如果一个节点正常离开，那么原始服务器会正常执行恢复操作；但是如果一个节点非正常退出，通常会导致原始服务器无法判断该节点是否完成或者放弃事务。为解决这个问题，本发明中要求在原始服务器上进行事务登记的节点在其邻居中周期性地发送心跳数据。如果在固定周期内其邻居没有收到心跳数据，这可以认为该节点非正常退出，即放弃事务；之后，该邻居会主动通知原始商用服务器以完成必要的数据恢复。
第六步，基于大量用户参与形成的商业动态集群建立个性化商业服务。商业系统中的个性化主要是能够从大量数据或者服务中，有效地确定用户需求，直接为其提供满足其个人需求特制系统。在当前商业计算系统中，这个目的实现困难或者效果不佳。其主要问题是对用户个性不易把握；相关算法不准确并且效率低。这在前面已经有了介绍。本发明个性化的实现是依托于动态集群来完成的。每个成熟的动态集群都是原始商用服务器商业逻辑的一个子集，具备了全部商用服务的一部分数据。当新用户访问原始服务器时，原始服务器可以把这个请求转发到相关动态集群，使其得到相关服务。由于在各个动态集群上的数据在相关用户意愿控制下通过向服务器进行请求逐步缓存获得的，可以认为一个动态集群就是满足一种个性化需求的计算系统。原始服务器可以根据用户请求判断用户关心的商业服务；再据此把数据转发到相关集群上就可以完成个性化服务。需要说明的是，动态集群说具备的个性化不需要任何额外干预；每个动态集群自身就具备了个性化特征；这是自然形成的，是智力资源在计算系统中的体现。只有大量用户参与大规模分布式系统才具备这个特点。
第七步，利用商业服务形成的动态集群实现重量级数据服务。商业计算中的重量级数据会使商业服务本身更加完善质量更高。当出现重量级数据时，本发明可以利用动态集群来完成重量级数据的传输。这种状态下的动态集群除了基于共同商业服务被组织在一起外，更多的资源花费在传输共同需要的重量级数据上。在多数情况下，这两种基于不同计算而形成的集群是高度重合的；这是用户需求在动态集群中趋同的自然特征造成的。因此，不会对其他集群带来影响。
第八步，通过利用客户端计算资源实现无限规模商业计算环境。无限规模商业计算环境的形成对于大型商业服务系统是关键问题。无限规模计算系统的形成主要取决于系统的伸缩性。具备强伸縮性的系统其潜在的规模也会大；反之亦然。由于本发明采取了商业逻辑及其相关商业数据迁移客户端的策略，使得计算在所有请求商业服务的计算节点上进行；同时大多数商业计算潜在的计算量不大，事实上成为了一个系统整体计算资源随着用户访问量增加不降反升的趋势；再加之有效的轻量级数据传输协议，使得网络维护负担降低。这造成了商业系统随着规模增大仍然能够应付甚至会具备更强能力来接纳更大甚至无限规模的潜在客户端。而传统商业系统随着规模增大会逐渐接近资源极限；这与本发明的商业系统形成鲜明对照。从实际应用来看，本发明除了帮助商业系统实现无限规模的目标以外，还大大节省了传统商业系统的投入，也为中小型企业的商业服务提供了低成本计算平台。
本发明的积极效果为
(1)降低基于互联网商用服务器计算资源的投入。本发明首要目的就是降低大型商业巨大的投入成本。通过本发明技术的使用，大型商业系统中的商用服务器只需远低于当前的投入即可达到比当前高投入情况下更高的服务质量。通过本发明用户可以节省计算设备、带宽以及降低服务器软件的设计代价。
(2) 有限计算资源条件下实现大规模商业计算系统。本发明的使用虽然可以大大降低服务器计算资源的投入，但并不妨碍一个商业系统在这样的条件下应付潜在大量客户的访问。当系统规模逐渐扩大时，系统仍然能够稳定地接收用户请求，并对所有请求进行迅速响应。在服务器资源适当保证的前提下，本系统可以达到无限制访问的效果。这是基于当前商用服务器的应用系统所无法解决的。
(3) 保证商业系统的个性化服务。对于基于互联网的大型商业应用来说，这是个明显的需求。本发明可以使得用户在访问商业系统时，能够只在和其个性需求相关的服务资源相互交互，而降低在大型系统中寻找与自身需求匹配服务的代价。
(4) 在商业服务中保证重量级数据传输性能。越来越多的商业系统开始提供重量级数据服务。这大大增加了服务质量和用户体验效果。本发明中的商用互联网服务器能够提供更优质的重量级数据服务，并且不会对计算资源的投入有更高要求。
(5) 建立基于廉价计算设备的商业服务器。对于一些中小型企业来说，没有足够的财力投入到互联网商业应用当中。通过使用本发明涉及的商用服务器，在投入不足的情况下，可以通过使用普通个人计算设备(如个人计算机)以及普通商用带宽(如ADSL)就可以构造出一个高性能商用服务器。如果辅助相关技术，其效果甚至可以达到或接近大型商业应用的效果。
(6) 尽量减少额外管理代价。本发明虽然为互联网商业应用带来上述变化，但由于本发明改造了当前互联网的一些基本结构，也会带来一些问题。这个问题在商业计算当中表现得最为突出。其主要问题体现在管理代价提高。本发明也提出了相关解决方案，保证在带来正面变化的同时，能够尽量减少额外管理代价。


无限规模商用服务器工作流程。
具体实施例方式
在本发明的具体实施当中，通常会遇到如下几种具体情形。通过应用本发明的技术，能够保证这些应用做到无限规模和高性能。
第一，通过个人计算设备建立小型超大规模商业系统。当前互联网商业系统的实施完全不考虑在个人计算设备上建立。个人设备在这里定义为本身计算资源有限、无固定互联
18网地址并且带宽低的计算设备。在当前互联网上，这样的设备在整个连接于互联网上的节 点中占据大多数。之所以当前互联网商业系统不考虑利用个人计算设备建立商业系统，主 要是因为这样的设备不能提供足够的计算资源。基于传统商业系统的建立手段，个人计算 设备无法满足客户对商业服务在规模逐渐扩大后的基本要求。借助本发明，可以在个人计 算设备上建立小型超大规模商业系统。这里的"小型"指的是商业系统本身所包含的服务 简单、涉及的商业数据有限，并非说这个商业系统潜在的规模小。这里的"小型"是由个 人计算设备存贮能力以及个人商业提供者的特征决定的。作为个人计算设备由于存贮空间
相对有限，其包含的商业数据受到限制；同时，个人用户提供的商业服务通常具体并且单 一。但这样的系统有可能拥有潜在的大规模。要实现上述目标，具体实施步骤为
(1) 在个人计算设备上部署商业逻辑和商业数据；
(2) 有意享用此商业服务的客户端安装统一的商业逻辑解释器；
(3) 在互联网上接受来自客户端的商业请求并把商业逻辑迁移至该客户端； (4 )根据用户的请求向客户端传输商业数据并在客户端进行缓存；
(5) 当客户端规模增大时，根据用户享用的商业服务类别形成动态集群；商业服务 类别是指具体商业服务，如卖书、卖电器等；
(6) 在动态集群中通过多播进行状态维护以及商业事务管理；
(7) 在个人计算设备允许的情况下，为用户提供一般质量的重量级数据服务以增强 服务质量。
第二，通过大型服务设备建立面向个人用户超大规模商业系统。除了利用个人计算设 备提供商业服务以外，对于致力于提供大型商业服务的企业来说，可以投入高得多的计算 资源来保证丰富的商业服务种类以及大量的商业数据。但是和传统建立大型商业服务系统 所采取的方法不同，利用本发明所需投入的计算资源总量要低，同时主要功能也不同。在 传统互联网商业环境中，所有商业计算以及相应管理任务都集中在这些设备上；对于本发 明的商业环境，投入的计算资源主要功能是管理而非直接商业计算。之所以需要比个人计 算设备相对多的计算资源，是为了存贮更多的商业数据、应付更大量的管理工作以及提供 高质量的重量级数据服务等。
(1) 在大型服务设备上部署商业逻辑和商业数据；
(2) 有意享用此商业服务的客户端安装统一的商业逻辑解释器；
(3) 在互联网上接受来自客户端的商业请求并把商业逻辑迁移至该客户端；
(4) 根据用户的请求向客户端传输商业数据并在客户端进行缓存；(5) 当客户端规模增大时，根据用户享用的商业服务类别形成动态集群；
(6) 在动态集群中通过多播进行状态维护以及商业事务管理；
(7) 为用户提供高质量的重量级数据服务以增强服务质量。
第三，通过大型服务设备为企业和个人提供商业环境。在互联网商业应用中，除了提 供商业逻辑和商业数据为终端用户提供商业服务外，还存在一种情况是为企业和个人提供 商业环境，从而帮助这些企业和个人借助这样的商业环境来为用户提供各自的商业服务。 利用传统互联网技术实现上述应用要求服务提供者负担所有计算资源。这些资源包括主要 商业逻辑、可适应商业逻辑、计算能力、内存空间、持久存贮空间以及带宽等等。除了具 体商业数据以外，几乎所有资源都由提供者投入。还有一个情况是，商业环境的提供者还 可以准备简洁的描述接口供用户表达其独特的商业逻辑；同时，商业环境中拥有逻辑解释 器来负责执行用户的商业逻辑。但无论哪种情况，对商业环境的提供者都要求足够的计算 资源以应付所有用户的计算压力。在这一点上和直接面对终端用户的商业服务来说是一致 的。为了减少商业环境提供者的计算压力并尽可能扩大商业环境说容纳的用户规模，可以 采用本发明的技术。利用本发明，商业环境的提供者只需负担主要商业逻辑、可适应商业 逻辑、商业逻辑描述工具、商业逻辑解释器以及少量计算资源即可。达到这个目标的原因， 同样是因为在本发明支持下的商业环境服务之负责管理而非直接商业计算。
(1 )在大型服务设备上提供主要企业或个人进行商业服务所涉及的商业逻辑；
(2) 除了具体的商业逻辑以外，还可以提供可适应商业逻辑、商业逻辑的描述及其 解释器；
(3) 接受企业或者个人对商业环境的请求，并根据其要求为其配置相关商业逻辑；
(4) 要求用户提供商业数据；
(5) 接受次级用户的请求并向其迁移相应的商业逻辑；
(6) 根据次级用户的请求在用户客户端缓存商业数据；
(7) 在次级用户的客户端之间形成动态集群；
(8) 在动态集群内部通过多播进行状态维护以及商业事务管理；
(9) 在动态集群内部进行重量级数据服务。
第四，通过小型服务设备建立企业内部商业环境。通常在一个企业内部也存在一个商 业环境。企业通过这个商业环境进行企业内部管理。这个环境与真实互联网环境的差别主 要体现在环境更安全、网络资源更丰富和更稳定。在这种情况下，本发明对系统的改造作 用不如在真实互联网环境下明显。但如果把本发明利用在企业内部商业环境中，仍然可以有效减小对企业商业环境资源的要求，并获得更强的重量级数据服务的支持。在这样的环 境中，本发明使用的基本方式没有变化主要指导思想仍然是把计算有中心服务设备转移 到客户端，中心服务设备只负责协调和管理任务。不同的是，由于企业内部网络资源丰富， 计算节点之间联系代价低以及企业内部固有的管理机制等因素，造成企业内部节点形成的 系统趋于稳定，这时基于轻量级多播的机制可以采用简单的树状拓扑结构即可。另外，当 系统规模不大时，重量级数据服务也可以采取树状或者森林拓扑结构为主的形式来进行。 这里实际上意味着动态集群的建立更加方便，而无需在大规模互联网环境下那样复杂的机 制。无论如何，由于计算被转移到客户端，使得在企业内部之使用小型服务设备就可以获 得比当前集中式的方式更强的计算性能。
(1) 在企业内部小型服务设备上部署商业逻辑和商业数据；
(2) 在企业内部参与商业服务的客户端上安装统一的商业逻辑解释器；
(3) 在企业内部网络上接受来自客户端的商业请求并把商业逻辑迁移至该客户端； (4 )根据用户的请求向客户端传输商业数据并在客户端进行缓存；
(5) 当客户端规模增大时，根据用户享用的商业服务类别形成基于树状拓扑结构的
集群；
(6) 在上述集群中通过多播进行状态维护以及商业事务管理；
(7) 在上述集群中提供高质量的重量级数据服务以增强服务质量。
第五，通过小型服务设备建立企业间商业环境。在当前商业计算环境中，还存在一种 企业之间协同计算的方式。不同企业由于业务上的需要，也产生了相互之间的依赖，从而 形成基于企业计算资源的商业应用。更普遍的情况是，每个企业还拥有大量客户端；这些 客户端以一个企业提供商业服务为中心；而企业之间有因为商业关系形成关联。在这样复 杂的情况下， 一个企业和其客户端之间可采用前面第二种方式进行计算；而在企业之间， 由于相互之间业务稳定、计算资源丰富，这可以采取类似企业内部的方式即第四种情况来 解决计算压力问题。
(1) 以第二种方式完成企业和其客户端之间的商业服务；
(2) 以第四种方式完成企业之间的商业服务。
参考文献
1Vinton Cerf; Specification of Internet Transmission Control Program; RFC 675, December 192Rosenberg J.， et al; STUN — Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs); RFC 3489， March 2003
Ananth Grama， et al; Introduction to Parallel Computing; Second Edition, Benjamin/Cummings Publishing Company Inc, 1994， ISBN: 0-201-64865-4Cohen B.; Incentives Build Robustness in BitTorrent; in Workshop on Economics of Peer-to-Peer Systems, Berkeley USA, May 2005Newman M E J.; The Structure and Function of Complex Networks; SIAM Review, 2003,45， Page(s): 167-256Vlavianos Aggelos， et al; BiToS: Enhancing BitTorrent for Supporting Streaming Applications; INFOCOM 2006， 25th IEEE International Conference on Computer Communications Proceedings, April 2006， Page(s): 1-7Rowstron A., Druschel P.; Pastry: Scalable, Decentralized Object Location and Routing for Large-Scale Peer-to-Peer Systems; in Proceedings of the 2001 ACM SIGCOMM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM，Ol), San Diego, CA， August 2001, page(s): 247-258Gribble S.D.; Measuring and Analyzing the Characteristic of Napster and Gnutella Hosts; Multimedia Systems Journal, 9(2), August 2003, page(s): 170-189Adar E.， Huberman B.A.; Free Riding on Gnutella; First Monday, Internet Journal, Oct. 2000， Available at http:〃www.firstmondav.dk/issues/issue5 10/adar/index.html
权利要求
1.一种互联网大规模应用环境的商用服务系统，包括服务器端和客户端，其特征在于所述服务器端部署商业逻辑解释器、商业逻辑和商业数据；所述客户端部署有商业逻辑解释器；所述服务器端和所述客户端通过网络连接。
2. —种互联网大规模应用环境的商用服务系统工作方法，其步骤为1) 采用TCP/IP对等协议模式使计算节点具有接收请求和发送请求的能力；2) 服务器端接收客户端的商业请求并把商业逻辑迁移到该客户端；3) 服务器端根据该客户端的请求传输商业数据；4) 服务器端根据客户端的商业服务类别建立动态集群；所述动态集群为一组具有共同 商业数据的客户端；5) 在上述动态集群中通过多播进行状态维护和商业事务管理。
3. 如权利要求2所述的方法，其特征在于采用SSL方法将所述商业逻辑迁移到客户端。
4. 如权利要求2所述的方法，其特征在于所述传输商业数据的传输方法为采用缓存的方法逐步将商业数据从服务器端迁移到客户端。
5. 如权利要求2所述的方法，其特征在于根据流网协议建立所述动态集群；所述动态集群中采用帕累托最优原则进行节点之间的配合。
6. 如权利要求5所述的方法，其特征在于所述动态集群中的多播方法为基于改进BT协议 的轻量级多播，其方法为1) 使用跟踪器监测动态集群节点状态；所述状态包括节点是否处于系统中、节点是否 对某个数据关注、节点是否为超级节点、节点是否已获得该数据；2) 跟踪器根据检测获得的状态均衡分配多播任务，其方法为a) 跟踪器根据节点在线时间长度所形成的历史信息确定适当数量的节点为超级节 点；b) 让这些超级节点首先从轻量级数据产生节点得到数据；C)所述超级节点平均分担剩余节点的多播任务并把相关状态信息返回给跟踪器。
7. 如权利要求6所述的方法，其特征在于跟踪器协调所述超级节点进行多播任务，其方 法为1)当一个超级节点试图发送数据时，首先要向跟踪器发出请求；2) 跟踪器对集群内所有需要发送数据的节点按照请求先后顺序进行排序；3) 跟踪器对被排序数据进行顺序编号，然后进行异步发送；4) 每个节点对获得的数据进行处理时，判断数据是否丢失，如果发现编号不连续，则 和数据源联系来获得相关数据。
8.如权利要求2所述的方法，其特征在于所述商业事务管理包括1) 服务器端将可能发生冲突的并发操作改变为符合时序的串行操作，其方法为首先 节点将自身包含写操作的商业事务执行状态通知服务器端；然后服务器端对事务写 操作状态进行统计，按时序和有共同被写数据的事务进行登记；最后服务器端根据 事务管理时序控制原则，回应相关节点是否可以立刻进行写操作或者延迟等待进一 步通知；2) 通过事务写操作时序控制以及对节点退出系统的监测完成事务放弃后的恢复，其方 法为在服务器端进行事务登记的节点向其邻居周期性地发送心跳数据，如果在固 定周期内其邻居没有收到心跳数据，这可以认为该节点非正常退出，即放弃事务； 之后，该邻居会主动通知服务器端以完成必要的数据恢复；如果节点正常退出，服 务器端正常执行恢复操作。
9. 如权利要求2所述的方法，其特征在于当新用户访问服务器时，服务器根据用户请求 判断用户关心的商业服务，再据此把数据转发到相关动态集群，使其得到相关服务。
10. 如权利要求2、 5至9中任一权利要求所述的方法，其特征在于所述节点包括客户端和 服务器端。
全文摘要
本发明公开了一种互联网大规模应用环境的商用服务系统及其工作方法，属于分布式技术领域。本发明的系统包括服务器端和客户端，服务器端上部署商业逻辑解释器、商业逻辑和商业数据；客户端上部署有商业逻辑解释器；服务器端和客户端通过网络连接。本发明的方法为服务器端接收客户端的商业请求，并根据请求把商业逻辑迁移和商业数据迁移到客户端；然后服务器根据客户端的商业服务类别建立动态集群；并对动态集群通过多播进行状态维护和商业事务管理。本发明降低了基于互联网商用服务器计算资源的投入，同时能够实现大规模的商业计算，本发明的系统不仅维护代价低、同时具有个性化特征。
文档编号H04L29/06GK101645872SQ20081011782
公开日2010年2月10日 申请日期2008年8月5日 优先权日2008年8月5日
发明者冰 李 申请人:北京大学