当前位置:网站首页>WebSocket 分布式集群怎麼搞?

WebSocket 分布式集群怎麼搞?

2021-11-25 17:56:44 Java技術棧

作者:邱城銓
來源:https://segmentfault.com/a/1190000017307713

問題起因

最近做項目時遇到了需要多用戶之間通信的問題,涉及到了WebSocket握手請求,以及集群中WebSocket Session共享的問題。

期間我經過了幾天的研究,總結出了幾個實現分布式WebSocket集群的辦法,從zuul到spring cloud gateway的不同嘗試,總結出了這篇文章,希望能幫助到某些人,並且能一起分享這方面的想法與研究。

以下是我的場景描述

  • 資源:4臺服務器。其中只有一臺服務器具備ssl認證域名,一臺redis+mysql服務器,兩臺應用服務器(集群)
  • 應用發布限制條件:由於場景需要,應用場所需要ssl認證的域名才能發布。因此ssl認證的域名服務器用來當api網關,負責https請求與wss(安全認證的ws)連接。俗稱https卸載,用戶請求https域名服務器,但真實訪問到的是http+ip地址的形式。只要網關配置高,能handle多個應用
  • 需求:用戶登錄應用,需要與服務器建立wss連接,不同角色之間可以單發消息,也可以群發消息
  • 集群中的應用服務類型:每個集群實例都負責http無狀態請求服務與ws長連接服務

系統架構圖

在我的實現裏,每個應用服務器都負責http and ws請求,其實也可以將ws請求建立的聊天模型單獨成立為一個模塊。從分布式的角度來看,這兩種實現類型差不多,但從實現方便性來說,一個應用服務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-redisspring-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服務端,速度快是絕對的,但是可能會遇到下列問題:

  1. 與系統的其他應用集成不方便,在rpc調用的時候,無法享受springcloud裏feign服務調用的便利性
  2. 業務邏輯可能要重複實現
  3. 使用netty可能需要重複造輪子
  4. 怎麼連接上服務注册中心,也是一件麻煩的事情
  5. restful服務與ws服務需要分開實現,如果在netty上實現restful服務,有多麻煩可想而知,用spring一站式restful開發相信很多人都習慣了。

使用spring websocket實現ws服務

spring websocket已經被springboot很好地集成了,所以在springboot上開發ws服務非常方便,做法非常簡單。

Spring Boot 基礎就不介紹了,推薦下這個實戰教程: https://github.com/javastacks/spring-boot-best-practice

第一步:添加依賴

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-websocket</artifactId>
</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<WebSocketSession> 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<String, String> 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技術轉型到spring cloud gateway

要實現websocket集群,我們必不可免地得從zuul轉型到spring cloud gateway。原因如下:

zuul1.0版本不支持websocket轉發,zuul 2.0開始支持websocket,zuul2.0幾個月前開源了,但是2.0版本沒有被spring boot集成,而且文檔不健全。因此轉型是必須的,同時轉型也很容易實現。

在gateway中,為了實現ssl認證和動態路由負載均衡,yml文件中以下的某些配置是必須的,在這裏提前避免大家采坑。

Spring Boot 基礎就不介紹了,推薦下這個實戰教程: https://github.com/javastacks/spring-boot-best-practice

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<Void> 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 && forwardedUri.startsWith("https")) {
          try {
              URI mutatedUri = new URI("http",
                      originalUri.getUserInfo(),
                      originalUri.getHost(),
                      originalUri.getPort(),
                      originalUri.getPath(),
                      originalUri.getQuery(),
                      originalUri.getFragment());
              mutate.uri(mutatedUri);
          } catch (Exception e) {
              throw new IllegalStateException(e.getMessage(), e);
          }
      }
      ServerHttpRequest build = mutate.build();
      ServerWebExchange webExchange = exchange.mutate().request(build).build();
      return chain.filter(webExchange);
  }

  @Override
  public int getOrder() {
      return HTTPS_TO_HTTP_FILTER_ORDER;
  }
}

這樣子我們就可以使用gateway來卸載https請求了,到目前為止,我們的基本框架已經搭建完畢,網關既可以轉發https請求,也可以轉發wss請求。接下來就是用戶多對多之間session互通的通訊解决方案了。接下來,我將根據方案的優雅性,從最不優雅的方案開始講起。

session廣播

這是最簡單的websocket集群通訊解决方案。場景如下:

教師A想要群發消息給他的學生們

  • 教師的消息請求發給網關,內容包含{我是教師A,我想把xxx消息發送我的學生們}
  • 網關接收到消息,獲取集群所有ip地址,逐個調用教師的請求
  • 集群中的每臺服務器獲取請求,根據教師A的信息查找本地有沒有與學生關聯的session,有則調用sendMessage方法,沒有則忽略請求

session廣播實現很簡單,但是有一個致命缺陷:計算力浪費現象,當服務器沒有消息接收者session的時候,相當於浪費了一次循環遍曆的計算力,該方案在並發需求不高的情况下可以優先考慮,實現很容易。

spring cloud中獲取服務集群中每臺服務器信息的方法如下

@Resource
private EurekaClient eurekaClient;

Application app = eurekaClient.getApplication("service-name");
//instanceInfo包括了一臺服務器ip,port等消息
InstanceInfo instanceInfo = app.getInstances().get(0);
System.out.println("ip address: " + instanceInfo.getIPAddr());

服務器需要維護關系映射錶,將用戶的id與session做映射,session建立時在映射錶中添加映射關系,session斷開後要删除映射錶內關聯關系

一致性哈希算法實現(本文的要點)

這種方法是本人認為最優雅的實現方案,理解這種方案需要一定的時間,如果你耐心看下去,相信你一定會有所收獲。再强調一次,不了解一致性哈希算法的同學請先看這裏,現先假設哈希環是順時針查找的。

首先,想要將一致性哈希算法的思想應用到我們的websocket集群,我們需要解决以下新問題:

  • 集群節點DOWN,會影響到哈希環映射到狀態是DOWN的節點。
  • 集群節點UP,會影響到舊key映射不到對應的節點。
  • 哈希環讀寫共享。

在集群中,總會出現服務UP/DOWN的問題。

針對節點DOWN的問題分析如下:

一個服務器DOWN的時候,其擁有的websocket session會自動關閉連接,並且前端會收到通知。此時會影響到哈希環的映射錯誤。我們只需要當監聽到服務器DOWN的時候,删除哈希環上面對應的實際結點和虛結點,避免讓網關轉發到狀態是DOWN的服務器上。

實現方法:在eureka治理中心監聽集群服務DOWN事件,並及時更新哈希環。

針對節點UP的問題分析如下:

現假設集群中有服務 CacheB上線了,該服務器的ip地址剛好被映射到key1和 cacheA之間。那麼key1對應的用戶每次要發消息時都跑去 CacheB發送消息,結果明顯是發送不了消息,因為 CacheB沒有key1對應的session。

此時我們有兩種解决方案。

方案A簡單,動作大:

eureka監聽到節點UP事件之後,根據現有集群信息,更新哈希環。並且斷開所有session連接,讓客戶端重新連接,此時客戶端會連接到更新後的哈希環節點,以此避免消息無法送達的情况。

方案B複雜,動作小:

我們先看看沒有虛擬節點的情况,假設 CacheC和 CacheA之間上線了服務器 CacheB。所有映射在 CacheC到 CacheB的用戶發消息時都會去 CacheB裏面找session發消息。也就是說 CacheB一但上線,便會影響到 CacheC到 CacheB之間的用戶發送消息。所以我們只需要將 CacheA斷開 CacheC到 CacheB的用戶所對應的session,讓客戶端重連。

接下來是有虛擬節點的情况,假設淺色的節點是虛擬節點。我們用長括號來代錶某段區域映射的結果屬於某個 Cache。首先是C節點未上線的情况。圖大家應該都懂吧,所有B的虛擬節點都會指向真實的B節點,所以所有B節點逆時針那一部分都會映射到B(因為我們規定哈希環順時針查找)。

接下來是C節點上線的情况,可以看到某些區域被C占領了。

由以上情况我們可以知道:節點上線,會有許多對應虛擬節點也同時上線,因此我們需要將多段範圍key對應的session斷開連接(上圖紅色的部分)。具體算法有點複雜,實現的方式因人而异,大家可以嘗試一下自己實現算法。

哈希環應該放在哪裏?

  • gateway本地創建並維護哈希環。當ws請求進來的時候,本地獲取哈希環並獲取映射服務器信息,轉發ws請求。這種方法看上去不錯,但實際上是不太可取的,回想一下上面服務器DOWN的時候只能通過eureka監聽,那麼eureka監聽到DOWN事件之後,需要通過io來通知gateway删除對應節點嗎?顯然太麻煩了,將eureka的職責分散到gateway,不建議這麼做。
  • eureka創建,並放到redis共享讀寫。這個方案可行,當eureka監聽到服務DOWN的時候,修改哈希環並推送到redis上。為了請求響應時間盡量地短,我們不可以讓gateway每次轉發ws請求的時候都去redis取一次哈希環。哈希環修改的概率的確很低,gateway只需要應用redis的消息訂閱模式,訂閱哈希環修改事件便可以解决此問題。

至此我們的spring websocket集群已經搭建的差不多了,最重要的地方還是一致性哈希算法。現在有最後一個技術瓶頸,網關如何根據ws請求轉發到指定的集群服務器上?

答案在負載均衡。spring cloud gateway或zuul都默認集成了ribbon作為負載均衡,我們只需要根據建立ws請求時客戶端發來的user id,重寫ribbon負載均衡算法,根據user id進行hash,並在哈希環上尋找ip,並將ws請求轉發到該ip便完事了。流程如下圖所示:

接下來用戶溝通的時候,只需要根據id進行hash,在哈希環上獲取對應ip,便可以知道與該用戶建立ws連接時的session存在哪臺服務器上了!

spring cloud Finchley.RELEASE 版本中ribbon未完善的地方

題主在實際操作的時候發現了ribbon兩個不完善的地方......

  • 根據網上找的方法,繼承AbstractLoadBalancerRule重寫負載均衡策略之後,多個不同應用的請求變得混亂。假如eureka上有兩個service A和B,重寫負載均衡策略之後,請求A或B的服務,最終只會映射到其中一個服務上。非常奇怪!可能spring cloud gateway官網需要給出一個正確的重寫負載均衡策略的demo。
  • 一致性哈希算法需要一個key,類似user id,根據key進行hash之後在哈希環上搜索並返回ip。但是ribbon沒有完善choose函數的key參數,直接寫死了default!

難道這樣子我們就沒有辦法了嗎?其實還有一個可行並且暫時可替代的辦法!

如下圖所示,客戶端發送一個普通的http請求(包含id參數)給網關,網關根據id進行hash,在哈希環中尋找ip地址,將ip地址返回給客戶端,客戶端再根據該ip地址進行ws請求。

由於ribbon未完善key的處理,我們暫時無法在ribbon上實現一致性哈希算法。只能間接地通過客戶端發起兩次請求(一次http,一次ws)的方式來實現一致性哈希。希望不久之後ribbon能更新這個缺陷!讓我們的websocket集群實現得更優雅一點。

後記

以上便是我這幾天探索的結果。期間遇到了許多問題,並逐一解决難題,列出兩個websocket集群解决方案。第一個是session廣播,第二個是一致性哈希。

這兩種方案針對不同場景各有優缺點,本文並未用到ActiveMQ,Karfa等消息隊列實現消息推送,只是想通過自己的想法,不依靠消息隊列來簡單地實現多用戶之間的長連接通訊。希望能為大家提供一條不同於尋常的思路。

近期熱文推薦:

1.1,000+ 道 Java面試題及答案整理(2021最新版)

2.別在再滿屏的 if/ else 了,試試策略模式,真香!!

3.臥槽!Java 中的 xx ≠ null 是什麼新語法?

4.Spring Boot 2.6 正式發布,一大波新特性。。

5.《Java開發手册(嵩山版)》最新發布,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!

版权声明
本文为[Java技術棧]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/11/20211125175543510f.html

随机推荐