提升微服務 (micro service) 實施效率

  1. 微服務必須要是全新的程式碼, 而不要clone/複製原本的程式, 避免依賴
  • 能建立獨立的CI/CD

2. 構建微服務的問題

  • (xx微服務) 用來
  • 在 (出現痛點的場景) 的情況下
  • 解決 (解決現有的某個問題)
  • 然而 (達到什麼樣的效果)
  • 提升 (微服務的價值)

ex:

  • (訂單查詢微服務) 用來
  • 在 (訂單查詢數量快速) 的情況下
  • 解決 (訪問數量迅速升高導致整體應用效能下降的問題)
  • 然而 (分離了訂單查詢請求)
  • 提升 (其他功能的效能)
  • 可以把 “拆分” 換成 “移除”, 思維方式把 “一個團隊負責兩個系統” 變成 “兩個團隊負責兩個系統”
  • 把 “集成” 換成 “調用”, 思維方式把兩個系統關係變得更精確, 微服務之間的關係和溝通方式
  • 領域驅動設計 (DDD) 可以幫助更容易劃分微服務
  • 關注點分離, ex: 接口中分離出流量較大的接口獨立部署, 把讀數據和寫數據的API 分開獨立部署, 把靜態和動態訪問分離

3. 以最小的成本發佈出 (Release) 第一個微服務

  • 最精簡的獨立敏捷全功能團隊
  • 最快的時間
  • 成本最小的技術債
  • 先考慮最後如何 Release, 根據Release時程往前推算
  • 採用 Feature Toggle, 可以在production 動態的控制微服務的啟用, 降低失敗的風險 (ex: Feature Toggle 就像是rollout)
  • 需要設定移除 Feature Toggle的時間, 一般來說不超過兩個月
  • 團隊較小時, 功能較單一, 不建議構建微服務

4. 取得快速勝利 (Quick wins), demo 驅動開發

  • 設定短期目標, 把scope切小
  • 設定當天結束的產出, 可以用來確定今天需要做什麼
  • 學習的文章分享也可以 / 踩過的坑 / 遇到的問題
  • 用天來拆分任務
  • Quick wins 範例:
  • 建構第一個微服務流水線
  • 上線第一個微服務 Hello World
  • 構造出第一個微服務自動化測試

5. Code 未動, DevOps先行

  • 把內部的複雜性, 分散到各個微服務之中, 降低整體的複雜性和架構的風險
  • 在這個過程之中會大量採用 DevOps技術和工具
  • 需要先建立好微服務的 CI/CD 交付和運行的平台, 之後才開始開發微服務
  • 服務註冊和Release是微小服務的核心, consul 和 Eureka 是這方面的佼佼者
  • Deploy 和 Release要分開

6. 除了 Deploy 和 Release之外, 微服務平台一切都應當自動化

  • 自動化功能性的測試
  • 自動化構建
  • 自動化部屬
  • 自動化性能測試
  • 自動化安全掃描
  • 不用一開始就追求全面的自動化, 根據團隊情況而運行
  • 機密訊息需要獨立管理, 可以採用 hashicorp vault

7. 可複製成功經驗, 建立起微服務交付

  • 剛開始需要每週建立會議, 需要快速的反饋和調整