！！！請先閱讀須知！！！

在數位轉型的浪潮下，企業的後端服務日益複雜，如何高效、安全、穩定地管理這些服務成為一個關鍵挑戰。API 網關（API Gateway）作為所有外部請求的統一入口，扮演了至關重要的角色。在眾多 API 網關解決方案中，Apache APISIX 憑藉其高性能、豐富的插件生態和動態配置能力脫穎而出。

本文將從 APISIX 的三個核心概念：路由 (Route)、上游 (Upstream) 和 服務 (Service) 出發，透過建立一個虛擬的「新竹百貨公司」實例，深入淺出地演示如何利用 APISIX 實現流量分發、負載均衡以及服務治理（例如流量限制）。

虛擬百貨公司的架構藍圖：APISIX 核心概念解析

要理解如何用 APISIX 構建虛擬百貨公司，我們必須先掌握其運作的基石。這三個概念構成了 APISIX 處理請求的完整流程：

1. 路由 (Route)：請求的引導者

路由是 APISIX 中最核心的功能，它決定了網路封包的去留方向。你可以將 Route 想像成道路上的路牌、演唱會的檢票口，或是高速公路的收費站。

• 功能： 根據請求的特徵（例如：URL 路徑、HTTP 方法、Host 域名、請求頭等）來匹配規則。一旦匹配成功，該請求就會被導向其指定的 Upstream 或 Service 進行後續處理。
• 在虛擬百貨公司中： 我們的 Route 將會是針對網域 新竹百貨公司.com 的請求所建立的規則。它會將所有發送到這個虛擬百貨公司網址的流量都導向我們定義的後端服務群集。

2. 上游 (Upstream)：後端服務的集合

上游是一組目的地（Target/Node）的集合。它代表著一組可以提供相同功能的後端服務群。

• 功能： Upstream 的主要職責是定義後端目標以及它們之間的負載均衡策略（例如輪詢、加權輪詢、一致性哈希等）和健康檢查機制。
• 在虛擬百貨公司中： Upstream 名為「新竹百貨公司」，它不是單一的實體，而是包含了所有實際的百貨公司分店（例如：巨城、SOGO、遠東等）的集合。每個分店都是一個 Target，APISIX 會在這個集合中進行選擇，將請求導向其中一個分店。

3. 服務 (Service)：規則與規定的模組化

服務是一組可重複使用的規定或規則的集合。它將一些通用的配置（例如插件配置）進行模組化，以便套用到多個路由上，避免重複設定。

• 功能： Service 可以綁定一個或多個 Plugin（如限流、身份驗證、日誌記錄等），並可被多個 Route 引用。它也可以直接指定一個 Upstream。
• 在虛擬百貨公司中： 我們可以將 Service 想像成國道上的**「高乘載管制」**規定。這項規定（Service）可以套用到所有的百貨公司路口（Route），當需要限制流量時，我們只需在 Service 中設定一次，所有套用它的 Route 都會立即具備這項功能。

實作步驟：從零開始搭建「新竹百貨公司」

我們將透過一個完整的實作流程，將上述概念具體化，用 APISIX Dashboard（管理介面）來完成配置。

步驟 1：前置作業與模擬後端服務

在開始配置 APISIX 之前，我們需要先建立一個能提供服務的「百貨公司」群集。這裡我們使用 http-server 這個簡單的工具來模擬靜態網頁服務。

1. 安裝 http-server： 這是用來快速啟動靜態伺服器的工具。
2. 建立分店目錄： 建立多個目錄，例如 megacity (巨城), sogo, fec (遠東百貨) 等。在每個目錄中放入一個簡單的 HTML 檔案，標註這是哪個分店。
3. 啟動多個服務：

   # 巨城分店
   http-server ./megacity -p 8081
   # SOGO分店
   http-server ./sogo -p 8082
   # 遠東分店
   http-server ./fec -p 8083
   # ... 其他分店
   

   現在，我們有了多個運行在不同端口（$8081, 8082, 8083...$）的後端服務，它們就是我們虛擬百貨公司的不同分店。

步驟 2：設定上游群集（Upstream）

在 APISIX Dashboard 中，我們將定義「新竹百貨公司」這個集合。

1. 創建 Upstream： 命名為 新竹百貨公司。
2. 配置負載均衡： 選擇負載均衡演算法，例如最常用的輪詢 (Round Robin)。
3. 添加目標節點 (Target)： 將我們所有啟動的百貨公司後端服務都加入這個 Upstream：
   • 127.0.0.1:8081 (巨城)
   • 127.0.0.1:8082 (SOGO)
   • 127.0.0.1:8083 (遠東)
   • ... (其他分店)

透過這個配置，APISIX 就知道當請求到達「新竹百貨公司」這個 Upstream 時，應該要在 $8081, 8082, 8083...$ 這些節點之間進行流量分發。

步驟 3：建立路由規則（Route）

接下來，我們定義外部請求如何進入這個 Upstream。

1. 創建 Route： 命名為 新竹百貨公司主路由。
2. 配置匹配條件： 設定這個 Route 只處理符合特定條件的請求：
   • Hosts (域名)： 設置為 xn--55qx5d0y0ax0p39ed04a.com（這是「新竹百貨公司.com」的 Punycode 編碼，用於確保瀏覽器兼容）。
3. 綁定上游： 將此 Route 的流量導向先前建立的 新竹百貨公司 Upstream。

步驟 4：測試拜訪與負載均衡驗證

1. 修改 hosts 文件： 為了讓瀏覽器能找到我們的虛擬網址，我們需要修改本地電腦的 hosts 文件，將 xn--55qx5d0y0ax0p39ed04a.com 指向 APISIX 的運行端口，通常是 $9080$ 或 $9180$。

   127.0.0.1 xn--55qx5d0y0ax0p39ed04a.com
   

2. 瀏覽驗證： 打開瀏覽器訪問 http://xn--55qx5d0y0ax0p39ed04a.com:9080/。
3. 結果： 你會發現，每當你重新整理頁面時，頁面顯示的百貨公司名稱會在巨城、SOGO、遠東等之間隨機或輪流切換。這證明 APISIX 的 Route 成功將請求攔截，並透過 Upstream 的配置，實現了對後端服務的負載均衡。

服務治理的實踐：引入「高乘載管制」服務（Service）

光有流量分發還不夠，一個成熟的 API 網關必須具備服務治理的能力，例如限制惡意或過高的請求流量。我們將透過 Service 來實現這個功能。

步驟 5：建立「高乘載管制」服務

我們將使用 APISIX 內建的 limit-count 插件來實現流量限制。

1. 創建 Service： 命名為 高乘載管制。
2. 啟用 Plugin： 在此 Service 中啟用 limit-count 插件。
3. 配置限流規則：
   • count： 設定為 $1$ (在指定時間窗內允許的請求次數)。
   • time_window： 設定為 $60$ (時間窗長度，單位為秒)。
   • key： 設定為 $remote_addr (以遠端 IP 地址作為計數依據)。

這項配置的含義是：「在 $60$ 秒內，單一 IP 地址 (客戶端) 僅允許成功訪問我們的服務 $1$ 次。」

步驟 6：套用服務並驗證

1. 套用 Service： 修改步驟 3 建立的 新竹百貨公司主路由。將其原本直接綁定 Upstream 的方式，改為綁定我們新建立的 高乘載管制 Service。

   • （註：Service 內部可以指定 Upstream，因此 Route 綁定 Service，Service 再導向 Upstream 是一種常見的模式，也可以選擇 Route 直接綁定 Service 和 Upstream，讓 Service 僅提供插件功能。）

2. 重新測試： 再次訪問 http://xn--55qx5d0y0ax0p39ed04a.com:9080/。

3. 第一次訪問： 成功看到隨機一家百貨公司的頁面。

4. 立即重新整理（第二次訪問）： 你會發現請求被 APISIX 拒絕，並返回一個錯誤提示，例如 $429$ Too Many Requests。

5. 等待 $60$ 秒後訪問： 再次成功訪問。

驗證結果： 我們成功地將限流這個「高乘載管制」規定透過 Service 的形式模組化，並將其套用到了 Route 上。這不僅實現了服務治理，未來如果我們有更多的路由需要相同的限流策略，只需要將其綁定到這個 高乘載管制 Service 即可，極大地提升了配置的效率和維護性。

總結與展望

透過 APISIX 構建「虛擬新竹百貨公司」的實例，我們不僅理解了 Route (路由)、Upstream (上游) 和 Service (服務) 這三個核心概念的職責與協作關係，更實踐了 API 網關的兩大核心功能：

1. 流量分發與負載均衡： Route 接收請求，Upstream 將請求均勻導向後端多個 Target，確保系統高可用性。
2. 服務治理： 透過 Service 結合插件（如 limit-count），高效地為 Route 批量啟用如限流、認證、日誌等專業功能。

APISIX 作為一個高性能的動態 API 網關，它的能力遠不止於此。在實際的生產環境中，它還可以結合更多的插件，例如：

• 身份驗證與授權 (Authentication & Authorization)：保護後端服務不被未授權的用戶訪問。
• 熔斷與降級 (Circuit Breaking)：防止單一後端服務故障導致整個系統雪崩。
• 可觀察性 (Observability)：與 Prometheus、SkyWalking 等工具整合，提供詳細的日誌和監控數據。

總而言之，掌握 APISIX 的核心概念，就像擁有了數位世界中的交通指揮系統。它能確保虛擬百貨公司（或任何複雜的微服務架構）的請求能夠安全、高效、穩定地到達它們的目的地。