服务器如何支持长连接,[Discuss] Nacos 支持长连接

Nacos 规划准备基于 gRPC 来替换现有的通信场景(Http + UDP)，以下是重点需要和社区讨论的项。请大家积极踊跃发表自己的看法。

Nacos 能够替换成长连接的两大前提

通信模型的匹配

现有的通信场景

新的通讯场景

Http 服务接口 服务接口 Request/Response

gRPC Request/Response

配置推送 Http Long Polling

gRPC Request/Stream

UDP 服务推送 Request/Response

gRPC Request/Stream

支持ssl 通讯

支持ssl 通讯

通信的数据格式能够匹配

基于 gRPC 的业务层俩进程之间是需要协调好一致的通信数据格式 ，然后在 proto 文件里面来描述。为了能够服务好多场景下的通信模型数据格式的一致性，就像 Http 的通信数据格式一样，不 care 上层业务通信的数据具体表现形式，只 care 通信时数据格式的表现能力。以下关注两方面来阐述基于 gRPC 之后的数据格式长啥样。

Request 数据格式

通信数据格式字段

数据类型

必要性

说明

RequestId

string

必要

标识当前的一次请求，方便于后续问题的排查

Action

string

必要

标识当前请求的具体行为，对标 Http 中的 URI 。

Headers

map

必要

动态可伸缩的消息头，对标 http 请求中的 header 。

Source

string

可选

标明消息的发送源，是哪一个节点发送的消息。

Params

map l 可选

动态可伸缩的参数传递，对标 http 请求中的 参数传递。

Method

string

可选

请求的 Method，对标 http 请求中的 method。

Payload

byte[]

必要

请求的消息内容体，对标 http 请求中的 请求内容体。

Response 数据格式

通信数据格式字段

数据类型

必要性

说明

ReponseId

string

必要

标识当前的一次 response，方便于后续问题的排查 。通常他的值是来源于 request id，标识当前这个 response 是针对那次 请求进行响应的。

Source

string

可选

标明消息的Response源，是哪一个节点响应的消息。

Action

string

必要

标识当前 Response 是对哪个 Action 进行响应的。

Headers

map

必要

动态可伸缩的消息头，对标 http 请求中的 header 。

Response Code

int l 必要

响应状态码，对标 http 响应中的响应码 。

Response Payload

byte[]

必要

响应的消息内容体，对标 http 响应中的内容体。

协议协商-通信的基础

长连接支持的过程中必然会出现客户端/服务端，服务端/服务端 版本支持的通信协议不一致的情况。比如说，此时客户端支持 Http，但是服务端升级到新版本，既支持 Http,有支持 gRPC。这个时候客户端服务端通信要协商好一致的通信协议。面对客户端/服务端通信协议不一致的场景，主要采取通信协议降级的处理方式。通信协议降级处理主要分为两种：服务端通信协议降级处理 和 客户端通信协议降级处理。

场景一：服务端版本高(既支持 Http+ UDP,有支持 gRPC),客户端版本低(支持 Http + UDP)。那这个时候经过客户端和服务端协议协商后，达成一致的通信协议是 Http + UDP。那么此时服务端对此客户端支持的通信协议就采用 Http +UDP，相对于新的通信协议，就降级了，这就是服务端通信协议降级处理。

注意: 服务端的通信协议降级处理是针对多个客户端而言的。因为有的客户端连接过来的是新版本，这个时候就没有服务端的通信协议降级处理，直接采用新的通信协议 gRPC 来处理；但是有的客户端连接过来的是低版本，那么这个时候就需要单独对这个客户端进行服务端通信协议降级处理了。

场景二：客户端版本高了(既支持 Http+ UDP,有支持 gRPC),服务端版本低(支持 Http + UDP)。那这个时候经过客户端和服务端协议协商后，达成一致的通信协议是 Http + UDP。那么此时客户端通信协议就采用 Http +UDP，相对于新的通信协议，就降级了，这就是客户端通信协议降级处理。

服务端推送(Naming+Config)的支持

服务端推送-Naming(注册中心)

服务端推送-Config(配置中心)

Http 接口的改造

Http 接口的改造，主要内容含两部分，分别是请求接口的数据和响应内容的处理。

Http/gRPC 请求 通信数据格式的映射

Http 请求

gRPC 请求

URL

Action

Headers

Headers

Params

Params

Body

Payload

/

其他字段按需指定

Http/gRPC 响应 通信数据格式的映射

Http 响应

gRPC 响应

Response Code

Response Code

Response Body

Response Payload

Response Headers

Response Headers

/

其他字段按需指定

也就是说改为 gRPC 长连接之后，原先设置 Http 请求/响应所携带的相关数据都有具体的协议格式来于此对应，与此同时，在此基础上还丰富了原有的通信协议(例如 RequestId，Source 等)。在不失扩展性的同时，还降低了切换时数据通信改造和学习的成本。

其他

上面抛出了一些关键项的改造思路，如果有改进的地方可以在下方积极的讨论。

同时还有一些没有考虑的点，如果您有更好的想法也欢迎在下方讨论。

下面是思考的 PPT。