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