# 微服務開發

原始問題：**如何協助拆分微服務？有什麼方法論？**

Phase1 : introduction
Phase2 : case study & discussion; implement stateless apps with microservice arch.
Phase3 : deep dive & implementation (Might leverage MW TAMs, e.g., integrate with AMQ, Fuse)

* 基本介紹與定義與特性
* 一群小的服務
* 獨立部署
* 分散式架構
* 拆解單體
* 何時該拆解？
* 拆分時機
* 快速迭代需求
* Merge 常衝突
* 橫向擴充能力不足
* 生產力和複雜性的權衡
* 拆分原則
* 單一職責
* 演進式拆分(單體先再來考量微服務)
* 如何取捨和拆分方式？
「微」如何定義?
* 程式碼行數 ?
* 開發時間 ?
* 這個微其實不好度量也不需要
* 業務領域邊界拆分
* 組織架構和團隊拓墣 (康威定律)
* 橫向擴展需求
* 變更頻率
* 特殊要求，例如：安全性
* 共通特色
* 單一職責
* 隔離性
* 資料的所有權
* 標準且輕量的通訊協定

* 典型的挑戰
* 分散式交易
* 業務對一致性的要求(強/弱一致性)
* 過多的跨服務交易
* 整合/測試複雜性
* 維運複雜性
* 多開發語言 (技術異質性)
* 優雅降級
* Anti-pattern
* 過多溝通
* 高耦合(複雜的依賴關係, e.g., 環狀, 雙向依賴)
* 敏捷精神
* 用最小的力氣做快速的迭代，並取得有效的回饋

## 延伸思考題
* 當有些業務明顯已經被拆成「太小」該怎麼「合」？
* 當業務尚未被市場驗證，這時我該一開始就拆解嗎？
* Team topology
* 解偶後又有各種聚合/adapter需求？（常見於 edge side)
* API Gateway
* GraphQL
* https://samnewman.io/patterns/architectural/bff/
* Request 治理相關
* 一個 request 的生命週期長怎樣？(request前中後)
* filter
* access, audit logging

* 怎麼去支撐/加速微服務開發
* Rate limit
* Circuit breaker
* Service discovery
* Configration management
* fault tolerance
* retry
* Authn/Authz
* Logging
* Monitoring/alert
* Troubleshooting (tracing)
* 開發團隊怎麼去落地？
* Pattern
* Best practice
* 盡可能無狀態