本发明涉及信息配置技术领域，特别是涉及一种移动应用后端系统拆分时app配置信息更新方法及系统。
背景技术：
随着业务的不断发展，系统越来越大这样对硬件的要求也会越来越高，但是硬件是有极限的，随着数据量以及并发量的不断上升，其解决方案的成本也会增长。为了解决这一问题，就会对业务系统进行拆分。
针对移动应用后端系统拆分的时候，由于现有技术中的app发版时请求后端服务的域名或者配置信息是固定的，这样就造成移动应用后端系统拆分之后的两个系统前置机将会耦合在一起，或者需要老系统代理请求转发到新系统前置机，但是会造成系统资源的浪费。同时由于调用链变长，会导致服务质量下降。对于快速发展的互联网公司来说，业务系统的拆分和升级是不可避免的，如果能够解决这个问题将会在节省资源的同时也能避免由于系统升级导致的用户体验感的下降。
技术实现要素：
针对于上述问题，本发明提供一种配置信息更新方法及系统，解决了app配置信息固定导致后端服务升级难度增加，及资源浪费的问题。
为了实现上述目的，根据本发明的第一方面，提供了一种配置信息更新方法，该方法包括：
为app后端的每个业务系统的接口分配与所述业务系统对应的业务标识；
在预设访问时间段内通过所述业务标识获取所述每个业务系统的配置信息；
当对所述app进行变更时，获取待变更的业务系统，通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息；
根据所述待变更的业务系统的配置信息，对所述app的配置信息进行更新。
优选地，当对所述app进行变更时，获取待变更的业务系统，通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息，包括：
当所述app进行变更时，解析获得所述app对应的前端变更信息；
根据所述app对应的前端变更信息，通过app前端与后端的业务系统对应的接口，查找到对应的待变更的业务系统；
根据通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息。
优选地，所述根据所述待变更的业务系统的配置信息，对所述app的配置信息进行更新，包括：
获取所述app进行变更之前的初始配置信息；
根据所述待变更的业务系统的配置信息，对所述初始配置信息进行更新，得到所述app的变更后的配置信息。
优选地，该方法还包括：
将所述每个业务系统对应的配置信息存储至配置服务器。
优选地，该方法还包括：
当所述配置服务器根据所述业务标识查询到与所述业务标识对应的业务系统的配置信息发生变更时，将所述业务系统对应的变更后的配置信息发送至所述app。
根据本发明的第二方面，提供了一种配置信息更新系统，该系统包括：
分配模块，用于为app后端的每个业务系统的接口分配与所述业务系统对应的业务标识；
获取模块，用于在预设访问时间段内通过所述业务标识获取所述每个业务系统的配置信息；
查找模块，用于当对所述app进行变更时，获取待变更的业务系统，通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息；
更新模块，用于根据所述待变更的业务系统的配置信息，对所述app的配置信息进行更新。
优选地，所述查找模块包括：
解析单元，用于当所述app进行变更时，解析获得所述app对应的前端变更信息；
第一查找单元，用于根据所述app对应的前端变更信息，通过app前端与后端的业务系统对应的接口，查找到对应的待变更的业务系统；
第二查找单元，用于根据通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息。
优选地，所述更新模块包括：
获取单元，用于获取所述app进行变更之前的初始配置信息；
更新单元，用于根据所述待变更的业务系统的配置信息，对所述初始配置信息进行更新，得到所述app的变更后的配置信息。
优选地，该系统还包括：
存储模块，用于将所述每个业务系统对应的配置信息存储至配置服务器。
优选地，该系统还包括：
推送模块，用于当所述配置服务器根据所述业务标识查询到与所述业务标识对应的业务系统的配置信息发生变更时，将所述业务系统对应的变更后的配置信息发送至所述app。
相较于现有技术，本发明为每个业务系统的接口分配与所述业务系统对应的业务标识；因为为每个业务系统分配的业务标识是全局唯一的业务标识，因此可以通过该业务标识及时获得对应的业务系统的配置信息的更新，进而当app进行变更时，可以根据获取的最新的配置信息进行动态配置，这样可以使得原有的域名或者配置信息更加灵活，当后端业务系统发生拆分或更新时，可以减少资源的浪费提升服务质量，因此解决了app配置信息固定导致后端服务升级难度增加，及资源浪费的问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例一提供的一种配置信息更新方法的流程示意图；
图2为本发明实施例二提供的一种配置信息更新系统的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例一
参见图1为本发明实施例一提供的一种配置信息更新方法的流程示意图，该方法包括以下步骤：
s11、为app后端的每个业务系统的接口分配与所述业务系统对应的业务标识；
可以理解的是，app(application)为计算机应用程序，现在主要是指终端软件，app软件分为前端和后端，前端通常为交互界面，也就是用户能够体验到的界面等相关功能信息，后端主要是用作功能的实现，例如，用户在app前端消息窗口发了消息，消息转换为数据传到服务器，在服务器上运行后端提供的程序，经过数据处理等把消息发送给收件人的客户端。因此，对应业务请求特点的不同，app后端对应了多个业务系统，并且该app可以为移动端的app也可以为电脑等终端上的app。
在步骤s11中为每个移动后端的业务系统的接口分配的业务标识，这个业务标识是全局唯一的业务标识，即可以通过这些业务标识来区分不同业务系统的接口，同时也可以通过该业务标识实时监测业务系统配置信息的变化情况，进而能够保证各个业务系统对应的配置信息的及时更新；
并且，唯一的业务标识key的定义可以通过如下代码实现：
md5(servicename+interfacename+timestamp)
比如评论服务里面的获取评论接口：
key＝md5(commentgetcomments1493777600)
s12、在预设访问时间段内通过所述业务标识获取所述每个业务系统的配置信息；
可以理解的是，在预设的访问时间段内获取每个业务系统的配置信息，相当于app周期性地主动获取业务系统的配置信息，而预设的访问时间段就为每个特定的时间进行一次配置信息获取，比如采用固定的算法计算更新周期t，而t的取值范围通常设置在1-2天之间，目的是为了防止更新时间太集中对配置服务器造成压力。例如：在本发明的实施例中优选采用该算法(86400+random(0，86400))得到的结果进行一次更新，计算公式中第一段的固定时间可以配置，第二段的随机时间是为了防止对热点给配置服务器造成压力。
s13、当对所述app进行变更时，获取待变更的业务系统，通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息；
具体可以包括：
当所述app进行变更时，解析获得所述app对应的前端变更信息；
根据所述app对应的前端变更信息，通过app前端与后端的业务系统对应的接口，查找到对应的待变更的业务系统；
根据通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息。
因为app的变更主要是根据现有的应用场景，对app进行升级或者功能完善，即变更最终体现在前端也就是用户的界面中，所以需要根据是前端哪些部分需要进行变更，获得其对应的接口，因为接口连接着后端，可以根据配置的唯一的业务标识查找到对应的业务系统的配置信息，然后进行配置信息更新，从而可以实现对app的变更。
s14、根据所述待变更的业务系统的配置信息，对所述app的配置信息进行更新。
在本实施例的基础上，该步骤可以包括：
获取所述app进行变更之前的初始配置信息；
根据所述待变更的业务系统的配置信息，对所述初始配置信息进行更新，得到所述app的变更后的配置信息。
需要说明的是，app进行变更通常指的是业务系统的拆分或者更新，在现有技术中在做系统拆分时，或者app版本更新时，请求后端服务的域名是写死的，也就是说各个业务系统的配置信息是固定的。当app变更时，本身会有一个初始配置信息，也就是通常的缺省的配置，该缺省的配置指的是比如常见的缺省的域名之类的信息，需要将该缺省的配置进行更新，才能保证app的正常运行。
当对app的初始配置信息进行更新后，保证了app请求后端服务时使用最新的配置信息，使得在后续的系统拆分或者更新时，配置信息更加准确。
在上述的实施例中主要是针对app主动获取各个业务系统的配置信息的情况，由于配置信息存储在配置服务器上，在本实施例一中还提供了一种配置服务器向app进行配置信息推送的实现方法。
将所述每个业务系统对应的配置信息存储至配置服务器。
当所述配置服务器根据所述业务标识查询到与所述业务标识对应的业务系统的配置信息发生变更时，将所述业务系统对应的变更后的配置信息发送至所述app。
具体的，所述配置服务器支持按照业务标识批量查询业务系统的配置；在某一个业务标识的配置发生变化时，能够给app推送配置变更信息；并且所述配置服务器提供配置界面，进而提供各个业务系统用户对业务系统的配置信息进行自主配置的功能。
当app接收到配置服务器推送的信息后，进行配置信息的更新。这样可以实时更新配置信息，使得app对应的业务系统的一些配置由写死改为动态配置更加灵活，减少后端升级的难度和资源浪费，提升了服务质量。
需要说明的是，在本发明中的主要针对的是移动端app，同样该方法也可以作为在电脑端的软件在发版或者系统拆分时的技术启示，具体实现方式参见本发明的实施例。
通过本发明实施例一公开的技术方案，为每个业务系统的接口分配与所述业务系统对应的业务标识；因为为每个业务系统分配的业务标识是全局唯一的业务标识，因此可以通过该业务标识及时获得对应的业务系统的配置信息的更新，进而当app进行变更时，可以根据获取的最新的配置信息进行动态配置；同时，当配置服务器获得业务系统的配置信息更新后，会将该更新后的配置信息主动推送至app，方便了app的动态配置。这样可以使得原有的域名或者配置信息更加灵活，当后端业务系统发生拆分或更新时，可以减少资源的浪费提升服务质量，因此解决了app配置信息固定导致后端服务升级难度增加，及资源浪费的问题。
实施例二
与本发明实施例一公开的配置信息更新方法相对应，本发明的实施例二还提供了一种配置信息更新系统，参见图2，该系统包括：
分配模块1，用于为app后端的每个业务系统的接口分配与所述业务系统对应的业务标识；
获取模块2，用于在预设访问时间段内通过所述业务标识获取所述每个业务系统的配置信息；
查找模块3，用于当对所述app进行变更时，获取待变更的业务系统，通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息；
更新模块4，用于根据所述待变更的业务系统的配置信息，对所述app的配置信息进行更新。
具体的，所述查找模块包括：
解析单元，用于当所述app进行变更时，解析获得所述app对应的前端变更信息；
第一查找单元，用于根据所述app对应的前端变更信息，通过app前端与后端的业务系统对应的接口，查找到对应的待变更的业务系统；
第二查找单元，用于根据通过所述待变更的业务系统的业务标识查找得到与所述待变更的业务系统对应的配置信息
对应的，所述更新模块包括：
获取单元，用于获取所述app进行变更之前的初始配置信息；
更新单元，用于根据所述待变更的业务系统的配置信息，对所述初始配置信息进行更新，得到所述app的变更后的配置信息。
同时，该系统还包括：
存储模块，用于将所述每个业务系统对应的配置信息存储至配置服务器。
对应的，该系统还包括：
推送模块，用于当所述配置服务器根据所述业务标识查询到与所述业务标识对应的业务系统的配置信息发生变更时，将所述业务系统对应的变更后的配置信息发送至所述app。
在本发明的实施例二中，为每个业务系统的接口分配与所述业务系统对应的业务标识；因为为每个业务系统分配的业务标识是全局唯一的业务标识，因此可以通过该业务标识及时获得对应的业务系统的配置信息的更新，进而当app进行变更时，可以根据获取的最新的配置信息进行动态配置，这样可以使得原有的域名或者配置信息更加灵活，当后端业务系统发生拆分或更新时，可以减少资源的浪费提升服务质量，因此解决了app配置信息固定导致后端服务升级难度增加，及资源浪费的问题。
本发明的说明书和权利要求书及上述附图中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述特定的顺序。此外术语“包括”和“具有”以及他们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有设定于已列出的步骤或单元，而是可包括没有列出的步骤或单元。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。