發表文章

目前顯示的是 3月, 2016的文章

筆記:Akka Streams: Streaming Data Transformation à la Carte

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...

筆記:Easier, Better, Faster, Safer Deployment with Docker and Immutable Containers

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的佈署...

筆記:Microservices and the Art of Taming the Dependency Hell Monster

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...