# 單體架構 — 一個程式包辦所有事
my-shop-app/
  ├── user.py        # 用戶管理
  ├── order.py       # 訂單處理
  ├── payment.py     # 支付功能
  └── notification.py # 通知推播
  → 全部打包成一個程式，部署在一台伺服器
Code language: PHP (php)

# 微服務架構 — 每個功能是獨立的程式
user-service/        → 獨立部署、獨立資料庫
order-service/       → 獨立部署、獨立資料庫
payment-service/     → 獨立部署、獨立資料庫
notification-service/ → 獨立部署、獨立資料庫
  → 各自打包，可以分別部署在不同伺服器
Code language: PHP (php)

用戶下單的流程：

[Client] → [Order Service]
               │
               ├──呼叫──→ [User Service]    (REST API：確認用戶存在)
               │
               ├──呼叫──→ [Payment Service]  (REST API：處理扣款)
               │
               └──發訊息→ [Notification Service] (Message Queue：寄確認信)
Code language: CSS (css)

# 特徵 1：每個服務有自己的入口
# user_service/main.py
app = FastAPI()

@app.get("/users/{id}")
def get_user(id: int):
    ...

# 特徵 2：呼叫其他服務用 HTTP
import httpx

async def verify_payment(order_id: str):
    response = await httpx.get(f"http://payment-service:8001/verify/{order_id}")
    return response.json()
# ↑ 注意：這裡不是 import 另一個模組，而是「發 HTTP 請求到另一台機器」
Code language: PHP (php)

[Order Service] →  放入訊息  → [ Queue ] →  取出處理  → [Email Service]
  (Producer)         │        (Message)        │         (Consumer)
                     │                         │
              「訂單 #123 完成」           「寄確認信給用戶」
Code language: CSS (css)

# 直接呼叫（同步）— 有問題
[Order Service] ──呼叫──→ [Email Service]
                  │
            如果 Email Service 掛了？
            Order Service 也卡住了！

# 透過 Queue（非同步）— 更穩
[Order Service] → [Queue] → [Email Service]
                    │
            如果 Email Service 掛了？
            訊息留在 Queue 裡，等 Email Service 恢復再處理。
            Order Service 完全不受影響！
Code language: CSS (css)

場景 1：背景任務
用戶上傳圖片 → Queue → 圖片壓縮服務（慢慢處理，用戶不用等）

場景 2：流量削峰
雙 11 瞬間湧入 10 萬筆訂單 → Queue 排隊 → 後端慢慢消化

場景 3：事件驅動
用戶註冊 → Queue → 同時觸發：寄歡迎信 + 初始化設定 + 發優惠券

# Producer（放訊息）
import pika  # RabbitMQ 的 Python 套件

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='order_completed')

channel.basic_publish(
    exchange='',
    routing_key='order_completed',       # 指定放進哪個 Queue
    body='{"order_id": "123", "user": "alice"}'  # 訊息內容
)
# ↑ 放完就走，不等回應
Code language: PHP (php)

# Consumer（收訊息）
def handle_message(ch, method, properties, body):
    order = json.loads(body)             # 解析訊息
    send_email(order['user'])            # 處理：寄信
    ch.basic_ack(delivery_tag=method.delivery_tag)  # 告訴 Queue：我處理完了
    # ↑ ACK 很重要 — 沒有 ACK，Queue 會認為訊息沒處理成功，會重新派送

channel.basic_consume(queue='order_completed', on_message_callback=handle_message)
channel.start_consuming()  # 持續監聽，有訊息就處理
Code language: PHP (php)

用戶 Alice：1 秒內發了 100 個請求

前 10 個 → 200 OK（正常回應）
第 11 個起 → 429 Too Many Requests（被限流了）

HTTP/1.1 429 Too Many Requests
Retry-After: 30
{
  "error": "Rate limit exceeded. Try again in 30 seconds."
}
Code language: JavaScript (javascript)

策略 1：Token Bucket（令牌桶）

想像一個桶子，每秒自動放入 10 個令牌。
每個請求需要消耗 1 個令牌。
桶子空了 → 請求被拒絕。
桶子最多存 20 個令牌 → 允許短暫爆發流量。

  [每秒補充 10 個]
        ↓
   ┌──────────┐
   │ 🪙🪙🪙🪙🪙  │  ← 桶子（最多 20 個）
   │ 🪙🪙🪙🪙🪙  │
   └────┬─────┘
        ↓
   [請求消耗令牌]
Code language: CSS (css)

策略 2：Sliding Window（滑動窗口）

以「過去 60 秒」為窗口，計算請求數量。
窗口隨時間滑動，不是固定的「每分鐘重置」。

  時間軸：
  |----60秒窗口----|
       ← 滑動 ←
  超過上限 → 拒絕

# 使用 FastAPI + slowapi 實現速率限制
from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)  # 用 client IP 識別身分

@app.get("/api/search")
@limiter.limit("10/minute")  # 每分鐘最多 10 次
async def search(request: Request, q: str):
    return {"results": do_search(q)}
# ↑ 超過 10 次就自動回傳 429
Code language: PHP (php)

沒有 Rate Limiting：
- 惡意用戶發送百萬請求 → 伺服器掛掉（DDoS 攻擊）
- 某個壞掉的程式無限重試 → 吃光所有資源
- 免費用戶和付費用戶搶同一份資源

有 Rate Limiting：
- 每個 IP 每秒最多 100 次 → 防 DDoS
- 每個 API Key 每天最多 1000 次 → 按方案分級
- 特定 endpoint 每分鐘 10 次 → 保護昂貴操作

沒有 API Gateway：
Client 需要知道每個服務的位址，自己去呼叫

[Client] → http://user-service:8001/users
[Client] → http://order-service:8002/orders
[Client] → http://payment-service:8003/pay
         → 如果有 20 個服務，Client 要記 20 個位址？
Code language: JavaScript (javascript)

有 API Gateway：
Client 只需知道一個位址

[Client] → https://api.myshop.com/users    ─→ [User Service]
[Client] → https://api.myshop.com/orders   ─→ [Order Service]
[Client] → https://api.myshop.com/pay      ─→ [Payment Service]
         → 只要記一個 api.myshop.com，Gateway 幫你轉發
Code language: JavaScript (javascript)

請求的完整旅程：

[Client] → [API Gateway]
              │
              ├─ 1. 認證：JWT Token 有效嗎？
              ├─ 2. 限流：這個用戶超過上限了嗎？
              ├─ 3. 日誌：記錄這筆請求
              ├─ 4. 路由：決定轉發給哪個服務
              ├─ 5. 轉換：把外部格式轉成內部格式
              │
              └─→ [對應的微服務]
Code language: CSS (css)

Reverse Proxy（反向代理）：
- 基本的流量轉發
- 負載均衡
- SSL 終止
→ 通用工具，不管你的架構是什麼

API Gateway：
- 上述所有功能，加上：
- API 認證 / 授權
- 速率限制（Rate Limiting）
- 請求/回應轉換
- API 版本管理
- 開發者入口網站
→ 專為微服務 API 設計
Code language: JavaScript (javascript)

# nginx.conf — 簡化版 API Gateway 設定
server {
    listen 443 ssl;
    server_name api.myshop.com;

    # 路由到 User Service
    location /users {
        proxy_pass http://user-service:8001;
    }

    # 路由到 Order Service
    location /orders {
        proxy_pass http://order-service:8002;
    }

    # 限流設定
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    # ↑ 每個 IP 每秒最多 10 個請求
}
Code language: PHP (php)

現實場景：用戶按了「付款」按鈕

1. Client 發送扣款請求 → 網路超時，沒收到回應
2. Client 不確定有沒有成功，自動重試
3. Server 收到兩次扣款請求

沒有冪等性：扣了兩次錢！用戶被收 $200 而不是 $100
有冪等性：第二次請求被辨識為重複，只扣一次 $100

第一次請求：
POST /api/charge
Headers:
  Idempotency-Key: "abc-123-xyz"    ← 唯一的請求 ID
Body:
  { "amount": 100, "user": "alice" }

Server 處理 → 扣款 $100 → 記錄 "abc-123-xyz" 已處理

第二次請求（重試）：
POST /api/charge
Headers:
  Idempotency-Key: "abc-123-xyz"    ← 同一個 ID
Body:
  { "amount": 100, "user": "alice" }

Server 發現 "abc-123-xyz" 已經處理過 → 直接回傳上次的結果，不再扣款
Code language: JavaScript (javascript)

天生冪等（做幾次結果都一樣）：
  GET    /users/123        → 永遠回傳同一個用戶（只是查詢）
  PUT    /users/123        → 永遠把用戶設為指定的值（整個覆蓋）
  DELETE /users/123        → 刪一次是刪除，刪第二次還是「已刪除」

不是天生冪等（需要額外處理）：
  POST   /orders           → 每次呼叫可能建立新訂單
  PATCH  /users/123/balance → 「餘額 +100」執行兩次就 +200 了

# 實作冪等性的簡化範例
@app.post("/api/charge")
async def charge(request: Request):
    idempotency_key = request.headers.get("Idempotency-Key")

    # 1. 檢查這個 key 是否已經處理過
    existing = await db.get(f"idempotency:{idempotency_key}")
    if existing:
        return existing  # 直接回傳上次的結果
        # ↑ 關鍵：不再執行扣款，而是回傳之前的結果

    # 2. 第一次處理：執行扣款
    result = await process_payment(request.body)

    # 3. 儲存結果，標記這個 key 已處理
    await db.set(f"idempotency:{idempotency_key}", result, expire=86400)
    # ↑ 保留 24 小時，之後自動清除

    return result
Code language: PHP (php)

一個完整的微服務系統長這樣：

[Client App]
     │
     ▼
[API Gateway]  ← 概念 29：統一入口、認證、限流
     │
     ├── Rate Limiting  ← 概念 28：擋掉過多請求
     │
     ▼
[User Service] ←─ REST API ─→ [Order Service]  ← 概念 26：微服務拆分
                                    │
                                    ▼
                              [Message Queue]  ← 概念 27：非同步通訊
                                    │
                              ┌─────┴─────┐
                              ▼           ▼
                     [Email Service] [Payment Service]
                                         │
                                    Idempotency Key  ← 概念 30：防重複扣款
Code language: CSS (css)