心得
看了這篇才知道可以用CEF來開發Desktop Client，Java Script統一所有前端的浪潮還在持續呀。最後講到了”datacenter in a desktop.”也蠻有趣的，Plugin架構雖然不是什麼新觀念，但卻可以很好的解決他們遇到的問題，以後遇到可以參考一下。話說回來，要寫個windows client要同時寫C++與Java Script，好像有點OOXX，不過這是因為他們不想連遠端Server的實作都改的折衷方案，畢竟Client整修失敗，就把舊的拿出去用就好，Server整修失敗，就….
筆記
- 主要就是談：the League client update，進遊戲之前的Client Application
- 原本使用Adobe AIR，使用它的RTMP協定，動畫呈現，而且還是跨「桌機」平台。遊戲推出的當下，可說是很好的解決方案，不過接下來就開始不合時代潮流，因此要做新架構
- 新架構要解決的：
- 用HTML5+JavaScript的解決方案，不管是在client端呈現，或是與Server溝通，還有工作流程與開發環境都比原本更有擴充性且易用。
- 不管是遊戲內遊戲外，玩家都可以保持連線：原本Adobe AIR的方案對PC資源使用率過大，也不支援手機。
- 工程師們想要有個更簡單一致的開發架構。
- 一開始想要改少一點，想說直接重用Adobe AIR的code來搞，但發覺現在已經有更多更好的方案。
- 後來選擇了 Chromium Embedded Framework (CEF) ，寫Desktop Client就像是寫網頁。對HTML 5有很好的支援，而且界面修改自訂可以更靈活。
- 決定重寫(!)，重寫很危險，但好處比壞處多就上。
Step A
- 所以Client界面主要就是Java Script
- 為了要讓Java Script與原本的Server溝通，原本Server是支援RTMP，所以他們為Java Script Client開發了一個C++原生Library，負責用RTMP與Server溝通，以及提供非同步的處理。
- 為什麼Server還是用RTMP？因為不想同時Client與Server。
- 選擇ember.js當Java Script Client框架，ember-orbit當作資料層
- 看起來架構還不賴？問題馬上出現了。
- Java Script Client變得非常複雜，裡面的元件各自處理非同步的部份，使用者的狀態也保留在Java Script Client這一層(!)，所以記憶體變得很大。
- 這個方案解決1.但是2.與3.都沒有處理好，而且Developer抱怨連連。
Step B
- 開始思考一般Web Application是怎麼做的，反正都用Java Script了，來向一般Web Application取經
- 發現少了中間層！
- 所以弄了個C++寫的micro service層，但是在本地端！
- micro service層就像是http server，按照REST的規則來提供資源存取，讓Java Script Client不要處理非同步(複雜度的主因)。
- micro service層與Java Script Client層用Web Socket溝通，micro service層與遠端Server還是用原來的RTMP溝通
- micro service層取名叫Foundation
- 弄成這個架構之後，精簡掉所有不必要的Java Script VMs，只留下Foundation，Java Script Client都只用GET
- Foundation大概佔用20MB記憶體，玩家不需要把Java Script Client砍掉才進LOL裡面！
- Foundation可以用system tray來呈現，不管玩家有沒有打開LOL都可以接觸到遊戲資訊。
Step C
- 換成新架構後，寫功能就是要寫micro service與遠端server，micro service與Java Script Client。
- 大家都改同樣的地方，互相影響。
- 需要架構上的解決方案來讓團隊協作更有效率。
- 作者自己研究了許久，決定採用Plug-in架構
- 每個Plug-in必須有自己的Semantic Versioning，還有它依賴哪個Plug-in與這個Plug-in的Semantic Versioning。
- 把架構呈現成Graph的形式，Plug-in的相依性一目了然
- 所以有front-end (FE) plugin，用Java Script，實作UI。有back-end (BE) plugin，用C++，實作資料處理與遠端Server溝通。
- 取名叫Front-end與Backend是代表這個架構模仿所謂的Client-Server架構
- 用Plug-in可以簡單開關使用者可用的功能，通常是不同區域的使用者。
- 由於之前用ember-orbit，Front-end還是可以直接操作很多資料，又增加複雜到，所以讓ember-orbit退休，資料都透過REST從back-end plugin拿，front-end plugin可以快取資料，但其他複雜資料的處理就不要在Front-end了。
Step D
- 已經有了更有生產力的架構，大家可以各自做自己的Plugin不會互相影響。
- 有些人不喜歡Ember.js，想直接用HTML 5的東西。
- 有些人在別的地方已經有了現成的Web Client，想說直接搬到這個Java Script Client，這樣就不用重作一次Client，反正都是Java Script。
- 本來很堅持來這邊開發就一定要用Ember.js，後來發現，就算每個Plug-in都用Ember.js，要保持每個Plug-in的Ember.js的版本相同，也很困難，公司太多Developer了。
- 最後改成每個Plugin都可以用自己的Java Script Framwork
結論
- 最後的架構，可以讓多個團隊獨立的開發the League client update，HTML5 Front-end與C++ back-end的配合夠靈活效能也夠好。Plug-in架構不只對開發有幫助，對實際產品呈現也有幫助。
- 大部分人都很滿意！
- 回頭來看，這就是一種”datacenter in a desktop.”的架構，Atom就是如此。
- 還有HTML視覺效果，功能可以獨立更新發布還沒講。
沒有留言:
張貼留言