云计算环境下的基于SOA的可扩展的分布式架构

摘要

本发明涉及软件系统架构领域的一种分布式软件架构，基于面向服务的体系架构SOA的理念，能够充分利用云计算平台的优势、便于扩展系统的处理能力、便于功能的维护和扩展，包括服务组件、任务池和应用程序；应用程序是面对最终用户的入口，根据业务逻辑的需要发出调用服务组件的任务，放入任务池；而服务组件则不断检查任务池，取走和自身相关的任务进行处理，并放回任务池；任务池负责接收任务，按照服务组件种类放入相应队列，并根据需要对服务组件返回的结果进行处理后，返回给应用程序。本发明可以通过增加任务池和分配服务组件可以扩展系统的处理能力，通过修改、替换或者增加服务组件能够方便的扩展系统的功能。

说明书

技术领域

本发明设计软件系统架构设计领域，尤其涉及云计算环境下的可扩展的软件架构设计。

背景技术

随着计算机技术的不断发展，人们对软件的功能、性能、处理能力等各个方面都提出了更高的要求，从而导致软件规模和复杂度日益增大。而今天云计算平台的出现又给软件行业带来了新的挑战。如何在云计算环境下实现软件？如何使这样的软件具有最大的代码复用？如何充分利用云计算平台的特性？等等这些问题都是我们今天需要面对的。下面首先来看看本发明所涉及的一些概念。

云计算，狭义云计算是指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需的资源(硬件、平台、软件)。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。这种特性经常被称为像水电一样使用IT基础设施。广义云计算是指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需的服务。这种服务可以是IT和软件、互联网相关的，也可以使任意其他的服务。

可扩展，一方面是指系统拥有这样一种能力，能够自如的处理不断增长的负荷。比如说，一个系统可以在负荷增大时通过增加新的资源或者降低性能来提高系统的吞吐量。另一方面，可扩展性也指系统能够便捷的增加或者修改某种功能，而不对现有系统的各个其他模块造成大的影响。

SOA，面向服务的体系结构(Service-oriented architecture)是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中前提有下面两点：

1)软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。

2)SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵单，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点是如何决定了SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：a)大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；b)大量、频繁的数据传输仍然速度缓慢并且不稳定；c)版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

发明内容

本发明的目的在于构造一种基于云计算平台的架构方式，一种能够充分利用云计算平台的优势、便于扩展系统的处理能力、便于功能的维护和扩展的分布式软件架构。

为达到上述目的，本发明所设计的架构方式如下：

架构中包括应用程序、服务、任务池；

根据面向服务的体系架构(SOA)的原则，将软件的可复用的功能模块剥离，只关注与其功能相关的逻辑，独立提供服务，以下均成为“服务”

应用程序作为直接面对最终用户的部分，是整个软件的入口，关注该应用所提供业务的业务逻辑，通过任务池来访问各个服务，以下称为“应用”；

任务池是一个临时存放应用程序对服务的调用的地方，应用将调用放入池中，而服务到池中取出相应的任务进行处理，并将返回结果在放回到池中。

服务可以存在多个，相互之间不发生交互；每个服务提供一套API外部接口，通过API调用来为调用者提供服务，同时在保证API接口不变的情况下，可以随时更换或修改服务模块，从而实现服务模块的复用。根据功能模块的相关性，一个服务可以包含一个或多个相关的功能模块；而不同的服务可以部署在同一个物理硬件上，也可以部署在不同的物理硬件；这样可以根据需要对特定服务调整它的硬件配置，从而能够通过最低的成本达到最大的系统吞吐量。

应用是系统直接面对最终用户的部分，关注和处理应用的业务逻辑，根据业务逻辑拆分不同步骤，调用相应的服务，并将服务的返回结果合并，返回给最终用户。

由于所有对服务的调用都放入同一个任务池，在服务众多并且高吞吐量的情况下，任务池有可能会首先达到处理能力的上限，此时任务池成了整个系统处理能力的瓶颈，那怎么解决这个问题？我们可以通过增加一个任务池并将部分服务的调用导向新的任务池从而解决处理极限的问题。在未来需要的时候我们可以通过增加更多的任务池来进一步提高整个系统的吞吐量。

服务独立于应用存在，这使得同一服务可以给不同的应用提供服务，只要这些应用按照服务公开的API接口来调用即可。

而且这个架构还可以通过一些小的变化来实现一些额外的特性：

1.容错性

对需要容错的服务，复制存在n个相同的服务，对于放入任务池的每个此类服务调用，都会同时被这n个服务来进行处理，只要其中一个服务能够正确处理并返回结果值，那么这个调用就是成功的，从而实现容错。

2.精确性

对于有精确性要求的服务，复制存在三个以上的相同服务，对于放入任务池的每个此类调用，都会同时被这些服务来处理，而任务池会等待所有服务都有返回值后，对所有结果取平均值，返回此平均值，从而保证结果的精确性。

附图说明

附图描述本发明的示例性实施方案，其中：

图1是本发明所设计的架构示意图；

图2是在大吞吐量环境下本发明的架构示意图；

图3是本发明的系统各部分进行注册的示意图；

图4是本发明架构的实施示例中一次典型的完整请求的时序图；

具体实施方式

下面参照附图对本发明进行详细的说明。以下对本发明的详细说明并不是对本发明的限制。相反，本发明的范围是由所附权利要求来限定的。

本发明的架构示意图，如图1所示，存在服务1到服务N(102)多个服务，应用1到应用N(101)多个使用其中某些服务的应用，以及一个任务池103。应用101将对服务102的调用作为一个任务104放入任务池103，而服务102则到任务池103中取出与其相关的任务104，进行处理，并将结果返还给任务池103，任务池103再将相应的结果返还给应用101。

在调用量大或者服务102或应用101众多的情况下，任务池103的有可能会达到它的处理极限，从而成为系统性能的瓶颈。这时，本发明通过增加一个新的任务池来解决这个问题。如图2所示。通过增加一个任务池203，并将对服务1到服务M(202)的调用任务204导向到任务池1(203)，而对服务M+1到服务N(202)的调用任务204导向到任务池2(203)，从而形成一个任务池203的负荷分担，解决任务池203处理能力成为性能瓶颈的问题。

而应用会根据对不同服务202的调用需要，将相应的调用任务204放入相应的任务池203当中，以得到正确的处理。

在将来任务池203的处理能力再次达到极限时，可以依照此方法增加更多的任务池203，从而不断的扩展处理能力。

由于服务和任务池都是通过开放式的web接口来提高服务的，为了避免恶意的攻击和对数据的非法操作，需要对所有接收到的调用进行鉴权，以鉴别调用方是否有合适的权限来访问数据。那么第一层的鉴权是鉴别调用方是否是一个合法的调用者。

为了要达到这个目的，我们需要给合法的调用者一个身份识别。这个身份识别必须是唯一的，而且无法被恶意的调用者伪造。于是我们借鉴了OAuth方式，为每一个合法的调用者提供一套唯一的私钥和公钥。

在本发明的架构中，如图3所示，应用301如果要使用服务302，就需要到服务302上进行注册，注册时提供应用的使用信息，注册成功后，服务302会给出应用301独有的一套私钥和公钥。私钥只有应用301和服务302知晓。

同样的，由于应用301和服务302都将访问任务池303，所以它们都应该到任务池303进行注册，方式和过程与上述的相同。

下面我们根据图4所示来详细说明一下在本发明架构下一次典型的任务请求的完整流程：

步骤404、405：在整个运转过程中，服务402以一定的频率轮询任务池403，以查询是否有对服务402的任务存在，如果有则取出处理。

步骤406：如果此时应用401需要发起一个对服务402的调用请求，应用401将调用请求用之前在服务402注册时获得的私钥和公钥进行签名，然后封装在一个任务中，这个任务用之前在任务池403注册时获得的私钥和公钥进行签名，最后发送任务请求给任务池403。

步骤407：任务池403在收到应用401发来的任务请求后，首先对应用401进行鉴权，以检查应用401是否是任务池403合法的访问者。鉴权的方法是：任务池403首先查到保存的分配给应用401的私钥，并与任务请求中的公钥一起对任务进行相同算法的签名，然后比较这次签名的结果和任务请求中的签名，如果一致则鉴权通过。

步骤408：通过鉴权后，任务池403将判断此任务是对哪一个服务402的请求，然后将任务放入任务池403中此服务402的任务队列中。

步骤409：如果此时服务402又一次过来轮询。轮询请求也是由服务402使用之前在任务池403注册时获得的私钥和公钥进行签名的。

步骤410：任务池403在收到服务402发来的轮询请求后，首先对服务402进行鉴权，以检查服务402是否是任务池403合法的访问者。鉴权的方法是：任务池403首先查到保存的分配给服务402的私钥，并与轮询请求中的公钥一起对轮询进行相同算法的签名，然后比较这次签名的结果和轮询请求中的签名，如果一致则鉴权通过。

步骤411：通过鉴权后，任务池403检查服务402所对应的任务队列是否为空，如果不为空，则取出队列中第一项任务。

步骤412：任务池403返回该任务给服务402。

步骤413：服务402在获得任务后，对任务中包含的请求进行鉴权，以检查应用401是否是服务402的合法访问者。鉴权的方法是：服务402从请求中鉴别是哪个应用401发来的请求，然后查到保存的分配给此应用401的私钥，并与请求中的公钥一起对请求进行相同算法的签名，然后比较这个签名和请求中的签名，如果一致则鉴权通过。

步骤414：在鉴权通过后，服务402将分析请求所有访问的是哪些数据，而应用401是否拥有对这些数据的访问权限，如果没有，则拒绝这次请求。如果有，则进行下一步。

步骤415：在确认应用401的此次请求是访问其拥有权限的数据后，服务402对请求进行处理。

步骤416：服务402发送处理的结果给任务池403，其中包含了当初获取的任务的任务识别号。

步骤417：任务池403在收到结果后，根据结果中的任务识别号，查询到对应的是哪一次的任务请求，并相应返回任务结果。

步骤418…步骤4xx：服务402依然不断的对任务池403进行轮询，不断循环步骤406到步骤417之间的过程。

通过以上的说明可以看出，本发明的架构通过增加一些请求和鉴权的开销，大大增强了系统的模块复用、可维护性以及处理能力的高扩展性。使得服务可以被不同的应用完全共享，服务和任务池一起组成了一个分布式的应用开发平台，不同的应用可以通过这个平台上使用部分或全部的服务来搭建。而开放这个平台接口，引入第三方应用的开发，也将变得非常容易。

每一个服务都提供一套应用侧的API文件，从应用的角度，无需知道或者关心对服务的调用是在本地进行的还是通过web接口进行；因为API文件已经封装了内部的细节，全权处理与任务池和服务的交互，这使得应用侧的编码无需关心开发平台的架构细节，只需关注在自身的业务逻辑编码上即可，大大减轻了应用侧编码的工作量。

综上所述，为云计算环境下可扩展的分布式架构的设计说明。上述的示例性的实施方案在所有方面趋于是用来描述而不是限制本发明。因此，本发明能够在具体实现中具有许多变种，也并不局限于云计算环境(比如也可应用于多线程环境)，本领域的技术人员能够通过包含在本文中的描述得到这些变种。所有在本发明的精神和原则之内的任何变种、修改、替换等，均应包含在本发明的权利要求范围之内。