一种服务化软件系统架构及其应用方法与流程

本发明涉及服务软件技术，更具体的说，是涉及一种服务化软件系统架构及其应用方法。

背景技术：

近年来随着互联网信息技术的发展，通过网络信息平台进行的相关网络技术的应用系统越来越多，不同应用系统间的关联性也越来越复杂。例如，为了保证应用系统的适应性，应用系统在开发时往往需要同时支持各种客户端，包括pc桌面浏览器、移动浏览器及原生移动应用等。

如图1所示，传统的it系统，是以技术分层，譬如数据层、逻辑层等，我们称之为单块架构系统。但随着产品周期短、用户需求个性化、市场需求不稳定等因素的出现，单块架构系统不旦无法满足多元化的需求，灵活性、可伸缩性等情况都面临着越来越多的问题。

技术实现要素：

有鉴于此，本发明提供了一种，以克服现有技术中由于的问题。

为实现上述目的，本发明提供如下技术方案：

一种服务化软件系统架构，包括：

注册中心，用于记录服务与服务地址之间的映射关系，并管理应用系统的调用权限；

配置中心，用于对所述服务化软件系统架构中的服务节点做配置管理，实时监控各个所述服务节点的工作状态；

服务中心，具有多个能够独立运行的服务节点，所述服务节点用于接受应用系统的调用，并为所述应用系统提供相应的服务，其中，不同的服务节点能够组合执行不同的业务逻辑。

可选的，所述注册中心具体用于：

收集所述服务化软件系统架构中所有的服务，记录每一个服务与服务地址之间的映射关系，并管理不同的应用系统的服务调用权限。

可选的，所述配置中心具体用于：

对所述服务化软件系统架构中的服务节点做配置管理，实时监控各个所述服务节点的工作状态，并将所述服务节点的工作状态发送给所述注册中心，以使其将工作异常的服务节点从可调用服务节点列表中删除。

可选的，所述服务中心具体用于：

向所述配置中心提供各个所述服务节点的配置信息，以使得各个所述服务节点后续根据其自身对应的配置信息提供服务。

可选的，所述配置信息包括服务器ip和端口。

一种服务化软件系统架构的应用方法，包括：

接收应用系统发送的请求；

确定所述应用系统服务注册列表，所述服务注册列表中记录了所述应用系统有权限调用的服务信息；

调用所述有权限调用的服务信息对应的相关服务，其中，每一个所述服务为能够独立运行的服务。

可选的，还包括：

监测各个服务节点的工作状态，确定工作异常的服务节点，并将所述工作异常的服务节点从所述服务注册列表中删除。

可选的，在所述确定所述应用系统服务注册列表后，还包括：

判断所述服务注册列表是否为空；

若否，则进入所述调用所述有权限调用的服务信息对应的相关服务的步骤。

可选的，还包括：

在监测到服务节点的更新信息后，将所述更新信息同步至所述服务注册列表。

经由上述的技术方案可知，与现有技术相比，本发明实施例公开了一种服务化软件系统架构及其应用方法，服务化软件系统架构包括注册中心，用于记录服务与服务地址之间的映射关系，并管理应用系统的调用权限；配置中心，用于对所述服务化软件系统架构中的服务节点做配置管理，实时监控各个所述服务节点的工作状态；服务中心，具有多个能够独立运行的服务节点，所述服务节点用于接受应用系统的调用，并为所述应用系统提供相应的服务，其中，不同的服务节点能够组合执行不同的业务逻辑。上述服务化软件系统架构可以接收应用系统请求，获取服务注册列表，调用所述服务注册列表中记录的有权限调用的服务。由于服务中心的多个服务都为能够独立运行的服务，具备松耦合、独立部署的特点，因此能够适应不同应用多的元化的需求。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为传统it系统架构示意图；

图2为本发明实施例公开的服务化软件系统架构图；

图3为本发明实施例公开的服务化软件系统架构的工作原理图；

图4为本发明实施例公开的一种服务化软件系统架构的应用方法的流程图；

图5为本发明实施例公开的另一种服务化软件系统架构的应用方法的流程图；

图6为本发明实施例公开的又一种服务化软件系统架构的应用方法的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图2为本发明实施例公开的服务化软件系统架构图，如图2所示，服务化软件系统架构可以包括：

注册中心201，用于记录服务与服务地址之间的映射关系，并管理应用系统的调用权限。

本实施例中，注册中心201为服务化软件系统架构最核心的基础服务之一，简单理解来说，注册中心可以说是服务化系统架构中的“通讯录”，记录了服务与服务地址间的映射关系。此外，所述注册中心201中还可以记录应用系统与其有权限调用服务之间的对应关系。当一个应用系统访问该服务化软件系统架构时，注册中心201会根据其记录的该应用系统有权限调用的服务，向该应用系统提供一个清单，清单上记载了其能够调用的服务信息，所述应用系统根据自身需求调用所述清单上的相关服务。

在其他的实现方式中，注册中心201也可以实现计算机域名系统服务器或负载均衡服务器的相关功能。

为了更好的理解注册中心201，举例如下：假如当前有个网站，其中有用户模块，这里假设将用户模块的登录、注册或改密码等功能抽离出来以服务的形式单独部署多台机器(暂称用户服务)，这个时候当网站需要向用户服务获取并执行某些功能的时候首先需要先知道“我能调用哪些服务和对应的哪些机器”，本实施例中，注册中心201负责收集当前架构上所有的服务(用户服务、产品服务、支付服务等等)，告诉网站“你有这些服务可以调用”。

配置中心202，用于对所述服务化软件系统架构中的服务节点做配置管理，实时监控各个所述服务节点的工作状态。

配置中心202作为服务化软件系统架构设计中的核心管理部件，主要用于解决分布式环境下如何去做软件配置管理的问题。通过统一的中央配置平台去配置管理不同的服务；配置中心还可以提供可分离、高可用、高稳定性的配置服务方案。

一般来说一个服务可能会同时部署到多个节点，而当一个节点出现异常导致无法访问的情况下，配置中心202扮演的主要职责为收集并监控每个节点的正常响应状态，并告诉注册中心201某个节点是否能正常返回给业务系统。例如：某服务部署了a和b两个节点，业务系统需要访问这个服务时需要先向注册中心201获取这个服务有哪些节点可以访问，而这时b节点出现异常，配置中心202将状态通知了注册中心201，这时注册中心201返回给业务系统的服务列表中将自动删除b节点。

服务中心203，具有多个能够独立运行的服务节点，所述服务节点用于接受应用系统的调用，并为所述应用系统提供相应的服务，其中，不同的服务节点能够组合执行不同的业务逻辑。

服务中心203为底层核心基础服务之一，本实施例中，应用系统将单一业务逻辑拆分为多个服务，服务与服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间可采用轻量级的通信机制互相沟通。

本实施例中，所述服务化软件系统架构中的每个服务都围绕着具体业务进行构建，具备松耦合、独立部署的特点，因此能够适应不同应用的多元化的需求。

上述实施例中，所述注册中心具体可用于：收集所述服务化软件系统架构中所有的服务，记录每一个服务与服务地址之间的映射关系，并管理不同的应用系统的服务调用权限。

上述实施例中，所述配置中心具体可用于：对所述服务化软件系统架构中的服务节点做配置管理，实时监控各个所述服务节点的工作状态，并将所述服务节点的工作状态发送给所述注册中心，以使其将工作异常的服务节点从可调用服务节点列表中删除。

上述实施例中，所述服务中心具体可用于：向所述配置中心提供各个所述服务节点的配置信息，以使得各个所述服务节点后续根据其自身对应的配置信息提供服务。其中，所述配置信息可以包括服务器ip和端口。

图3为本发明实施例公开的服务化软件系统架构的工作原理图，可结合图3所示内容理解服务化软件系统架构的工作内容。

其中，应用系统、配置中心集群和服务集群预先都在注册中心集群注册了相关内容，因此，注册中心集群中记录了服务集群中所有服务与服务地址之间的映射关系，记录了各个服务的配置信息，还记录了各个应用系统可以调用的服务。工作过程中，配置中心可以随时从服务集群拉取配置信息，这样，当服务集群中有服务信息更新时，配置中心就能够获取更新信息，并将更新信息告知给注册中心，以使得注册中心能够根据最新的服务配置信息为应用系统分配可调用服务。

本发明还公开了一种服务化软件系统架构的应用方法，下面给出具体的实施例进行详细说明。

图4为本发明实施例公开的一种服务化软件系统架构的应用方法的流程图，参见图4所示，服务化软件系统架构的应用方法可以包括：

步骤401：接收应用系统发送的请求。

当用户使用某个应用系统时，应用系统就会向服务化软件系统架构发出调用服务的请求。具体的，可以是调用服务的请求。

步骤402：确定所述应用系统的服务注册列表，所述服务注册列表中记录了所述应用系统有权限调用的服务信息。

由于服务化软件系统架构中，注册中心负责应用系统的调用权限管理，因此，因此，服务注册列表可以由注册中心确定提供。

步骤403：调用所述有权限调用的服务信息对应的相关服务，其中，每一个所述服务为能够独立运行的服务。

所述服务注册列表中存在的服务，都是能够正常工作的服务，在确定了所述应用系统有权限调用的服务后，可直接调用所述服务注册列表中的服务。

本实施例中，由于服务化软件系统架构中的每一个服务都为能够独立运行的服务，因此这些独立的服务之间存在松耦合、独立部署的特点，这就使得不同应用及业务的开发更加灵活，且维护成本低，能够适应不同应用的多元化的需求。

图5为本发明实施例公开的另一种服务化软件系统架构的应用方法的流程图，参见图5所示，服务化软件架构的应用方法可以包括：

步骤501：接收应用系统发送的请求。

步骤502：确定所述应用系统服务注册列表，所述服务注册列表中记录了所述应用系统有权限调用的服务信息。

步骤503：监测各个服务节点的工作状态，确定工作异常的服务节点，并将所述工作异常的服务节点从所述服务注册列表中删除。

服务化软件系统架构中包括很多服务节点，在正常工作过程中，由于服务节点自身的内因或外因，一些服务节点会出现异常状态，使得其不能或不能准确提供相关服务，因此，本实施例中，可以根据预设规则，例如周期性的，或者在检测到状态或信息发生变化时，监测各个服务节点的工作状态，及时了解所有服务节点的工作情况，确定已不能正常提供服务的服务节点，将其从所述服务注册列表中删除，使其暂停工作，以免后续导致应用系统在调用时出错。

步骤504：调用删除工作异常的服务节点后的服务注册列表中的相关服务，其中，每一个所述服务为能够独立运行的服务。

本实施例中，能够监测各个服务节点的工作状态，及时将工作异常的服务节点从服务注册列表中删除，避免后续应用系统在调用工作异常的服务节点时出错。

图6为本发明实施例公开的又一种服务化软件系统架构的应用方法的流程图，结合图6所示，服务化软件架构的应用方法可以包括：

步骤601：接收应用系统发送的请求。

步骤602：确定所述应用系统服务注册列表，所述服务注册列表中记录了所述应用系统有权限调用的服务信息。

步骤603：判断所述服务注册列表是否为空，若否，进入步骤604。

如果所述服务注册列表为空，则说明能够被当前应用系统调用的服务节点都处于异常状态，不能正常调用，则后续不会调用任何服务。

如果所述服务注册列表不为空，则说明当前有所述应用系统能够调用的服务，则进入后续调用所述有权限调用的服务信息对应的相关服务的步骤。

步骤604：调用所述有权限调用的服务信息对应的相关服务，其中，每一个所述服务为能够独立运行的服务。

本实施例中，在确定所述应用系统服务注册列表后，调用所述有权限调用的服务信息对应的相关服务前，先判断服务注册列表是否为空，只有在服务注册列表中存在可调用的服务时，才会进行后续服务调用的操作。

在其他的实现方式中，服务化软件架构的应用方法还可以包括：在监测到服务节点的更新信息后，将所述更新信息同步至所述服务注册列表。所述更新信息可以包括新添加或删除的服务节点信息，或者服务节点的服务器ip、端口等信息。这样，保证服务化软件系统架构中相关的记录模块，如注册中心中记录的服务节点的相关信息的实时性，保证相关信息的准确性，从而使后续相关调用操作顺利进行。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。