SAIKURON 13.Ned

參考來源： http://engineering.riotgames.com/news/architecture-league-client-update 心得 看了這篇才知道可以用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？因...

參考來源：微众银行基于自主可控技术的分布式架构实践 http://www.infoq.com/cn/presentations/webank-distributed-architecture-practice-based-on-self-controlled-technology 心得 難得看到新銀行的案例分享，新銀行就沒有過去技術的包袱，每個邏輯節點可以作所有業務，但把user分塊，也就是沒有一個資料庫有全部的資料，不同節點之間需要對方的資料就要去查詢。並且同時有Scale up與Scale out的方案，把模組切分的更獨立來架構變得靈活，用Open Source技術與同一機器環境讓運營成本比起傳統銀行少了10+倍。非常值得參考！ 筆記 普惠金融：普惠金融體系(Financial Inclusion System)普惠金融體系是指一整套全方位為社會全體人員，尤其是金融弱勢群體提供金融服務的思路、方案和保障措施等。 去IOE：(去掉IBM的小型机、Oracle数据库、EMC存储设备) 微眾銀行WeBank，全虛擬化銀行。開發時間很短，30億資本，半年籌建。 選擇自主可控全分布式架構 分散風險的進化，目前一般銀行的架構是集中式鬆耦合，同一個業務由一個節點或是多個節點服務，但業務之間還是緊耦合，所以只要某業務所屬節點有問題，還是會造成其他業務出問題。後來進化成一個節點包所有業務，但是只服務特定客群 提高冗餘的進化：一般銀行多主節點，沒辦法滿足CAP。最後捨棄高性能，一主兩從， 取CP 進化後：一個節點是一個邏輯概念，可以做同一客戶群的所有業務，有多台機器，一主二從架構的保持資料一致性與備份。 把服務分成兩大類，對客戶，對內部後台管理，所以有兩種類型節點 一個客戶的業務在一個節點上處理，一個節點可以處理多個客戶，一客戶一開始就指定在哪個節點，客戶創立與查詢用GNS(客戶在哪裡)來做。 雙向擴展 橫向擴展：客戶變多加節點 縱向擴展：同樣的客戶業務變多，升級機器，或是增加節點的機器數量。 規則：客戶變多只能用橫向，一節點五百萬就是五百萬。 分佈式架構平台，參考圖，業務能力、基礎能力(無狀態服務，大數據框架)、基礎資源(資料中心，虛擬機器，網路)。 這個架構其他業務也可以參考。 所有節點不共享網路、服...

http://www.infoq.com/presentations/akka-streams?utm_source=infoq 心得 這位Viktor Klang講話方式與外型都很像我前同事XD，現在Akka除了可以提供不用管Thread的執行模型之外，還有Akka Stream可以提供處理資料的模型。其實我對Akka沒很熟啦，不過因為後來都是在寫Backend的關係，所以對Backend處理架構有興趣。看起來Akka Stream除了提供原本基於Actor的好處之外，還提供了對資料流更高階更有效率的抽象化架構，像是Source, Flow, Sink這樣的概念，以前在做M$的DirectShow就有接觸了，不過那個只是單機視訊播放。這個是處理數千數萬的資料流，應用的等級差很大。最後帶到Reactive Stream的概念，那個Dynamic Push-Pull Model看來真的是蠻屌，但應該還在發展中。話說現在typesafe也要改名成lightblend了，看來他們公司搞的技術都頗有看頭，希望他們Live long and Prosper！ 筆記 簡介Akka Akka: Simple message-oriented programming model for build reactive applications. 會用Scala demo因為可以顯示比較完整(!) 不需要考慮Share state, memory visibility, threads, locks, concurrent collections, thread notifications. 高CPU使用率, 低延遲, 高輸出, 有彈性 Supervisor hierarchy可以讓application有彈性 有個root actor當supervisor，管控其下的child actor，有問題就換掉，做得慢supervisor就找其他actor幫忙。 這種是製造業思維，被敏捷洗腦的我聽了有點OOXX，不過Akka處理message就是製造業沒錯啦… Akka的計算單位稱為Actor Actor有address, mailbox, current behavior, local storage Actor週期性的送出message...

http://www.infoq.com/presentations/immutable-servers-docker?utm_source=infoq&utm_medium=email&utm_campaign=03112016Seg3 心得 這篇也算是Docker官方業配文？這位法國來的Jerome Petazzoni講英文我意外蠻好懂的。所謂Immutable這個概念最常就是拿人體的細胞來比。聽起來是很有說服力啦。基本上這樣子的Deploy方式就很像修車模組化整批換掉，而且軟體是虛擬的，完全不會有什麼零件製造品質問題或是什麼物理性問題。而這個架構可以強迫設計者把Storage與Service分開，讓Service成為真正的Stateless，而Data與Service分開的速度部份，我覺得也不用擔心，現在幾乎所有雲端Solution都有Storage Service了，怕延遲就是要用In Mem Cache。我最驚豔的是，有side kick container這種東東呀！裝個Container在正在運作的Container旁邊就可以偷看網路與其它東西…Docker真的是越來越成熟了！不過缺點就是，幾乎什麼都要寫code，想要完成這樣子的架構就是要寫一堆configuration！然後就有比較高的學習曲線，然後就要引進版本管理機制，然後就要管理這些東西的複雜度，然後就要找更厲害的Engineer才能把東西搞好搞大！這樣其實對我們來講是好事啦！在IT界總有新觀念可學習，新東西可以玩~ 筆記 Never change what’t on a server 不要裝新的packages 不要upgrade原來的packages 不要移除或down grade原來的packages 就算有安全性問題！ 不要編輯configuraiton files 不要更新application的code! 如何upgrade 起一個全新的Server然後測試過沒問題之後換掉舊的 那新舊Server可以同時存在，寫DB怎辦？這可能又是一個只新增欄位與換Data Model才能解決的問題 避免server confiugration drift導致難以維護的結果。 導入Immutable Server的佈署...

InfoQ辦的2015 QCon，裡面的Session都很不錯呢！這次看的是： Microservices and the Art of Taming the Dependency Hell Monster http://www.infoq.com/presentations/microservices-dependencies?utm_source=infoq&utm_medium=email&utm_campaign=03112016Seg3 心得 Gilt是在歐洲美國都很有名的線上購物網站，尤其是折扣商品的銷售很猛，雖然我沒買過啦。看他們完全導入Micro Service的數量很驚人，而DB的選擇方式也是相當多元，基本上就是歷史因素以及各取所長。還有就是在Gilt裡，Play+Scala幾乎都是主流了！聽了這場，我覺得學Functional還是應該學Scala啦！裡面講到的Dependecy問題非常有感覺。只要軟體複雜度到一個程度，一定會出現這種問題，還好他們已經先把戰略佈置成Micro Service的形式了。各各擊破比起所有Application或Service大一統簡單。但Micro Service要能減緩Dependency Hell還是要靠REST Service，裡面提出的策略非常有用。就算是想用Remote API Call，這場Session也派的上用場。把Document當成一個產品，放到軟體生產流程裡面成為一個不可或缺的環節，這樣可以完全避免掉Document更新跟不上實作的問題！ 筆記 Gilt從Ruby+Memchache->PostgreSQL to Play+Scala->MicroService+Scala->Legacy Service->PostgreSQL Micro Service 156+個，Application Service 5~9個。 User service, 百萬user，10000 request 1秒，用mongo db(CP)存，有consistency 用Remote API呼叫，回傳Future！可以這樣用喔？ Catalog Service, 取所有product，5000 request 1秒，用postgreSQL...

話說最近正在讀《無瑕的程式碼》這本書，所以一直擺在手邊，三不五十就會瞄這本經典鉅作一下，不過最近眼花常會看錯書名... 當程式寫出來，功能完整，沒啥bug，自我感覺天下無敵的那一瞬間，就會看成「無敵」的程式碼 當不小心打開Open Source的專案原始碼時，一堆看不懂的程式碼在眼前，老鼠怎麼捲都捲不完，眼花撩亂的那一瞬間，就會看成「無窮」的程式碼 當看到某些函式訂了參數，傳進去卻沒用到，咒罵這分明是脫褲子放屁的那一瞬間，就會看成「無用」的程式碼 當看到某些大師的程式碼，想說來重構一下，以證明自己比大師更厲害，卻發覺完全沒地方下手，體會到大師果然厲害的那瞬間，就會看成「無缺」的程式碼 當看到某些程式碼模組交互呼叫，糾纏不清，你濃我濃時，想修個bug卻不知從何下手時，就會看成「無縫」的程式碼 當看到某些程式碼根本只是隨便寫寫，完全不考慮後續維護，魔術數字四散各地，變數名稱與流程邏輯完全對不上，改起來簡直想要跳樓，就會看成「無恥」的程式碼 當bug截止時間將到，知道錯誤在這段，卻完全沒有idea要怎麼改，就會看成「無望」的程式碼 當一直寫一樣的東西，絲毫沒有變化，感覺悶的要死時，就會看成「無趣」的程式碼 當看到某些程式碼內含一堆架構，實際上架構根本就沒做到什麼重要的事，完全是一個熱臉貼冷屁股的那一瞬間，就會看成「無感」的程式碼。 當程式碼架構設計的好，還貼心的附上完整的測試案例，要新增功能，要修bug都是一塊蛋糕，照著架構改好跑跑測試就搞定，感覺人生輕鬆愉快的那一瞬間，就會看成「無痛」的程式碼。 當看到好不容易重構後變得比較簡單的程式碼，一次又一次被加個阿紗布魯，天邊飛來的一朵邏輯的那一瞬間，就會看成「無力」的程式碼 當花了十年參透大師寫的那一行程式碼背後所隱含的大宇宙的奧秘的那一瞬間，就會看成「無極」的程式碼。 軟體進步到現在，開發測試部署全部都可以用程式碼控制，四輪傳動系統、行車主動安全系統，物聯網，OOXX什麼東西都會有程式碼存在，當我想到2XXX年還是有一堆人要寫程式碼的那一瞬間，就會看成「無限」的程式碼。 以上純屬嘴砲，我只是想表達這本書的中文標題，真的意義深遠...