---
# System prepended metadata

title: 微服務開發

---

# 微服務開發

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

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
    * 盡可能無狀態
