一种服务订阅系统的制作方法

1.本发明涉及计算机技术领域，特别是涉及一种服务订阅系统。


背景技术：

2.对于传统的rpc框架,设计思想是通过共享接口类进行rpc调用，比较适用于单体应用的系统模块化拆分；缺点在于我行目前存在着几百个旧系统，平均每一个系统的关联系统就有十个以上，有的甚至更多；而适用这种接口共享的方式，引入的依赖包就有十几个，而且大部分的接口都是无关接口，更严重的是版本升级带来的依赖包升级，非常容易就出现错漏而导致生产问题。现有对于共享接口的依赖较大，不利于服务订阅。


技术实现要素：

3.本发明实施例提供一种屏蔽器控制方法及装置，以解决现有技术对于共享接口的依赖较大，不利于服务订阅的问题，包括：
4.一种服务订阅系统，所述服务订阅系统包括服务消费端、注册中心以及服务提供端，所述服务消费端分别连接所述注册中心以及所述服务提供端，所述注册中心连接所述服务提供端，所述方法包括：
5.所述服务提供端用于使用服务码绑定业务接口，并将所述服务码发送至注册中心；
6.所述服务消费端用于从所述注册中心获取所述服务码，并通过所述服务码动态生成的目标服务接口从所述服务提供端进行服务订阅。
7.可选地，所述服务提供端用于使用原生的xml配置文件对应的服务码绑定业务接口。
8.可选地，所述服务提供端用于通过标准的服务码绑定业务接口。
9.可选地，所述服务提供端用于使用json进行服务码的序列化。
10.可选地，所述服务消费端用于将所述服务码缓存于sdk的链路。
11.可选地，所述服务消费端从所述sdk的链路调用所述服务码。
12.可选地，所述注册中心用于存储所述服务码，并且与所述服务提供端保持通讯，在与所述服务提供端断链预设时间后进行服务清理。
13.本发明具有以下优点：
14.在本发明中，通过服务码进行动态接口生成。通过将服务码动态生成接口，对于服务消费端的使用者是完全透明的，普通业务开发无需关心接口的存在，只要关注与业务相关的服务码。对业务开发进行了技术层面的屏蔽后，由于接口都是动态生成的，从而解决了服务接口强依赖带来的一系列代码共享、版本升级等一系列问题，大大的降低了系统的耦合度以及开发之间的沟通成本。为开发带来了极大的方便，同时为系统进行快速的服务化升级提供了技术支撑。
附图说明
15.为了更清楚地说明本发明的技术方案，下面将对本发明的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
16.图1是本发明一实施例提供的一种服务订阅系统的结构示意图；
17.图2是本发明一实施例提供的一种服务订阅系统的示意图。
具体实施方式
18.为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
19.rpc(remote procedure call protocol)协议是当前流行的服务化通讯协议，如比较有名的dubbo框架。
20.通常地，rpc框架通过接口将服务发布到服务注册中心，消费方(服务调用方)通过提供方共享的接口创建动态代理，实现服务的订阅与消费。
21.目前，我行存在着大量的单体应用，应用间通过原始的固定地址配置进行网络通讯；系统间的链路梳理已经面临严峻的挑战，无法进行快速的业务梳理、业务沉淀、问题排查、业务创新等，但是对这些应用进行技术重构是不现实的，按照目前的技术发展，服务化是系统未来发展不可逆转的趋势。
22.更多的，系统间的相互调用关系已经错综复杂，如果系统间使用传统的服务技术实现方式，必定每个系统都会引入大量的依赖包，后期系统服务进行升级后，这些依赖包升级的及时性无法保证。
23.本发明主要解决的技术问题是为传统rpc服务化框架提供http协议的支持及解耦系统间的包强依赖，主要应用与两个系统间的服务化通讯，达到新旧系统进行快速的服务化改造及服务升级。
24.对于传统的rpc框架,设计思想是通过共享接口类进行rpc调用，比较适用于单体应用的系统模块化拆分；缺点在于我行目前存在着几百个旧系统，平均每一个系统的关联系统就有十个以上，有的甚至更多；而适用这种接口共享的方式，引入的依赖包就有十几个，而且大部分的接口都是无关接口，更严重的是版本升级带来的依赖包升级，非常容易就出现错漏而导致生产问题。
25.目的是解决大规模系统服务化带来的版本依赖，应用间网络交互问题，使应用能够快速的进行服务化升级改造。
26.系统间代码必须是解耦的，否则除了影响开发的效率，版本升级问题会非常容易触发生产问题。所以需要解决传统rpc框架由于接口共享带来的版本问题、依赖过多问题。
27.为了解决上述问题，参照图1，示出了本发明一实施例提供的一种服务订阅系统的示意图，本技术包括三个部分，分别为服务消费端、注册中心以及服务提供端，所述服务消费端分别连接所述注册中心以及所述服务提供端，所述注册中心连接所述服务提供端。
28.服务提供端：将本应用的服务发布到注册中心
29.注册中心：存储服务提供方发布的服务，并且与提供方保持通讯，在与提供方断链一定时间后进行服务清理。
30.服务消费端：通过使用服务码从注册中心拉取所需服务，然后通过拉取到的关键信息(如提供方ip、端口、接口名)进行远程通讯。
31.参照图2，示出了本发明一实施例提供的一种服务订阅系统的示意图程图，其中，服务提供端用于使用服务码绑定业务接口，并将服务码发送至注册中心；
32.服务消费端用于从注册中心获取服务码，并通过服务码动态生成的目标服务接口从服务提供端进行服务订阅。
33.在本技术一实施例中，所述服务提供端用于使用原生的xml配置文件对应的服务码绑定业务接口。
34.由于没有强依赖的接口，服务必须要有识别码，引入了服务码替换共享的代码接口。服务码是按照一定的规则编写并赋予一定场景含义、业务含义，如：prod.ivst.f.mrchorderpayment。以服务码的形式可形成一整套比较规范的编码，除了较为人性化外还可以在全局范围内形成全行的服务资产；为服务的持续治理、监控、优化升级形成了一个比较完整的体系。
35.在本技术一实施例中，所述服务提供端用于通过标准的服务码绑定业务接口。
36.在本技术一实施例中，所述服务提供端用于使用json进行服务码的序列化。
37.使用json进行对象的序列化，如此服务消费端与服务提供端即可解决数据传输实体在序列化与反序列化时共享代码类的问题。从而使得由原始的强依赖变成了弱依赖。好处在于服务提供端的报文字段发生改变时，只要提供方做好新旧版本的兼容即可，影响的范围就会大大降低。
38.在本技术一实施例中，所述服务消费端用于将所述服务码缓存于sdk的链路。
39.在本技术一实施例中，所述服务消费端从所述sdk的链路调用所述服务码。
40.在本技术一实施例中，所述注册中心用于存储所述服务码，并且与所述服务提供端保持通讯，在与所述服务提供端断链预设时间后进行服务清理。
41.在本发明中，通过服务码进行动态接口生成。通过将服务码动态生成接口，对于服务消费端的使用者是完全透明的，普通业务开发无需关心接口的存在，只要关注与业务相关的服务码。对业务开发进行了技术层面的屏蔽后，由于接口都是动态生成的，从而解决了服务接口强依赖带来的一系列代码共享、版本升级等一系列问题，大大的降低了系统的耦合度以及开发之间的沟通成本。为开发带来了极大的方便，同时为系统进行快速的服务化升级提供了技术支撑。服务标准化：通过定义统一规范、带有业务含义的服务码，标准化带来的好处就是更好的进行服务治理、服务统计与业务沉淀，为服务组合提供方便。系统松耦合：通过将服务码动态生成服务接口，使用动态生成字节码的技术，屏蔽了系统间的代码强依赖。旧系统快速服务化：支持两种服务发布方式，通过将旧的业务接口与服务码进行绑定完成原有服务的包装发布，在没有修改原代码的任何逻辑下进行业务接口的重用。
42.本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可
用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
43.本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
44.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
45.这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
46.尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
47.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
48.以上对本发明所提供的一种服务订阅系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。