CN102035864B - 一种开放式服务的实现方法及系统 - Google Patents

Abstract

本申请公开了一种开放式服务的实现方法，包括：服务发布平台接收客户端侧发送的业务请求消息，并在根据该业务请求消息携带的业务标识确定其请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；以及根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。这样，既不会增加实现成本，又实现了动态可扩展的服务分流和隔离，同时能够根据业务需求灵活配置分流策略，提高了服务隔离的效果，从而增加了系统整体服务的稳定性和可用性，提升了服务质量。本申请同时公开了一种用于管辖开放式服务的服务发布平台和一种用于提供开放式服务的互联网系统。

Description

一种开放式服务的实现方法及系统

技术领域

本发明涉及互联网技术，特别涉及一种开放式服务的实现方法及系统。

背景技术

随着面向服务的体系框架(Service Oriented Architecture，SOA)的不断成熟，以及表象化状态转变(Representational State Transfer，REST)风格的深入人心，互联网开放式服务(Open API)逐渐成为互联网新兴资源。传统的互联网软件企业也开始作出新的尝试；例如，作为服务提供商，开放自身服务资源，最大化内部数据的服务社会化作用，以及为网站自身发展提供新的开放模式。

为了支持新型开放模式，对于大型网站来说，可以构建专属的服务开放平台，而对于小型网站或者传统软件企业来说，往往会借助于外部共享的服务开放平台。但不论专属的服务平台亦或是共享的服务平台，都拥有多种多样的服务内容，而各种服务本身对于资源的需求(如，服务器带宽，CPU处理速率、响应速度等等)通常都大相径庭；那么，资源需求不同的多种服务集中于一个服务平台上，整体的服务质量很难保证，例如，在多个服务之间可能由于某一服务的不稳定，导致整体服务质量的下降，从而影响服务使用者的体验。因此，针对一个服务平台上统一开放的各种服务需要采用分流和隔离机制，以确保服务质量的稳定。

现有技术下，已存在的服务分流和隔离机制有以下几种：

1、采用二级域名将不同服务在入口区分开，从而实现服务的分流和隔离。

若采用这种方式，则针对不同的二级域名需要对外申请不同的IP地址，申请流程比较复杂，代价也较高，并且难以对整体的服务架构进行动态扩展及灵活的参数配置。

2、采用硬件负载均衡(如，F5)实现服务的分流和隔离。

通过硬件负载均衡实现的服务分流隔离体系框架保证了发布在服务平台上的各种服务的独立性及资源可调配性，提高了服务本身的稳定性和可用性。但是，硬件负载均衡对于Http协议层的解析效率很低，而服务数据通常是在http协议层进行分流，因此，在业务高峰期间，硬件负载均衡无法顺利承载全部服务分流任务，从而仍会降低了整体的服务质量。

有鉴于此，需要提供一种新的开放式服务的实现方法，以克服上述缺陷。

发明内容

本申请实施例提供一种开放式服务的实现方法及系统，用以提高开放式服务的服务质量。

本申请实施例提供的具体技术方案如下：

一种开放式服务的实现方法，包括：

服务发布平台接收客户端侧发送的业务请求消息，并获取该业务请求消息携带的业务标识；

所述服务发布平台根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；

所述服务发布平台根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。

一种用于管辖开放式服务的服务发布平台，包括：

通信单元，用于接收客户端侧发送的业务请求消息，并获取该业务请求消息携带的业务标识；

第一处理单元，用于根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围时，指示第二处理单元获取对应该业务标识保存的服务状态信息；

第二处理单元，用于获取对应所述业务标识保存的服务状态信息，并在根，，，，据获得的服务状态信息确定所述业务标识指示的业务不可用时，指示所述通信单元拒绝响应所述业务请求消息。

一种用于提供开放式服务的互联网系统，包括若干服务发布平台，所述服务发布平台用于接收客户端侧发送的业务请求消息，并在根据该业务请求消息携带的业务标识确定其请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；以及根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。

本申请实施例中，将用于分配业务数据的服务发布平布设置有相应的业务属性，每组服务发布平台接受到归属于本地管辖的服务范围的业务请求消息时，直接发往后台进行处理；接收到不归属于本地管辖的服务范围的业务请求消息时，对该业务请求消息所针对业务的当前状态进行判断，若该业务当前状态为正常，再将接收到的业务请求消息发往后台进行处理，若该业务当前状态为非正常，则拒绝处理接收到的业务请求消息，这样，由于拒绝了部分不归属于本地管辖范围的业务请求消息，因此，有效降低了系统的整体负荷，避免了因系统处理大量无效的业务请求消息而造成的资源浪费，既不会增加实现成本，又实现了动态可扩展的服务分流和隔离，同时能够根据业务需求灵活配置分流策略，提高了服务隔离的效果，从而增加了系统整体服务的稳定性和可用性，提升了服务质量。

附图说明

图1为本申请实施例中提供开放式服务的互联网系统第一种体系架构图；

图2为本申请实施例中服务发布平台功能结构图；

图3为本申请实施例中服务发布平台对接收的业务请求消息进行分流和隔离流程图；

图4为本申请实施例中提供开放式服务的互联网系统第二种体系架构图。

具体实施方式

在提供开放式服务的互联网系统内，为了在降低服务分流和隔离实现难度的同时，提高服务分流和隔离的质量。本申请实施例中，系统内的服务发布平台接收客户端侧发送的业务请求消息，并获取该业务请求消息携带的业务标识；所述服务发布平台根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；所述服务发布平台根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。

所谓服务分流是一种静态或者半静态的解决方法，即通过配置将不同的服务定向到不同的服务器处理。

所谓服务隔离是指在运行期，通过监控服务状态和质量，按照一定的算法和策略隔离出现问题的服务进程1，减小出现问题的服务进程对其他服务进程的影响。

下面结合附图对本申请优选的实施方式进行详细说明。

参阅图1所示，本申请实施例中，在提供开放式服务的互联网系统内，设置有用于进行服务发布的系统，称为快速服务发布系统，用于实现服务分流，在该快速服务发布系统内，设置有多个服务发布平台10，用于对来自于客户端的业务请求消息作初步分析处理，然后中转给后端相应的业务处理平台11。所述初步处理包括：根据业务请求消息携带的业务标识确定其请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；以及根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。

如图1所示，在提供开放式服务的互联网系统内，还包括业务处理平台11和存储服务平台12，其中

业务处理平台11，用于提供后台的实际业务处理服务，本申请实施例中，业务处理平台11由服务器集群组成，归属于同一业务处理平台11的服务器共同完成某一业务的处理服务。

存储服务平台12，用于提供集中式缓存服务，与快速服务发布系统内的各个服务发布平台10之间均存在信息交互；对应各业务标识保存相应的服务状态信息。

本申请实施例中，上述快速服务发布系统内的各个服务发布平台11，可以配置虚拟组也可以不配置虚拟组，所谓配置虚拟组，即是为各服务发布平台10配置相应的业务属性，一个服务发布平台10可以监管一个或多个业务处理平台11：各服务发布平台10会在某业务处理平台11的服务发生故障时，对发往该业务处理平台11且与本服务发布平台10的业务属性不同的业务请求消息进行拦阻，以确保系统整体的服务质量。虚拟组的配置包括：在应用配置中增加一个配置项virtualServiceGroup(虚拟服务属性)，通过逗号分割多个虚拟服务属性，例如：AAAA，BBBB就表示这个服务分布平台10可以管辖标识为AAAA的服务及标识为BBBB的服务。isolation Valve为隔离阀值，当isolation Valve＝0的时候表示不需要采取隔离机制，isolation Valve＞0就结合配置的虚拟组采取隔离机制。在运行期，管理人员可以通过相应接口修改virtualServiceGroup和isolation Valve这两个属性。

例如，假设系统内存在两个服务发布平台10，分别称为服务发布平台A和服务发布平台B，同时存在两个业务处理平台11，分别称为业务处理平台A和业务处理平台B，其中，服务发布平台A用于监管针对电子商务服务(即第一业务)的业务处理平台A，而服务发布平台B用于监管针对即时通讯服务的业务处理平台B，那么，当网络侧接收到终端侧发来的大量业务请求消息时，会将其随机分配给服务发布平台A和服务发布平台B，这样，服务发布平台A和服务发布平台B既可以接收到针对电子商务服务的业务请求消息，也可以接收到针对即时通讯服务的业务请求消息，以服务发布平台A为例，本实施例中，为了尽可能的降低系统运行负荷，服务发布平台A接收到针对电子商务服务的业务请求消息(即归属于本地管辖的服务范围)时，不会对其进行拦截，会直接将其发往后台的业务处理平台A进行相关业务处理，从而保障业务的流畅性；而服务发布平台A在接收到针对即时通讯服务的业务请求消息(即不归属于本地管辖的服务范围)时，会对其进行拦截，即先判断即时通讯服务当前的服务状态是否为“可用”，若可用，为了保证服务的流畅性，即使即时通讯服务不归属于服务发布平台A应当管理的服务范畴，服务发布平台A仍会将针对即时通讯服务的业务请求消息代为转发至相应的业务处理平台B，但是，若不可用，则服务发布平台A针将不归属于本地管辖范围的针对即时通讯服务的业务请求消息进行丢弃，以节省系统资源，避免不必要的系统运行负荷。

另一方面，如图1所示，为了提高系统性能，较佳地，在快速服务发布系统与客户端之间设置硬件负载均衡前端，硬件负载均衡前端的作用就是将从客户端接收的所有业务请求消息，分配给后端的各个服务发布平台10(不作Http层解析，仅解析到TCP/IP层)，从而实现了初步的负载均衡，也提高了后续分流的效率。

参阅图2所示，本申请实施例中，服务发布平台10包括通信单元100、第一处理单元101和第二处理单元102，其中，

通信单元100，用于接收客户端侧发送的业务请求消息，并获取该业务请求消息携带的业务标识；

第一处理单元101，用于根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围时，指示第二处理单元102获取对应该业务标识保存的服务状态信息；

第二处理单元102，用于获取对应所述业务标识保存的服务状态信息，并在根据获得的服务状态信息确定所述业务标识指示的业务不可用时，指示所述通信单元100拒绝响应所述业务请求消息。

基于上述网络环境，如图1所示，本实施例中，假设设置了两个虚拟组，分别针对第一业务(如，电子商务服务)和第二业务(如，即时通讯服务)，相应地，也分别设置了针对第一业务和第二业务的业务处理平台11，为了便于表述，以下实施例中，将针对第一业务设置的虚拟组称为服务发布平台A，将其配置项(即业务标识)设置为AAA，将相应的业务处理平台11称为业务处理平台A；同理，将针对第二业务设置的虚拟组称为服务发布平台B，将其配置项设置为BBB，将相应的业务处理平台11称为业务处理平台B，客户端发送的业务请求消息中将会携带业务标识以供各个虚拟组对接收的业务请求消息的业务属性加以识别。那么，以服务发布平台A为例，参阅图3所示，本申请实施例中，服务发布平台A对接收的业务请求消息进行分流和隔离的详细流程如下：

步骤300：接收客户端侧发送的业务请求消息。

本申请实施例中，服务发布平台A接收的业务请求消息，可以是从客户端侧直接接收的，也可以是硬件负载均衡前端执行初步分流后转发的。

步骤301：判断是否设置了虚拟组，即判断是否设置了配置项virtualServiceGroup，若是，则进行步骤302；否则，进行步骤308。

步骤302：进一步判断是否执行隔离机制，即判断隔离阈值isolationValve＞0？，若是，则进行步骤303；否则，进行步骤308。

步骤303：获取业务请求消息中携带的业务标识，并与本地配置的虚拟组的业务标识进行比较。

步骤304：根据比较结果判断接收的业务请求消息是否归属于本服务发布平台A管辖的服务范围？若是，则进行步骤308；否则，进行步骤305。

例如，本实施例中，由于服务发布平台A管辖第一业务，且配置项指示的业务标识为AAA，那么，若服务发布平台A从接收的业务请求消息中获取的业务标识为AAA，则说明该业务请求消息是针对第一业务的，归属于服务发布平台A管辖的服务范围；若服务发布平台A从接收的业务请求消息中获取的业务标识为BBB，则说明该业务请求消息是针对第二业务的，不归属于服务发布平台A管辖的服务范围。

这样，由于服务发布平台A拒绝了部分不归属于本地管辖范围的业务请求消息，因此，有效降低了系统的整体负荷，避免了因系统处理大量无效的业务请求消息而造成的资源浪费

步骤305：在存储服务平台中获取接收的业务请求消息所针对业务的服务状态信息。

本实施例中，在提供集中式缓存服务的存储服务平台内，针对系统提供的每一项业务都设置有对应的服务状态信息，通过该服务状态信息可获知相应的业务当前是否可用，如，若服务状态信息为“00”则表示业务可用，若服务状态信息为“11”，则表示业务不可用，可能是由于网络传输中断，或者相应的业务处理平台发生故障等等原因。服务发布平台A可以根据获得的业务标识在存储服务平台内获取对应该业务标识保存的服务状态信息，以确定相关服务的当前状态。

步骤306：接收的业务请求消息所针对业务的服务状态是否为不可用？若是，则进行步骤307；否则，进行步骤308。

步骤307：向客户端侧返回提示业务不可用的响应消息，以拒绝转发接收的业务请求消息。

步骤308：根据接收的业务请求消息中携带的业务标识，将该业务请求消息发往业务处理平台A或业务处理平台B。

例如，若业务请求消息携带的业务标识为AAA，则将其发往业务处理平台A进行处理，

若业务请求消息携带的业务标识为BBB，则将其发往业务处理平台B进行处理。

步骤309：根据业务处理平台A或业务处理平台B返回的响应消息，判断此次业务处理操作是否成功？若是，则进行步骤310；否则，进行步骤311。

步骤310：向客户端侧返回提示业务处理成功的响应消息。

步骤311：判断当前处理业务的服务状态是否为不可用？若是，则进行步骤315；否则，进行步骤312。

步骤312：在存储服务平台中针对当前处理业务执行失败次数累计。

本实施例中，在存储服务平台内针对系统提供的各项业务分别设置有用于累计失败次数的计数器，当该计数器的累计数值达到设定阈值时，将相应业务的服务状态设置为“不可用”。

步骤313：判断当前处理业务对应的计数器所累计的失败次数是否达到设定阈值？若是，则进行步骤314；否则，进行步骤315。

步骤314：在存储服务平台中将当前处理业务的服务状态标识为不可用，接着，进行步骤315。

本实施例中，将当前处理业务的服务状态标识为“不可用”后，要将累计失败次数的计数器清零，以便在业务恢复正常运行后重新开始计数。

步骤315：向客户端侧返回提示业务处理失败的响应消息。

通过上述实施例，系统内的各个服务发布平台可以在某些业务发生故障时，对其进行有效隔离，从而保证了系统整体的服务质量。如，当第一业务发生故障时，服务发布平台B会对接收的针对第一业务的业务请求消息进行拒绝，以减轻系统的运行负荷，从而保证系统整体的服务稳定性。另一方面，服务发布平台A仍会将接收的针对第一业务的业务请求消息发往业务处理平台A进行处理，这样做是为了根据业务处理平台A返回的响应消息，一旦获知第一业务的运行恢复正常，可以及时将存储服务平台内针对第一业务设置的服务状态信息由“不可用”改为“可用”，以确保系统的正常运作。

较佳地，如图1所示，还可以基于上述服务发布平台A和服务发布平台B，另行设置无虚拟组(即无专属业务)的服务发布平台11，以下称为服务发布平台C。设置服务发布平台C的有益之处在于：一旦第一业务和第二业务均发生故障，服务发布平台A将会拒绝接收的针对第二业务的业务请求消息，而服务发布平台B将会拒绝接收的针对第一业务的业务请求消息，此时，系统的承载能力将大大下降，而通过设置服务发布平台C可以保证将接收的针对各类业务的业务请求消息均发往相应的业务处理平台进行处理，从而避免了因系统的承载能力过于低下而影响用户体验，也提高了系统获知业务恢复正常运行的能力，可以及时将存储服务平台内针对第一业务和第二业务设置的服务状态信息由“不可用”改为“可用”，以确保系统的正常运作。即当某业务的服务状态为不可用时，只有通过配置虚拟组管辖此业务的服务发布平台和没有配置虚拟组的服务发布平台依然中转针对该业务的业务请求消息，请求后端的业务处理平台进行处理，一旦处理成功，则立刻将该业务的服务状态修改为“可用”，这样，既保证了该业务的可用性，同时也不会影响其他业务的进行，从而产生了有效的服务隔离效果。

当然，在实际应用中，上述服务发布平台A除了根据业务处理的响应消息来累计第一业务的处理失败次数，还可以周期性地从业务处理平台A检测第一业务的处理失败次数(即作后台异步定时检查，并将结果反馈给相应的累计失败次数的计数器)，服务发布平台B执行的操作与服务发布平台A相同，在此不再赘述。

此外，管理人员还可以调用指定接口，在系统运行期间动态修改虚拟组的配置项及其他相关阀值，这样，便增加了服务隔离的可配置性和可扩展性，从而提升了系统服务的灵活性。

基于上述流程，参阅图4所示，为了进一步提高系统的业务处理能力，以及系统的运行稳定性和容灾性，在提供开放式服务的互联网系统内进一步设置与快速服务发布系统并行的软负载前端服务器。客户端侧发送的业务请求消息通过域名调用，从网络侧对外的统一服务入口发送至硬件负载均衡前端，由硬件负载均衡前端进行初步分流(非业务性负载选择分配)。从而转发至内部网络的各个服务发布平台，以及软负载前端服务器。之所以不将全部业务请求消息交付给软负载前端服务器，是因为软负载前端服务器在分析和负载分发的过程中会有性能损耗，同时单台软负载前端服务器可以管辖的后端业务处理平台的数目有限，因此兼顾性能和分流效果，采用软负载前端服务器和服务发布平台配合使用的分流方式，直接接入到硬件负载均衡前端的服务发布平台组成了快速服务发布系统(这里的快速是相对于软负载分发后性能损失带来的速度下降而言的)。软负载前端服务器将接收到的业务请求消息根据业务内容配置分流到接入至本地的不同的服务发布平台，即根据业务需求，在Http层次解析请求内容，分流负载到不同的服务发布平台上，从而实现业务级别的服务分流；再由这些服务发布平台将接收的业务请求消息转发给后台相应的业务处理平台进行相关操作；其中，由于软负载前端服务器本身提供动态的配置载入更新机制，使得服务分流在运行期可以动态扩展和改变。使用“软负载”进行辅助分流，可以提高分流效率的效率，而“软负载”带来了服务性能不稳定问题可以由快速服务发布平台进行优化、缓冲，从而起到了相得益彰的效果。

综上所述，采用本实施例中记载的技术方案在提供开放式服务的互联网系统中实现服务分流和隔离，既不会增加实现成本，又实现了动态可扩展的服务分流和隔离，同时能够根据业务需求灵活配置分流策略，提高了服务隔离的效果，从而增加了系统整体服务的稳定性和可用性，提升了服务质量。

显然，本领域的技术人员可以对本申请中的实施例进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请实施例中的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请中的实施例也意图包含这些改动和变型在内。

Claims (12)

1.一种开放式服务的实现方法，其特征在于，包括：

服务发布平台接收客户端侧发送的业务请求消息，并获取该业务请求消息携带的业务标识；

所述服务发布平台根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；

所述服务发布平台根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。

2.如权利要求1所述的方法，其特征在于，所述服务发布平台从客户端侧直接接收所述业务请求消息；或者，从具有硬件负载均衡能力的前端服务器接收转发的所述业务请求消息。

3.如权利要求1所述的方法，其特征在于，所述服务发布平台根据获得的业务标识，确定所述业务请求消息的请求对象归属于本地管辖的服务范围，或者，根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围，但该业务标识对应的服务状态信息指示业务可用时，将所述业务请求消息发往后台进行业务处理操作。

4.如权利要求3所述的方法，其特征在于，所述服务发布平台根据后台返回的业务处理结果判断业务处理操作是否成功，并对应所述业务标识累计失败次数，以及在确定所述失败次数的累计值达到设定阈值时，将对应所述业务标识保存的服务状态信息设置为不可用。

5.如权利要求2所述的方法，其特征在于，接收具有硬件负载均衡能力的前端服务器转发的所述业务请求消息之前，还包括：

通过具有软件负载均衡能力的前端服务器对所述具有硬件负载均衡能力的前端服务器转发的所述业务请求消息进行分流。

6.一种用于管辖开放式服务的服务发布平台，其特征在于，包括：

通信单元，用于接收客户端侧发送的业务请求消息，并获取该业务请求消息携带的业务标识；

第一处理单元，用于根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围时，指示第二处理单元获取对应该业务标识保存的服务状态信息；

第二处理单元，用于获取对应所述业务标识保存的服务状态信息，并在根据获得的服务状态信息确定所述业务标识指示的业务不可用时，指示所述通信单元拒绝响应所述业务请求消息。

7.一种用于提供开放式服务的互联网系统，包括若干服务发布平台，其特征在于，

所述服务发布平台用于接收客户端侧发送的业务请求消息，并在根据该业务请求消息携带的业务标识确定其请求对象不归属于本地管辖的服务范围时，获取对应该业务标识保存的服务状态信息；以及根据获得的服务状态信息确定所述业务标识指示的业务不可用时，拒绝响应所述业务请求消息。

8.如权利要求7所述的系统，其特征在于，还包括：

存储服务平台，用于提供集中式缓存服务，针对各业务标识保存相应的服务状态信息。

9.如权利要求7所述的系统，其特征在于，还包括：

具有硬件负载均衡能力的前端服务器，用于从客户端侧接收业务请求消息，并将接收的业务请求消息分配至各个服务发布平台。

10.如权利要求7所述的系统，其特征在于，所述服务发布平台根据获得的业务标识，确定所述业务请求消息的请求对象归属于本地管辖的服务范围，或者，根据获得的业务标识，确定所述业务请求消息的请求对象不归属于本地管辖的服务范围，但该业务标识对应的服务状态信息指示业务可用时，将所述业务请求消息发往后台进行业务处理操作。

11.如权利要求10所述的系统，其特征在于，所述服务发布平台根据后台返回的业务处理结果判断业务处理操作是否成功，并对应所述业务标识累计失败次数，以及在确定所述失败次数的累计值达到设定阈值时，将对应所述业务标识保存的服务状态信息设置为不可用。

12.如权利要求9所述的系统，其特征在于，还包括：

具有软件负载均衡能力的前端服务器，用于在所述服务发布平台接收具有硬件负载均衡能力的前端服务器转发的所述业务请求消息之前，对所述具有硬件负载均衡能力的前端服务器转发的所述业务请求消息进行分流。

Images