AWS快速開戶 雲原生微服務架構詳解：服務拆分與通訊機制

# 雲原生微服務架構詳解：服務拆分與通訊機制

很多人搜尋這個主題，不是為了看概念定義，而是因為系統已經走到以下階段之一：

- 單體應用發版越來越慢，想拆分服務但不知道先拆哪一塊
- 已經上了 Kubernetes，卻發現服務之間常出現連接超時、DNS 解析慢、重試風暴
- 訂單、支付、庫存之間的同步調用越來越複雜，不知道該用 HTTP、gRPC 還是消息隊列
- 微服務數量增加後，配置、日誌、監控、權限與網絡策略難以維護

這篇文章不講空泛理論，直接從實際部署與配置角度，說清楚兩件事：**服務如何拆分**，以及**拆完之後如何穩定通訊**。

---

## 一、先判斷：你的系統為什麼要拆分

在開始操作前，先確認拆分目標。常見場景如下：

1. **開發效率問題**：多人同時改一個程式，測試與發版相互影響。
2. **性能瓶頸問題**：某個模組流量高，但整個單體應用只能一起擴容。
3. **可靠性問題**：一個模組異常拖垮整站。
4. **技術棧受限**：某些模組需要不同語言或不同資料庫。

如果你的系統還很小、團隊人數不多、日請求量不高，先不要急著大量拆分。過早拆分通常會帶來更多運維成本。比較穩妥的做法是：**先做模組邊界梳理，再按業務壓力拆第一批服務**。

---

AWS快速開戶 ## 二、服務拆分的實際方法：從單體到微服務

### 1. 先找業務邊界，不要先按程式目錄拆

錯誤做法：

- `user-service`
- `user-dao-service`
- `user-controller-service`

這種拆法只是把程式碼分散，沒有真正形成獨立業務能力。

正確方向應優先按業務域拆，例如電商系統可先拆成：

- 使用者服務
- 商品服務
- 訂單服務
- 庫存服務
- 支付服務
- 通知服務

### 2. 第一批適合拆出的模組

實操中，建議優先拆以下幾類：

- **變更頻繁且邏輯相對獨立的模組**：如通知、活動、搜尋
- **流量波動大的模組**：如商品詳情、下單、秒殺
- **資源消耗明顯的模組**：如報表、圖片處理、推薦
- **與外部系統整合較多的模組**：如支付、簡訊、物流

### 3. 拆分時的資料庫原則

很多專案失敗，不是服務拆錯，而是資料邊界沒切乾淨。

建議遵守：

- 一個服務管理自己的資料表
- 不要跨服務直接連別人的資料庫
- 查詢其他服務資料，優先通過 API 或消息同步
- 強一致交易場景，先縮小範圍，不要一開始就做全域分散式事務

### 4. 一個可執行的拆分順序

假設你現在有一個單體商城系統，可按以下順序拆：

**第一階段：低風險拆分**

AWS快速開戶 - 通知服務
- 檔案服務
- 報表服務

**第二階段：高價值拆分**

- 商品服務
- 庫存服務
- 訂單服務

**第三階段：高複雜度拆分**

- 支付服務
- 促銷服務
- 會員服務

這樣做的好處是先建立部署、監控、服務發現與日誌追蹤能力，再處理核心鏈路。

---

## 三、在 Kubernetes 中部署微服務的基本流程

大多數雲原生微服務最終都會跑在 Kubernetes。下面直接看最常用的部署方式。

### 1. 建立 Deployment

以下是一個典型的微服務部署範例：

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
namespace: prod
spec:
replicas: 3
selector:
matchLabels:
app: order-service
template:
metadata:
labels:
app: order-service
spec:
containers:
- name: order-service
image: registry.example.com/order-service:1.0.0
ports:
- containerPort: 8080
env:
- name: SPRING_PROFILES_ACTIVE
value: prod
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
```

### 2. 建立 Service

```yaml
apiVersion: v1
kind: Service
metadata:
name: order-service
namespace: prod
spec:
selector:
app: order-service
ports:
- port: 80
targetPort: 8080
type: ClusterIP
```

建立後，集群內其他服務可以透過以下位址連接：

```bash
http://order-service.prod.svc.cluster.local
```

如果同命名空間，也可直接用：

```bash
http://order-service
```

### 3. 對外暴露服務

若需要公網入口，通常透過 Ingress。

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-gateway
namespace: prod
spec:
ingressClassName: nginx
rules:
- host: api.example.com
http:
paths:
- path: /order
pathType: Prefix
backend:
service:
name: order-service
port:
number: 80
```

### 4. 常見部署問題

#### 問題一：Pod 啟動了，但服務不可用

排查順序：

```bash
kubectl get pods -n prod
kubectl describe pod -n prod
kubectl logs -n prod
kubectl get svc -n prod
kubectl get endpoints -n prod
```

重點檢查：

- Pod 標籤是否與 Service selector 一致
- readinessProbe 是否失敗
- 應用是否只監聽 `127.0.0.1`，而不是 `0.0.0.0`
- 容器埠與 Service targetPort 是否一致

#### 問題二：Ingress 已配置，但外部無法訪問

檢查：

```bash
kubectl get ingress -n prod
kubectl describe ingress api-gateway -n prod
kubectl get svc -n ingress-nginx
```

同時確認：

- DNS 是否已解析到 Ingress 公網 IP
- 雲平台安全組是否開放 80/443
- 節點防火牆是否放行對應埠
- Ingress Controller 是否正常運行

---

## 四、服務間通訊怎麼選：HTTP、gRPC 還是消息隊列

服務通訊方式選錯，後面會一直卡在性能、穩定性和維護成本上。

### 1. HTTP/REST 適用場景

適合：

- 前後端 API
- 管理後台接口
- 低頻同步調用
- 需要易於除錯與觀察的場景

優點是調試方便，缺點是序列化開銷偏高，強型別約束較弱。

### 2. gRPC 適用場景

適合：

- 內部高頻服務調用
- 低延遲需求
- 多語言服務協作
- 需要明確接口契約

如果服務之間 QPS 高，且調用鏈深，gRPC 通常比 HTTP 更合適。

AWS快速開戶 ### 3. 消息隊列適用場景

適合：

- 訂單建立後觸發通知
- 支付成功後更新積分
- 非同步解耦
- 削峰填谷
- 最終一致性流程

常見做法是：

- 同步查詢用 HTTP/gRPC
- 非同步事件用 Kafka/RabbitMQ/RocketMQ

### 4. 一個實際選型建議

對大部分專案，可採用以下策略：

- 對外 API：HTTP
- 內部核心同步調用：gRPC
- 非同步事件：消息隊列

不要試圖用一種通訊方式解決所有問題。

---

## 五、服務通訊配置實踐：超時、重試、熔斷一定要有

微服務最常見的事故不是服務掛了，而是**某個服務變慢後，整條鏈路被拖死**。

### 1. 超時必須顯式設定

很多框架默認超時太長，會導致請求大量堆積。

例如 Java HTTP client 可設定：

- 連接超時：1~3 秒
- 讀取超時：2~5 秒
- 寫入超時：2~5 秒

原則：

AWS快速開戶 - 內部服務不要使用 30 秒、60 秒這種過長超時
- 下游慢時要快速失敗，避免拖垮執行緒池

### 2. 重試不是越多越好

建議：

- 只對短暫性錯誤重試，例如 502、503、連接重置
- 不要對業務明確失敗重試，例如參數錯誤、庫存不足
- 重試次數 1~2 次即可
- 重試前加退避時間，避免重試風暴

### 3. 熔斷與限流

當庫存服務異常時，訂單服務若不做保護，很容易因等待下游而資源耗盡。

建議加入：

- 熔斷：下游失敗率高時，暫停調用
- 限流：保護核心服務不被打爆
- 降級：返回預設值或簡化資料
- 隔離：不同依賴使用不同執行緒池或連接池

如果使用服務網格或 API Gateway，也可將部分流控策略下沉到基礎設施層。

---

## 六、Kubernetes 內的服務發現與 DNS 問題排查

服務發現問題在微服務場景非常常見，尤其是跨命名空間調用時。

### 1. 基本檢查命令

進入 Pod 內部測試：

```bash
kubectl exec -it -n prod -- /bin/sh
```

檢查 DNS：

```bash
nslookup order-service
nslookup order-service.prod.svc.cluster.local
```

檢查連通性：

```bash
curl http://order-service
curl http://order-service.prod.svc.cluster.local
```

### 2. 如果 DNS 解析失敗

排查：

```bash
kubectl get pods -n kube-system | grep coredns
kubectl logs -n kube-system
```

常見原因：

AWS快速開戶 - CoreDNS 異常
- Pod DNSPolicy 配置錯誤
- 網絡插件故障
- 使用了錯誤的服務名稱

### 3. 如果 DNS 正常，但仍然連不上

檢查：

- Service 是否有 endpoints
- Pod readiness 是否通過
- NetworkPolicy 是否封鎖流量
- 應用是否監聽正確埠

查看 endpoints：

AWS快速開戶 ```bash
kubectl get endpoints order-service -n prod
```

若輸出為空，多半是 selector 對不上或 Pod 未就緒。

---

## 七、跨服務安全控制：不要讓所有服務互相直連

微服務一多，若網絡沒有邊界，後續排查與安全風險都會變大。

### 1. 使用 NetworkPolicy 限制訪問

例如只允許 `api-service` 訪問 `order-service`：

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-to-order
namespace: prod
spec:
podSelector:
matchLabels:
app: order-service
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: api-service
ports:
- protocol: TCP
port: 8080
```

### 2. 配置 TLS/mTLS

如果跨節點、跨集群或跨 VPC 傳輸敏感資料，建議加密通訊。

實操上可考慮：

- Ingress 層配置 HTTPS
- 服務網格中啟用 mTLS
- 內部 API 使用短期憑證或 Token 驗證

### 3. 密鑰與配置不要寫死在映像中

推薦使用：

- Secret 管理密碼、Token、憑證
- ConfigMap 管理非敏感配置
- 依環境拆分配置，不要共用一套

---

## 八、配置中心與環境隔離：避免發版後才發現連錯庫

微服務數量一多，最常見的人為失誤是：

- 測試服務連到正式資料庫
- 正式環境誤用測試 MQ
- 服務 A 調用了另一個命名空間的舊版本服務

### 建議做法

1. **命名空間隔離**：dev、test、staging、prod 分開。
2. **配置分層**：基礎配置、環境配置、敏感配置分開管理。
3. **資源命名規則固定**：如 `order-service.prod`、`mysql-order.prod`。
4. **發版前檢查環境變數**：特別是資料庫地址、MQ Topic、Redis 位址。

可用以下命令檢查容器內實際環境變數：

```bash
kubectl exec -it -n prod -- env
```

---

## 九、資料一致性問題：拆分後最容易踩坑的地方

服務拆分後，訂單、庫存、支付之間不可能再完全依靠本地交易處理。

### 1. 不要一開始就上複雜分散式事務

AWS快速開戶 更常見、也更實用的方法是：

AWS快速開戶 - 同步接口保證局部成功
- 後續狀態變更透過消息事件傳遞
- 消費端做到冪等
- 補償流程可重試

### 2. 冪等處理一定要做

例如支付成功消息可能重複投遞，庫存扣減也可能重試執行。

處理方式：

- 以訂單號、支付流水號作為唯一鍵
- 執行前先檢查是否已處理
- 消息消費記錄落庫

### 3. 一個常見流程範例

AWS快速開戶 1. 訂單服務建立訂單，狀態為 `PENDING`
2. 調用支付服務
3. 支付成功後發送 `payment.success` 事件
4. 庫存服務消費事件並扣減庫存
5. 通知服務發送簡訊或郵件
6. 若扣庫存失敗，進入補償或人工處理隊列

這類流程的重點不是“絕對同步”，而是“狀態可追蹤、可補償”。

---

## 十、性能優化：微服務變慢時先查哪裡

AWS快速開戶 ### 1. 先看是否為網絡問題

可在 Pod 內測試延遲：

```bash
time curl -o /dev/null -s http://order-service
```

如果偶發慢，可再檢查：

- Node 間網絡延遲
- 跨可用區部署導致 RTT 增加
- Ingress 或 Gateway 轉發層是否瓶頸

### 2. 看連接池是否耗盡

常見現象：

- 程式 CPU 不高，但大量請求超時
- 資料庫 QPS 正常，但應用端拿不到連接

需檢查：

- HTTP 連接池大小
- MySQL 連接池大小
- Redis 連接池大小
- gRPC channel 是否正確複用

### 3. 看執行緒池是否阻塞

很多同步調用鏈過長的服務，最後不是慢在網絡，而是執行緒池被阻塞。

建議觀察：

- Tomcat/Netty 工作執行緒
- 業務執行緒池排隊情況
- MQ 消費執行緒堆積

### 4. 資源配置建議

對一般 Java 微服務初始配置，可先從以下級別起步：

- 開發環境：0.5 核 CPU / 512Mi 記憶體
- 測試環境：1 核 CPU / 1Gi 記憶體
- 生產環境：1~2 核 CPU / 2~4Gi 記憶體

實際應根據 GC、QPS、平均延遲與峰值負載調整，不要只看 CPU 使用率。

---

## 十一、可觀測性配置：沒有追蹤就很難排查微服務問題

微服務出現錯誤時，單看某一台伺服器日誌通常不夠。

至少要有三類資料：

### 1. 日誌

要求：

- 所有服務統一輸出 JSON 日誌
- 每筆請求帶 traceId
- 錯誤日誌包含服務名、環境、埠、實例 ID

AWS快速開戶 ### 2. 指標

至少關注：

- QPS
- P95/P99 延遲
- 5xx 比例
- JVM 記憶體
- 執行緒池使用率
- 資料庫連接池使用率

### 3. 鏈路追蹤

當訂單建立失敗時，要能快速看到：

- 是 API Gateway 慢
- 還是訂單服務調支付超時
- 或庫存服務處理慢

AWS快速開戶 如果沒有 traceId，跨服務排查時間會非常長。

---

## 十二、常見故障排查清單

下面是實際專案最常遇到的幾類問題與排查方式。

### 故障 1：A 服務無法調用 B 服務

排查順序：

1. `kubectl get svc`
2. `kubectl get endpoints`
3. Pod 內 `nslookup`
4. Pod 內 `curl`
5. 檢查 NetworkPolicy
6. 檢查應用監聽埠與健康檢查

### 故障 2：服務偶發超時

重點看：

- 是否跨可用區部署
- 是否 DNS 查詢慢
- 是否連接池不足
- 是否重試次數過多
- 下游是否有 GC 或慢 SQL

### 故障 3：發版後部分請求 502/503

檢查：

- readinessProbe 是否過早放量
- 滾動更新過程中最小可用 Pod 是否足夠
- Ingress 後端 endpoints 是否瞬間為空
- 啟動時間較長的服務是否需要調整 `initialDelaySeconds`

### 故障 4：消息重複消費

檢查：

- 消費邏輯是否冪等
- 消費成功後是否正確提交 offset
- 消息處理超時是否導致重投
- 死信隊列與重試隊列是否設置合理

### 故障 5：某個服務 CPU 不高但響應很慢

通常排查：

- 執行緒池滿
- 外部依賴等待時間長
- 連接池耗盡
- 鎖競爭
- 磁碟 IO 或日誌阻塞

---

## 十三、部署最佳實踐：一套能落地的微服務運行標準

如果你正在建立一套可維護的雲原生微服務架構，建議至少落實以下規範：

1. **每個服務都有健康檢查**：readiness 與 liveness 分開。
2. **每個服務都有資源 requests/limits**：避免搶占。
3. **每個服務都有超時與重試配置**：且數值固定化。
4. **每個服務都有統一日誌格式與 traceId**。
5. **所有服務禁止直連他人資料庫**。
6. **同步與非同步通訊邊界清楚**。
7. **重要服務至少多副本部署**。
8. **跨可用區部署前先測網絡延遲**。
9. **對外入口統一經過 Gateway 或 Ingress**。
10. **所有配置變更可追溯，可回滾。**

---

## 十四、結語：先拆對，再把通訊做穩

微服務最大的難點不在「拆」本身，而在拆完後是否還能穩定運行。

實務上，最有效的落地路線通常是：

- 先按業務邊界拆出第一批服務
- 在 Kubernetes 中建立標準部署模板
- 明確同步與非同步通訊方式
- 為所有調用補上超時、重試、熔斷與限流
- 補齊日誌、指標與鏈路追蹤
- 再逐步優化資料一致性與性能

如果你現在正卡在某個具體環節，例如：

- Kubernetes 內部服務無法互通
- Ingress 配置後域名無法訪問
- gRPC 與 HTTP 不知道如何選
- 訂單與庫存拆分後資料一致性出問題

AWS快速開戶 最實際的做法不是再看抽象架構圖，而是按本文的排查與配置順序逐項落地。只要服務邊界清楚、通訊策略合理、故障可觀測，微服務架構就能真正支撐業務，而不是增加系統複雜度。