一种分布式WebSocket接入系统及方法与流程

一种分布式websocket接入系统及方法
技术领域
1.本技术涉及网络通信领域，特别是涉及一种分布式websocket接入系统及方法。


背景技术：

2.websocket是一种通信协议，其使得客户端和服务器之间的数据交换变得更加简单高效，且允许服务端主动向客户端推送数据。基于上述优点，websocket在实时通信场合应用越来越多，例如：app或浏览器的消息推送，微信小游戏的实时互动等。
3.在业务场景下，通常服务端都需连接大量（如100万）的客户端；在相关技术中，针对大规模客户端连接，采用常规的分布式websocket接入方法存在如下缺陷：1：服务端程序需要尽可能的高效（即单个进程算力消耗应尽量小），同时，还需对服务端操作系统的网络层进行优化，经优化后，能够支持大量连接的服务端需要较大的内存（例如100万的连接数量，需要至少20g内存空间作为支撑）；2：由于客户端的请求需通过负载均衡设备进行处理及转发，当客户端连接数量较多时，将对负载均衡设备造成很大运行压力，对负载均衡设备的使用寿命和系统的整体稳定性均产生不利影响；3：相比较于传统http协议，服务端针对websocket协议进行开发的过程较为复杂，开发难度更大，需要消耗更多的的时间和人力成本。
4.目前针对现有websocket接入系统中的上述问题，尚未提出有效的解决方案。


技术实现要素：

5.本技术实施例提供了一种分布式websocket接入方法系统、方法、计算机设备和存储介质，以至少解决websocket通信方式中服务端可连接客户端数量受限的问题。
6.第一方面，本技术实施例提供了一种分布式websocket接入系统，所述系统包括：代理接入器和消息服务器，其中；所述代理接入器用于，分别与所述消息服务器和客户端进行双向通信，其中，系统中分布式部署多个代理接入器，且每个代理接入器连接多个客户端；所述消息服务器用于，分别与所述代理接入器和业务服务器进行双向通信，其中，各个代理接入器，分别通过各自的一条websocket连接通道，与所述消息服务器连接，所述websocket连接通道基于websocket tunnel协议建立，所述websocket tunnel协议中，通过特定封装结构，将代理接入器转发的多个客户端数据，集合在一条websocket连接通道上进行传输。
7.在其中一些实施例中，所述特定封装结构中，将多个客户端发送的消息数据进行聚合，并重新定义所述消息数据的消息体结构，其中，所述消息体结构的文件头添加有消息类型和客户id。
8.在其中一些实施例中，所述消息服务器中维护有客户端列表，所述客户端列表中包括多组客户端信息记录，所述客户端信息记录包括：互相匹配的客户id、客户端地址和代
理接入器id。
9.在其中一些实施例中，在向所述客户端推送消息数据的情况下：所述业务服务器用于，向所述消息服务器发送消息数据，其中，所述消息数据中包括客户id和消息内容；所述消息服务器用于，根据所述客户id在所述客户端列表中查找，确定所述消息数据对应的代理接入器id，以及，将所述消息数据以所述websocket tunnel协议的特定封装结构处理后，根据所述代理接入器id，通过所述websocket连接通道，将其转发对应的代理接入器；所述代理接入器用于，根据所述消息数据中的消息类型，判断所述消息数据的处理方式，并根据所述客户id确定对应的客户端地址，以及根据所述客户端地址，将所述消息数据转发至对应的客户端。
10.在其中一些实施例中，所述websocket tunnel协议中传输的消息数据是websocket消息，所述websocket tunnel协议中消息数据为json格式。
11.在其中一些实施例中，所述消息服务器还用于：在接收到所述代理接入器转发的消息数据之后，将所述消息数据由websocket协议格式转换成http协议格式，并将所述http协议格式的消息数据转发至所述业务服务器。
12.在其中一些实施例中，所述系统还包括自定义部署模块，所述自定义部署模块用于，根据业务需求，自定义部署所述消息服务器和所述代理接入器，包括：根据业务服务器的不同业务事项，针对性部署每个业务服务器的专用消息服务器；根据资源配置需求，将所述消息服务器部署在不同的机房或云平台；根据运营商线路，部署所述代理接入器和配置所述代理接入器的数量，以及，在多个所述消息服务器之间，共用所述代理接入器。
13.第二方面，本技术实施例提供了一种分布式websocket接入方法，所述方法包括：代理接入器，分别与消息服务器和客户端进行双向通信，其中，系统中分布式部署多个代理接入器，且每个代理接入器连接多个客户端；消息服务器，分别与所述代理接入器和业务服务器进行双向通信，其中，各个代理接入器，分别通过各自的一条websocket连接通道，与所述消息服务器连接，其中，所述websocket连接通道基于websocket tunnel协议建立，所述websocket tunnel协议中，通过特定封装结构，将所述代理接入器转发的多个客户端数据，集合在一条websocket连接通道上进行传输。
14.第三方面，本技术实施例提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的方法。
15.第四方面，本技术实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的方法。
16.相比于现有技术，本技术实施例提供的分布式websocket接入系统至少具备如下有益效果：
1．分布式部署多个代理接入器，可支持水平扩展的特点，首先可允许接入更多数量的客户端；进一步的，基于特定的websocket tunnel协议，可将多个客户端的数据，通过一条线路发送至消息服务器进而发送至业务服务器，对于业务服务器而言，其只需处理较小数量的连接线路，即可实现与大量客户端通信，从而在服务端硬件资源不变的情况下，提升了客户端连接上限；2．由于服务器的连接线路数量降低，负载均衡设备的处理量也随之降低，因此，可降低负载均衡设备的运行压力，提升其使用寿命；3．通过消息服务器将客户端发送的消息数据，由websocket协议转换为http协议，无需在服务端针对websocket协议进行独立开发配置，降低了服务端开发难度和时间及人力成本；4．用户可以根据自身需求，结合业务实际情况灵活部署消息服务器，例如：将配置较高的消息服务器专用于其主营业务，将配置相对较差的消息服务器专用于辅助业务，或者将不同消息服务器部署在不同的机房或者云平台等，从而将负载合理分配、实现资源最大化利用，进而提升服务的稳定性。
附图说明
17.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：图1是现有技术中分布式websocket通信方式的示意图；图2是根据本技术实施例的一种分布式websocket接入系统的架构图；图3是根据本技术实施例的一种websocket tunnel协议的封装结构的示意图；图4是根据本技术实施例的部分消息结构的示意图；图5是根据本技术实施例的代理接入器的工作示意图；图6是根据本技术实施例的消息服务器的工作示意图；图7是根据本技术实施例的一种客户端列表的示意图；图8是根据本技术实施例的一种业务端推送数据到目标客户端的流程示意图；图9是根据本技术实施例的一种自定义部署消息服务器的示意图；图10是根据本技术实施例的电子设备的内部结构示意图。
具体实施方式
18.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。基于本技术提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
19.显而易见地，下面描述中的附图仅仅是本技术的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本技术应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本技术公开的内容相关的本领域的普通技术人员而言，在本技术揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应
当理解为本技术公开的内容不充分。
20.在本技术中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本技术所描述的实施例在不冲突的情况下，可以与其它实施例相结合。
21.除非另作定义，本技术所涉及的技术术语或者科学术语应当为本技术所属技术领域内具有一般技能的人士所理解的通常意义。本技术所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本技术所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块（单元）的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本技术所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本技术所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本技术所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。
22.图1是现有技术中分布式websocket通信方式的示意图，如图1所示，无论是云服务还是idc（机房）的服务部署，一般都会存在一个7层网关/负载均衡设备（可利用专用硬件设备或者nginx、haproxy等软件实现），用于统一接受用户请求，再将请求发送到对应的服务节点。
23.在服务端内存等配置固定的情况下，由于算力有限，可连接客户端数量是有限的，同时，数量庞大的客户端会对负载均衡设备造成很大的运行压力，以支持100万客户端为例，负载均衡设备需要维护200万的websocket连接。
24.针对上述问题，本案发明人提出了一种改进方案，图2是根据本技术实施例的一种分布式websocket接入系统的架构图，如图2所示，该系统主要包括：代理接入器和消息服务器，其中；代理接入器（websocket agent）用于，分别与消息服务器（websocket message server）和客户端进行双向通信，其中，系统中分布式部署多个代理接入器，且每个代理接入器连接多个客户端；其中，代理接入器负责将客户端发送的消息转发给消息服务器，同时把消息服务器发来的消息转发给客户端。当然，代理接入器同时也负责将把客户端的一些事件（例如客户端连接、客户端断开等状态信息）发送至消息服务器，以及与客户端的连接认证及心跳检测。本技术中，由于代理接入器只用于客户端的维护和数据转发，不参与具体的业务处理，因此，其算力消耗较小，可选择性能要求相对较低的环境进行部署。
25.另外，代理接入器与客户端之间通过传统websocket协议传输数据，且一个代理接入器可以同时连接多个客户端。该代理接入器通常部署在网络的边缘侧，且各个客户端所连接的代理接入器应就近分配。
26.进一步的，在初始情况下，系统中可部署一定数量的代理接入器，随着业务发展，若需进一步提升客户端接入数量，可基于利用其支持水平扩展的特点，随时在系统中增加部署新的代理接入器。
27.还需说明的是，本实施例中，代理接入器的分布式部署还可以带来如下有益效果：1.可以针对客户所在网络针对性的进行部署，例如：针对电信用户就把代理接入器部署到电信网络，针对联通用户将代理接入器部署到联通网络。从而提高各个客户端的消息传输速度。
28.2.可以针对客户数量分布调整部署。比如电信用户多，就可以在电信网络部署多个（例如8个）代理接入器，而联通用户少，就可以在联通网络部署较少个（例如1个）代理接入器。
29.3.因为每个代理接入器只负责一部分客户端的连接，因此，当某个代理接入器出现故障的时候，只会影响到一小部分的客户端，而不会对所有客户端造成影响，从而限制了故障的影响面，提升了系统整体的稳定性。
30.消息服务器（websocket message server）用于，分别与代理接入器和业务服务器进行双向通信，其中，各个代理接入器，分别通过各自的一条websocket连接通道，与消息服务器连接，websocket连接通道基于websocket tunnel协议建立，websocket tunnel协议中，通过特定封装结构，将代理接入器转发的多个客户端数据，集合在一条websocket连接通道上进行传输。
31.需强调的是，本实施例中，一个代理接入器与一个消息服务器之间只有一条连接通道（线路），该连接通道基于本案发明人自行设计的websocket tunnel协议建立。
32.通过该websocket tunnel协议，代理接入器可将与其连接的多个客户端的消息数据，聚合在一个线路中发送至消息服务器。具体的：该websocket tunnel协议中采用特定的封装结构，图3是根据本技术实施例的一种websocket tunnel协议的封装结构的示意图，如图3所示：各个客户端的消息数据被结合为一个消息文件，各个消息消息数据被重新定义消息结构，具体的，在每个消息数据的数据内容之前，添加消息类型和客户id，其中，消息类型用于指示该消息数据将被执行何种处理，客户id为用户的身份识别id。另外，消息采用使用广泛的json格式传输，不需要专门设计消息编码和解码。
33.如图4所示，图4是根据本技术实施例的部分消息结构的示意图。
34.进一步的，由于websocket tunnel协议的底层仍然基于websocket，在websocket tunnel协议中传输的数据也仍然是websocket消息；因此，无需任何特殊设备，使用现有的网络基础设施即可实现通信，通过现有的网关设备，即可在代理接入器和消息服务器之间建立上述websocket连接通道。
35.相比较于传统基于websocket协议的通信方式，本系统通过分布式部署的代理接入器接入多个客户端，并通过websocket tunnel协议将多个客户端的消息数据汇集到一条连接线路上转发给消息服务器，进而转发至业务服务器。由于业务服务器连接线路仅为与代理接入器的连接线路，因此服务端所需处理的连接线路大大降低，从而提升客户端的接入量，同时，也并不干扰与客户端的正常通信。
36.进一步的，消息服务器还用于协议转换，即将代理接入器发送的websocket tunnel协议数据转换为http协议数据之后，再将其转发至服务端。
37.或者，将服务端发送的http协议数据，转换为websocket tunnel协议数据之后，再将其发送至代理接入器。
38.需要说明的是，相比较于传统http协议，服务端针对websocket协议进行开发的过程较为复杂，且开发难度更大，需要消耗更多的的时间和人力成本。本实施例中，由消息服务器中将消息数据转换为传统的http协议，从而在服务端，无需进行额外开发，从而降低时间和人力成本，也可无缝对接现有的基于http协议的服务端。
39.在其中一些实施例中，图5是根据本技术实施例的代理接入器的工作示意图，如图5所示：代理接入器用于接入客户端，以及分别与消息服务器和客户端进行双向通信，即将客户端发送的数据转发至消息服务器，以及，将消息服务器发送的数据转发至客户端。
40.进一步的，代理接入器还负责与客户端和消息服务器的身份认证及心跳检测。由于如何建立连接、如何进行身份认证以及如何心跳检测，均不涉及本技术的核心发明点，且是本领域技术人员的的常规技术手段，故在本实施例不再展开说明。
41.在其中一些实施例中，图6是根据本技术实施例的消息服务器的工作示意图，如图6所示：消息服务器，分别与代理接入器和业务服务器进行双向通信。即将代理接入器发送的数据转发至业务服务器，或者，将代理服务器发送的数据转发至代理接入器。除此之外，还负责websocket协议与http协议的相互转换。进一步的，进行身份认证和心跳检测的具体技术细节此处也不再赘述。
42.在其中一些实施例中，图7是根据本技术实施例的一种客户端列表的示意图，消息服务器中维护有客户端列表，客户端列表中包括多组客户端信息记录，客户端信息记录包括：客户id、客户端地址和客户端连接的代理接入器的id。
43.其中，在上述列表中，客户id(client_id)需8个字节，代理接入器编号（agent_id）需2个字节，客户端地址（remote_addr）需6个字节，时间（time）需8个字节。因此，一条客户端记录只占24字节的内存，当100万个客户端连接时，只需要24m内存即可。
44.另外，由图7可以看出，有两条记录的客户id都为“34567”，是因为该系统支持同一个客户在多个设备上同时连接。
45.在其中一些实施例中，图8是根据本技术实施例的一种业务端推送数据到目标客户端的流程示意图，如图8所示，首先，业务服务器向消息服务器发送http消息数据，例如：“post/23456｛
‘
message’.
‘
你有2条未读消息’｝”，其中，消息数据中包括客户id和消息内容；其次，消息服务器，根据客户id，在本地保存的客户端列表中查找客户端信息，进而确定到与该消息数据匹配的代理接入器id和客户端地址；进一步的，消息服务器将消息数据以websocket tunnel协议特定封装结构处理后，根据代理接入器id，通过上述websocket连接通道，将其转发至对应的代理接入器，其中，封装之后的消息数据包括：消息类型、客户id和消息内容；最后，代理接入器根据消息数据中封装的的消息类型，判断消息数据的处理方式，
（例如：消息类型“type”的指代字符“0
×
05”，则判断该消息数据需要被发送至客户端）。并根据客户id“23456”确定对应的客户端地址，以及将消息数据“你有2条未读消息”转发至对应的客户端。
46.在其中一些实施例中，在客户端向业务服务器发送数据时，数据首先被代理接入器获取，其次代理控制器将多个客户端的消息数据以固定格式封装，并通过基于websocket tunnel协议建立的websocket连接通道，将其发送至消息服务器。最后，经由消息服务器将各个客户端的消息数据转换为http协议数据之后，发送至业务服务器。
47.在其中一些实施例中，本技术方案在实际部署中，还具备具备灵活多变的特点，即可以根据业务情况和自身需求灵活制定多种部署方案。本系统通过自定义部署模块，根据人工指令自定义部署消息服务器和代理接入器；例如：在一个具备多业务线的公司，可以针对不同的业务部署多个专用的消息服务器，同时使多个消息服务器共用代理接入器，具体的，用户可以结合自身需求，根据业务实际情况灵活部署消息服务器，例如：将硬件配置较高的消息服务器专用于其主营业务，将配置相对较差的消息服务器专用于辅助业务。
48.图9是根据本技术实施例的一种自定义部署消息服务器的示意图，如图9所示，游戏业务服务器由专用的游戏消息服务器负责通信，社交业务服务器由专用的社交消息服务器负责通信。
49.由于消息服务器是所有客户信息的中转和协议转换组件，利用上述自定义部署方式，将拥有更高配置的节点用于算力需求更大、场景更为复杂的业务，将配置相对较差的消息服务器节点应用于较为简单的业务。从而针对特定的业务需求，针对性地部署专用的消息服务器，进而合理均衡分配系统负载，提升整体稳定性。
50.进一步的，针对某些场景特别复杂，消息处理压力特别大的业务场景，还可以针对该业务设置多个专用消息服务器以分担运行压力，从而进一步提升整体稳定性。
51.另外，还需说明的是，代理接入器一般部署在网络边缘，其尽量靠近客户端。例如，针对各个运营商的线路分别部署，从而提高客户连接速度。同时，由于代理接入器要支持大量客户端，且其数量较多，考虑到成本，代理接入器可以设设计为支持各条业务线（即各个业务服务器）共用，而无需针对每条业务线各自部署一遍。
52.在其中一些实施例中，本技术实施例还提供了一种分布式websocket接入方法，该方法包括：代理接入器，分别与消息服务器和客户端进行双向通信，其中，系统中分布式部署多个代理接入器，且每个代理接入器连接多个客户端；消息服务器，分别与代理接入器和业务服务器，进行双向通信，且各个代理接入器，分别通过各自的一条websocket连接通道，与消息服务器连接，其中，websocket连接通道基于websocket tunnel协议建立，websocket tunnel协议中，通过特定封装结构，将代理接入器转发的多个客户端数据，集合在一条websocket连接通道上进行传输。
53.在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、
内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种分布式websocket接入方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
54.在一个实施例中，图10是根据本技术实施例的电子设备的内部结构示意图，如图10所示，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图10所示。该电子设备包括通过内部总线连接的处理器、网络接口、内存储器和非易失性存储器，其中，该非易失性存储器存储有操作系统、计算机程序和数据库。处理器用于提供计算和控制能力，网络接口用于与外部的终端通过网络连接通信，内存储器用于为操作系统和计算机程序的运行提供环境，计算机程序被处理器执行时以实现一种分布式websocket接入方法，数据库用于存储数据。
55.本领域技术人员可以理解，图10中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
56.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（rom）、可编程rom（prom）、电可编程rom（eprom）、电可擦除可编程rom（eeprom）或闪存。易失性存储器可包括随机存取存储器（ram）或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram（sram）、动态ram（dram）、同步dram（sdram）、双数据率sdram（ddrsdram）、增强型sdram（esdram）、同步链路（synchlink） dram（sldram）、存储器总线（rambus）直接ram（rdram）、直接存储器总线动态ram（drdram）、以及存储器总线动态ram（rdram）等。
57.以上实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。