序
- 今天看到一個文章談論了一些游戲server為什么不愿意使用微服務的原因。覺得說的挺好，從側面能反映出來微服務的好處和弊端。
首先說下微服務架構
就是把一個大型的單個應用程序和服務拆分為數十個的支持微服務。一個微服務的策略可以讓工作變得更為簡便，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協(xié)議。
- 微服務有什么好處？
方便測試，方便維護，方便升級，服務之間松耦合，可多語言開發(fā)，自動擴容 等等
- 微服務有什么弊端？
分布式事務，運維的成本增加，模塊與模塊之間的調試相對復雜。
- PS 如果你之前接觸過模塊化構建的工程，那么微服務化和模塊化思想上還是有點類似的，只不過微服務更復雜了。我個人理解一個Springboot的模塊化工程也是需要考慮，模塊的拆解，哪些是公共依賴模塊，哪些是自己獨立的模塊不需要被人依賴，怎么設計模塊之間的依賴關系，會不會開發(fā)途中發(fā)現循環(huán)依賴了。諸如此類的東西都需要慢慢經歷了解。舉個例子，工程里面可能會集成操作Mysql的模塊，也會有操作MongoDB的模塊。這兩個模塊就可以都構建成獨立的模塊。其他的模塊需要對Mysql操作就依賴Mysql模塊。
以Moba類型游戲為例，最重要的關鍵是 real time
- 微服務為了把業(yè)務完美拆解，把原來的同一個進程里的模塊拆分成不同的服務，顯著增加額外的網絡開銷。更別說什么service mesh，各種gateway，proxy，sidecar，簡直就是擔心延遲太低。
- 微服務基本只有request/response的模式。做不了streaming？微服務通常要求應用是無狀態(tài)的才能做到水平擴展。streaming本身就是加入了狀態(tài)
- 我可以想像，為了提高通訊的性能，一場英雄聯盟游戲很可能會使用同一個服務器負責這10個玩家之間的通訊，這樣就使得數據可以在本地交換，性能最大化。這對客戶端或者說服務端統(tǒng)一網關的要求是必須支持sticky routing。假設客戶端連接斷了，接下來的必須重連之前的同一個服務器。微服務的stateless，水瓶擴展要求本身就是反sticky routing的，因為sticky routing本身就是狀態(tài)。
- 對服務端集群來說，同時有無數個王者榮耀的比賽在進行，每個都可以看成一個沙盒，每個沙盒都處于一個不同的狀態(tài)：塔被推了幾個了，你被殺了幾次了，對面幾個超神了，20分鐘到了沒。這些都是長時間存在的狀態(tài)，直到游戲結束，服務端才可以清理一場游戲的狀態(tài)。所以雖然不用把這些狀態(tài)寫進持久性存儲，但是必然會在內存中存在很長時間。都是狀態(tài)，反正有狀態(tài)，就別想用微服務。除非你說把這些狀態(tài)都移到redis里去，那么在服務器在信息流傳輸到一半還要做一個remote request，一來一回，延遲就上升了?？傊鯓佣疾缓谩＃ū热缦胂髮Ψ皆贏你的水晶，每一次A的操作都是一個event，被streaming到服務端的沙盒中，沙盒中有一個流處理器，每次接收到一個你水晶被A的event都會計算一下你水晶爆了沒。這個計算需要極快，你是不可能把你水晶生命值的數據存在遠端的）。
- PS : Spring的出發(fā)點是為J2EE 而生，是替代EJB的產物。本就不是為設計開發(fā)游戲而生。
