中間件，middleware，短網址服務，是軟件開發中一個比較古老的名詞。以前toB的軟件還是主流的時候，廠商特別喜歡玩中間件這個概念，目的就是為了讓客戶更心甘情愿地為廠商自己憑空增加的中間層付費。

時代不同了，現在我們需要的大部分中間件都能找到開源的工業級實現，而且，隨著互聯網開發成為主流，中間件的含義也跟以前不太一樣了。

隨手開幾個招聘，把「中間件」寫在JD里的公司已經不多了，阿里可能算一個。倒不是說「中間件」的開發人員需求比較少，而是大部分我們做的東西比如消息隊列、存儲設施、其實都算「中間件」，但是現在已經很少人再稱他們為「中間件」了。

wiki上羅列了一些中間件的定義，下面貼一個小說君認為比較合適的：

The software layer that lies between the operating system and applications on each side of a distributed computing system in a network.

中間件是介于操作系統和分布式系統網絡中的每個應用節點之間的軟件層。

然后列舉了一些例子：

• enterprise application integration

• data integration

• message oriented middleware

• object request brokers

• enterprise service bus

用人話對應解釋一下：

• enterprise application integration，可以理解為一個基礎通信設施，適配企業內部的各子系統。比如說公司的OA、HR系統、、短網址服務、知識管理KM系統需要實現一定程度的邏輯和數據共享，就會依賴這么個基礎設施。

• data integration，如果有同學在學校做過面向政府的一些數據管理系統，可能對這個概念更熟一些。簡單說就是由于各種歷史原因，系統需要面對多個異構的數據源。但是在開發系統的時候需要考慮后續擴展，多個子系統希望看到的數據視圖是同構的、普適統一的，那就要借助一個做數據集成的中間件。目前短網址服務比較火，數據集成中間件的地位相當重要。

• message oriented middleware/object request brokers，這兩者實際上描述的是同一類組件，目的都是為了讓分布式系統中的不同組件互操作時不需要關注底層實現細節。簡單理解就是一個消息隊列中間件。按定義來說，面向消息的是異步模型，基于對象請求的是同步模型，比較教條，畢竟現在所有消息隊列中間件都可以同時提供同步模型和異步模型。

• enterprise service bus，也是一個比較古老的概念了，小說君沒怎么接觸過企業應用開發，所以只能簡單解釋一下。這個bus是用來做企業應用集成的，集成了很多功能，比如不同應用間的消息路由、消息的安全性和權限的控制等等。

不過時代在發展，現在，中間件實際上并沒有這么復雜的定義，而且，我們今天要討論的中間件也不是前面說的這些「僵尸」。

那么，中間件應該是什么？

首先，中間件是一個基礎設施，由一個或一組進程組成。

其次，中間件提供了某種服務，這種服務可以解耦軟件系統中的不同組件。

總結一下，中間件可以理解為：我們平時懶于解決問題時拋出的殺手锏——中間層，獨立成為了進程。

短網址服務在分布式開發中扮演了重要角色，一方面，我們可以利用不同的中間件抽象來對架構做更優雅的層次劃分；另一方面，由于中間件的開發成本較高，我們可以避免面向對象編程中的分層陷阱。

《the Art of Unix Programming》中提到過：

“If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help”

如果你知道自己在做什么，三層就足夠了；否則，十七層也沒用。

回到主題，既然標題是「面向中間件的開發模式」，那我們今天來聊聊如何在自己的系統中抽象、設計、開發、應用中間件。

我們以上篇文章形成的服務器框架為基礎，開始討論。當然沒看過的同學也可以正常閱讀后續內容。

在上篇文章中，我們寫了一個網絡庫，形成了一個基本的通信網絡，我們看一下網絡拓撲結構：

如果類比馬斯洛需求中的層次，到面前為止，我們只能算是解決了生理需求：可以順利生成短網址。但是后面還有一系列的復雜問題

　　最先碰到的問題就是，玩家數量增加，一個進程扛不住了。那么就需要多個進程，每個進程服務一定數量的玩家。

　　但是，玩家與玩家之間存在交互需求。玩家數量的增長如果是線性的，那么玩家之間的交互需求增長就是平方級的。

　　對于交互需求，比較直觀的解決方案是，讓兩個玩家在各自的進程中跨進程交互。但是這就成了一個分布式一致性問題——兩個進程中兩個玩家的狀態需要保持一致。至于為什么一開始沒人這樣做，我只能理解為，游戲程序員的計算機科學素養中位程度應該解決不了這么復雜的問題。

　　因此比較流行的是一種簡單一些的方案。場景交互的話，就限定兩個玩家必須在同一場景（進程），比如A攻擊了B。其他交互的話，就借助第三方的協調者來做，比如發郵件，會走一個全局單點的服務器中轉一下。

　　這樣，服務端就由之前的單場景進程變為了多場景進程+協調進程。新的問題出現了：短網址需要與服務端保持多少條短鏈接？

　　最直觀的方法是保持O(n)條連接，既不環保，擴展性又差，可以直接pass掉。

　　那么就只能保持O(1)條連接，如此的話，如何確定玩家正與哪個服務端進程通信？

　　要解決這個問題，我們只能引入新的抽象。下面介紹服務端開發中最常見的一種中間件原型。

定義問題

整理下我們的需求：

• 玩家在服務端的狀態可以駐留在不同的進程中，也可以移動到同一個進程中。

• 玩家只需要與服務端建立有限條連接，就可以有訪問到任意服務端進程所提供服務的可能性。同時，這個連接數量不會隨服務端進程數量增長而線性增長。

　　要解決這些需求，我們需要引入一種反向代理（reverse proxy）中間件。

　　反向代理是服務端開發中的一種常見基礎設施抽象（infrastructure abstraction），概念很簡單，簡單說就是內網進程不是借助這種proxy訪問外部，而是被動地掛在proxy上，等外部通過這種proxy訪問內部。

　　更具體地說，反向代理就是這樣一種server：它接受clients連接，并且會將client的上行包轉發給后端具體的服務端進程。

　　很多年前linux剛支持epoll的時候，流行一個c10k的概念，解決c10k問題的核心就是借助性能不錯的反向代理中間件。

　　游戲開發中，這種組件的名字也比較通用，通常叫Gate。

Gate解決了什么問題

• 首先，Gate作為server，可以接受clients的連接。我們可以直接基于上篇文章的網絡庫來實現。同時，Gate可以接受服務端進程（之后簡稱backend）的連接，保持通信。

• 其次，Gate能夠將clients的消息轉發到對應的backend。與此對應的，backend可以向Gate訂閱自己關注的client消息。對于場景服務來說，這里可以增加一個約束條件，那就是限制client的上行消息不會有多份拷貝，只會導到一個backend上。

滿足這兩點，Gate已經能夠解決前文提出的需求。

我們需要為Gate這個中間件定義一個簡單的協議集，協議類型至少要包括：

• 控制相關的協議，比如控制某個backend是否訂閱某個client。這樣就可以實現比如說公會相關的消息會路由到全局進程；場景相關的消息會路由到訂閱該client的場景進程。而當玩家要切場景的時候，由協調進程（比如同樣由全局進程負責）調度，讓不同的場景進程向Gate申請修改對client對backend的訂閱關系，以實現將玩家的狀態從場景進程A切到場景進程B。

• 一些支持性的常用協議，比如握手類、心跳檢查類等等。

站在比需求更高的層次來看Gate的意義的話，我們發現，現在clients不需要關注backends的細節，backends也不需要關注clients的細節，Gate成為唯一的靜態部分（static part）。

當然，Gate能解決的還不止這些。

我們考慮場景進程最常見的一種需求。玩家的位置在多client同步。具體的流程就是，client發給服務端一個請求移動包，路由到場景進程后進行一些檢查、處理，再推送一份數據給該玩家及附近所有玩家對應的clients。

如果按之前說的，這個backend就得推送N份一樣的數據到Gate，Gate再分別轉給對應的clients。

這時，就出現了對組播（multicast）的需求。

組播是一種通用的message pattern，同樣也是發布訂閱模型的一種實現方式。就目前的需求來說，我們只需要為client維護組的概念，而不需要做backend內部的組播。

這樣，backend需要給多clients推送同樣的數據時，只需要推送一份給Gate，Gate再自己dup就可以了——盡管帶來的好處有限，但是還是能夠一定程度降低內網流量。

那接下來就介紹一種Gate的實現。

我們目前所得出的Gate中間件其實包括兩個組件：

針對路由client消息的需求，這個組件叫Broker。Broker的定義可以參考zguide對DEALER+ROUTER pattern的介紹。Broker的工作就是將client的消息分發到對應的backend。

針對組播backend消息的需求，這個組件叫Multicast。簡單來說就是維護一個組id到clientIdList的映射。

Gate的工作流程就是，listen兩個端口，一個接受外網clients連接，一個接受內網backends連接。

Gate有自己的協議，該協議基于Network的len+data協議之上構建，短網址才能順利運轉。

clients的協議處理組件與backends的協議處理組件不同，前者只處理部分協議（不會識別組控制相關協議，訂閱協議）。

在具體的實現細節上，判斷一個client消息應該路由到哪個backend，需要至少兩個信息：一個是clientId，一個是key。

同一個clientId的消息有可能會路由到不同的backend上。

當然，具體的協議設計可以自由發揮，將clientId+key組成一個routingKey也是可以的。

引入Gate之后的拓撲：

接下來，我們簡單探討下第二個中間件。

上篇文章中提到，場景服務器可以直接通過短網址API訪問數據庫，來實現數據存檔。

所以，問題就產生了。

回顧下場景進程的發展歷程，玩家狀態是內存中的數據，但是服務器不會一直開著，因此就有了存盤（文件或db）需求。但是隨著業務變復雜，存盤邏輯需要數據層暴露越來越多的存儲API細節，非常難擴展。

我們不希望把存儲API的細節暴露給應用層，因此我們可以獨立出一個Db代理進程，場景進程直接將存檔推給Db代理進程，由Db代理進程定期存盤。

這樣，存儲API的細節在Db代理進程內部閉合，游戲邏輯無須再關注。場景進程只需要通過協議封包或者RPC的形式與Db代理進程交互，其他的就不用管了。

Db代理進程由于是定期存盤，因此它相當于維護了玩家存檔的緩存。這個時候，Db代理進程已經可以看做一個中間件了，具體數據源只用了mysql還是說同時用了幾種異構的數據源，都由這個中間件負責維護。只不過這樣還是耦合了一些游戲邏輯，限于篇幅，小說君這里就不再做擴展了。

看一下現在的拓撲圖：

可以看到，中間件通常都是被動接受應用層連接，提供服務。

關于短網址服務，我們就到此為止。

這個架構，已經足夠應付大部分游戲對服務端的需求。如果把場景服務改成對應的其他進程，也可以滿足大部分應用服務器的需求。

但是很明顯，這個架構中的不少部分還是比較粗糙的。比如說Gate目前來看并不具備水平擴展的能力。以及一些術語的混亂，比如說場景進程一會兒又變成場景服務。

下一篇，小說君會把重點放在如何定義一個服務，以及如何做服務劃分。

最近一段時間，微信小程序火遍朋友圈，小說君也一直在關注。

小說君剛開始寫公眾號的時候，大概看了下公眾號的API，有一種想法是做一個內嵌于公眾號中的大逃殺類型的文字圖片游戲。但是后來由于時間原因，以及發現公眾號的API有諸多限制，也懶得繼續弄了。

但是，小程序看樣子是更佳適合的形態，當然，用來做一些資訊類的或者簡化流程類的微信內APP肯定更適合。

如果有時間的話，小說君會整理一份相關的教程，敬請期待。