基于物联网的分布式动态调节长连接服务的方法及装置与流程

1.本发明涉及计算机技术领域，具体而言，涉及一种基于物联网的分布式动态调节长连接服务的方法及装置。


背景技术：

2.一般来说，为了解决在物联网(iot)系统下，负载均衡需要部分人为操作的技术问题，并且大多数物联网系统依赖于java开发，java在系统业务上的庞大依赖包，对系统内存和cpu的高负荷。分布式系统的运行环境，存在下列异构性（即存在多样性和差别）：网络、计算机硬件、操作系统、编程语言、由不同开发者完成的软件实现。中间件是解决异构性的一种方式，中间件是指一个软件层，它提供了一个编程抽象，屏蔽了底层网络、计算机硬件、操作系统、编程语言的异构性。分布式系统可以在不同的规模下有效且高效地运行，大多数物联网服务是通过运维人员手动调节负载，即服务性能达不到生产的需求后开启新的节点服务，支撑业务正常运转，而且目前市面上大多采用java的springcloud全家桶来实现负载均衡和动态扩容的策略。
3.负载均衡策略：（1）random：加权随机，按权重设置随机概率；在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重；缺点：存在慢的提供者累积请求的问题，比如，第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
4.（2）roundrobin：加权轮询，按公约后的权重设置轮询比率，循环调用节点；缺点：同样存在慢的提供者累积请求的问题。
5.对此，consul 借鉴 nginx的平滑加权轮询算法，对此做了优化，调用过程可抽象成下表1:表1轮前加和权重本轮胜者合计权重轮后权重（胜者减去合计权重）起始轮\\a(0),b(0),c(0)a(3),b(2),c(1)a6a(-3),b(2),c(1)a(0),b(4),c(2)b6a(0),b(-2),c(2)a(3),b(0),c(3)a6a(-3),b(0),c(3)a(0),b(2),c(4)c6a(0),b(2),c(-2)a(3),b(4),c(-1)b6a(3),b(-2),c(-1)a(6),b(0),c(0)a6a(0),b(0),c(0)发现经过合计权重（3 2 1）轮次后，循环又回到了起点，整个过程中节点流量是平
滑的，且哪怕在很短的时间周期内，概率都是按期望分布的。
6.如果用户有加权轮询的需求，可放心使用该算法。
7.（3）leastactive：加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数
ꢀ‑ꢀ
响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强；使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。
8.应特别注意，consul支持raft算法，能够平滑的实现高可用的注册中心。
9.grpc (google remote procedure call)优势如下：http/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低tcp链接次数、节省cpu，帮助移动设备延长电池寿命等。grpc的协议设计上使用了http2 现有的语义，请求和响应的数据使用http body 发送，其他的控制信息则用header 表示。
10.grpc使用protobuf来定义服务，protobuf是由google开发的一种数据序列化协议（类似于xml、json、hessian）。protobuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。
11.grpc支持多种语言（c, c , python, php, nodejs, c#, objective-c、golang、java），并能够基于语言自动生成客户端和服务端功能库。目前已提供了c版本grpc、java版本grpc-java 和 go版本grpc-go，其它语言的版本正在积极开发中，其中，grpc支持c、c 、node.js、python、ruby、objective-c、php和c#等语言，grpc-java已经支持android开发。
12.proto文件生成目标代码，并且传输数据压缩，有效的节省了带宽压力。序列化，反序列化直接在应用程序中的数据类，不需要解析映射xml，json等格式。


技术实现要素：

13.鉴于上述问题，本发明提供了一种基于物联网的分布式动态调节长连接服务的方法及装置，能够有效解决在物联网达不到生产的需求后动态调节服务连接的问题。
14.为了实现上述目的，本发明采用如下的技术方案：第一方面，本发明提供了一种基于物联网的分布式动态调节长连接服务的方法，所述方法包括：由用户端定义protoc协议，根据所述protoc协议生成对应的用户端代码，所述用户端将所述用户端代码通过物联网发送至nginx服务端后，所述用户端获取关联于所述nginx服务端的长连接地址；由所述nginx服务端通过所述长连接地址实现对网关服务端的代理转发配置；由所述网关服务端根据所述代理转发配置经过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理；由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理。
15.在一实施例中，在所述由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理后，所述方法包括：由所述网关服务端通过其中的docker应用引擎的驱动代码根据所述多个服务连接模式的连接数量获取的阈值，以通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；其中，当所述多个服务连接模式的连接数量没有到达距离所述阈值的预设范围时，则不通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理。
16.在一实施例中，在所述由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理后，所述方法包括：当所述多个服务连接模式的连接数量到达距离阈值的预设范围时，则通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；由所述网关服务端执行的所述策略管理为关闭先前的业务服务信息，并启动新的业务服务代码发送至所述业务服务端；由所述业务服务端将所述新的业务服务代码发送至所述consul集群端的服务注册中心进行注册。
17.在一实施例中，在由所述网关服务端通过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理中，所述方法包括：所述用户端及/或所述网关服务端通过可配置方式修改关联于负载均衡的所述策略管理。
18.在一实施例中，在由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理中，所述方法包括：由所述网关服务端通过所述业务服务端对所述多个服务连接模式的连接数量分别进行设置后，获取关联于所述多个服务连接模式的其中之任一的连接数量并传送至redis存储端进行存储。
19.第二方面，本发明提供了一种基于物联网的分布式动态调节长连接服务的装置，所述装置包括：定义模块，所述定义模块用于对用户端定义protoc协议，根据所述protoc协议生成对应的用户端代码，所述用户端将所述用户端代码通过物联网发送至nginx服务端后，所述用户端获取关联于所述nginx服务端的长连接地址；处理模块，所述处理模块用于对所述nginx服务端通过所述长连接地址实现对网关服务端的代理转发配置；计算模块，所述计算模块用于对所述网关服务端根据所述代理转发配置经过通过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理；调节模块，所述调节模块用于对所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理。
20.在一实施例中，所述装置还包括：驱动模块，所述驱动模块用于对所述网关服务端通过其中的docker应用引擎的驱动代码根据所述多个服务连接模式的连接数量获取的阈值，以通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；其中，当所述多个服务连接模式的连接数量没有到达距离所述阈值的预设范围时，则不通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理。
21.在一实施例中，所述装置还包括：预设模块，所述预设模块用于当所述多个服务连接模式的连接数量到达距离阈值的预设范围时，通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；所述网关服务端执行的所述策略管理为关闭先前的业务服务信息，并启动新的业务服务代码发送至所述业务服务端；所述业务服务端将所述新的业务服务代码发送至所述consul集群端的服务注册中心进行注册。
22.在一实施例中，所述装置还包括：所述修改模块，所述修改模块用于对所述用户端及/或所述网关服务端通过可配置方式修改关联于负载均衡的所述策略管理。
23.在一实施例中，所述装置还包括：存储模块，所述存储模块用于对所述网关服务端通过所述业务服务端对所述多个服务连接模式的连接数量分别进行设置后，获取关联于所述多个服务连接模式的其中之任一的连接数量并传送至redis存储端进行存储。
24.根据本发明提供了一种基于物联网的分布式动态调节长连接服务的方法，方法包括：由用户端定义protoc协议，根据protoc协议生成对应的用户端代码，用户端将用户端代码通过物联网发送至nginx服务端后，用户端获取关联于nginx服务端的长连接地址；由nginx服务端通过长连接地址实现对网关服务端的代理转发配置；由网关服务端根据代理转发配置经过通过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理；由网关服务端结合对应的策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现网关服务端对多个服务连接模式的连接数量的策略管理。
25.本发明提供的方法，可以动态的配置服务的负载策略，结合负载均衡的策略，实现了可配置，且应用上灵活方便，可以采用灰度发布等动态更新的方式，满足业务高可用的需求，采用配置与逻辑相分离的架构设计方式实现了产品的高可用性。需要声明的是，本发明所述的一种基于物联网的分布式动态调节长连接服务的方法及装置并不局限于上述应用场景或特定电子设备，具有很强的通用性。另外，本发明通过使用nodejs grpc consul的技术创新，解决了在设备过载的问题上，实现自动化物联网服务(iot)启动，动态负载的技术手段，突破了java在物联权开发语言上的垄断地位，又填补了nodejs在物联网上的技术空白，即降低了技术难度，又降低了运维难度，并且能够承载更多用户，实现高可用，高可靠的物联网轻型服务。
26.为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
27.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对本发明范围的限定。
28.图1是本发明提供的一种基于物联网的分布式动态调节长连接服务的方法的方法流程图。
29.图2是本发明提供的一种基于物联网的分布式动态调节长连接服务的方法的另一方法流程图。
30.图3是本发明提供的一种基于物联网的分布式动态调节长连接服务的方法的又一方法流程图。
31.图4是本发明提供的一种基于物联网的分布式动态调节长连接服务的具体架构图。
32.图5是本发明提供的一种基于物联网的分布式动态调节长连接服务的具体业务时序图。
33.图6是本发明提供的一种基于物联网的分布式动态调节长连接服务的装置的示意性方块图。
具体实施方式
34.下面详细描述本发明的实施例，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。
35.应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
36.下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
37.请参阅图1，图1是本发明提供的一种基于物联网的分布式动态调节长连接服务的方法的方法流程图。
38.一种基于物联网的分布式动态调节长连接服务的方法，所述方法包括：s1：由用户端定义protoc协议，根据所述protoc协议生成对应的用户端代码，所述用户端将所述用户端代码通过物联网发送至nginx服务端后，所述用户端获取关联于所述nginx服务端的长连接地址。
39.在一实施例中，用户端可以是用户服务器。首先，由用户端定义protoc协议，例如，protoc协议为进行网络（可视为物联网）中的数据交换而建立的规则、标准或约定。protoc协议用于不同系统、服务器或各种电子设备内的软件中关于实体间的通信。当两个实体要进行通信，必须由同一种语言构成的协议，对于通信内容（可视为用户端代码），怎样通信、对象通信和何时通信，都必须遵守一定的规定，这些规定就是协议。亦可简单地定义为控制两个以上的实体间数据交换的一套规则。在电子通讯连接中，各个不同的层次都有特定的
协议。在硬件设备层次和应用程序层次的数据交换都有自己的协议。在开放式系统互连（osi，open system interface）的标准模式中，每个层都可以包括一到两种协议，发生通讯的两个电子设备终端都必须能识别和遵守协议。另外，协议通常以工业或国际标准的形式被描述。nginx服务端可以通过软件或服务器来实现，其中，nginx 是一个高性能的http和反向代理web服务器，同时也提供了imap/pop3/smtp服务。用户端根据用户端代码获取关联于nginx服务端的长连接地址。以应用于长连接的地址来说，http长连接，指的是tcp（transmission control protocol）连接建立后，传输层连接不再进行释放，供应用层反复使用。
40.s2：由所述nginx服务端通过所述长连接地址实现对网关服务端的代理转发配置。
41.在一实施例中，nginx服务端接收到用户端通过定义protoc协议产生的用户端代码后，nginx服务端进一步由用户端代码对网关服务端的代理转发配置。
42.s3：由所述网关服务端根据所述代理转发配置经过所述consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理。
43.在一实施例中，consul集群端是一个用来实现分布式系统的服务发现与配置的开源工具，可以实现服务提供者（可视为业务服务端）和服务消费者（可视为用户端）的隔离，比如服务提供者(goods service)将自身注册到consul集群端的服务注册中心中，注册的信息为servicename ip/port，这样服务消费者只需要知道servicename就可以知道对应服务的ip 端口，从而进行访问及/或注册。例如，业务连接分配的策略管理可以视为对多个智能家电进行多种业务连接的方式进行多样化的策略管理，用于增加灵活性，并不会因为多个智能家电的其中之一失去网络连线后，而造成其他的智能家电也同样失去网络连线。
44.s4：由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理。
45.在一实施例中，在网关服务端结合对应的策略管理，并由策略管理的多个变数因子（可视为根据不同的电子设备或在不同时间进行连接网络的变数因子），通过分布式动态调节长连接服务方式分配多个服务连接模式（例如第一群组的电子设备1、3、5进行连线，或是第二群组的电子设备2、4、6、8进行连线），实现网关服务端对多个服务连接模式的连接数量的策略管理，例如通过策略管理在第一群组的电子设备的连接数量为3，通过策略管理在第二群组的电子设备的连接数量为4，由于在通过策略管理的多个服务连接模式的连接数量有多种排列组合，本发明不以特定连接数量为限制。本发明通过策略管理的多个服务连接模式在应用上灵活方便，可以采用灰度发布等动态实时更新的方式，满足业务高可用的需求，及完成复杂业务难度高的要求。
46.请同时参阅图1和图2，图1是本发明提供的一种基于物联网的分布式动态调节长连接服务的方法的另一方法流程图。其中，s1-4请参阅图1的实施例说明，在此不加赘述。
47.在所述s4由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理后，所述方法包括：s5：由所述网关服务端通过其中的docker应用引擎的驱动代码根据所述多个服务连接模式的连接数量获取的阈值，以通过所述分布式动态调节长连接服务方式进行启动及
关闭的所述策略管理；其中，当所述多个服务连接模式的连接数量没有到达距离所述阈值的预设范围时，则不通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理。
48.在一实施例中，docker应用引擎可以让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 linux或windows操作系统的电子设备上通过驱动代码实现虚拟化的操作，进一步计算多个服务连接模式的连接数量获取的阈值，例如第一服务连接模式的连接数量获取的阈值为（例如为10）。当第一服务连接模式的连接数量（例如为7）没有到达距离阈值的预设范围（例如为8）时，则不通过分布式动态调节长连接服务方式进行启动及关闭的策略管理，换言之，第一服务连接模式的连接数量尚有可加入可连线的其它电子设备的空间，因此不执行分布式动态调节长连接服务方式的策略管理。
49.在所述s4由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理后，所述方法包括：当所述多个服务连接模式的连接数量到达距离所述阈值的预设范围时，则通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；由所述网关服务端执行的所述策略管理为关闭先前的业务服务信息，并启动新的业务服务代码发送至所述业务服务端；s6：由所述业务服务端将所述新的业务服务代码发送至所述consul集群端的服务注册中心进行注册。
50.在一实施例中，例如第二服务连接模式的连接数量获取的阈值为（例如为12）。当第二服务连接模式的连接数量（例如为10）到达距离阈值的预设范围（例如为10）时，则通过分布式动态调节长连接服务方式进行启动及关闭的策略管理，换言之，第二服务连接模式的连接数量没有可加入可连线其它电子设备的空间，因此执行分布式动态调节长连接服务方式的策略管理。网关服务端执行的更新的策略管理为关闭先前的业务服务信息后，并进一步启动新的业务服务代码，将新的业务服务代码发送至业务服务端。由业务服务端通过更新的策略管理将新的业务服务代码发送至consul集群端的服务注册中心进行注册。
51.请同时参阅图1、图2和图3，图1是本发明提供的一种基于物联网的分布式动态调节长连接服务的方法的又一方法流程图。s1-2、s5-6请参阅图1-2的实施例说明，在此不加赘述。
52.在s3由所述网关服务端通过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理中，所述方法包括：s31：所述用户端及/或所述网关服务端通过可配置方式修改关联于负载均衡的所述策略管理。
53.在一实施例中，本发明提出的负载均衡为提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。并且在服务连接模式的连接数量到达距离阈值的预设范围时，用户端及/或网关服务端通过可配置方式修改关联于负载均衡的策略管理，换言之，用户端可以自行设定于手动或自动方式修改关联于负载均衡的策略管理，网关服务端也可以自行设定于手动或自动方式修改关联于负载均衡的策略管理。
54.在s4由所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理中，所述方法包括：s41：由所述网关服务端通过所述业务服务端对所述多个服务连接模式的连接数量分别进行设置后，获取关联于所述多个服务连接模式的其中之任一的连接数量并传送至redis存储端进行存储。
55.在一实施例中，由网关服务端通过业务服务端对多个服务连接模式（例如第一、二服务连接模式）的连接数量分别进行设置（例如第一服务连接模式为7，第二服务连接模式为10）。获取关联于第一、二服务连接模式的其中之任一的连接数量后，将第一、二服务连接模式的连接数量分别传送至redis存储端进行存储。本发明基于nodejs完全自主的开发了一套物联网动态调度负载均衡的长链接服务，提高了服务的可用性，并且降低了服务器（可视为各服务端）采购的成本。
56.请同时参阅图1-2、图4-5，图4是本发明提供的一种基于物联网的分布式动态调节长连接服务的具体架构图，图5是本发明提供的一种基于物联网的分布式动态调节长连接服务的具体业务时序图。在图4中，用户端将用户端代码通过物联网发送至nginx服务端，nginx服务端通过长连接地址实现对网关服务端的代理转发配置，网关服务端根据代理转发配置经过consul集群端的服务注册中心经由（grps）对业务服务端进行关联于业务连接分配的策略管理。例如，grps (google remote procedure call): sap（system applications and products in data processing）系统rpc调用的原理其实很简单，有一些类似于三层构架的c/s (client/server，客户机/服务器)系统，第三方的客户程序通过接口调用sap内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。本发明基于nodejs grpc consul的动态长链接调度策略，利用nodejs轻型开发语言，弥补了nodejs在物联网方向的技术弱势，提高了服务的可用性，并且降低了服务器（可视为服务端）采购的成本。
57.在图5中，s1为用户端定义protoc协议，根据protoc协议生成对应的用户端代码，用户端将用户端代码通过物联网发送至nginx服务端后，用户端获取关联于nginx服务端的长连接地址；s2为由nginx服务端通过长连接地址实现对网关服务端的代理转发配置；s3由网关服务端根据代理转发配置经过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理；s4为由网关服务端结合对应的策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现网关服务端对多个服务连接模式的连接数量的策略管理；s5为由网关服务端通过其中的docker应用引擎的驱动代码根据多个服务连接模式的连接数量的阈值，以通过分布式动态调节长连接服务方式进行启动及关闭的策略管理；s6为由业务服务端将新的业务服务代码发送至consul集群端的服务注册中心进行注册。
58.请参阅图6，图6是本发明提供的一种基于物联网的分布式动态调节长连接服务的装置的示意性方块图。
59.一种基于物联网的分布式动态调节长连接服务的装置，所述装置600包括：定义模块610，所述定义模块610用于对用户端定义protoc协议，根据所述protoc协议生成对应的用户端代码，所述用户端将所述用户端代码通过物联网发送至nginx服务
端后，所述用户端获取关联于所述nginx服务端的长连接地址；处理模块620，所述处理模块620用于对所述nginx服务端通过所述长连接地址实现对网关服务端的代理转发配置；计算模块630，所述计算模块630对所述网关服务端根据所述代理转发配置经过所述通过consul集群端的服务注册中心对业务服务端进行关联于业务连接分配的策略管理；调节模块640，所述调节模块640对所述网关服务端结合对应的所述策略管理来通过分布式动态调节长连接服务方式分配多个服务连接模式，以实现所述网关服务端对所述多个服务连接模式的连接数量的所述策略管理。
60.在一实施例中，所述装置600还包括：驱动模块650，所述驱动模块650用于对所述网关服务端通过其中的docker应用引擎的驱动代码根据所述多个服务连接模式的连接数量的阈值，以通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；其中，当所述多个服务连接模式的连接数量没有到达距离所述阈值的预设范围时，则不通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理。
61.在一实施例中，所述装置600还包括：预设模块660，所述预设模块660用于当所述多个服务连接模式的连接数量到达距离所述阈值的预设范围时，通过所述分布式动态调节长连接服务方式进行启动及关闭的所述策略管理；所述网关服务端执行的所述策略管理为关闭先前的业务服务信息，并启动新的业务服务代码发送至所述业务服务端；所述业务服务端将所述新的业务服务代码发送至所述consul集群端的服务注册中心进行注册。
62.在一实施例中，所述装置600还包括：所述修改模块670，所述修改模块670用于对所述用户端及/或所述网关服务端通过可配置方式修改关联于负载均衡的所述策略管理。
63.在一实施例中，所述装置600还包括：存储模块680，所述存储模块680用于对所述网关服务端通过所述业务服务端对所述多个服务连接模式的连接数量分别进行设置后，获取关联于所述多个服务连接模式的其中之任一的连接数量并传送至redis存储端进行存储。其中，定义模块610、处理模块620、计算模块630、调节模块640、驱动模块650、预设模块660、所述修改模块670和存储模块680彼此电性连接，且可通过适配的功能电路及/或软件来实现。
64.为使本发明实施例的目的、技术方案和优点更加清楚，上面结合本发明实施例中的附图，对本发明实施例中的技术方案进行了清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
65.因此，以上对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。