一种面向微服务的服务请求消息响应方法和系统与流程

1.本发明涉及微服务领域，尤其涉及一种面向微服务的服务请求消息响应方法和系统。


背景技术：

2.在云计算时代，微服务是最流行的架构，各个微服务之间消息的传递影响着整个系统通讯与消息传递的重要桥梁。消息传输是微服务架构或者分布式下信息传输必须考虑的难点，现有在微服务架构下消息传输方案中无法同时兼顾提升信息传输效率，支持微服务自由组合，标准格式，同时保证，全流程各模块的统一。


技术实现要素：

3.本发明所要解决的技术问题是针对现有技术的不足，提供一种面向微服务的服务请求消息响应方法和系统。
4.本发明解决上述技术问题的技术方案如下：
5.一种面向微服务的服务请求消息响应方法，包括：
6.s1，监听通过预设请求方式发出的服务请求消息；
7.s2，判断监听到的服务请求信息的响应类型；
8.s3，当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应。
9.本发明的有益效果是：本方案通过监听通过预设请求方式发出的服务请求消息，判断监听到的服务请求信息的响应类型，当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应，通过本方案能够提升信息传输效率，支持微服务自由组合，标准格式，信息封装能够防止业务代码对底层框架的入侵和污染，同时保证，全流程各模块的统一。
10.进一步地，所述通过已配置全局变量的协同消息队列对服务请求消息进行响应具体包括：
11.根据所述全局变量选择同步方式或异步方式对按照协同消息队列的排布规则的服务请求消息进行响应。
12.采用上述进一步方案的有益效果是：本方案通过选择同步方式或异步方式对所述服务请求消息进行响应，实现可熟练且安全地在应用之间进行消息传递。面向微服务的企业级协同消息对列，具有稳定性与统一性。
13.进一步地，还包括：
14.当所述响应类型为实时响应时，对通过http请求方式发送的服务请求消息进行实时响应采用上述进一步方案的有益效果是：本方案在微服务架构下，对有实时响应需求的服务请求进行即时响应。
15.进一步地，所述预设请求方式包括：http请求方式或消息队列请求方式。
16.进一步地，所述服务请求消息包括：请求的方法、url、协议版本、请求头部和请求数据。
17.本发明解决上述技术问题的另一种技术方案如下：
18.一种面向微服务的服务请求消息响应系统，包括：监听模块、类型判断模块和响应模块；
19.所述监听模块用于监听通过预设请求方式发出的服务请求消息；
20.所述类型判断模块用于判断监听到的服务请求信息的响应类型；
21.所述响应模块用于当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应。
22.本发明的有益效果是：本方案通过监听通过预设请求方式发出的服务请求消息，判断监听到的服务请求信息的响应类型，当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应，通过本方案能够提升信息传输效率，支持微服务自由组合，标准格式，信息封装能够防止业务代码对底层框架的入侵和污染，同时保证，全流程各模块的统一。
23.进一步地，所述响应模块具体用于根据所述全局变量选择同步方式或异步方式对按照协同消息队列的排布规则的服务请求消息进行响应。
24.采用上述进一步方案的有益效果是：本方案通过选择同步方式或异步方式对所述服务请求消息进行响应，实现可熟练且安全地在应用之间进行消息传递。面向微服务的企业级协同消息对列，具有稳定性与统一性。
25.进一步地，还包括：实时响应模块，用于当所述响应类型为实时响应时，对通过http请求方式发送的服务请求消息进行实时响应。
26.采用上述进一步方案的有益效果是：本方案在微服务架构下，对有实时响应需求的服务请求进行即时响应。
27.进一步地，所述预设请求方式包括：http请求方式或消息队列请求方式。
28.进一步地，所述服务请求消息包括：请求的方法、url、协议版本、请求头部和请求数据。
29.本发明附加的方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明实践了解到。
附图说明
30.图1为本发明的实施例提供的一种面向微服务的服务请求消息响应方法的流程示意图；
31.图2为本发明的实施例提供的一种面向微服务的服务请求消息响应系统结构框图；
32.图3为本发明的其他实施例提供的消息对列同步请求的流程示意图
33.图4为本发明的其他实施例提供的消息对列异步请求的流程示意图；
34.图5为本发明的其他实施例提供的微服务架构下的服务请求流程示意图。
具体实施方式
35.以下结合附图对本发明的原理和特征进行描述，所举实施例只用于解释本发明，并非用于限定本发明的范围。
36.如图1所示，为本发明实施例提供的一种面向微服务的服务请求消息响应方法，包括：
37.在某一实施例中，微服务是一种软件开发技术-面向服务的体系结构(soa)架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。微服务(或微服务架构)是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。
38.s1，监听通过预设请求方式发出的服务请求消息；在某一实施例中，所有使用ui界面的操作系统，后台都运行着一个死循环，在不停的监听和接收用户发出的指令，一旦接收指令就立即执行。
39.s2，判断监听到的服务请求信息的响应类型；
40.s3，当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应。
41.在某一实施例中，s3可以具体包括：根据所述全局变量选择同步方式或异步方式对所述服务请求消息进行响应。
42.在某一实施例中，消息队列响应方法可以包括：http是超文本传输协议，其定义了客户端与服务器端之间文本传输的规范。http协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、url、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。普通http同步请求系统同时接收到了这三个请求，如图3所示：由于是同步方式，因此需要按顺序分别处理用户1、用户2、用户3的请求。
43.消息对列异步请求如图4所示，用户的三个请求先分配到一个队列消息中，通常这个队列会放到另一台服务器中，与系统服务器区分开。系统一直在监听着这个队列的请求消息，一旦系统处理完当前请求，就会从队列中取出下一条消息，以此类推。
44.在另一实施例中，服务请求消息响应可以包括：在微服务架构下，如图5所示，多个服务请求等待时间是有差异的，比如有些需要实时响应的就可以选择http请求，而有些对实时性要求不高的响应，如图所示：比如日志服务，就可以用消息对列的形式进行消息传输。协同消息对列是通过全局配置指定哪些走消息对列，哪些请求走本地。并同时支持同步与异步调用微服务。
45.实时的信息同步场景走本地http；http是同步通讯，建立连接-发送请求-接收响应，系统中主要用在前后端交互和后端各微服务之间需要实时响应的接口调用中，如图中的元数据、权限。
46.需要同步大量数据但是对实时性要求不高，或者数据高并发场景时走消息对列。消息对列场景有：1)日志，系统目前使用场景是各个微服务记录日志时，异步推送日志到mq上，然后日志微服务监听mq，有消息就获取下来，进行日志记录。2)统一认证系统中的用户
信息同步到采集填报系统；3)订单秒杀。
47.协同场景：某系统中资源目录的发布，需要调用mq把大量数据存储到到es(全文搜索引擎)便于查询，而其他基本信息需要调用http存储到es便于管理。
48.在某一实施例中，使用企业级协同消息对列可以包括以下步骤：
49.步骤一：需要创建默认交换机fusion；
50.步骤二：需要创建微服务队列，以监听服务的服务名，参见bootstrap.yml中的spring.application.name来做routingkey，绑定到交换机上；
51.步骤三：需要写全局配置，指定哪些请求走mq，哪些请求走本地，具体配置方法如下：
52.配置写在环境公共的配置文件(如fusion-common-dev.yaml)中,如果不写默认全部走本地；
53.配置逻辑：对某微服务发送时,如果目标微服务需要通过mq发消息且不是本服务自己,则走mq,否则走本地；
54.群发时,只要有一个微服务需要通过mq发消息,则不走mq,否则走本地；
55.如果要使用群发方法，必须先用setexchange()方法设置fanout模式的交换机；
56.配置方法：always表示默认配置，决定默认走mq还是local。exclude表示相反规则，多个规则逗号分开，
57.每组规则由三项构成：微服务1：可以是all，代表所有微服务；双向或单向(《＝》或＝》)、微服务2(可以是all，代表所有微服务)。
58.当all规则与一般规则产生冲突时，哪个在前面哪个生效。
59.步骤四：如果要群发消息，需要创建fanout模式的交换机，并在使用本类时指定exchange，使用setexchange方法来指定。
60.步骤五：要调用的远程方法，其参数必须实现serialversionuid接口，如果没有，请自行将参数转成json，通过fastjson实现了序列化。
61.本方案通过监听通过预设请求方式发出的服务请求消息，判断监听到的服务请求信息的响应类型，当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应，通过本方案能够提升信息传输效率，支持微服务自由组合，标准格式，信息封装能够防止业务代码对底层框架的入侵和污染，同时保证，全流程各模块的统一。
62.优选地，在上述任意实施例中，所述通过已配置全局变量的协同消息队列对服务请求消息进行响应具体包括：
63.根据所述全局变量选择同步方式或异步方式对按照协同消息队列的排布规则的服务请求消息进行响应。
64.本方案通过选择同步方式或异步方式对所述服务请求消息进行响应，实现可熟练且安全地在应用之间进行消息传递。面向微服务的企业级协同消息对列，具有稳定性与统一性。
65.优选地，在上述任意实施例中，还包括：
66.当所述响应类型为实时响应时，对通过http请求方式发送的服务请求消息进行实时响应。
67.本方案在微服务架构下，对有实时响应需求的服务请求进行即时响应。
68.优选地，在上述任意实施例中，所述预设请求方式包括：http请求方式或消息队列请求方式。
69.优选地，在上述任意实施例中，所述服务请求消息包括：请求的方法、url、协议版本、请求头部和请求数据。
70.在某一实施例中，通过mq发送消息的接口,基本使用方法如下:
71.mqapimanager manager＝new mqapimanager()；
72.mqrequest request＝manager.wrap(...)；//选择合适的生成request的方法；
73.manager.send(...,request)；//选择合适的发送request的方法；
74.配置示例如下：
75.1、总是发mq，但是data-fill与fill-task间走本地、sso与所有微服务间走本地，
76.mq-api-manager:
77.always:mq
78.exclude:data-fill《＝》fill-task,sso《＝》all
79.2、总是走本地，但是所有服务向ops-manage发请求时都走mq
80.mq-api-manager:
81.always:local
82.exclude:all＝》ops-manage
83.3、只走本地，包括fanout模式
84.mq-api-manager:
85.always:local
86.exclude:
87.4、如何配置消费者同时处理的线程数：
88.默认是同时10个线程处理，只有有空线处理线程时才能接收新消息，所以有可能出现堆积的情况，此时就需要修改线程数。
89.修改方法参考springboot继承mq的参数：
90.spring:
91.rabbitmq:
92.listener:
93.simple:
94.concurrency:10
95.在某一实施例中，在s1步骤之前还可以包括：
96.创建默认交换机fusion；
97.创建要监听的微服务队列，以监听服务的服务名来做routingkey，绑定到交换机上；
98.写全局配置，指定哪些请求走mq，哪些请求走本地；
99.如果需要群发消息，需要创建fanout模式的交换机，并在使用本类时指定exchangge。
100.实现程序如下：
101.public static void main(string[]args){
[0102]
authuser user＝new authuser()；
[0103]
user.setusername("用户1")；
[0104]
//1.通过类名+方法名远程调用java代码
[0105]
mqapimanager manager＝new mqapimanager()；
[0106]
mqrequest request＝manager.wrap(mqapimanager.class,"test",collections.singletonlist(user))；
[0107]
//1.1异步调用单个微服务的方法,不等消费者接收,如:推送日志数据(乱序)
[0108]
manager.send("ops-manage",request)；
[0109]
//1.2同步调用单个微服务的方法,等待消费者接收后才会发下一个,如:推送业务数据(有序)、rpc调用
[0110]
object result＝manager.call("datafill",request)；
[0111]
//2.通过url地址远程调用controller方法,且controller的方法必须使用optimus框架
[0112]
mqrequest request2＝manager.wrap("/user",new optimusrequest())；
[0113]
//2.1同步调用单个微服务的方法.如:推送业务数据(有序)(走url)、rpc调用(走url)
[0114]
object result2＝manager.call("datafill",request2)；
[0115]
//2.2同步调用同一个交换机下所有消费者的同一个请求.如:向所有外部系统推送同步数据
[0116]
//注：这种模式下交换机必须是fanout模式。
[0117]
manager.setexchange("datasynchronize")；
[0118]
manager.call(request2)；
[0119]
在某一实施例中，如图2所示，一种面向微服务的服务请求消息响应系统，包括：监听模块1001、类型判断模块1002和响应模块1003；
[0120]
所述监听模块1001用于监听通过预设请求方式发出的服务请求消息；
[0121]
所述类型判断模块1002用于判断监听到的服务请求信息的响应类型；
[0122]
所述响应模块1003用于当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应。
[0123]
本方案通过监听通过预设请求方式发出的服务请求消息，判断监听到的服务请求信息的响应类型，当所述响应类型为非实时响应时，通过已配置全局变量的协同消息队列对服务请求消息进行响应，通过本方案能够提升信息传输效率，支持微服务自由组合，标准格式，信息封装能够防止业务代码对底层框架的入侵和污染，同时保证，全流程各模块的统一。
[0124]
优选地，在上述任意实施例中，所述响应模块1003具体用于根据所述全局变量选择同步方式或异步方式对按照协同消息队列的排布规则的服务请求消息进行响应。
[0125]
本方案通过选择同步方式或异步方式对所述服务请求消息进行响应，实现可熟练且安全地在应用之间进行消息传递。面向微服务的企业级协同消息对列，具有稳定性与统一性。
[0126]
优选地，在上述任意实施例中，还包括：实时响应模块，用于当所述响应类型为实时响应时，对通过http请求方式发送的服务请求消息进行实时响应。
[0127]
本方案在微服务架构下，对有实时响应需求的服务请求进行即时响应。
[0128]
优选地，在上述任意实施例中，所述预设请求方式包括：http请求方式或消息队列请求方式。
[0129]
优选地，在上述任意实施例中，所述服务请求消息包括：请求的方法、url、协议版本、请求头部和请求数据。
[0130]
可以理解，在一些实施例中，可以包含如上述各实施例中的部分或全部可选实施方式。
[0131]
需要说明的是，上述各实施例是与在先方法实施例对应的产品实施例，对于产品实施例中各可选实施方式的说明可以参考上述各方法实施例中的对应说明，在此不再赘述。
[0132]
读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
[0133]
在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。
[0134]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
[0135]
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0136]
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0137]
以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，
这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。