[发明专利]一种基于应用市场架构的数据交互方法及设备

说明书

本申请的目的是提供一种基于应用市场架构的数据交互方法及设备，本申请的网关服务设备将从客户端接收的时长请求中的路由信息确定应用程序的市场版本类型并获取与市场版本类型对应的解密参数，根据解密参数解密应用数据得到业务标识信息和路由参数信息并发送至集群注册设备；集群注册设备根据路由参数信息确定与业务标识信息对应的业务服务设备及其对应的路由设备的网络地址并向业务服务设备发起业务请求；业务服务设备获取网络地址对应的路由设备服务的业务的业务结果数据并原路返回至客户端，实现了基于构建的应用市场架构对不同应用程序的业务结果数据的交互。

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于应用市场架构的数据交互方法及设备。

背景技术

应用市场功能模块增多，由最开始的一台服务器的成本慢慢地扩展累计到十几台，甚至是几十台的服务器。所有功能都融合在一个单体服务中，承载的业务庞大，服务内部逻辑变得复杂，导致整个市场服务体系越来越臃肿、业务扩展性也越来越差、开发人员研发或迭代功能也越来越困难、新人接手管理服务也越来越费精力、运营人员也无法更精准更可靠地获取有效的数据可供分析、服务器的维护成本也越来越高、无法支持高并发的请求访问、手机端用户体验不好等。

在现有技术中，当前应用市场使用的技术是Java的SSM框架组合，其中，SSM为Spring+SpringMVC+MyBatis；随着市场需求的不断增加，越来越多的人加入开发团队，代码库也在飞速膨胀，导致系统越来越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高，使得当前服务存在很多不足之处：

比如，复杂性高：当前整个项目代码已经达到了百万行级别了，包含的模块非常多、代码质量参差不齐、混乱地堆砌在一起；整个项目非常复杂，每次修改代码都心惊胆战，甚至添加一个简单的功能，或修改一个Bug都会带来隐含的缺陷。

又比如，部署频率低：随着代码的增多，构建和不是的时间也会增加，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用服务；全量不是的方式非常耗时长、影响范围大、风险高，这使得时长项目上线部署的频率较低。

又比如，可靠性差：若某个应用Bug，例如，死循环、内存溢出等，可能会导致整个市场服务的崩溃。

又比如，灵活性低：多人合作迭代新功能时分工不方便、研发新业务功能扩展性差、兼容各个新旧版本越来越困难；支持的框架的系统库版本老旧，不能完全与市面最新库兼容使用。

又比如，成本高：Java对服务器硬件的性能要求高、服务费用成本偏高，相对于更费服务器的内存资源，当多个复杂算法同时操作时容易出现系统内存被Java占满，而导致整个项目停止服务。

又比如，当前支持并发量低：当前的服务架构的服务支持高并发量过低；日志数据零散：用户数据采集零散、不规范、不便于运营人员日常分析运营市场；及阻碍技术创新：项目开发人员全都熟悉懂得此市场的Java架构、每个研发都必须掌握整个服务架构流程和运行逻辑。

发明内容

本申请的一个目的是提供一种基于应用市场架构的数据交互方法及设备，实现了基于应用市场架构，对不同应用程序的业务结果数据的传递。

根据本申请的一个方面，提供了一种基于应用市场架构的数据交互方法，应用于网关服务设备端，其中，所述方法包括：

接收从客户端的应用程序中传递过来的市场请求，所述市场请求包括路由信息和应用数据；

根据所述路由信息确定所述应用程序的市场版本类型，并获取与所述市场版本类型对应的解密参数；

根据与所述市场版本类型对应的解密参数解密所述应用数据，得到业务标识信息和路由参数信息；

将所述业务标识信息和所述路由参数信息发送至集群注册设备，以使所述集群注册设备根据所述路由参数信息确定与所述业务标识信息对应的业务服务设备的标识及其对应的路由设备的网络地址；