GCP企業認證帳號 谷歌云新加坡實例部署負載均衡器教學

第一章：為什麼要用負載均衡器

很多人第一次做上線時，會直接把一台虛擬機公開到網際網路：有請求就回應，慢了就加 CPU。這做法在早期確實快，但它有明顯的上限。當流量變大，單點就會成為瓶頸；當機器故障，你的服務也會跟著中斷。負載均衡器的價值就在這裡：它把使用者請求分散到多個後端，並持續監控後端的健康狀態，確保「不健康的節點」不會繼續接流量。

在谷歌云（GCP）裡，負載均衡器不只是「分流」。它通常與雲端網路、健康檢查、後端服務、轉發規則一起工作，讓你能更接近雲原生的思維：把可用性與擴展交給系統，把你從反覆手動操作中解放出來。

本教學的目標是：以新加坡區域作為部署範例，說清楚你需要做哪些設定，為什麼要這樣做，以及遇到問題時要從哪裡查。你不必完全理解每一個名詞，但需要知道「每一步在達成什麼效果」。

第二章：建立前提—選擇新加坡區域與網路規劃

開始之前，先想一件事：你的使用者主要在哪裡？如果你希望服務面向亞洲客戶，新加坡是很常見的選擇。選擇區域不是迷信，而是延遲與資料主權的綜合考量。當你把計算資源放在新加坡（例如 asia-southeast1）附近，通常能獲得更好的 RTT。

在 GCP 的概念中，你通常會先有 VPC 與子網，再把運算資源接入。負載均衡器要能轉發到後端，因此網路要通暢。

2.1 建立 VPC 與子網

如果你已經有可用的 VPC，可以直接使用。若你是從零開始，建議建立一個專用 VPC，讓後續管理更乾淨。子網方面，至少要確保：

• 子網所在區域/模式符合你的實例放置方式（新加坡對應的 region）。
• 防火牆規則允許負載均衡器到後端實例的連線。
• 必要的埠開放範圍正確，避免「看起來建好了但就是不通」。

GCP企業認證帳號 2.2 防火牆思維：只開必要的埠

很多初學者會一次把所有埠都開放，直到出問題才縮小範圍。這不只是安全問題，也會讓除錯變得困難。你要先定義你服務的端口。例如：

• 網站服務通常用 TCP 80（HTTP）或 TCP 443（HTTPS）。
• 若你只是測試，可以用 8080 或 3000，但要全程一致。

後端實例上運行什麼服務，就開什麼埠，負載均衡器要轉發到那個埠。

第三章：建立兩台後端實例（可承接健康檢查）

負載均衡器要分流，至少要有兩個後端。兩台的好處是：你能驗證「分流」與「健康檢查」的效果。即使你最終可能會用更多後端，從兩台開始最容易理解。

3.1 建立 Compute Engine 實例

在新加坡區域建立兩台虛擬機（例如 instance-1、instance-2）。建議：

• 選擇你熟悉的作業系統（Ubuntu、Debian 都常見）。
• 至少在其中一台能快速啟動你的測試服務。
• 避免過度複雜的部署流程，先跑通連線再談優化。

在每台實例上，你要有一個簡單的 Web 服務。例如你可以用 Nginx 或簡單的 HTTP 伺服器來回應。關鍵是：回應內容最好能區分不同後端，讓你能在瀏覽器或 curl 看到「請求確實分到不同機器」。

3.2 後端服務回應內容：讓分流看得見

建議在每台機器上做一個差異化回應，例如：

• instance-1 回傳「Hello from instance-1, asia-southeast1」。
• instance-2 回傳「Hello from instance-2, asia-southeast1」。

這樣你測試時就知道流量是否均衡，以及健康檢查是否真的在工作。

3.3 健康檢查端點：不要只會回首頁

負載均衡器會定期探測後端是否健康。這個探測不一定是你網站的根路徑，也可以是特定端點，例如 /healthz。實務上，你最好準備一個獨立的健康檢查頁面：

• 內容很短、回應快。
• 不依賴複雜的外部服務（例如資料庫），避免健康檢查因為其他錯誤而把節點判成不健康。
• 當你要「手動模擬故障」時，可以直接讓健康端點返回錯誤或停止服務。

即便你沒有資料庫，仍建議讓健康檢查邏輯清楚，這會讓除錯更直觀。

第四章：建立健康檢查—讓負載均衡器有判斷依據

健康檢查是負載均衡器穩定運作的核心。沒有健康檢查，你的負載均衡器可能仍然把流量送到已掛掉的實例，造成用戶看到錯誤。

4.1 健康檢查要檢查什麼

常見設定包含：

• 協議：HTTP 或 HTTPS。
• GCP企業認證帳號 端口：通常是後端服務的埠，例如 80、8080 或你自訂的埠。
• 路徑：例如 /healthz。
• 回應碼：例如期望 200 作為健康。

4.2 健康判定的參數：別一口氣用最激進值

你需要配置探測頻率與容忍次數。參數通常類似「每隔 N 秒探測一次，連續 M 次成功才判定健康、連續 K 次失敗才判定不健康」。初學者常見的錯誤是把參數設得太激進，例如：

• 探測太頻繁 → 後端壓力上升。
• 失敗容忍太少 → 網路抖動就被判定不健康。

建議先使用預設或相對保守的值，跑通流程後再根據實際流量與延遲調整。

第五章：建立後端服務—把實例集合起來

後端服務可以理解為「一組可接收流量的後端實例」的抽象。你不把每台實例獨立設定一堆東西，而是把它們放進後端服務，再由負載均衡器依據規則把流量轉發過去。

5.1 後端服務要包含哪些元素

一個典型後端服務通常包含：

• 後端實例群組（或是 instance group / managed instance group，依你採用的方式）。
• 健康檢查設定。
• 協議與端口（負載均衡器用什麼方式跟後端通訊）。
• 可選：流量模式（例如會不會使用會話親和等策略）。

5.2 使用 instance group 的好處

即使你一開始只有兩台，也建議把它們放到 instance group 裡。理由是：後續擴容、替換、滾動更新都更容易。你不必每次都重新手動挑選後端實例，降低操作錯誤。

5.3 後端埠一致性：最常見的踩雷點

GCP企業認證帳號 從這裡開始，你要對「埠」特別敏感。錯一次就會出現：

• 健康檢查失敗：負載均衡器打到錯的端口。
• 前端能通但後端沒回應：防火牆允許了前端連線，但沒允許到後端。
• 只在某一台機器正常：另一台服務沒在對的埠啟動。

所以每一步建議你都寫在筆記：前端用哪個埠、後端服務設定哪個埠、實例上的服務實際監聽哪個埠、健康檢查探測哪個端口。

第六章：建立前端與轉發規則—讓使用者流量進來

GCP企業認證帳號 前端可以理解為「入口」。當你把網際網路的請求打到負載均衡器的 IP 或網域時，負載均衡器會根據你配置的轉發規則，選擇後端服務並把請求送到健康的後端。

6.1 選擇 HTTP 還是 HTTPS

你可以先用 HTTP 快速驗證流程。當你確認服務穩定後，再考慮 HTTPS。HTTPS 需要憑證（證書可以透過你取得的方式配置），同時涉及更多設定。但在教學階段，HTTP 能讓你更快看到「分流是否成功」。

若你要同時體驗 HTTPS，也可以把教學拆成兩段：先跑 HTTP 通，再補上 HTTPS。

6.2 前端轉發規則：簡單但別漏關鍵條件

轉發規則常見內容：

• 協議（HTTP/HTTPS）。
• 埠（例如 80 或 443）。
• 目標後端服務（你前面建立的那個）。
• 路徑匹配或主機名匹配（若你做多服務共用負載均衡器）。

在單一服務的情境下，你可以用最簡化的規則：把所有流量都轉到同一個後端服務。等流程通了，再增加路由規則的精細度。

6.3 靜態 IP 的管理思維

負載均衡器通常會對外提供一個 IP（可為臨時或靜態）。若你希望後續把 IP 綁到 DNS、或讓部署流程能重複，建議使用靜態 IP。否則重建後可能會拿到不同的 IP，造成維運困擾。

第七章：測試與驗證—確保分流、健康檢查與可用性真的生效

GCP企業認證帳號 設定完成後，最重要的是「驗證你以為生效的東西，真的已經生效」。建議按照順序測試，避免一開始就亂猜。

7.1 在瀏覽器測試：先看是否有回應

把負載均衡器的前端 IP 貼到瀏覽器，應該能看到你的頁面回應。如果完全沒回應，先不要急著認定是負載均衡器壞了，回到最基本的檢查：

• 前端端口是否正確（HTTP 80 是否有對應規則）。
• 後端埠是否正確。
• 防火牆是否允許負載均衡器到後端的流量。

7.2 驗證分流：刷新多次或用多連線測試

你在 instance-1 與 instance-2 上設定了不同回應內容。你可以：

• 連續刷新觀察回傳是否輪替。
• 用簡單的方式做多次請求（例如從命令列重複 curl）。

理想狀態是兩台都會出現。若只有其中一台出現，要麼另一台沒有被判定為健康，要麼負載均衡器實際只把流量送到單一後端。

7.3 驗證健康檢查：讓一台故意失效

這一步最能驗證你的配置是否正確。你可以短暫地讓 instance-2 的健康端點返回非 200（例如把 /healthz 改成回 500），或乾脆停止那台的 Web 服務。然後觀察：

• 負載均衡器是否在一段時間後將該台判為不健康。
• 流量是否會自動轉向 instance-1。
• 用戶端是否仍能得到正確回應（不會突然整體崩掉）。

當這些都成立，你就真正完成了「可用性」層面的測試。

第八章：常見問題與除錯路徑—少走冤枉路

負載均衡器架構看起來複雜，其實除錯有固定套路。你要建立一個心智模型：每次錯誤都對應到鏈路中的某一段。

8.1 健康檢查一直失敗

最常見原因：

• 健康檢查路徑錯了（/healthz 實際沒有設定）。
• 健康檢查端口錯了（後端實際監聽在 8080，但健康檢查填 80）。
• 防火牆阻擋探測連線。
• 服務啟動慢：健康檢查過早開始，導致初期連續失敗。

除錯建議做法：

• 先在每台實例本機測試健康端點是否能回 200。
• 確認負載均衡器到後端的防火牆規則允許探測埠。
• GCP企業認證帳號 查看健康狀態的時間線：它是一直失敗還是偶發？

8.2 前端有回應，但分流不均

GCP企業認證帳號 常見原因：

• 只有一台是健康狀態，另一台其實不健康。
• 其中一台服務回應慢或間歇失敗，導致健康檢查把它短暫移出。
• 你測試方式太少次，輪替未必立刻顯示。

解法：

• 先確認兩台都健康。
• 再增加測試次數或並發請求，觀察分流是否出現輪替。

8.3 遇到「能連上但就是 404」

這通常是路徑或 Web 伺服器設定問題。負載均衡器把請求轉發到了後端，但後端對該路徑沒有處理。例如你健康檢查用 /healthz，但你的 Nginx 只配置了 / 或沒有對應 location。解法是讓健康端點與測試端點都明確存在。

第九章：把新加坡實例部署做成可重複的流程

學會一次不代表你能穩定維運。當你希望在新加坡區域快速複製這套架構，就要讓流程可重複：至少做到「設定一致、可追蹤、可回滾」。你可以用自動化工具或以腳本管理變更（是否要上 Infrastructure as Code 取決於你的團隊成熟度，但概念上你要朝這方向走）。

9.1 建立部署清單：避免每次重做都漏步

建議你寫一份簡單清單，內容對應你剛做過的每一段：

• VPC/子網：名稱、CIDR、區域設定。
• 防火牆：允許哪些埠與來源。
• 後端實例：兩台或更多，映像與啟動腳本。
• GCP企業認證帳號 健康檢查：協議、端口、路徑、期望回應碼。
• 後端服務：連到哪個 instance group。
• 前端：端口、協議、目標後端服務。
• 測試方法：瀏覽器與健康端點驗證方式。

這份清單看起來瑣碎，但它能讓你在未來遇到問題時更快定位。

GCP企業認證帳號 9.2 擴容的思路：先保證健康，再談規模

你之後可能會把兩台擴到更多。這時候你要確保：

• 健康檢查端點可靠。
• 後端服務部署流程能快速把新實例拉起來。
• 防火牆與網路策略能覆蓋到新增實例。

擴容不是把機器數量加上去而已，還包括把可用性保障機制一併維持。

第十章：小結—你已經完成一個「能上線」的負載均衡器架構

回顧整個流程，你其實做了三件事：

• 把後端服務準備好：至少兩台實例、提供清楚的健康端點與回應內容。
• 把治理邏輯設定好：健康檢查讓負載均衡器知道哪些節點可以接流量。
• 把入口規則打通：前端轉發把使用者請求導到後端服務，並在不同狀況下維持可用性。

當你在新加坡區域把這套配置跑通，你就不只是完成一個操作示範，而是掌握了負載均衡器在雲環境真正扮演的角色：讓服務可擴展、可偵測、可維持。

如果你接下來想更進一步，可以把下一步放在：HTTPS 憑證、域名解析、滾動更新、以及更完善的監控告警。先把這次的架構掌握扎實，後續的升級才會變得更順。