簡介
這篇，我們討論一下傳統架構與 ioGame 架構的對比，會選擇性的抽出幾點來做對比，但不涵蓋全部，因爲對比得越多，傳統架構暴露的缺點也會越多。
傳統架構
前置說明：
在傳統架構設計中，遊戲對外服部分稱爲網關（或稱爲玩家網關）。爲了方便理解，這裏沿用了 ioGame 遊戲對外服的叫法。
傳統架構設計通常都是相互直連，從圖中可以看出，每個遊戲邏輯服都需要與其他的邏輯服建立連接。與其他遊戲邏輯服建立連接是爲了能夠相互通信。
由於筆墨有限，上圖中只畫出了三個遊戲邏輯服和一個遊戲對外服，此時的線條已經足夠凌亂了。由於傳統的架構服務器之間會相互連接，那麼【實際連接數=N*(N-1)】；爲了方便表達與計算，後續稱這個術語稱爲 【N*N 問題】 。
N * N 問題
可以看出，傳統架構會產生NN 問題，下面簡單說說 NN 帶來的其他問題。
在連接方面
- 假設我們有 1,000 個遊戲邏輯服，那麼光內部連接就有 1000*1000=1,000,000 個。你沒有看錯，是百萬的內部連接。
- 假設我們有 10,000 個遊戲邏輯服呢，此時大約有一億個內部連接。
在心跳消耗方面
邏輯服之間的心跳：爲了檢測連接是否存活，就需要心跳，心跳有發送心跳與響應心跳。那麼連接之間每次處理心跳的次數爲：心跳次數=2NN。
先不說其他的，光心跳就佔用了多少開銷了。如果有 10,000 個遊戲邏輯服，大約有一億個內部連接，這樣啥都沒幹，光每次心跳檢測就消耗了 2 億次（請求、響應）。
隨着遊戲對外服、遊戲邏輯服的增加，內部連接總數會以恐怖的數字增加。
依賴中間件方面
此外，你還需要藉助很多需要安裝的第三方中間件，如：Redis、MQ、ZooKeeper ...等，才能滿足整體架構的運作。只要引入了需要安裝的中間件，那麼你的架構或者說框架，基本上與輕量級無緣了；
很多開發者無法正確分辨一個架構或框架是否是輕量級的，甚至還見過以代碼量來劃分是否輕量級的；spring 代碼量比較多吧，這裏可以明確的告訴你，spring 是輕量級的框架。
或許你會說，spring-data 系列需要安裝 mysql、MongoDB、Redis 之類的，爲什麼還說 spring 是輕量級的；首先，spring-data 只是 spring 的一個子項目，其次，是你爲了滿足業務需要才引入的，而不是 spring 強行給你引入的。
一個架構、框架是不是真正的輕量級，取決於是否依賴了需要獨立安裝的中間件。
或許你會說，我不安裝這些中間件不就是輕量級的架構或框架了。老哥，你這麼說是沒毛病的，但隨着你的業務發展需要，安裝中間件是必然的，因爲傳統架構就是這麼設計的。
管理使用方面
你需要爲每個遊戲邏輯服都分配獨立的端口，這裏還是以 10,000 個遊戲邏輯服爲例，這樣就需要管理着上萬的端口。在這個數量的基礎上，每次有新的遊戲邏輯服上線，都需要從註冊中心得到各遊戲邏輯服的 ip:port，並與這些遊戲邏輯服建立連接。
如果使用的是雲服務器之類的，別忘了你還需要配置一下相關 port ，否則其他邏輯服連接不進來，別小看這一個環節，通常這些小地方最浪費開發者的時間。
開發成本
在分佈式開發體驗方面，大部分傳統架構是不支持同進程啓動多個遊戲邏輯服的。這會讓調試與排查問題變得非常困難，從而降低開發者的效率、增加工作量等；隨着你的業務增加，你的開發成本將越來超高。
在業務開發成本，由於傳統架構各自相互連接，越多越混亂，那麼業務開發的複雜度無形之中又上升了。
成本方面
在使用傳統架構時，在成本方面還需要關注，如：安裝中間件的成本、維護中間件的成本、學習中間件的成本、部署中間件的成本。
穩定性方面的考慮，安裝和使用的中間件越多，不穩定因素則越多；甚至你還得考慮團隊其他成員亂用中間件的因素。
優點
由於各服務器之間是相互直連的，那麼只需要一次傳輸就可以到達。
ioGame 架構
ioGame 架構除了具備傳統架構的優點外，還能避免傳統架構的所有缺點。
從圖中可以看出，架構由三部分組成：1.遊戲對外服、2.Broker（遊戲網關）、3.遊戲邏輯服；三者既可相互獨立，又可相互融合。
圖中每個部分各自使用了一個虛線框，並用一根長連接線條就能表示了，意思是虛線框內的每個實例都與另外的虛線框內的實例建立連接。請看下面這張圖，類似把多條線捆紮在一起了。
N * B
這裏的 N 指的是遊戲對外服和遊戲邏輯服，而 B 指的是 Broker（遊戲網關）。
在連接方面
- 假設我們有 1,000 個遊戲邏輯服，那麼內部連接的數量是 1000*1=1,000 個。你沒有看錯，只有一千個內部連接。
- 假設我們有 10,000 個遊戲邏輯服呢，此時的連接大約是一萬個內部連接。
Broker（遊戲網關）只負責轉發請求，全是 cpu 密集型的處理；所以，我們需要 Broker（遊戲網關）機器的數量並不會很多。
通過對比可以看出，無論我們如何計算，ioGame 架構的連接總數是遠遠少於傳統架構的。
在心跳消耗方面
由於 ioGame 架構沒有 N*N問題，所以在心跳開銷方面幾乎可以忽略不計。
依賴中間件方面
正如 ioGame 簡單介紹中所說的。在輕量級方面，ioGame 不依賴任何第三方中間件或數據庫就能支持集羣、分佈式，只需要 java 環境就可以運行。這意味着在使用上簡單了，在部署上也爲企業減少了部署成本、維護難度。使用 ioGame 時，只需一個依賴即可獲得整個框架，而無需在安裝其他服務，如： Nginx、Redis、MQ、Mysql、ZooKeeper、Protobuf協議編譯工具 ... ...等。
管理使用方面
在 ioGame 中，你不需要爲每個邏輯服（遊戲對外服、遊戲邏輯服）都分配獨立的端口。因爲邏輯服是以客戶端的方式來連接 Broker（遊戲網關）的，所以，我們只需要知道其中一個 Broker（遊戲網關）的 ip:port 就夠了。
即使是使用雲服務器之類的，也不需要關心端口是否開放權限的問題了；別小看這一個環節，通常這些小地方最浪費開發者的時間。由於我們不需要管理這些 ip:port 了，意味着這部分的工作量就自然的消亡了。
更少的開發成本
在分佈式開發體驗方面，通常在開發分佈式應用時是需要啓動多個進程的。這會讓調試與排查問題變得非常困難，從而降低開發者的效率、增加工作量等，這也是很多框架都解決不了的問題，但 ioGame 做到了！ioGame 支持多服單進程的啓動方式，這使得開發者在開發和調試分步式系統時更加簡單。
成本方面
ioGame 不依賴任何第三方中間件或數據庫就能支持集羣、分佈式，只需要 java 環境就可以運行。從而避免了安裝中間件的成本、維護中間件的成本、學習中間件的成本、部署中間件的成本
由於我們不需要打理和使用任何中間件，意味着這部分的工作量就自然的消亡了。
優點
在傳統架構中，各服務器之間是相互直連的，那麼只需要一次傳輸就可以到達。
初次接觸 ioGame 的開發者在看完架構圖後，會認爲 ioGame 必須比傳統架構多一次的跳轉才能到達。這麼理解是正確的，但也不完全正確，不完全正確是因爲 ioGame 是具備架構多樣性的，架構多樣性使其具備了能夠適應各種業務場景的可能性。
如果時間充裕可以先閱讀 ioGame 架構多樣性這篇文檔，這裏在簡單的重複一下架構的靈活性。ioGame 的架構由三部分組成：1.遊戲對外服、2.Broker（遊戲網關）、3.遊戲邏輯服；三者既可相互獨立，又可相互融合。所以，使用 ioGame 幾乎可以滿足任意的部署方式，可以根據你的需求來適應不同類型的遊戲，並且在 ioGame 中做這些工作是簡單的。
爲了更簡單的說明三者之間的靈活性，現在把三者用字母代替，A.遊戲對外服、B.Broker（遊戲網關）、C.遊戲邏輯服；我們可以得出如下組合
ABC ：三者在一個進程中，他們之間使用內存通信；（無需傳輸）
AB + C ：【遊戲對外服和遊戲網關】在一個進程中，他們之間使用內存通信；（傳輸一次）
A + BC ：【遊戲網關和遊戲邏輯服】在一個進程中，他們之間使用內存通信；（傳輸一次）
A + B + C : 三者在不同的進程中。（比傳統多一次傳輸）
通過上面的組合，我們可以看出，ioGame 架構是支持類似傳統架構那樣只做一次跳轉，甚至可以做到零跳轉，這完全取決於你們的部署方式。
提示：ioGame 架構是可以做混合組合的，雖然上面只列出了 4 種，但這 4 種是可以混合使用的，不需要侷限於某一種方式。ioGame 的架構由三部分組成，可以將其比作爲樂高積木，想適配什麼樣的遊戲，就組裝成什麼樣的架構。無論如何組裝，你的業務代碼都不需要做任何改變。
通過不同的部署方式，可以適應各種類型的遊戲。部署方式可以隨意的進行切換、變更，並且部署方式的變更是不會對現有的業務造成破壞性影響的，這就是架構靈活性。
小結
本篇中，只是做了一些簡單的對比。
- 從對比中我們可以看出，傳統架構是重量級的，ioGame 架構則是輕量級的。
- 傳統架構需要藉助很多第三方中間件才能正常的運作，而引入的中間件越多，則會造成不穩定性就會上。
- 引入需要安裝的中間件，存在着安裝中間件的成本、維護中間件的成本、學習中間件的成本、部署中間件的成本。
- 傳統架構還存在 N*N的問題，即使什麼都不做，心跳就已經消耗了大部分的機器資源了。
- 傳統的遊戲邏輯服需要給每臺機器安排一個啓動端口，如果使用的是雲服務器之類的，別忘了你還需要配置一下相關 port ，否則其他邏輯服連接不進來，別小看這一個環節，通常這些小地方最浪費開發者的時間。而 ioGame 中的邏輯服不需要做這些工作，意味着這部分的工作量自然的消亡了。
這裏還沒有對比通訊方式，ioGame 提供了多種通訊方式，幫助開發者簡化跨進程通信，並且這些通訊方式是可擴展的，通過這些豐富的通訊方式，幾乎可以滿足任何業務。