WebSocket 集群解决方案
时间：2021-11-15 14:30:59
[导读]- 问题起因 -最近做项目时遇到了需要多用户之间通信的问题，涉及到了WebSocket握手请求，以及集群中WebSocketSession共享的问题。期间我经过了几天的研究，总结出了几个实现分布式WebSocket集群的办法，从zuul到springcloudgateway...
- 问题起因 -最近做项目时遇到了需要多用户之间通信的问题，涉及到了WebSocket握手请求，以及集群中WebSocket Session共享的问题。
期间我经过了几天的研究，总结出了几个实现分布式WebSocket集群的办法，从zuul到spring cloud gateway的不同尝试，总结出了这篇文章，希望能帮助到某些人，并且能一起分享这方面的想法与研究。以下是我的场景描述
- 资源：4台服务器。其中只有一台服务器具备ssl认证域名，一台redis mysql服务器，两台应用服务器（集群）
- 应用发布限制条件：由于场景需要，应用场所需要ssl认证的域名才能发布。因此ssl认证的域名服务器用来当api网关，负责https请求与wss（安全认证的ws）连接。俗称https卸载，用户请求https域名服务器（eg：https://oiscircle.com/xxx），但真实访问到的是http ip地址的形式。只要网关配置高，能handle多个应用
- 需求：用户登录应用，需要与服务器建立wss连接，不同角色之间可以单发消息，也可以群发消息
- 集群中的应用服务类型：每个集群实例都负责http无状态请求服务与ws长连接服务
- 系统架构图 -
- Eureka 服务发现与注册
- Redis Session共享
- Redis 消息订阅
- Spring Boot
- Zuul 网关
- Spring Cloud Gateway 网关
- Spring WebSocket 处理长连接
- Ribbon 负载均衡
- Netty 多协议NIO网络通信框架
- Consistent Hash 一致性哈希算法
- 技术可行性分析 -下面我将描述session特性，以及根据这些特性列举出n个解决分布式架构中处理ws请求的集群方案
WebSocketSession与HttpSession在Spring所集成的WebSocket里面，每个ws连接都有一个对应的session：WebSocketSession，在Spring WebSocket中，我们建立ws连接之后可以通过类似这样的方式进行与客户端的通信:
protected void handleTextMessage(WebSocketSession session, TextMessage message) {
System.out.println("服务器接收到的消息： " message );
//send message to client
session.sendMessage(new TextMessage("message"));
}
那么问题来了：ws的session无法序列化到redis，因此在集群中，我们无法将所有WebSocketSession都缓存到redis进行session共享。每台服务器都有各自的session。于此相反的是HttpSession，redis可以支持httpsession共享，但是目前没有websocket session共享的方案，因此走redis websocket session共享这条路是行不通的。有的人可能会想：我可不可以将sessin关键信息缓存到redis，集群中的服务器从redis拿取session关键信息然后重新构建websocket session...我只想说这种方法如果有人能试出来，请告诉我一声...以上便是websocket session与http session共享的区别，总的来说就是http session共享已经有解决方案了，而且很简单，只要引入相关依赖：spring-session-data-redis和spring-boot-starter-redis，大家可以从网上找个demo玩一下就知道怎么做了。而websocket session共享的方案由于websocket底层实现的方式，我们无法做到真正的websocket session共享。- 解决方案的演变 -Netty与Spring WebSocket
刚开始的时候，我尝试着用netty实现了websocket服务端的搭建。在netty里面，并没有websocket session这样的概念，与其类似的是channel，每一个客户端连接都代表一个channel。前端的ws请求通过netty监听的端口，走websocket协议进行ws握手连接之后，通过一些列的handler（责链模式）进行消息处理。与websocket session类似地，服务端在连接建立后有一个channel，我们可以通过channel进行与客户端的通信。
/**
* TODO 根据服务器传进来的id，分配到不同的group
*/
private static final ChannelGroup GROUP = new DefaultChannelGroup(ImmediateEventExecutor.INSTANCE);
@Override
protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) throws Exception {
//retain增加引用计数，防止接下来的调用引用失效
System.out.println("服务器接收到来自 " ctx.channel().id() " 的消息： " msg.text());
//将消息发送给group里面的所有channel，也就是发送消息给客户端
GROUP.writeAndFlush(msg.retain());
}
那么，服务端用netty还是用spring websocket？以下我将从几个方面列举这两种实现方式的优缺点。- 使用 netty 实现 websocket -
玩过netty的人都知道netty是的线程模型是nio模型，并发量非常高，spring5之前的网络线程模型是servlet实现的，而servlet不是nio模型，所以在spring5之后，spring的底层网络实现采用了netty。如果我们单独使用netty来开发websocket服务端，速度快是绝对的，但是可能会遇到下列问题：
- 与系统的其他应用集成不方便，在rpc调用的时候，无法享受springcloud里feign服务调用的便利性
- 业务逻辑可能要重复实现
- 使用netty可能需要重复造轮子
- 怎么连接上服务注册中心，也是一件麻烦的事情
- restful服务与ws服务需要分开实现，如果在netty上实现restful服务，有多麻烦可想而知，用spring一站式restful开发相信很多人都习惯了。
- 使用 spring websocket 实现 ws 服务 -spring websocket已经被springboot很好地集成了，所以在springboot上开发ws服务非常方便，做法非常简单第一步：添加依赖
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-websocketartifactId>
dependency>
第二步：添加配置类@Configuration
public class WebSocketConfig implements WebSocketConfigurer {
@Override
public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
registry.addHandler(myHandler(), "/")
.setAllowedOrigins("*");
}
@Bean
public WebSocketHandler myHandler() {
return new MessageHandler();
}
}
第三步：实现消息监听类@Component
@SuppressWarnings("unchecked")
public class MessageHandler extends TextWebSocketHandler {
private List clients = new ArrayList<>();
@Override
public void afterConnectionEstablished(WebSocketSession session) {
clients.add(session);
System.out.println("uri :" session.getUri());
System.out.println("连接建立: " session.getId());
System.out.println("current seesion: " clients.size());
}
@Override
public void afterConnectionClosed(WebSocketSession session, CloseStatus status) {
clients.remove(session);
System.out.println("断开连接: " session.getId());
}
@Override
protected void handleTextMessage(WebSocketSession session, TextMessage message) {
String payload = message.getPayload();
Map map = JSONObject.parseObject(payload, HashMap.class);
System.out.println("接受到的数据" map);
clients.forEach(s -> {
try {
System.out.println("发送消息给: " session.getId());
s.sendMessage(new TextMessage("服务器返回收到的信息," payload));
} catch (Exception e) {
e.printStackTrace();
}
});
}
}
从这个demo中，使用spring websocket实现ws服务的便利性大家可想而知了。为了能更好地向spring cloud大家族看齐，我最终采用了spring websocket实现ws服务。因此我的应用服务架构是这样子的：一个应用既负责restful服务，也负责ws服务。没有将ws服务模块拆分是因为拆分出去要使用feign来进行服务调用。第一本人比较懒惰，第二拆分与不拆分相差在多了一层服务间的io调用，所以就没有这么做了。- 从zuul开始技术转型 -要实现websocket集群，我们必不可免地得从zuul转型到spring cloud gateway。原因如下：zuul1.0版本不支持websocket转发，zuul 2.0开始支持websocket，zuul2.0几个月前开源了，但是2.0版本没有被spring boot集成，而且文档不健全。因此转型是必须的，同时转型也很容易实现。在gateway中，为了实现ssl认证和动态路由负载均衡，yml文件中以下的某些配置是必须的，在这里提前避免大家采坑
server:
port: 443
ssl:
enabled: true
key-store: classpath:xxx.jks
key-store-password: xxxx
key-store-type: JKS
key-alias: alias
spring:
application:
name: api-gateway
cloud:
gateway:
httpclient:
ssl:
handshake-timeout-millis: 10000
close-notify-flush-timeout-millis: 3000
close-notify-read-timeout-millis: 0
useInsecureTrustManager: true
discovery:
locator:
enabled: true
lower-case-service-id: true
routes:
- id: dc
uri: lb://dc
predicates:
- Path=/dc/**
- id: wecheck
uri: lb://wecheck
predicates:
- Path=/wecheck/**
如果要愉快地玩https卸载，我们还需要配置一个filter，否则请求网关时会出现错误not an SSL/TLS record@Component
public class HttpsToHttpFilter implements GlobalFilter, Ordered {
private static final int HTTPS_TO_HTTP_FILTER_ORDER = 10099;
@Override
public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
URI originalUri = exchange.getRequest().getURI();
ServerHttpRequest request = exchange.getRequest();
ServerHttpRequest.Builder mutate = request.mutate();
String forwardedUri = request.getURI().toString();
if (forwardedUri != null 
下载文档
