基于MQ替代RPC实现全域应用解耦

一种基于MQ替代RPC实现软件系统全域应用解耦的方法

交底书名称 一种基于MQ替代RPC实现软件系统全域应用解耦的方法

申请类型： 发明

发明人/设计人 张三

交底书注意事项

保持一样即可,不用填写

0 缩略语和关键术语定义

解释MQ、RocketMQ、restful api、RPC , 消息总线，生产者，消费者，Request-Reply模式

1 技术背景及与本发明最相近似的现有技术

1.1 背景技术

​ （填写要求:1、简介该技术领域的发展；2、解释相关关键技术；3、对于理解发明内容没有帮助的不要提供。）

1.2 与本发明相关的现有技术一

1.2.1 现有技术一的技术方案

（填写要求：1、只提供相关现有技术，不相关的不提供，如果该现有技术的缺点或不足正是本发明所要解决的技术问题，则为相关现有技术，否则为非相关现有技术；2、结合附图，用文字对实现方案进行描述；应详细介绍，以不需再去看文献即可领会该技术内容为准，如果现有技术出自专利、期刊、书籍，则提供出处。3、现有技术的提供非常重要，能加快专利的授权，还能使专利代理人找出本发明的创新点，以确定合适的保护范围。)

现有技术一可以用restful api来举例说明

1.2.2 现有技术一的缺点

（填写要求：1、根据本发明的优点来找对应的缺点；2、本发明不能解决的缺点，不需要提供；3、缺点可以是成本高、效率低、反应速度慢等类似的问题。）

说明restful api的方式进行服务间调用通信的缺点

1.3 与本发明相关的现有技术二

1.3.1 现有技术二的技术方案

​ 现有技术二可以用微服务来举例说明

1.3.2 现有技术一的缺点

​ 说明微服务的方式进行服务间调用通信的缺点：微服务分布式的治理非常痛苦，springcloud虽然设计好了，也有微服务相关的组件(配置中心、注册中心等待)，但是微服务毕竟太重了，且对于服务间线性调用，即服务A->B->C->D，不是在单一线程中完成的，也没法进行链路追踪。

2 技术方案

2.1 本发明所要解决的技术问题（发明目的）

（填写要求：1、对应现有技术的所有缺点，一一正面描述本发明所要解决的技术问题；2、本发明解决不了的，不要写；）

采用事件总线模式，即MQ。目前RabbitMQ的RPC模式，以及RocketMQ的Request-Reply模式，不再区分传统消息队列的生产者消费者，而是客户端和服务器端，他们互为生产者和消费者。同时通过配置，在一个请求中，产生两个队列（入列和出列）

2.2 本发明提供的完整技术方案（发明方案）

（填写要求：1、本部分为专利申请最重要的部分，需要详细提供；2、专利必须是一个技术方案，应该阐述发明目的是通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍；3、附图以黑色线条图的方式提供，不必提供彩色图例，图中要显示发明创造点的结构、连接关系、位置关系等；4、对于软件方法，除提供流程图外，还应提供相关的系统装置；5、必须结合流程图、原理框图、电路图、时序图等附图进行说明，每个图都应有对应的文字描述，以别人不看附图即可明白技术方案为准；6、 描述发明内容时，不同类型的发明有不同的描述方式。举例如下：
产品发明：应当具体说明其零部件的结构及相互位置关系和连接关系。
方法发明：应当说明为完成发明任务所必须实现的工艺方法、工艺流程和条件（如时间、压力、温度、浓度）。
电路发明：应当说明各功能电路之间的电连接关系或信号传送关系及各功能电路的具体构成。
组合物或者混合物发明：应当说明其成分及含量、制备方法，用途等。在描述其成分及含量时，尽可能提供其取值或者选择范围，并说明确定该范围的依据或者原因。）

3、针对2中的技术方案，是否还有别的替代方案同样能完成发明目的

（填写要求1、如果有，请尽量写明，内容的提供可以扩大专利的保护范围，防止他人绕过本技术去实现同样的发明目的，2、“替代方案”可以是部分结构、器件、方法步骤的替代，也可以是完整技术方案的替代。）

4、本发明的技术关键点和欲保护点是什么

（填写要求：1、简单点明；2、具体可以是根据2.3部分能给本发明带来有益效果的关键技术点）

5、附件

参考文献（如专利/论文/标准）

技术交底书

交底书名称 一种微服务下的大数据业务查询方法
申请类型： □发明 □实用新型

知识产权部负责人
电话
Email

跟进专利工程师
电话
Email

交底书注意事项

1. 技术交底书是帮助代理人理解真实发明创造点，写好申请文件的基础。代理人并不是技术专家，交底书要使代理人能看懂，尤其是背景技术和详细技术方案，一定要写得全面、清楚。
   2.英文缩写要有中文译文，避免使用英文单词。术语应采用行业标准用语。
   3.全文对同一事物的叫法应统一，避免出现一种东西多种叫法。
   4.代理人的沟通时，对于代理人的疑问应认真讲解，要求补充的材料应及时补充。代理人对交底技术内容承担保密责任，因此申请人应充分公开其发明创造技术内容。
   5.专利法规定：
   1）专利必须是一个技术方案，应该阐述发明目的是通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍；
   2）专利必须充分公开，以本领域技术人员不需付出创造性劳动即可实现为准。由于专利申请文件在申请后不能对其内容进行修改，即不能改变、增加或删除，因此交底书必须充分完整。
   必须满足上述规定，专利才能批准，但为了不让竞争对手完全掌握我司技术，对于希望保密的地方，可以在细节上做一些加工，如隐藏，或提供别的实现方式。对于希望保密的地方，可向代理人说明。

0、缩略语和关键术语定义（填写要求:1、注明所使用的英文缩写所表示的中文内容；2、注明本文中所使用的关键术语的定义。）
ElasticSearch：Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用Elasticsearch的水平伸缩性，能使数据在生产环境变得更有价值。Elasticsearch 的实现原理主要分为以下几个步骤，首先用户将数据提交到Elasticsearch 数据库中，再通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。
Kafka：Kafka是Apache旗下的一款分布式流媒体平台，Kafka是一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。 它最初由LinkedIn(领英)公司发布，使用Scala语言编写，与2010年12月份开源，成为Apache的顶级子项目。 它主要用于处理消费者规模网站中的所有动作流数据。动作指(网页浏览、搜索和其它用户行动所产生的数据)。
数据库：数据库（Database）是按照数据结构来组织、存储和管理数据的仓库。每个数据库都有一个或多个不同的 API 用于创建，访问，管理，搜索和复制所保存的数据。我们也可以将数据存储在文件中，但是在文件中读写数据速度相对较慢。所以，现在我们使用关系型数据库管理系统（RDBMS）来存储和管理大数据量。所谓的关系型数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。
Mysql：MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。
微服务：又叫微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。在微服务架构中，每个服务都是自我包含的，并且实现了单一的业务功能。
数据聚合：合并来自不同数据源的数据。
Canal：Canal是阿里开源的一款基于Mysql数据库binlog的增量订阅和消费组件，通过它可以订阅数据库的binlog日志，然后进行一些数据消费，如数据镜像、数据异构、数据索引、缓存更新等。相对于消息队列，通过这种机制可以实现数据的有序化和一致性。
CAP定理

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

1、 技术背景及与本发明最相近似的现有技术
1.1 背景技术（填写要求:1、简介该技术领域的发展；2、解释相关关键技术；3、对于理解发明内容没有帮助的不要提供。）
在当前现实软件开发使用中，一般采用Mysql关系型数据库作为软件数据存储关系型数据，而在软件查询中，必然存在关系型数据的聚合查询，即假设有关系A，B两种关系，业务存在A，B关系的交集的集合，如下图所示：

而在微服务中，假设软件中分成微服务A，微服务B，那业务查询结果往往是多个微服务的聚合结果，而每个微服务里面的单聚合结果往往是关心型数据库的关系聚合结果，如下图所示：

Mysql的关系表关联查询的结果是笛卡尔积，如果为关系A查询结果条数为n，关系B查询结果为m，查询的复杂度为n*m，可见随着关系A，B的数据量增加，符合条件的数据在增加，那复杂度呈线性增加。而在微服务架构下，查询往往是聚合多微服务查询结果，所以在随数据量增加后，聚合业务查询速度会更加地慢。针对以上这些情况，本文提供一种微服务下的大数据业务查询方法。

1.2 与本发明相关的现有技术一
1.2.1 现有技术一的技术方案（填写要求：1、只提供相关现有技术，不相关的不提供，如果该现有技术的缺点或不足正是本发明所要解决的技术问题，则为相关现有技术，否则为非相关现有技术；2、结合附图，用文字对实现方案进行描述；应详细介绍，以不需再去看文献即可领会该技术内容为准，如果现有技术出自专利、期刊、书籍，则提供出处。3、现有技术的提供非常重要，能加快专利的授权，还能使专利代理人找出本发明的创新点，以确定合适的保护范围。)
现有技术有一种是直接进行微服务的聚合查询，采用一个聚合查询服务，在各服务里进行关系型数据库的联表查询，然后将结果聚合返回给UI界面展示。如图所示：

举例说明：假设存在微服务A，微服务B，有一个业务查询分别需要微服务A中的关系a,关系b中的交集c，微服务B中的关系d,关系e中的交集f，然后聚合查询服务通过http请求微服务A，微服务B，得到结果交集c,交集f，然后进行循环拼装结果返回给软件UI界面展示。
1.2.2 现有技术一的缺点（填写要求：1、根据本发明的优点来找对应的缺点；2、本发明不能解决的缺点，不需要提供；3、缺点可以是成本高、效率低、反应速度慢等类似的问题。）
1：多个服务查询，通过http请求，需等待两个服务的结果返回后再进行数据拼装，在等待过程耗时和数据拼装的耗时；
2：每个服务都需要进行关系型数据库的联表查询，随着数据量的增加，复杂度呈现线性增长，查询速度越来越慢；

1.3 与本发明相关的现有技术二（填写要求：如没有则不写，有更多则新建1.4节等，写法与现有技术一的写法完全一样）
1.3.1 现有技术二的技术方案
现有技术有一种方案是采用嵌入事件的方式，当软件进行保存，更新等操作时，除更新相关关系数据外，采用发送微服务事件的方式通知业务数据聚合服务，然后由业务数据聚合服务进行相关数据处理计算。聚合为业务服务需要的数据格式并存储，架构如下：

1.3.2 现有技术二的缺点
需要在每个保存，更新，删除操作进行事件嵌入逻辑编写，容易发生遗漏和加大编码维护工作

1.4 与本发明相关的现有技术三（填写要求：如没有则不写，有更多则新建1.4节等，写法与现有技术一的写法完全一样）
1.4.1 现有技术三的技术方案
现有技术有一种方案是采用开源Canal组件进行Mysql数据库的订阅，但后将数据的改变写入到Kafka，然后由数据处理服务进行数据订阅并处理，并存储到Elastiv Search中，架构如下：

1.4.2 现有技术二的缺点
数据处理服务将会成为瓶颈，需要在数据处理服务进行Canal数据的转换处理和业务数据的处理，而Canal数据的转换（由Canal数据流转换成实体对象）速度一般是大于业务数据处理（需找到对应的聚合数据逻辑，比如ElasticSearch中的索引A，字段a需要进行逻辑x的处理后在保存进入索引A中），这样会由于业务处理的问题导致整个Canal的吞吐量降低。
2、 技术方案
2.1 本发明所要解决的技术问题（发明目的）（填写要求：1、对应现有技术的所有缺点，一一正面描述本发明所要解决的技术问题；2、本发明解决不了的，不要写；）

1：针对跨服务请求各微服务，会出现网络请求，后续多服务拼装结果，并且各服务需要进行关系型数据库联表查询的缺点，本方案采用单独的业务数据数据库的方式存储解决。
即比如业务查询需要关系c，而关系c来源于微服务A的关系a，关系b的交集，微服务B的关系c，关系d的交集。那就将关系c座位该业务的关系表存储，当微服务中触发关系a，关系b，微服务B触发关系c，关系d的增加，删除，修改操作时，通过Canal组件进行通知然后发送消息队列，然后数据处理服务进行聚合处理存储为关系c。故业务查询时就是直接进行单关系表c的单表查询，无任何跨微服务聚合查询，也无任何的表关联查询。
2：针对每个保存，更新，删除操作进行事件嵌入逻辑编写，容易发生遗漏和加大编码维护工作
问题，采用如下方案：
Canal组件可以订阅数据库的binlog日志，然后进行一些数据消费，如数据镜像、数据异构、数据索引、缓存更新等。通过这个特性可以进行无嵌入式的通知，而Canal组件还可以和消息队列如Kafka进行链接，即触发事件后通过消息队列进行发送，大大增加了处理速度。这样再通过集群式的数据处理服务进行订阅，达到无需代码嵌入业务系统和快速处理的目的。
3：针对数据处理服务的瓶颈问题，本解决方案采用如下方案：
3.1：将数据处理服务拆分为Canal数据处理服务和业务数据处理服务，并在服务之间用消息队列进行解耦，加大Canal数据处理服务的吞吐量
3.2：针对消息队列的丢失问题，采用CAP定理，用本地确保的方式（即本地数据库+消息队列的方式）来保证消息的可靠性

2.2 本发明提供的完整技术方案（发明方案）（填写要求：1、本部分为专利申请最重要的部分，需要详细提供；2、专利必须是一个技术方案，应该阐述发明目的是通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍；3、附图以黑色线条图的方式提供，不必提供彩色图例，图中要显示发明创造点的结构、连接关系、位置关系等；4、对于软件方法，除提供流程图外，还应提供相关的系统装置；5、必须结合流程图、原理框图、电路图、时序图等附图进行说明，每个图都应有对应的文字描述，以别人不看附图即可明白技术方案为准；6、 描述发明内容时，不同类型的发明有不同的描述方式。举例如下：
产品发明：应当具体说明其零部件的结构及相互位置关系和连接关系。
方法发明：应当说明为完成发明任务所必须实现的工艺方法、工艺流程和条件（如时间、压力、温度、浓度）。
电路发明：应当说明各功能电路之间的电连接关系或信号传送关系及各功能电路的具体构成。
组合物或者混合物发明：应当说明其成分及含量、制备方法，用途等。在描述其成分及含量时，尽可能提供其取值或者选择范围，并说明确定该范围的依据或者原因。）

实现原理：
ElasticSearch：Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用Elasticsearch的水平伸缩性，能使数据在生产环境变得更有价值。Elasticsearch 的实现原理主要分为以下几个步骤，首先用户将数据提交到Elasticsearch 数据库中，再通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。
Canal：Canal是阿里开源的一款基于Mysql数据库binlog的增量订阅和消费组件，通过它可以订阅数据库的binlog日志，然后进行一些数据消费，如数据镜像、数据异构、数据索引、缓存更新等。相对于消息队列，通过这种机制可以实现数据的有序化和一致性。
BASE理论：
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）

本申请提供了一种微服务下的大数据业务查询方法，可以提高微服务架构下的聚合业务查询的查询效率。
一方面，本申请的微服务下的大数据业务查询方法，包括：
1：聚合业务数据处理的处理
1.1：Canal组件，部署Canal组件对业务关系型数据库进行增量订阅，当业务数据关系表数据发生新增，修改，删除时，触发，然后将新增，修改，删除数据及事件发送至消息队列如kafka中；
1.2：编写Canal数据处理服务，该服务属于web服务，主要功能是订阅消息队列如kafka中的Canal组件监听发送的消息，然后解析该数据，然后通过本地确保的方式，组装消息体，然后将消息保存到常用的数据库中（Mysql，MongoDB等都可）存储并将消息体发布到消息队列中；
1.3：编写业务数据处理服务，订阅Canal数据处理服务中的消息，将接收到的消息存储到到常用的数据库中（Mysql，MongoDB等都可），然后进行业务聚合，如服务A的关系a，包含在业务关系c,关系d的逻辑中。当订阅的消息中有服务A的关系a的数据时，即进行对应的逻辑处理，将数据更新或新增到业务关系c，关系d中，存储到Elastic Search中；

2：聚合查询
2.1：编写业务聚合查询服务，该服务直接查询对应聚合业务关系表即可，然后将结果返回给用户展现。

                           程序网络拓扑图

该方法的核心如下：
1：通过Canal组件实现无代码嵌入的方式进行数据更改的通知，解决在业务代码中的嵌入遗漏问题和提高程序的可维护性；
2：通过Canal+kafka+数据处理服务集群的方式增加业务聚合数据处理的效率，减少查询的数据延迟；
3：通过聚合业务数据关系表的方式来解决微服务查询的跨微服务聚合请求并拼装数据返回的问题，解决关系型数据库联表查询速度慢的问题；
4：通过拆分为Canal数据处理服务和业务数据处理服务来解耦Canal数据解析和业务数据聚合逻辑处理，增加Canal数据处理的吞吐量，最大化利用资源；
5：通过MQ+本地确保的方式保证消息的可靠性，用来处理采用MQ传输可能出现的消息丢失和处理失败问题。

2.3 本发明技术方案带来的有益效果（填写要求：1、结合技术方案来描述，做到有理有据；描述发明效果，能够量化的尽量量化，不能量化的，可以用对结构特点的分析和理论说明的方法加以描述，不要笼统的描述，也不要使用广告性宣传语言。2、可以对应2.1部分所要解决的技术问题来描述。）

1：通过Canal组件实现无代码嵌入的方式进行数据更改的通知，解决在业务代码中的嵌入遗漏问题和提高程序的可维护性；
2：通过Canal+kafka+数据处理服务集群的方式增加业务聚合数据处理的效率，减少查询的数据延迟；
3：通过聚合业务数据关系表的方式来解决微服务查询的跨微服务聚合请求并拼装数据返回的问题，解决关系型数据库联表查询速度慢的问题。
4：通过拆分为Canal数据处理服务和业务数据处理服务来解耦Canal数据解析和业务数据聚合逻辑处理，增加Canal数据处理的吞吐量，最大化利用资源；
5：通过MQ+本地确保的方式保证消息的可靠性，用来处理采用MQ传输可能出现的消息丢失和处理失败问题
3、针对2中的技术方案，是否还有别的替代方案同样能完成发明目的（填写要求1、如果有，请尽量写明，内容的提供可以扩大专利的保护范围，防止他人绕过本技术去实现同样的发明目的，2、“替代方案”可以是部分结构、器件、方法步骤的替代，也可以是完整技术方案的替代。）

4、本发明的技术关键点和欲保护点是什么（填写要求：1、简单点明；2、具体可以是根据2.3部分能给本发明带来有益效果的关键技术点）

5、附件：
参考文献（如专利/论文/标准）