InfoQ辦的2015 QCon，裡面的Session都很不錯呢！這次看的是：
Microservices and the Art of Taming the Dependency Hell Monster
心得
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選擇他要用的版本。
沒有留言:
張貼留言