---
# System prepended metadata

title: 選課卡成狗？微服務架構帶你翻轉校園系統 - Pan
tags: [SITCON 2025, 共筆, SITCON 2025 共筆, R3, '2025']

---

# 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 滿適合微服務的部署。