使用 Kubernetes 部署 PHP 留言板應用（含 Redis 架構）

教程概述

本教程將深入指導你如何借助 Kubernetes 構建一個多層 Web 應用系統。此系統具備高可用性、可擴展性和讀寫分離的特性，主要由以下核心組件構成：

• 單實例 Redis 領導者（Leader）：作為 Redis 集群的核心節點，專門負責處理數據的寫入操作。它就像是整個數據寫入流程的“指揮官”，確保所有的寫入請求都能被準確無誤地處理。
• 多個 Redis 跟隨者（Follower）：這些跟隨者節點的主要任務是分擔數據的讀取負載。通過將讀取請求分散到多個跟隨者節點上，可以顯著提升系統的讀取性能和吞吐量。
• PHP 前端服務集群：為用戶提供直觀的交互界面，使用戶能夠方便地與留言板應用進行交互。這個集群由多個運行 PHP 代碼的 Pod 組成，通過 Kubernetes 的服務發現和負載均衡機制，確保用戶的請求能夠被均勻地分配到各個 Pod 上。

技術架構特點

此架構采用了典型的 讀寫分離模式，這是一種在分布式系統中廣泛應用的設計模式，具有以下優點：

• 寫入操作集中于 Redis 領導者節點：將所有的寫入請求集中處理，有助于保證數據的一致性和完整性。因為只有一個領導者節點負責寫入，避免了多個節點同時寫入可能導致的數據沖突問題。
• 讀取操作由多個 Redis 跟隨者節點處理：多個跟隨者節點可以并行地處理讀取請求，大大提高了系統的讀取性能。同時，當領導者節點出現故障時，跟隨者節點還可以作為備用節點，提升系統的容錯能力。
• 前端服務通過 Kubernetes Service 實現服務發現與負載均衡：Kubernetes Service 為前端服務提供了一個穩定的網絡入口，使得前端應用能夠方便地發現并連接到后端的 Redis 服務。同時，Service 還內置了負載均衡機制，能夠將用戶的請求均勻地分配到多個前端 Pod 上，避免了單個 Pod 負載過高的問題。

準備工作

環境要求

• Kubernetes 集群：至少包含 2 個工作節點（非控制平面節點）。工作節點是運行應用程序容器的地方，多個工作節點可以提供更高的可用性和可擴展性。控制平面節點主要負責集群的管理和調度，與應用程序的運行沒有直接關系。
• kubectl 工具：需配置為可連接至目標集群。kubectl 是 Kubernetes 的命令行工具，通過它可以方便地與 Kubernetes 集群進行交互，如創建、刪除和管理各種資源。
• 版本要求：Kubernetes 服務器版本不低于 v1.14。較新的版本通常包含更多的功能和性能優化，同時也能提供更好的安全性和穩定性。

Redis 數據庫部署

Redis 主從架構原理

Redis 主從復制是一種數據同步機制，其核心特性包括：

• 主節點（Leader）：負責處理寫操作，并將數據變更同步至從節點。主節點就像是數據的“源頭”，所有的寫入請求都首先由主節點處理，然后主節點會將這些數據變更同步到所有的從節點上，確保從節點的數據與主節點保持一致。
• 從節點（Follower）：僅處理讀操作，實現讀寫分離。從節點主要用于分擔主節點的讀取壓力，通過將讀取請求分散到多個從節點上，可以提高系統的讀取性能和吞吐量。同時，從節點還可以作為備用節點，當主節點出現故障時，可以手動或自動將某個從節點提升為新的主節點，保證系統的高可用性。
• 高可用性：從節點可作為備用節點，提升系統容錯能力。當主節點出現故障時，系統可以快速切換到從節點繼續提供服務，從而避免了服務的中斷。此外，通過增加從節點的數量，還可以進一步提高系統的容錯能力和可靠性。

創建 Redis 領導者 Deployment

Deployment 是 Kubernetes 中用于管理無狀態應用的核心控制器，其主要功能包括：

• 定義 Pod 模板及副本數量：Deployment 通過定義 Pod 模板來描述應用程序的運行環境和配置信息，同時可以指定 Pod 的副本數量，實現應用程序的水平擴展。例如，在 Redis 領導者的 Deployment 中，我們可以指定只創建一個副本，因為 Redis 領導者通常只需要一個實例來處理寫入操作。
• 實現滾動更新與回滾機制：當需要對應用程序進行升級或修改配置時，Deployment 可以實現滾動更新，即逐步替換舊的 Pod 實例為新的 Pod 實例，確保服務的不間斷運行。如果更新過程中出現問題，還可以通過回滾機制將應用程序恢復到之前的版本。
• 自動監控并修復 Pod 故障：Deployment 會自動監控 Pod 的狀態，如果發現某個 Pod 出現故障或異常，會自動創建一個新的 Pod 實例來替換它，確保應用程序的正常運行。

# redis-leader-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: redis-leaderlabels:app: redisrole: leadertier: backend
spec:replicas: 1selector:matchLabels:app: redistemplate:metadata:labels:app: redisrole: leadertier: backendspec:containers:- name: leaderimage: "docker.io/redis:6.0.5"resources:requests:cpu: 100mmemory: 100Miports:- containerPort: 6379

部署執行命令

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml

通過執行該命令，Kubernetes 會根據指定的 Deployment 配置文件創建 Redis 領導者的 Pod 實例。

狀態驗證命令

kubectl get pods

執行該命令可以查看當前集群中所有 Pod 的狀態信息。如果 Redis 領導者的 Pod 正常運行，輸出結果中會顯示該 Pod 的名稱、狀態、重啟次數和運行時間等信息。

典型輸出：

NAME                           READY   STATUS    RESTARTS   AGE
redis-leader-fb76b4755-xjr2n   1/1     Running   0          13s

日志查看命令

kubectl logs -f deployment/redis-leader

通過執行該命令，可以實時查看 Redis 領導者 Deployment 中所有 Pod 的日志信息。這對于排查問題和監控應用程序的運行狀態非常有幫助。

創建 Redis 領導者服務

Kubernetes Service 概念

Service 是 Kubernetes 中實現服務發現的核心組件，其關鍵特性包括：

• 為一組 Pod 提供穩定的網絡入口：在 Kubernetes 中，Pod 的生命周期是短暫的，可能會因為各種原因（如故障、升級等）被銷毀和重新創建。Service 為一組 Pod 提供了一個穩定的網絡地址，使得其他應用程序可以通過這個地址訪問這些 Pod，而不需要關心 Pod 的具體位置和狀態。
• 支持基于標簽的動態選擇器：Service 可以通過標簽選擇器來動態地選擇要關聯的 Pod。例如，在 Redis 領導者服務中，我們可以通過標簽 app=redis、role=leader 和 tier=backend 來選擇所有符合這些標簽的 Pod。這樣，當有新的 Pod 創建或舊的 Pod 銷毀時，Service 會自動更新其關聯的 Pod 列表，確保服務的正常運行。
• 內置負載均衡機制（輪詢或會話親和性）：Service 內置了負載均衡機制，可以將客戶端的請求均勻地分配到關聯的 Pod 上。常見的負載均衡算法包括輪詢和會話親和性。輪詢算法會依次將請求分配到每個 Pod 上，而會話親和性算法會將同一個客戶端的請求始終分配到同一個 Pod 上，適用于需要保持會話狀態的應用程序。

# redis-leader-service.yaml
apiVersion: v1
kind: Service
metadata:name: redis-leaderlabels:app: redisrole: leadertier: backend
spec:ports:- port: 6379targetPort: 6379selector:app: redisrole: leadertier: backend

服務創建命令

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml

通過執行該命令，Kubernetes 會根據指定的 Service 配置文件創建 Redis 領導者服務。

服務列表查詢

kubectl get service

執行該命令可以查看當前集群中所有 Service 的信息，包括服務的名稱、類型、集群 IP、外部 IP 和端口等。

典型輸出：

NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    1m
redis-leader   ClusterIP   10.103.78.24 <none>        6379/TCP   16s

配置 Redis 跟隨者集群

讀寫分離架構優勢

部署多個 Redis 跟隨者節點的核心價值在于：

• 負載分擔：通過將讀請求分散到多個跟隨者節點上，可以顯著減輕主節點的讀取壓力，提升系統的吞吐量。特別是在高并發的場景下，多個跟隨者節點可以并行地處理讀取請求，大大提高了系統的響應速度。
• 高可用性：當領導者節點出現故障時，可以手動或自動將某個跟隨者節點提升為新的領導者節點，繼續提供服務，從而避免了服務的中斷。此外，多個跟隨者節點還可以作為備用節點，提高了系統的容錯能力。
• 水平擴展：通過增加跟隨者節點的數量，可以線性提升系統的讀處理能力。當系統的讀取負載增加時，只需要簡單地增加跟隨者節點的數量，就可以滿足業務的需求，而不需要對系統進行大規模的改造。

# redis-follower-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: redis-followerlabels:app: redisrole: followertier: backend
spec:replicas: 2selector:matchLabels:app: redistemplate:metadata:labels:app: redisrole: followertier: backendspec:containers:- name: followerimage: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2resources:requests:cpu: 100mmemory: 100Miports:- containerPort: 6379

跟隨者部署命令

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml

通過執行該命令，Kubernetes 會根據指定的 Deployment 配置文件創建 Redis 跟隨者的 Pod 實例。

節點狀態驗證

kubectl get pods

執行該命令可以查看當前集群中所有 Pod 的狀態信息。如果 Redis 跟隨者的 Pod 正常運行，輸出結果中會顯示這些 Pod 的名稱、狀態、重啟次數和運行時間等信息。

典型輸出：

NAME                             READY   STATUS    RESTARTS   AGE
redis-follower-dddfbdcc9-82sfr   1/1     Running   0          37s
redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          38s
redis-leader-fb76b4755-xjr2n     1/1     Running   0          11m

創建 Redis 跟隨者服務

多服務協同設計

為跟隨者單獨創建服務的核心目的是：

• 讀寫流量分離：通過不同的服務地址區分讀寫請求，使得寫入請求可以直接發送到 Redis 領導者服務，而讀取請求可以發送到 Redis 跟隨者服務。這樣可以避免讀寫請求相互干擾，提高系統的性能和穩定性。
• 靈活路由策略：可以針對讀服務配置更高的負載均衡權重，使得更多的讀取請求可以被分配到跟隨者節點上，進一步減輕主節點的壓力。同時，還可以根據業務需求對讀服務和寫服務分別進行優化和調整。
• 服務發現優化：前端應用可以根據操作類型選擇對應服務，提高服務發現的效率和準確性。例如，當需要進行寫入操作時，前端應用可以直接連接到 Redis 領導者服務；當需要進行讀取操作時，可以連接到 Redis 跟隨者服務。

# redis-follower-service.yaml
apiVersion: v1
kind: Service
metadata:name: redis-followerlabels:app: redisrole: followertier: backend
spec:ports:- port: 6379selector:app: redisrole: followertier: backend

跟隨者服務創建

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml

通過執行該命令，Kubernetes 會根據指定的 Service 配置文件創建 Redis 跟隨者服務。

服務狀態查詢

kubectl get service

執行該命令可以查看當前集群中所有 Service 的信息，包括服務的名稱、類型、集群 IP、外部 IP 和端口等。

典型輸出：

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP    3d19h
redis-follower   ClusterIP   10.110.162.42   <none>        6379/TCP   9s
redis-leader     ClusterIP   10.103.78.24    <none>        6379/TCP   6m10s

部署留言板前端服務

無狀態應用設計原則

前端服務采用 Deployment 部署的優勢：

• 彈性伸縮：可以根據流量的變化動態調整副本數量，實現資源的合理利用。例如，在業務高峰期，可以增加前端服務的副本數量，以應對更多的用戶請求；在業務低谷期，可以減少副本數量，降低資源消耗。
• 故障自愈：當某個前端 Pod 出現故障時，Deployment 會自動創建一個新的 Pod 實例來替換它，確保服務的正常運行。這大大提高了系統的可靠性和可用性。
• 滾動更新：支持版本迭代時的零停機部署。當需要對前端服務進行升級或修改配置時，Deployment 可以逐步替換舊的 Pod 實例為新的 Pod 實例，確保服務的不間斷運行。

# frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: frontend
spec:replicas: 3selector:matchLabels:app: guestbooktier: frontendtemplate:metadata:labels:app: guestbooktier: frontendspec:containers:- name: php-redisimage: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5env:- name: GET_HOSTS_FROMvalue: "dns"resources:requests:cpu: 100mmemory: 100Miports:- containerPort: 80

前端部署執行

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml

通過執行該命令，Kubernetes 會根據指定的 Deployment 配置文件創建留言板前端服務的 Pod 實例。

前端節點驗證

kubectl get pods -l app=guestbook -l tier=frontend

執行該命令可以查看當前集群中所有符合指定標簽的前端 Pod 的狀態信息。如果前端 Pod 正常運行，輸出結果中會顯示這些 Pod 的名稱、狀態、重啟次數和運行時間等信息。

典型輸出：

NAME                        READY   STATUS    RESTARTS   AGE
frontend-85595f5bf9-5tqhb   1/1     Running   0          47s
frontend-85595f5bf9-qbzwm   1/1     Running   0          47s
frontend-85595f5bf9-zchwc   1/1     Running   0          47s

暴露前端服務

服務暴露方式解析

Kubernetes 提供多種服務暴露方式，本教程涉及兩種主要方式：

1. 端口轉發（port-forward）

適用于本地開發調試，核心特點：

• 臨時映射：會話結束后映射自動失效，不會對生產環境造成任何影響。這使得開發人員可以在本地方便地進行調試，而不需要擔心對線上服務產生干擾。
• 安全隔離：僅本地可訪問，無需暴露至公網，提高了系統的安全性。在開發調試過程中，很多敏感信息可能會在網絡中傳輸，通過端口轉發可以確保這些信息只在本地網絡中可見，避免了信息泄露的風險。
• 便捷調試：直接將集群服務映射到本地端口，使得開發人員可以像訪問本地服務一樣訪問集群中的服務。這大大簡化了開發調試的流程，提高了開發效率。

2. 負載均衡器（LoadBalancer）

適用于生產環境，核心特點：

• 永久地址：分配固定公網 IP，使得外部用戶可以通過這個 IP 地址訪問服務。這對于面向公眾的 Web 應用來說非常重要，因為用戶需要一個穩定的地址來訪問應用。
• 流量分發：支持 TCP/UDP 四層負載均衡，可以將用戶的請求均勻地分配到多個前端 Pod 上，提高系統的吞吐量和響應速度。在高并發的場景下，負載均衡器可以有效地避免單個 Pod 負載過高的問題，確保服務的穩定運行。
• 云平臺集成：與云服務商的負載均衡器對接，可以充分利用云平臺的優勢，如自動伸縮、高可用性等。云平臺的負載均衡器通常具有更強大的功能和更高的性能，可以為應用提供更好的服務。

# frontend-service.yaml
apiVersion: v1
kind: Service
metadata:name: frontendlabels:app: guestbooktier: frontend
spec:# 如需使用負載均衡器，取消以下行注釋# type: LoadBalancerports:- port: 80selector:app: guestbooktier: frontend

服務創建命令

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml

通過執行該命令，Kubernetes 會根據指定的 Service 配置文件創建留言板前端服務。

服務列表查詢

kubectl get services

執行該命令可以查看當前集群中所有 Service 的信息，包括服務的名稱、類型、集群 IP、外部 IP 和端口等。

典型輸出（ClusterIP 類型）：

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
frontend         ClusterIP   10.97.28.230    <none>        80/TCP     19s

通過端口轉發訪問服務

kubectl port-forward svc/frontend 8080:80

執行該命令后，Kubernetes 會將前端服務的 80 端口映射到本地的 8080 端口。此時，你可以通過訪問 http://localhost:8080 來訪問留言板應用。

通過負載均衡器訪問服務

kubectl get service frontend

執行該命令可以查看前端服務的詳細信息，包括服務的類型、集群 IP、外部 IP 和端口等。

典型輸出（LoadBalancer 類型）：

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE
frontend   LoadBalancer   10.51.242.136   109.197.92.229     80:32372/TCP   1m

如果前端服務的類型為 LoadBalancer，會分配一個外部 IP 地址。你可以通過訪問 http://<EXTERNAL-IP> 來訪問留言板應用。

服務彈性伸縮

水平伸縮原理

Kubernetes 支持基于以下條件的自動/手動伸縮：

• CPU/內存利用率：基于指標服務器的資源監控，Kubernetes 可以實時獲取 Pod 的 CPU 和內存使用情況。當某個 Pod 的資源利用率超過預設的閾值時，可以自動增加副本數量；當資源利用率低于閾值時，可以自動減少副本數量。這種方式可以根據實際的資源需求動態調整服務的規模，實現資源的合理利用。
• 自定義指標：通過 External Metrics API 接入業務指標，如請求數、響應時間等。Kubernetes 可以根據這些自定義指標來調整服務的副本數量，以滿足業務的需求。例如，當請求數急劇增加時，可以自動增加前端服務的副本數量，以應對更多的用戶請求。
• 手動指定副本數：通過命令行或 API 直接調整服務的副本數量。這種方式適用于需要手動干預的場景，如在進行性能測試或故障排查時，可以手動增加或減少副本數量，以觀察系統的性能變化。

擴展前端服務至 5 個副本

kubectl scale deployment frontend --replicas=5

通過執行該命令，可以將前端服務的副本數量擴展到 5 個。Kubernetes 會自動創建新的 Pod 實例，以滿足指定的副本數量。

縮容前端服務至 2 個副本

kubectl scale deployment frontend --replicas=2

通過執行該命令，可以將前端服務的副本數量縮容到 2 個。Kubernetes 會自動刪除多余的 Pod 實例，以達到指定的副本數量。

資源清理

資源刪除策略

Kubernetes 支持通過標簽選擇器批量刪除資源，優勢包括：

• 高效操作：一條命令可以刪除同類所有資源，大大提高了資源清理的效率。例如，通過指定標簽 app=redis，可以一次性刪除所有與 Redis 相關的 Deployment 和 Service。
• 避免殘留：自動級聯刪除相關資源（如 Pod），確保資源的徹底刪除。當刪除 Deployment 時，Kubernetes 會自動刪除與之關聯的所有 Pod 實例，避免了資源的殘留。
• 安全可控：可通過預覽模式確認刪除范圍，避免誤刪除重要資源。在執行刪除命令之前，可以使用 --dry-run 參數進行預覽，查看即將刪除的資源列表，確保刪除操作的安全性和可控性。

批量刪除命令

# 刪除 Redis 相關 Deployment
kubectl delete deployment -l app=redis
# 刪除 Redis 相關 Service
kubectl delete service -l app=redis
# 刪除前端 Deployment
kubectl delete deployment frontend
# 刪除前端 Service
kubectl delete service frontend

通過執行以上命令，可以依次刪除 Redis 相關的 Deployment 和 Service，以及留言板前端服務的 Deployment 和 Service。

最終狀態驗證

kubectl get pods

執行該命令可以查看當前集群中所有 Pod 的狀態信息。如果所有資源都已成功刪除，輸出結果中會顯示 No resources found in default namespace.，表示默認命名空間中沒有任何 Pod 資源。

擴展思考

生產環境優化方向

1. 持久化存儲：為 Redis 增加 PersistentVolume 確保數據持久化。在生產環境中，數據的持久化非常重要，因為 Redis 領導者節點負責處理數據的寫入操作，如果沒有持久化存儲，當節點出現故障或重啟時，數據可能會丟失。通過使用 PersistentVolume，可以將 Redis 的數據存儲在持久化的存儲設備上，確保數據的安全性和可靠性。
2. 服務監控：集成 Prometheus + Grafana 監控集群狀態。Prometheus 是一個開源的監控系統，可以收集和存儲各種指標數據，而 Grafana 是一個可視化工具，可以將這些指標數據以直觀的圖表和報表的形式展示出來。通過集成 Prometheus 和 Grafana，可以實時監控 Kubernetes 集群和應用程序的運行狀態，及時發現和解決問題。
3. 日志收集：添加 Fluentd + Elasticsearch 實現日志聚合。Fluentd 是一個開源的日志收集器，可以收集和轉發各種日志數據，而 Elasticsearch 是一個分布式搜索和分析引擎，可以存儲和分析大量的日志數據。通過集成 Fluentd 和 Elasticsearch，可以將 Kubernetes 集群和應用程序的日志數據集中存儲和管理，方便進行日志分析和問題排查。
4. 安全加固：配置 NetworkPolicy 限制服務間訪問權限。NetworkPolicy 是 Kubernetes 中的一種網絡策略資源，可以定義 Pod 之間的網絡訪問規則。通過配置 NetworkPolicy，可以限制不同服務之間的網絡訪問權限，提高系統的安全性。例如，可以只允許前端服務訪問 Redis 領導者和跟隨者服務，而禁止其他服務訪問。
5. 自動伸縮：啟用 Horizontal Pod Autoscaler 基于負載動態調整副本數。Horizontal Pod Autoscaler（HPA）是 Kubernetes 中的一種自動伸縮資源，可以根據 CPU 利用率、內存利用率或自定義指標等動態調整 Deployment 或 ReplicaSet 的副本數量。通過啟用 HPA，可以實現服務的自動伸縮，根據實際的負載情況動態調整資源的使用，提高系統的性能和資源利用率。

架構擴展方案

1. 多區域部署：通過 Global LoadBalancer 實現跨區域容災。在多區域部署中，可以將應用程序部署到多個地理位置不同的數據中心或云區域，通過 Global LoadBalancer 將用戶的請求路由到最近或最合適的區域。這樣可以提高應用程序的可用性和性能，同時實現跨區域的容災。當某個區域出現故障時，用戶的請求可以自動路由到其他正常的區域，確保服務的不間斷運行。
2. 灰度發布：使用 Canary 部署策略實現版本平滑過渡。Canary 部署是一種灰度發布策略，通過將新版本的應用程序逐步引入到生產環境中，只讓一小部分用戶訪問新版本，從而可以在不影響大多數用戶的情況下對新版本進行測試和驗證。如果新版本運行正常，可以逐步擴大訪問范圍，直到所有用戶都切換到新版本；如果出現問題，可以及時回滾到舊版本。這種方式可以實現版本的平滑過渡，降低升級風險。
3. 微服務拆分：將前端進一步拆分為 API 服務與 Web 服務。微服務架構是一種將大型應用程序拆分為多個小型、自治的服務的架構模式。通過將前端服務拆分為 API 服務和 Web 服務，可以提高系統的可維護性和可擴展性。API 服務負責處理業務邏輯和數據交互，Web 服務負責提供用戶界面。這樣，不同的服務可以獨立開發、部署和擴展，提高了開發效率和系統的靈活性。
   Global LoadBalancer 將用戶的請求路由到最近或最合適的區域。這樣可以提高應用程序的可用性和性能，同時實現跨區域的容災。當某個區域出現故障時，用戶的請求可以自動路由到其他正常的區域，確保服務的不間斷運行。
4. 灰度發布：使用 Canary 部署策略實現版本平滑過渡。Canary 部署是一種灰度發布策略，通過將新版本的應用程序逐步引入到生產環境中，只讓一小部分用戶訪問新版本，從而可以在不影響大多數用戶的情況下對新版本進行測試和驗證。如果新版本運行正常，可以逐步擴大訪問范圍，直到所有用戶都切換到新版本；如果出現問題，可以及時回滾到舊版本。這種方式可以實現版本的平滑過渡，降低升級風險。
5. 微服務拆分：將前端進一步拆分為 API 服務與 Web 服務。微服務架構是一種將大型應用程序拆分為多個小型、自治的服務的架構模式。通過將前端服務拆分為 API 服務和 Web 服務，可以提高系統的可維護性和可擴展性。API 服務負責處理業務邏輯和數據交互，Web 服務負責提供用戶界面。這樣，不同的服務可以獨立開發、部署和擴展，提高了開發效率和系統的靈活性。
6. 緩存優化：在前端與 Redis 之間添加 CDN 或本地緩存層。CDN（Content Delivery Network）是一種分布式網絡，可以將內容緩存到離用戶最近的節點上，從而提高內容的訪問速度。本地緩存層可以將經常訪問的數據緩存在本地，減少對后端 Redis 服務的訪問次數，提高系統的響應速度。通過在前端與 Redis 之間添加 CDN 或本地緩存層，可以進一步優化系統的性能，提高用戶體驗。