之前有寫一篇文章介紹自己的練習專案 gusher，沒想到過沒多久，竟然朝著要cluster方向前進，所以理論當然它就進化了，稍微紀錄一下這兩年來的變化。

首先，我們先來看看下面這張架構變化圖，左邊為舊的gusher，右邊為gusher.cluster

gusher vs gusher.cluster

為了因應連線上越來越大的需求，在gusher推出後，就開始設計如何能夠簡易的橫向擴充機制，由上圖可以看出，原本的機制必須要由gusher，承受全部流量，改成右邊gusher.cluster的狀態後，透過redis當作平行擴充的一個轉接，gusher.cluster，主要分成兩個mode:

  1. slave mode: 只提供一個功能，客戶端websocket連線，每一個slave mode server，各自管理自己的連線，接收到來自redis推播來的訊息，再透過演算法把訊息個別送到該訊息的訂閱客戶端。
  2. master mode: 則是接收其他服務想要對客端傳送訊息，把訊息推入redis。

目前這個架構下，還是無法避免單點故障(SPOF)，只要redis死掉，服務會全部死掉，未來的改版會朝這個方向去改進去。

在這個版本gusher.cluster實現了channel機制，客戶端可以依照自己權限，訂閱自己想要聽的channel，沒訂閱到的channel，客戶端並不會收到。與舊版本gusher的差異在於，舊版本一條連線建立後，所有需求都必須要在這條線上傳送，如果有新增業務邏輯，除非多加連線，否則客端的js需要實作很多特殊邏輯去繞過。在這點上節省了非常多不必要的開銷。

當然原本的gusher對客戶端完全單是單向溝通，客戶端無法反向傳訊息回server，在gusher.cluster改善了這一點，新增的remote的命令，做到可以跟server雙向同步溝通。以達到更多的應用。

下一篇會介紹有關於remote的進階應用。