# SITCON 2025 微服務筆記 [簡報連結](https://craft.pan93.com/sitcon2025-public-resources)、[共筆連結](https://hackmd.io/@SITCON/2025/%2F%40SITCON%2FSklske7i1e)，因為都是我寫的所以就複製一份。 ## 單體後端的擴縮問題 一個功能壞掉，其他功能也無法使用。 可以多開幾個服務解決，但狀態要共享的話不容易，讓後端變得無狀態就行了。 MySQL 可以讓一個主資料庫僅寫入，多個從資料庫僅讀取。但寫入還是可能成為瓶頸。 以功能、領域切割資料庫，就不會互相影響 ## 引入微服務 一樣以功能、領域切割服務。可以針對微服務擴縮。 使用一個 gateway，把微服務統整成 API。 ## 微服務的技術議題 ### 名詞介紹 * 服務：應用程式 * 實例：可獨立運行的虛擬化計算單元（比如兩個使用者服務） * 節點：一台機器 * 叢集：多個節點組成 ### 服務探索 服務在不同節點，不好互相溝通。如果 IP 寫死，就需要改很多設定。 可以把連線方式寫在一個共同資料庫。client-side servie discovery，由服務回報自己的位置。 或是用 DNS，用固定的主機名稱連線。server-side servie discovery，由基礎設施應對。 ### 負載平衡 多開微服務後，gateway 需要進行管理，client-side load balancing(LB)。 也可以交給基礎設施，如雲服務，即 server-side LB ### 服務間的通訊協定 RPC：gateway 與使用者互動的介面。 gRPC：寫出定義後，可以產生用戶端和服務端的程式 ### CQRS 資料庫的讀寫分離有好處，因為邏輯分明，讀取可以從快取讀。 CQRS(Command Query Responsibility Segregation)：Command(寫入), Query(讀取)。 ### 處理非同步動作 問題：待補，不太懂 用訊息佇列解決。 ## 部署微服務 啟動執行單元時，如果用同樣的環境，可能有衝突。 最直覺的想法是開虛擬機，但開銷過大。因此用 docker 的**容器**來封装環境。 容器編排平台如 Kubernates 會分配、管理多個節點上的容器，偏向維運人員的工作。 簡單的解法是 PaaS。 ## 技術選型和學習路線 真的有必要微服務嗎？ 如果沒有瓶頸，或許不需要，簡單的方法如多開或許就解決了。 微服務的 Roadmap 就是後端 Roadmap 的下半部分，很多議題是為了解決現實問題，因此可以邊玩邊學 ## QA 微服務主要還是為了單一服務的擴縮 微服務的拆分：DDD Zeabur 滿適合微服務的部署。