筆記：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
• 每個Actor有一個Parent，由Parent處理該Actor失敗的情境
• 每個Actor有1..N個child Actor
• 沒做事的Actor不會佔用CPU時間
• 一個Actor一次只處理一個message，避免Concurrent issue
• 一個Actor佔用450 byte，所以一台機器可以有百萬個Actor(!)
• Akka Cluster可以有2500個node，所以如果都是10G RAM以上的機器，可以有到兆等級的Actor(!)

  Akka Stream

• 有誰敢說自己Multi Thread的實作100%正確呢？就算有Test，Multi Thread這件事本質上就是容易錯，我們有一定要用這個作業系統特性嗎？
• 如果有更簡單的方式，是否可以不用Thread
• Akka Stream特性：
  • immutable，Actor處理方式讓各個資料流不互相干擾
  • reuseable，有Immutable就很容易可以做到
  • composable，既然可以reuse，就可以很容易組合
  • coordinated，Actor的Supvisor架構
  • asynchronus，Actor是message driven，可以做到非同步
  • transformations，提供各種不同的Transformation方式來處理Flow
• Linear transformation
  • Source
  • Sink
• Non-linear transformation
  • Fan in
  • Fan out
• Non-linear transformation：可以建構Graph，拿來做Protocol
• 擴展
  • Akka TCP stream
  • Akka Http
  • Reactive Stream Inter op
  • …其他
• Materialization具體化
  • Akka Stream把what與how分離
  • Source/Flow/Sink的DSL可以建立藍圖
  • ActorFlowMaterializer把藍圖用Actor執行
• Demo: 定義Source, Flow, Sink形成資料流處理的管道
• Klang’s Conjecture: “If you cannot solve a problem without programming; you cannot solve a problem with programming.”

  本日學到的名言

• 比較Push與Pull的特性，主要就是Push沒辦法處理Drop，Pull會有多的Overhead
• 比較Push&Pull與Supply＆Demand
• 2-way在Publisher與Subscriber
• 如果我們的Data Flow可以同時有Push與Pull?
  • 當Subscriber比較快就用Push
  • 當Publisher比較快就用Pull
  • 自動切換Push與Pull->Dynamic push-pull
  • 當可以有批次的Demand，就可以有批次的動作，設計者決定要累積多少的Demand才發出信號進行動作。
• 帶出Reactive Stream，可以完成以上的model
• 推廣時間：
  • https://github.com/typesafehub/activator-akka-stream-scala
  • https://github.com/reactive-streams/reactive-streams-jvm

​

筆記：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的佈署概念

• 一陣子就重新換Servers
• 維護Golden image，所有的Server都用這個image佈署

  缺點

  小修改很可怕

• 小修改就要把整個Server群的image換掉
  • create image要時間
  • 重新啟用同數量的server要時間
  • 把舊的Server的Request導到新的也要時間
• 解法：
  • 全部都自動化
  • 用中間image減少編譯時間

    很難Debug

• 沒裝tcpdump或iptables怎辦
• log怎麼導出去
• 解法：把需要用的工具裝進去image裡面
• 解法：把log導到外面。

  存資料

• Immutable沒辦法存資料
• 解法：不要存在Server上，存在其他Storage，Amazon RDS
• 解法：存在外部系統

  導入Immutable Container也就是Docker

• Create docker image可以有snapshot，所以小修改要create image更快。
• 換Image後啟動速度比一般VM快非常多！完全不能比！
• 可以重使用原本在Host作業系統上的資料，或是用Data Volume Container。
• Container之間可以分享：
  • 目錄，像是Log
  • 網路，可以用B Container來看到A Container的Traffic！這種叫做side kick container
• 執行Service的Container完全可以是Read only

​

筆記：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(CA)，百萬product
• Inventory Service，檢查庫存，與其他domain隔開，10000 request 1秒，用hbase(CP)，每天更新一次庫存，需要保證不會多賣。
• Cart Service：處理購物車，處理量較小，用dynamoDB，用了7年，可選consistency。
• 從2008~2015年，每個Service的發展速度都不同，所使用的library演進也不同，但是都透過Http提供服務
• 看起來戰略規劃得很好，但是隨著產品越做越複雜，直接面對User的Application Service也變得複雜，需要包含user service, catalog service, inventory service, cart service等等在一個頁面呈現，結果就是，要把幾乎所有的client library包含進來。
• 接下來就是
  • 開發application service變得很慢
  • 只要一點小變化就做一個新的client library->因為不想包含太多
  • 做custom API避免包含太多client library
  • 大量相同架構的程式碼，因為想避免client libary dependency
  • Code的品質變差，讓開發變慢
  • 最後就會真正在產品上看到錯誤：java.lang.NoSuchMethodError，哈哈
• 怎麼辦？從Open Source借鏡
• http://www.apidoc.me/ 自動產生document

API design must be First Class

• protocol buffer, api doc就是一種契約，尤其是可作完就丟的micro service，這樣的靈活度就是來自於訂立良好的契約。
• 這樣的方式就是”Schema First Design”，Server Client就看資料是什麼就怎麼處理。而不要關心其他實作細節。

  這看來有點不敏捷…不過Gilt的code base已經累積很多，不是說改就改，而以micro service的形式，還是可以把改動的影響範圍縮到最少，並且也有可能以敏捷的方式開發。

• 定義REST API就要遵守REST的語意

Backward and Forward Compatibility

• 向前相容，新增欄位只能是Optional或是有Default Value
• 向前相容， 不要Rename！如果真的有需要的話，導入新的Data Model並且提供Migration機制。
• 向後相容，小心使用Enum，像是他們用Scala定義Enum時會一定要有個Undefined，把處理未知enum的責任交給Micro Service開發者，而不是由不知道實作的Micro Service使用者負責。

Accurate Documentation

• 他們發現唯一可以讓Document精確的方式就是在Software Process裡使用Document。
• 用Sematic Versioning，X.Y.Z，當API有不向後相容時，X請進版！

Generated client libraries

• 有爭議，但他們覺得有用
• 為了避免寫重複的code，例如發http request，組json
• 有了Data Schema，API doc，是可以產出Client libary
• 最小dependency，頂多是包含處理http與處理json的library
• 為有用到的語言產一個，例如Ruby client library，Play client library等等
• 產出來的client library只要有通過自動測試，使用者就可以拿去用！
• 使用者可以從client libary選擇他要用的版本。

​