AWS企業帳號開通雲原生應用開發指南：從傳統應用到雲原生轉型

亞馬遜雲AWS / 2026-10-21 15:24:35

# 雲原生應用開發指南：從傳統應用到雲原生轉型

很多團隊搜尋這個主題，並不是想了解名詞定義，而是卡在真正落地的幾個環節：

- 傳統單體應用怎麼拆分，才不會一上雲就出問題
- 伺服器、資料庫、網路資源應該怎麼選
- 應用如何容器化，如何部署到 Kubernetes
- 配置、日誌、監控、備份要怎麼做才便於維護
- 上線後遇到連接失敗、端口不通、性能下降該怎麼排查

本文不講空泛概念，直接按照真實工程流程，提供一套從評估、改造、部署到排障的操作指南。

---

## 一、開始前先明確：你現在要解決的是哪一類轉型問題

在動手之前，先對現有系統做一次盤點。這一步做不好，後面部署越快，返工越多。

建議按以下清單整理：

### 1. 應用現狀盤點

- 應用是單體架構還是已有部分服務拆分
- 使用語言與框架：Java、Node.js、Python、Go、.NET
- 當前部署方式：實體機、虛擬機、雲伺服器
- 啟動方式：jar、war、systemd、Windows 服務、Docker
- 是否依賴本地檔案、共享磁碟、Session 黏性

### 2. 基礎設施盤點

- 現有伺服器數量、CPU、記憶體、磁碟使用率
- 是否有公網 IP
- 是否已有負載均衡、VPC、子網、安全組
- 是否使用 MySQL、Redis、MQ 等中介服務
- 備份與快照機制是否已建立

### 3. 遷移風險盤點

最常見的問題通常出現在：

- 應用寫死本機 IP 或資料庫位址
- 檔案上傳存在本地磁碟，Pod 重建後資料丟失
- 使用本地 Session，導致多副本登入狀態不一致
- 資料庫連接數配置過低，上線後大量報錯
- 安全組或防火牆沒有放行對應端口

如果你在盤點階段就發現以上問題，先修正，再進入雲原生改造。

---

AWS企業帳號開通 ## 二、雲上資源怎麼準備：先把伺服器、網路、資料庫配好

很多團隊一開始就寫 Dockerfile、建 K8s YAML，結果部署上去後發現網路不通、資料庫連不上。正確順序應該是先準備基礎資源。

## 三、雲伺服器購買與實例建立建議

如果你還沒有 Kubernetes 環境，通常需要先準備幾台 Linux 雲伺服器作為測試或自建叢集節點。

### 1. 地域與可用區選擇

實際選擇原則：

- 使用者主要在華南，就優先選華南地域
- 資料庫與應用必須部署在同一地域，避免跨地域延遲
- 同一套業務的應用與資料庫盡量在同一可用區，先降低網路抖動
- 如需高可用，再將部分節點分散到不同可用區

### 2. CPU／記憶體／硬碟怎麼選

初期測試環境建議：

- 應用伺服器：2 核 4GB 或 4 核 8GB
- MySQL：2 核 4GB 起步，小流量可用
- Redis：1 核 2GB 或以上
- 系統碟：50GB 以上 SSD
- 資料碟：依據日誌、上傳檔案、資料量規劃

如果是 Java 應用，記憶體不要壓得太低。容器限制與 JVM 參數沒有對齊時，很容易 OOM。

### 3. Linux 系統選擇建議

AWS企業帳號開通 常見選擇：

- Ubuntu 22.04 LTS
- Debian 12
- Rocky Linux 9
- CentOS 替代版本

如果你準備跑 Kubernetes，建議優先選社群文檔完整、套件更新穩定的版本，不要使用太舊的系統映像。

### 4. 實例建立時要注意的配置

建立雲伺服器時，至少確認以下項目：

- 已分配公網 IP 或有跳板機可連入
- 安全組開放 22 端口（SSH）
- 如果後續測試 Web，開放 80、443
- 如果需要遠端桌面，Windows 開放 3389
- 磁碟性能類型與 IOPS 是否符合需求
- 是否啟用自動快照

---

## 四、SSH 遠端連接與基礎安全設定

建立完 Linux 實例後，先完成遠端登入與基礎加固。

### 1. SSH 連接

本機執行：

```bash
ssh root@你的公網IP
```

如果是金鑰登入：

```bash
ssh -i ~/.ssh/id_rsa root@你的公網IP
```

### 2. 常見 SSH 連不上排查

依序檢查：

- 安全組是否開放 TCP 22
- 雲伺服器系統防火牆是否允許 22
- 公網 IP 是否正確
- 是否綁定錯誤網卡或子網
- 本地網路是否限制對外 SSH

### 3. Linux 防火牆設定

如果使用 Ubuntu UFW：

```bash
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status
```

如果使用 firewalld：

AWS企業帳號開通 ```bash
sudo firewall-cmd --permanent --add-port=22/tcp
sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports
```

注意：安全組放行不代表系統防火牆也放行，兩邊都要檢查。

AWS企業帳號開通 ---

## 五、從傳統應用到容器化：先做這 4 件事

不是所有應用都能直接打包成容器。容器化前，建議先完成以下改造。

### 1. 把配置從程式碼中抽離

AWS企業帳號開通 不要把以下內容寫死在程式裡：

- 資料庫位址
- Redis 位址
- MQ 帳密
- 第三方 API 金鑰
- 檔案路徑

應改為：

- 環境變數
- 配置中心
- Kubernetes ConfigMap
- Kubernetes Secret

### 2. 移除本地狀態依賴

容器重建是常態，因此以下設計要調整：

- 上傳檔案不要存本地，改存物件儲存或掛載持久卷
- Session 不存本機記憶體，改用 Redis
- 日誌不要只寫本地檔案，至少輸出到 stdout/stderr

### 3. 調整啟動與停止邏輯

應用需要支援：

- 啟動健康檢查
- 優雅停止
- 啟動超時控制
- 依賴服務不可用時的重試機制

### 4. 明確資源需求

部署到 K8s 前，要先知道：

- 最低 CPU 需求
- 平均記憶體使用
- 高峰期連接數
- 啟動時間

否則 requests 與 limits 很難配置準確。

---

## 六、Dockerfile 實踐：把傳統應用打包成可部署鏡像

下面以 Java Spring Boot 為例。

### 1. 基礎 Dockerfile

```dockerfile
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/app.jar"]
```

### 2. 更適合生產的寫法

```dockerfile
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/app.jar app.jar
ENV JAVA_OPTS="-Xms512m -Xmx1024m"
EXPOSE 8080
ENTRYPOINT ["sh","-c","java $JAVA_OPTS -jar /app/app.jar"]
```

### 3. 建構與測試

```bash
docker build -t myapp:1.0.0 .
docker run -d --name myapp -p 8080:8080 myapp:1.0.0
```

檢查應用：

```bash
curl http://127.0.0.1:8080/actuator/health
```

### 4. 容器化常見問題

#### 問題 1：容器啟動後立刻退出

排查：

```bash
docker logs myapp
```

常見原因：

- 啟動命令錯誤
- jar 檔案路徑不對
- 應用啟動失敗但未輸出到標準輸出

#### 問題 2：容器內能啟動，外部訪問不到

檢查：

- 應用是否監聽 0.0.0.0 而不是 127.0.0.1
- Docker 映射端口是否正確
- 雲伺服器安全組與防火牆是否開放對應端口

---

## 七、鏡像推送與倉庫管理

容器化完成後，需要將鏡像推送到鏡像倉庫，供 Kubernetes 拉取。

```bash
docker tag myapp:1.0.0 registry.example.com/project/myapp:1.0.0
docker login registry.example.com
docker push registry.example.com/project/myapp:1.0.0
```

如果 K8s 拉取失敗，優先檢查：

- 鏡像位址是否正確
- Tag 是否存在
- 倉庫認證 Secret 是否已建立
- 節點是否能連外或能訪問私有倉庫

---

## 八、Kubernetes 部署實戰：Deployment、Service、Ingress 怎麼配

下面是最小可用範例。

### 1. Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 2
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: registry.example.com/project/myapp: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
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
livenessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 30
periodSeconds: 20
```

### 2. Service

```yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP
```

### 3. Ingress

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-service
port:
number: 80
```

### 4. 部署命令

```bash
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
```

### 5. 查看狀態

```bash
kubectl get pods -o wide
kubectl get svc
kubectl get ingress
kubectl describe pod
kubectl logs
```

---

## 九、應用連接 MySQL 與 Redis：最常卡住的配置點

雲原生改造時，應用本身能啟動，不代表依賴正常。

## 十、建立資料庫實例時怎麼選

如果使用雲資料庫而不是自建 MySQL，建立實例時重點看這些參數：

- 部署地域與應用一致
- 選擇私網連接，避免不必要公網暴露
- 根據連接數與資料量選 CPU、記憶體、磁碟
- 啟用自動備份與保留週期
- 設定白名單或安全組規則

AWS企業帳號開通 ### 1. MySQL 連接字串示例

```properties
spring.datasource.url=jdbc:mysql://mysql.internal:3306/appdb?useSSL=false&serverTimezone=Asia/Taipei
spring.datasource.username=appuser
spring.datasource.password=yourpassword
```

### 2. Redis 配置示例

```properties
spring.data.redis.host=redis.internal
spring.data.redis.port=6379
spring.data.redis.password=yourpassword
```

### 3. MySQL 連接失敗排查

AWS企業帳號開通 常見報錯：

- Connection timed out
- Communications link failure
- Access denied for user
- Too many connections

排查順序：

1. 先從 Pod 內測試 DNS

```bash
kubectl exec -it -- nslookup mysql.internal
```

2. 測試端口

```bash
kubectl exec -it -- sh
nc -zv mysql.internal 3306
```

3. 檢查安全組、防火牆、白名單

4. 檢查帳號授權

```sql
SHOW GRANTS FOR 'appuser'@'%';
```

5. 檢查資料庫最大連接數

```sql
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
```

### 4. Redis 連接失敗排查

重點檢查：

- Redis 是否僅監聽 127.0.0.1
- 是否設定 requirepass
- 雲安全組是否開放對應來源
- 客戶端是否使用正確 DB 與密碼

---

## 十一、配置管理：ConfigMap 與 Secret 的正確用法

AWS企業帳號開通 不要把密碼直接寫進 Deployment。

### 1. ConfigMap 示例

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myapp-config
data:
SPRING_PROFILES_ACTIVE: prod
MYSQL_HOST: mysql.internal
REDIS_HOST: redis.internal
```

### 2. Secret 示例

```yaml
apiVersion: v1
kind: Secret
metadata:
name: myapp-secret
type: Opaque
stringData:
MYSQL_USERNAME: appuser
MYSQL_PASSWORD: yourpassword
REDIS_PASSWORD: yourpassword
```

### 3. 在 Deployment 中引用

```yaml
envFrom:
- configMapRef:
name: myapp-config
- secretRef:
name: myapp-secret
```

這樣做的好處不是理論上的規範，而是後續你切換測試、預發、生產環境時，不用反覆修改鏡像。

---

## 十二、網路配置實踐：公網、私網、端口開放怎麼處理

雲原生應用最怕的不是部署失敗，而是你以為服務起來了，實際外部根本訪問不到。

### 1. 私網優先

內部服務之間通訊，優先使用：

- VPC 私網
- Kubernetes Service 名稱
- 雲資料庫內網位址

不要讓應用繞公網訪問資料庫。

### 2. 對外暴露方式

AWS企業帳號開通 常見選擇：

AWS企業帳號開通 - 開發測試：NodePort
- 正式環境：Ingress + 負載均衡

### 3. 端口不通排查

按這個順序查：

1. Pod 是否 Running
2. readinessProbe 是否通過
3. Service selector 是否匹配 Pod label
4. Ingress 規則是否正確
5. 負載均衡監聽端口是否建立
6. 安全組是否開放 80/443
7. DNS 是否解析到正確 IP

### 4. 網路延遲測試

AWS企業帳號開通 ```bash
ping mysql.internal
traceroute mysql.internal
curl -w "DNS:%{time_namelookup} TCP:%{time_connect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" -o /dev/null -s http://myapp.example.com
```

如果跨可用區或跨地域存取明顯變慢，就要重新調整應用與資料庫位置。

---

## 十三、持久化與備份：不要把資料留在會被重建的容器裡

如果你的應用仍然要寫檔，例如匯出報表、暫存圖片、任務中間結果，至少要明確資料類型。

### 1. 適合放持久卷的資料

- 暫時性共享檔案
- 需要 Pod 重建後仍保留的資料
- 單機服務的工作檔

### 2. 不建議直接放容器內的資料

- 使用者上傳檔案
- 正式環境備份檔
- 唯一性業務資料

AWS企業帳號開通 ### 3. 備份建議

- 資料庫啟用自動備份
- 雲伺服器開啟快照策略
- 關鍵配置檔納入 Git 管理
- Kubernetes YAML 與 Helm Values 建立版本控制

### 4. 資料恢復演練

很多團隊有備份，卻沒做恢復測試。建議每月至少驗證一次：

- MySQL 邏輯備份可否還原
- 快照能否建立新磁碟
- 應用重新部署後能否連回恢復後資料庫

---

## 十四、CI/CD 配置實踐：讓部署可重複，而不是靠手工操作

轉成雲原生後，如果還在手動上傳 jar、手動改配置，會很快失控。

一條基本流水線至少包含：

1. 拉取程式碼
2. 執行單元測試
3. 打包鏡像
4. 推送鏡像倉庫
5. 更新 Kubernetes 部署
6. 驗證健康檢查
7. 失敗自動回滾或人工回滾

### 1. 部署更新命令

```bash
kubectl set image deployment/myapp myapp=registry.example.com/project/myapp:1.0.1
kubectl rollout status deployment/myapp
```

### 2. 回滾命令

```bash
kubectl rollout undo deployment/myapp
```

### 3. 發版常見問題

- 鏡像已更新但 Pod 沒重建
- 使用 latest 導致版本不可追蹤
- 配置已改但沒觸發 Deployment 更新
- readinessProbe 太嚴格，導致新版本一直無法就緒

---

## 十五、性能調優：從伺服器、容器、資料庫三層一起看

雲原生不是部署完就結束，性能問題往往在上線後才出現。

AWS企業帳號開通 ### 1. 容器資源調整

先看實際使用量：

```bash
kubectl top pod
kubectl top node
```

調整原則：

- CPU 長期打滿：提高 limits，或增加副本數
- 記憶體接近上限：提高 limits，檢查是否存在記憶體洩漏
- 啟動慢：增加 initialDelaySeconds

### 2. JVM 參數與容器記憶體一致

例如容器 limit 為 1Gi，不要把 JVM 設成 1500m。

### 3. MySQL 性能觀察

優先檢查：

- 慢查詢
- 缺失索引
- 連接池配置
- 大量短連接
- 事務過長

### 4. 高並發建議

- 應用層做水平擴容
- Session 外置到 Redis
- 熱點資料加快取
- 查詢使用索引並分頁
- 靜態資源走 CDN 或物件儲存

---

## 十六、典型故障排查案例

下面是實際最常遇到的幾類問題。

### 案例 1：Pod 一直 CrashLoopBackOff

排查命令：

```bash
kubectl logs --previous
kubectl describe pod
```

常見原因：

- 環境變數缺失
- 資料庫連接失敗導致啟動退出
- JVM 記憶體過小
- 掛載路徑不存在

### 案例 2：Service 有 IP，但外部訪問 502/504

檢查：

- Pod readiness 是否成功
- Ingress 後端服務端口是否寫錯
- 應用啟動是否超時
- 上游代理超時設定是否過低

### 案例 3：應用偶發連不上 MySQL

常見根因：

- 連接池過小
- MySQL 最大連接數不足
- DNS 解析不穩定
- 應用與資料庫跨可用區導致延遲抖動

### 案例 4：升級後 CPU 飆高

檢查方向：

- 新版是否有死循環或過度重試
- 日誌等級是否被打到 debug
- readiness 失敗導致頻繁重建
- 查詢語句是否變慢導致執行緒堆積

---

## 十七、從傳統應用遷移到雲原生的推薦實施順序

如果你需要一條可執行路線，建議按這個順序推進：

### 階段 1：基礎設施準備

- 建立 VPC、子網、安全組
- 建立 Linux 雲伺服器或 Kubernetes 叢集
- 建立 MySQL、Redis 等依賴服務
- 配置私網、白名單、備份

### 階段 2：應用改造

- 配置外部化
- Session 外置
- 檔案存儲調整
- 健康檢查接口補齊
- 容器化打包

### 階段 3：部署驗證

- 部署到測試環境
- 驗證資料庫連接
- 驗證 Redis、MQ、檔案服務
- 壓測 CPU、記憶體、延遲
- 修正 requests/limits

### 階段 4：上線與回滾方案

- 設定 CI/CD
- 小流量灰度發布
- 監控錯誤率與資源消耗
- 保留上一版鏡像與資料備份
- 明確回滾步驟

---

AWS企業帳號開通 ## 十八、實際落地時最重要的 8 條建議

1. 先解決配置、狀態、檔案依賴，再談微服務拆分。
2. 應用、資料庫、Redis 優先放同一地域私網通訊。
3. 安全組與系統防火牆要雙重檢查。
4. 不要把密碼直接寫入 YAML。
5. readinessProbe 與 livenessProbe 必須分開設計。
6. 任何正式環境更新都要可回滾。
7. 備份不只要有，還要做恢復驗證。
8. 先完成單體容器化，再逐步拆分服務，風險更低。

---

## 結語

從傳統應用轉向雲原生，最容易失敗的原因不是技術棧選錯，而是跳過了基礎配置與操作細節。真正可落地的做法，是按「資源準備 → 應用改造 → 容器化 → Kubernetes 部署 → 資料庫連接 → 網路與安全 → 性能調整 → 故障排查」這條路線穩步推進。

如果你正在實作這類轉型，建議先拿一個低風險業務做試點，完整走一遍部署、擴容、備份、回滾和排障流程。等第一個服務跑穩，再複製方法到其他應用，效率會比一次性全面重構更高。