一个注解,优雅的实现 WebSocket 集群!
程序员的成长之路
共 5733字，需浏览 12分钟
·
2023-08-31 09:12
程序员的成长之路互联网/程序员/技术/资料共享 关注
阅读本文大概需要 8 分钟。
来自：blog.csdn.net/m0_64360721/article/details/125597943
介绍
WebSocket大家应该是再熟悉不过了，如果是单体应用确实不会有什么问题，但是当我们的项目使用微服务架构时，就可能会存在问题比如服务A有两个实例A1和A2，前端的WebSocket客户端C通过网关的负载均衡连到了A1，这个时候当A2触发消息发送的逻辑，需要将某个消息发送给所有的客户端时，C就接受不到消息这个时候我们很快就能想到一种最简单的解决方案，就是把A2的消息转发给A1，A1再把消息发送给C，这样C就能收到A2发送的消息了
基于这个思路，我实现了一个库，一个配置注解搞定一切
- 传送门：https://github.com/Linyuzai/concept/wiki/Concept-WebSocket-LoadBalance
用法
接下来让我们看看这个库的用法 首先我们需要在启动类上添加一个注解@EnableWebSocketLoadBalanceConcept@EnableWebSocketLoadBalanceConcept
@EnableDiscoveryClient
@SpringBootApplication
public class AServiceApplication {
public static void main(String[] args) {
SpringApplication.run(AServiceApplication.class, args);
}
}
@RestController
@RequestMapping("/ws")
public class WsController {
@Autowired
private WebSocketLoadBalanceConcept concept;
@RequestMapping("/send")
public void send(@RequestParam String msg) {
concept.send(msg);
}
}
抽象思路
其实我之前有专门针对WebSocket实现过类似功能的模块，只是当时的一些场景都是基于项目定死的，所以相对来说实现比较简单，但是过于定制化不好扩展有一天在和我的一个前同事聊天的过程中得知，他们在考虑让设备和服务直连，并且服务要部署成多实例，设备和服务直连无非就是通过TCP这种长连接来实现，可以使用缓存来保存连接和服务地址的映射关系来实现点对点转发的功能需求❞听到这里，是不是感觉似曾相识？当时就有一道光穿过我的脑瓜子，真相只有一个！这不就和WebSocket在集群模式下的问题一样么于是我从原来针对WebSocket的思考，变成了对各种长连接的思考，最终我将这个问题抽象成了：长连接的集群方案而不管是WebSocket还是TCP都是长连接的一种具体实现所以我们可以抽象一个顶级接口Connection，然后实现WebSocketConnection或者是TCPConnection其实从抽象的角度来说不仅仅是长连接，短连接也在我们的抽象范围之内，只不过类似HTTP等协议并不存在上述的问题，但是并不妨碍你实现一个HTTPConnection用于转发消息，所以大家不要被先入为主的思维束缚住了转发思路
之前讲到，这个库的主要思路就是将消息转发给其他的服务实例来达到一个单播或广播的效果所以消息转发的设计就非常重要了首先消息转发需要凭借一些支持数据交互的技术手段比如HTTP，MQ，TCP，WebSocket说到这里。。。大家是不是。。。你TM原来自己就能搞定啊（掀桌）长连接不就是用来交互数据的吗，所以完全可以自给自足啊于是就有一个精妙的想法在我脑子里形成：如果每个服务实例都把自己作为一个客户端，连接到其他服务上呢？-
WebSocket的场景下，我们将当前服务实例作为一个WebSocket客户端去连接其他服务实例的WebSocket服务端
-
TCP的场景下，我们将当前服务实例作为一个TCP的客户端去连接其他服务实例的TCP服务端
连接流程
让我们来看看互相建立连接是怎么设计的
我定义了一个ConnectionSubscriber的接口，大家可以理解为我们的服务实例要去订阅监听其他服务发送的消息同时提供了默认实现，就是基于自身的协议进行连接和消息的发送当然也能够灵活的支持其他方式，只需要自定义一个ConnectionSubscriber就可以了，如果使用MQ的方式就可以实现一个MQConnectionSubscriber或者使用HTTP就可以实现一个HTTPConnectionSubscriber只不过使用自身的协议就可以不用依赖其他的库或是中间件了，当然如果你对消息的丢失率有比较严格的要求也可以使用MQ作为消息转发的中介，而以我之前参与过的项目来说，一般普通的WebSocket场景基本上还是能忍受一定的丢失率的
获取服务实例信息
那么我们怎么知道要去连接哪些实例呢我定义了一个ConnectionServerManager的接口用来管理服务信息当然我们完全可以自己实现一个，比如通过配置文件来配置服务实例信息不过我们有更方便的方式，那就是依赖Spring Cloud的服务发现组件了，不管是Eureka还是Nacos还是其他的注册中心相当于都支持了，这就是抽象的魅力啊我们可以通过DiscoveryClient#getInstances(Registration.getServiceId())来获得所有的实例，排除掉自身就是需要连接的服务实例了当我们的服务实例连接上其他的服务实例之后，发送一个自身实例信息的消息过去，其他的服务实例接收到对应的消息之后反过来连接我们的服务实例，保证一定的连接及时性，这样双方的连接就搭建起来了，可以互相转发消息了同时我还添加了心跳检测和自动重连，当一段时间没有收到心跳回复后就会断开连接，并且每隔一段时间就会重新查询一遍实例信息，如果发现存在某个服务实例没有对应的连接，就会重新进行连接，这样就能在某些偶尔网络不好的情况下有一定的容错到目前为止，我们基本的框架已经建立了，当我们启动服务之后，服务间就会自动建立连接❞
连接区分和管理
基于上述的思路，我们肯定需要区分真实的客户端和用来转发的客户端于是我就把这些连接做了一个分类
然后对于这些连接进行一个统一的管理
通过连接工厂ConnectionFactory我们可以将任意的连接适配成Connection对象，并实现各种连接间的消息转发每个连接都会配置一个MessageEncoder和MessageDecoder用于消息的编码和解码，而且不同类别的连接对应的编码器和解码器肯定是不一样的，比如转发的消息和发给真实客户端的消息很大程度上都是有区别的，所以额外定义了一个MessageCodecAdapter用来适配不同类型的编解码器，也能让大家在自定义时方便管理
消息发送
现在当我们发送某条消息之后，消息就会被转发到其他的服务实例，所有的客户端就都能收到了不对啊，在有些情况下我们不想让所有客户端都收到啊，能不能我们想让谁收到就让谁收到啊真麻烦，来，我把所有的连接都给你，你自己选吧连接选择
我们需要在消息发送时确定发送给哪些连接
于是我就定义了一个连接选择器ConnectionSelector每次要发送消息的时候，我都会匹配一个连接选择器，然后通过选择器来获得需要发送消息的连接，而我们可以通过自定义连接选择器来实现我们消息的精准发送这里其实就是我为什么会取名WebSocketLoadBalanceConcept的原因，为什么要叫LoadBalance呢Ribbon通过IRule来选择一个Server我通过ConnectionSelector来选择一个Connection集合是不是有异曲同工之妙继续来说自定义选择器准备工作：
-
我们的Connection有一个metadata字段用于存放自定义属性
-
我们的Message有一个headers字段用于存放消息头
结束
最后请允许我发表一点对于抽象的拙见抽象其实就和 “道生一，一生二，二生三，三生万物” 一样，根据你的顶级接口（也就是核心功能）不断的向外展开，你的顶级接口就是道（狭义的来讲）以这个库为例，ConnectionLoadBalanceConcept就是这个库的道，他的核心功能就是发送消息，至于怎么发，发给谁，不确定，像是一个混沌的状态那么什么是一，二，三呢，我们发送消息需要载体于是就有了Connection和Message，我们需要对Connection进行管理于是就有了ConnectionRepository， 我们需要转发消息于是就有了ConnectionSubscriber等等而万物就像是具体的实现，是能落实的，基于Spring Cloud服务发现的连接管理器DiscoveryConnectionServerManager，基于路径的连接选择器PathSelector，基于Reactive的WebSocket连接ReactiveWebSocketConnection就像是你创造的世界，不断的衍生出各种各样的规则，这些规则相辅相成，让你的世界平稳的运行当然你的世界也有可能存在bug，手动狗头。 <END> 推荐阅读：
为什么 List 原生排序比 stream() 流效率更高？
互联网初中高级大厂面试题(9个G)
内容包含Java基础、JavaWeb、MySQL性能优化、JVM、锁、百万并发、消息队列、高性能缓存、反射、Spring全家桶原理、微服务、Zookeeper......等技术栈！
⬇戳阅读原文领取！ 朕已阅 
评论