再談 websocket 論架構設計

（點選上方公眾號，可快速關註）

來源：Lrwin ，

lrwinx.github.io/2017/07/09/再談websocket-論架構設計/

導語

本篇文章以websocket的原理和落地為核心，來敘述websocket的使用，以及相關應用場景。

websocket概述

http與websocket

如我們所瞭解，http連線為一次請求一次響應(request->response)，必須為同步呼叫方式。

而websocket為一次連線以後，會建立tcp連線，後續客戶端與伺服器互動為全雙工方式的互動方式，客戶端可以傳送訊息到服務端，服務端也可將訊息傳送給客戶端。

此圖來源於Websocket協議的學習、調研和實現,如有侵權問題，告知後，刪除。

根據上圖，我們大致可以瞭解到http與websocket之間的區別和不同。

為什麼要使用websocket

那麼瞭解http與websocket之間的不同以後，我們為什麼要使用websocket呢？ 他的應用場景是什麼呢？

我找到了一個比較符合websocket使用場景的描述

“The best fit for WebSocket is in web applications where the client and server need to exchange events at high frequency and with low latency.”

翻譯: 在客戶端與伺服器端互動的web應用中，websocket最適合在高頻率低延遲的場景下，進行事件的交換和處理

此段來源於spring websocket的官方檔案

http://docs.spring.io/spring/docs/5.0.0.M5/spring-framework-reference/html/websocket.html

瞭解以上知識後，我舉出幾個比較常見的場景:

1. 遊戲中的資料傳輸

2. 股票K線圖資料

3. 客服系統

根據如上所述，各個系統都來使用websocket不是更好嗎？

其實並不是，websocket建立連線之後，後邊互動都由tcp協議進行互動，故開發的複雜度會較高。當然websocket通訊，本身要考慮的事情要比HTTP協議的通訊考慮的更多.

所以如果不是有特殊要求(即 應用不是”高頻率低延遲”的要求),需要優先考慮HTTP協議是否可以滿足。

比如新聞系統，新聞的資料晚上10分鐘-30分鐘，是可以接受的，那麼就可以採用HTTP的方式進行輪詢(polling)操作呼叫REST介面。

當然有時我們建立了websocket通訊，並且希望透過HTTP提供的REST介面推送給某客戶端，此時需要考慮REST介面接受資料傳送給websocket中，進行廣播式的通訊方式。

至此，我已經講述了三種互動方式的使用場景:

1. websocket獨立使用場景

2. HTTP獨立使用場景

3. HTTP中轉websocket使用場景

相關技術概念

websocket

websocket為一次HTTP握手後，後續通訊為tcp協議的通訊方式。

當然，和HTTP一樣，websocket也有一些約定的通訊方式，http通訊方式為http開頭的方式,e.g. http://xxx.com/path ,websocket通訊方式則為ws開頭的方式,e.g. ws://xxx.com/path

SSL:

1. HTTP: https://xxx.com/path

2. WEBSOCKET: wss://xxx.com/path

此圖來源於WebSocket 教程,如有侵權問題，告知後，刪除。

SockJS

正如我們所知,websocket協議雖然已經被制定，當時還有很多版本的瀏覽器或瀏覽器廠商還沒有支援的很好。

所以,SockJS,可以理解為是websocket的一個備選方案。

那它如何規定備選方案的呢？

它大概支援這樣幾個方案:

1. Websockets

2. Streaming

3. Polling

當然，開啟並使用SockJS後，它會優先選用websocket協議作為傳輸協議，如果瀏覽器不支援websocket協議，則會在其他方案中，選擇一個較好的協議進行通訊。

看一下目前瀏覽器的支援情況:

此圖來源於github: sockjs-client

所以，如果使用SockJS進行通訊，它將在使用上保持一致，底層由它自己去選擇相應的協議。

可以認為SockJS是websocket通訊層上的上層協議。

底層對於開發者來說是透明的。

STOMP

STOMP 中文為: 面向訊息的簡單文字協議

websocket定義了兩種傳輸資訊型別: 文字資訊 和 二進位制資訊 ( text and binary ).

型別雖然被確定，但是他們的傳輸體是沒有規定的。

當然你可以自己來寫傳輸體，來規定傳輸內容。(當然，這樣的複雜度是很高的)

所以,需要用一種簡單的文字傳輸型別來規定傳輸內容，它可以作為通訊中的文字傳輸協議,即互動中的高階協議來定義互動資訊。

STOMP本身可以支援流型別的網路傳輸協議: websocket協議和tcp協議

它的格式為:

COMMAND

essay-header1:value1

essay-header2:value2

 

Body^@

  

 

SUBSCRIBE

id:sub-1

destination:/topic/price.stock.*

 

^@

 

 

 

SEND

destination:/queue/trade

content-type:application/json

content-length:44

 

{“action”:”BUY”,”ticker”:”MMM”,”shares”,44}^@

當然STOMP已經應用於很多訊息代理中，作為一個傳輸協議的規定，如:RabbitMQ, ActiveMQ

我們皆可以用STOMP和這類MQ進行訊息互動.

除了STOMP相關的代理外，實際上還提供了一個stomp.js,用於瀏覽器客戶端使用STOMP訊息協議傳輸的js庫。

讓我們很方便的使用stomp.js進行與STOMP協議相關的代理進行互動.

正如我們所知，如果websocket內容傳輸資訊使用STOMP來進行互動，websocket也很好的於訊息代理器進行互動(如:RabbitMQ, ActiveMQ)

這樣就很好的提供了訊息代理的整合方案。

總結，使用STOMP的優點如下:

1. 不需要自建一套自定義的訊息格式

2. 現有stomp.js客戶端(瀏覽器中使用)可以直接使用

3. 能路由資訊到指定訊息地點

4. 可以直接使用成熟的STOMP代理進行廣播 如:RabbitMQ, ActiveMQ

技術落地

後端技術方案選型

websocket服務端選型:spring websocket

支援SockJS,開啟SockJS後，可應對不同瀏覽器的通訊支援

支援STOMP傳輸協議，可無縫對接STOMP協議下的訊息代理器(如:RabbitMQ, ActiveMQ)

前端技術方案選型

前端選型: stomp.js,sockjs.js

後端開啟SOMP和SockJS支援後，前對應有對應的js庫進行支援.

所以選用此兩個庫.

總結

上述所用技術，是這樣的邏輯:

開啟socktJS:

如果有瀏覽器不支援websocket協議，可以在其他兩種協議中進行選擇，但是對於應用層來講，使用起來是一樣的。

這是為了支援瀏覽器不支援websocket協議的一種備選方案

使用STOMP:

使用STOMP進行互動，前端可以使用stomp.js類庫進行互動，訊息一STOMP協議格式進行傳輸，這樣就規定了訊息傳輸格式。

訊息進入後端以後，可以將訊息與實現STOMP格式的代理器進行整合。

這是為了訊息統一管理，進行機器擴容時，可進行負載均衡部署

使用spring websocket:

使用spring websocket,是因為他提供了STOMP的傳輸自協議的同時，還提供了StockJS的支援。

當然，除此之外，spring websocket還提供了許可權整合的功能，還有自帶天生與spring家族等相關框架進行無縫整合。

應用場景

應用背景

2016年，在公司與同事一起討論和開發了公司內部的客服系統，由於前端技能的不足，很多通訊方面的問題，無法親自除錯前端來解決問題。

因為公司技術架構體系以前後端分離為主，故前端無法協助後端除錯，後端無法協助前端除錯

在加上websocket為公司剛啟用的協議，瞭解的人不多，導致前後端除錯問題重重。

一年後的今天，我打算將前端重溫，自己來除錯一下前後端，來發掘一下之前聯調的問題.

當然，前端，我只是考慮stomp.js和sockt.js的使用。

程式碼階段設計

角色

客服

客戶

登入使用者狀態

上線

下線

分配策略

使用者登陸後，應該根據使用者角色進行分配

關係儲存策略

應該提供關係型儲存策略: 考慮記憶體式策略(可用於測試)，redis式策略

備註:優先應該考慮實現Inmemory策略，用於測試，讓關係儲存策略與儲存平臺無關

通訊層設計

歸類topic的廣播設計(通訊方式:1-n)

歸類queue的單點設計(通訊方式:1-1)

程式碼實現

角色

import org.springframework.security.core.GrantedAuthority;

import org.springframework.security.core.authority.SimpleGrantedAuthority;

import org.springframework.security.core.userdetails.User;

import java.util.Collection;

public enum Role {

  CUSTOMER_SERVICE,

  CUSTOMER;

 

 

  public static boolean isCustomer(User user) {

      Collection authorities = user.getAuthorities();

      SimpleGrantedAuthority customerGrantedAuthority = new SimpleGrantedAuthority(“ROLE_” + Role.CUSTOMER.name());

      return authorities.contains(customerGrantedAuthority);

  }

 

  public static boolean isCustomerService(User user) {

      Collection authorities = user.getAuthorities();

      SimpleGrantedAuthority customerServiceGrantedAuthority = new SimpleGrantedAuthority(“ROLE_” + Role.CUSTOMER_SERVICE.name());

      return authorities.contains(customerServiceGrantedAuthority);

  }

}

程式碼中User物件，為安全物件，即 spring中org.springframework.security.core.userdetails.User，為UserDetails的實現類。

User物件中，儲存了使用者授權後的很多基礎許可權資訊，和使用者資訊。

如下:

public interface UserDetails extends Serializable {

  Collection extends GrantedAuthority> getAuthorities();

 

  String getPassword();

 

  String getUsername();

 

  boolean isAccountNonExpired();

 

  boolean isAccountNonLocked();

 

  boolean isCredentialsNonExpired();

 

  boolean isEnabled();

}

方法 #isCustomer 和 #isCustomerService 用來判斷使用者當前是否是顧客或者是客服。

登入使用者狀態

public interface StatesManager {

 

    enum StatesManagerEnum{

        ON_LINE,

        OFF_LINE

    }

 

    void changeState(User user , StatesManagerEnum statesManagerEnum);

 

    StatesManagerEnum currentState(User user);

}

設計登入狀態時，應存在登入狀態管理相關的狀態管理器，此管理器只負責更改使用者狀態和獲取使用者狀態相關操作。

並不涉及其他關聯邏輯，這樣的程式碼劃分，更有助於面向介面程式設計的擴充套件性

分配策略

public interface DistributionUsers {

  void distribution(User user);

}

分配角色介面設計，只關註傳入的使用者，並不關註此使用者是客服或者使用者，具體需要如何去做，由具體的分配策略來決定。

關係儲存策略

public interface RelationHandler {

 

  void saveRelation(User customerService,User customer);

 

  List listCustomers(User customerService);

 

  void deleteRelation(User customerService,User customer);

 

  void saveCustomerService(User customerService);

 

  List listCustomerService();

 

  User getCustomerService(User customer);

 

  boolean exist(User user);

 

  User availableNextCustomerService();

 

}

關係儲存策略，亦是隻關註關係儲存相關，並不在乎於儲存到哪個儲存介質中。

實現類由Inmemory還是redis還是mysql,它並不專註。

但是，此處需要註意，對於這種關係儲存策略，開發測試時，並不涉及高可用，可將Inmemory先做出來用於測試。

開發功能同時，相關同事再來開發其他介質儲存的策略，效能測試以及UAT相關測試時，應切換為此介質儲存的策略再進行測試。

使用者綜合管理

對於不同功能的實現策略，由各個功能自己來實現，在使用上，我們僅僅根據介面程式設計即可。

所以，要將上述所有功能封裝成一個工具類進行使用，這就是所謂的 設計樣式: 門面樣式

@Component

public class UserManagerFacade {

    @Autowired

    private DistributionUsers distributionUsers;

    @Autowired

    private StatesManager statesManager;

    @Autowired

    private RelationHandler relationHandler;

 

 

    public void login(User user) {

        if (roleSemanticsMistiness(user)) {

            throw new SessionAuthenticationException(“角色語意不清晰”);

        }

 

        distributionUsers.distribution(user);

        statesManager.changeState(user, StatesManager.StatesManagerEnum.ON_LINE);

    }

    private boolean roleSemanticsMistiness(User user) {

        Collection authorities = user.getAuthorities();

 

        SimpleGrantedAuthority customerGrantedAuthority = new SimpleGrantedAuthority(“ROLE_”+Role.CUSTOMER.name());

        SimpleGrantedAuthority customerServiceGrantedAuthority = new SimpleGrantedAuthority(“ROLE_”+Role.CUSTOMER_SERVICE.name());

 

        if (authorities.contains(customerGrantedAuthority)

                && authorities.contains(customerServiceGrantedAuthority)) {

            return true;

        }

 

        return false;

    }

 

    public void logout(User user){

        statesManager.changeState(user, StatesManager.StatesManagerEnum.OFF_LINE);

    }

 

 

    public User getCustomerService(User user){

        return relationHandler.getCustomerService(user);

    }

 

    public List listCustomers(User user){

        return relationHandler.listCustomers(user);

    }

 

    public StatesManager.StatesManagerEnum getStates(User user){

        return statesManager.currentState(user);

    }

 

}

UserManagerFacade 中註入三個相關的功能介面:

@Autowired

private DistributionUsers distributionUsers;

@Autowired

private StatesManager statesManager;

@Autowired

private RelationHandler relationHandler;

可提供:

1. 登入(#login)

2. 登出(#logout)

3. 獲取對應客服(#getCustomerService)

4. 獲取對應使用者串列(#listCustomers)

5. 當前使用者登入狀態(#getStates)

這樣的設計，可保證對於使用者關係的管理都由UserManagerFacade來決定

其他內部的操作類，對於使用者來說，並不關心，對開發來講，不同功能的策略都是透明的。

通訊層設計 – 登入，授權

spring websocket雖然並沒有要求connect時，必須授權，因為連線以後，會分發給客戶端websocket的session id，來區分客戶端的不同。

但是對於大多數應用來講，登入授權以後，進行websocket連線是最合理的，我們可以進行許可權的分配，和許可權相關的管理。

我模擬例子中，使用的是spring security的Inmemory的相關配置:

public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

 

  @Override

  protected void configure(AuthenticationManagerBuilder auth) throws Exception {

      auth.inMemoryAuthentication().withUser(“admin”).password(“admin”).roles(Role.CUSTOMER_SERVICE.name());

      auth.inMemoryAuthentication().withUser(“admin1”).password(“admin”).roles(Role.CUSTOMER_SERVICE.name());

 

 

      auth.inMemoryAuthentication().withUser(“user”).password(“user”).roles(Role.CUSTOMER.name());

      auth.inMemoryAuthentication().withUser(“user1”).password(“user”).roles(Role.CUSTOMER.name());

      auth.inMemoryAuthentication().withUser(“user2”).password(“user”).roles(Role.CUSTOMER.name());

      auth.inMemoryAuthentication().withUser(“user3”).password(“user”).roles(Role.CUSTOMER.name());

  }

 

  @Override

  protected void configure(HttpSecurity http) throws Exception {

      http.csrf().disable()

              .formLogin()

              .and()

              .authorizeRequests()

              .anyRequest()

              .authenticated();

  }

}

相對較為簡單，建立2個客戶，4個普通使用者。

當認證管理器認證後，會將認證後的合法認證安全物件user(即 認證後的token)放入STOMP的essay-header中.

此例中，認證管理認證之後，認證的token為org.springframework.security.authentication.UsernamePasswordAuthenticationToken,

此token認證後，將放入websocket的essay-header中。（即 後邊會談到的安全物件 java.security.Principal)

通訊層設計 – websocket配置

@Order(Ordered.HIGHEST_PRECEDENCE + 99)

@Configuration

@EnableWebSocketMessageBroker

public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {

 

    @Override

    public void registerStompEndpoints(StompEndpointRegistry registry) {

        registry.addEndpoint(“/portfolio”).withSockJS();

    }

 

    @Override

    public void configureMessageBroker(MessageBrokerRegistry config) {

        config.setApplicationDestinationPrefixes(“/app”);

        config.enableSimpleBroker(“/topic”, “/queue”);

 

    }

}

此配置中，有幾點需進行講解：

其中端點”portfolio”,用於socktJs進行websocket連線時使用，只用於建立連線。

“/topic”, “/queue”,則為STOMP的語意約束，topic語意為1-n(廣播機制),queue語意為1-1(單點機制)

“app”,此為應用級別的對映終點字首，這樣說有些晦澀，一會看一下示例將會清晰很多。

通訊層設計 – 建立連線

用於連線spring websocket的端點為portfolio，它可用於連線，看一下具體實現: