@RestController
@RequestMapping("/session")
public class SessionController {

    @GetMapping("/set")
    public String setSession(HttpSession session) {
        // Set session attribute
        session.setAttribute("user", "John Doe");
        return "Session data set for user: John Doe";
    }

    @GetMapping("/get")
    public String getSession(HttpSession session) {
        // Retrieve session attribute
        String user = (String) session.getAttribute("user");
        return "Session data: " + (user != null ? user : "No session data found");
    }
}

請注意，這僅僅是示例代碼，用於演示如何使用單獨的存儲來存儲會話數據。

負載均衡

負載均衡涉及將進來的網絡流量分配到多個服務器，以確保沒有單一服務器被壓垮。

負載均衡的一些重要用例如下：

1 - 反向代理

反向代理位於後端服務器之前，並代表它們處理客戶端請求。

當客戶端向應用程序發送請求時，反向代理接收請求並確定哪個後端服務器最適合處理該請求。然後，反向代理將請求轉發給所選服務器並等待響應。

w_1456_fb4af8d1-91e1-4a20-a706-5cbfbdb8a4b2_1600x974.png

反向代理的主要好處如下：

負載均衡： 反向代理可以將進來的請求分配到多個後端伺服器。後端伺服器可以在不影響客戶端的情況下添加、刪除或更新。
增強安全性： 透過作為客戶端請求的單一入口點，反向代理隱藏了後端伺服器的內部結構。它們還可以實施額外的安全措施，例如 SSL 終止和請求過濾。
緩存和壓縮： 反向代理可以緩存經常訪問的內容，以減少後端伺服器的負載並改善響應時間。它們還可以在將響應發送回客戶端之前進行壓縮。

在現代 API 架構中，流行的工具如 NGINX 和 HAProxy 可以用作反向代理和負載均衡器。

這裡有一個 HAProxy 配置的基本示例，用於作為反向代理在多個後端服務器之間負載均衡 HTTP 流量。請注意，這僅僅是演示代碼，用於解釋各種選項。

global
    log stdout format raw local0
    maxconn 4096

defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server server1 192.168.1.101:80 check
    server server2 192.168.1.102:80 check
    server server3 192.168.1.103:80 check

這裡的前端部分定義了通過監聽 80 端口來處理進來的 HTTP 請求的入口點，並將請求轉發到默認的後端 http_back。

後端部分指定了後端服務器和負載均衡算法。

2 - DNS 負載均衡

DNS 負載均衡是一種通過利用域名系統 (DNS) 將流量分配到多個服務器的技術。它將單個域名映射到多個 IP 地址，允許 DNS 服務器根據各種負載均衡算法將客戶端引導到不同的服務器。

IP 地址的選擇由 DNS 服務器使用的負載均衡算法決定。一些常見的算法包括：

循環賽
地理位置
加權分配

3 - 健康檢查

健康檢查對於確保流量僅指向健康實例至關重要。

負載均衡器定期通過發送定期請求來監控後端伺服器的健康狀態，以檢查其狀態。

如果伺服器未通過健康檢查，它將暫時從可用伺服器池中移除，直到它恢復。在 HAProxy 的示例中，後端配置中的檢查選項啟用每個伺服器的健康檢查。

速率限制

速率限制是一種機制，限制客戶端在預定時間內對 API 的請求數量。

它設置了請求的頻率和數量限制，防止任何單一客戶端壟斷 API 的資源或對其他用戶造成性能問題。這對於保持 API 層的可擴展性至關重要，以便為正確的用戶集提供服務。

w_1456_6e13c022-e146-4a94-8c8b-030625d6cf0e_1600x1031.png

速率限制的主要目標是：

防止濫用：速率限制有助於減輕拒絕服務攻擊的風險，攻擊者試圖通過大量請求淹沒 API 以破壞其功能。
確保公平使用：通過對每個客戶端的請求數量施加限制，速率限制確保沒有單一客戶端能消耗不成比例的資源，讓所有用戶都能公平訪問。
保護後端服務：速率限制作為後端服務的保護措施，防止其被過量流量淹沒。

實施速率限制時，有幾個關鍵方面需要考慮：

基於配額的限制：速率限制通常涉及設置配額或客戶端在特定時間範圍內可以發出的最大請求數。例如，API 可能允許特定客戶端每小時發出 1000 個請求。一旦超過配額，額外的請求將被拒絕或延遲，直到下一個時間窗口開始。
粒度：根據 API 的具體要求，速率限制可以在不同的粒度級別上應用。常見的粒度級別包括：
- 每位用戶：每位用戶被分配一個單獨的配額，確保個別用戶無法超過其分配的限制。
- 每個 IP 地址：根據客戶端的 IP 地址執行速率限制，防止單一 IP 發出過多請求。
- 每個 API 密鑰：如果 API 使用 API 密鑰進行身份驗證，則速率限制可以與每個 API 密鑰相關聯，允許對客戶端訪問進行更細緻的控制。
響應標頭：為了提供透明度並幫助客戶端管理其請求速率，API 通常在響應標頭中包含速率限制信息。通過包含這些標頭，API 使客戶端能夠監控其使用情況並相應調整其請求模式。這些標頭可能包括：
- X-RateLimit-Limit：在時間窗口內允許的最大請求數。
- X-RateLimit-Remaining: 當前時間窗口內可用的剩餘請求數量。
- X-RateLimit-Reset: 指示速率限制何時重置的時間戳或持續時間。

異步處理

非同步處理涉及在背景中執行任務，與主應用程序線程分開。

通過將耗時或資源密集型的任務卸載到單獨的線程或進程中，應用程序可以保持響應並繼續處理傳入請求，而不會阻塞。

消息隊列在促進應用程序組件之間的非同步通信中發揮著至關重要的作用。它們充當中介，允許組件非同步地發送和接收消息，而無需直接耦合或同步依賴。

w_1456_9d4fab29-af50-45a5-b61a-4add4d28a983_1600x1405.png

例如，像 RabbitMQ 這樣的消息代理通過提供可靠的方式來發送、接收和處理消息來促進這一過程。使用它們，組件可以通過將消息發送到隊列並獨立處理它們來進行非同步通信。

這是一個簡單的 Spring Boot 中的 MessageProducer 代碼示例，該示例將消息發送到 RabbitMQ 實例。

@RestController
public class MessageProducer {

    @Autowired
    private RabbitTemplate rabbitTemplate;

    @GetMapping("/send")
    public String sendMessage() {
        rabbitTemplate.convertAndSend("myQueue", "Hello, World!");
        return "Message sent!";
    }
}

這是相應的 MessageListener 的基本代碼示例。

@Component
public class MessageListener {

    @RabbitListener(queues = "myQueue")
    public void receiveMessage(String message) {
        System.out.println("Received message: " + message);
    }
}

在這個例子中，消息被發送到 RabbitMQ 隊列，並且一個監聽器非同步地處理該消息。

微服務架構

擴展 API 的最常見障礙之一通常是支持該 API 的服務是大型單體應用程序的一部分。擴展這樣的單體應用程序並不容易。

這就是為什麼使用微服務架構可以間接使 API 更具可擴展性的原因。

微服務架構是一種將應用程序設計和構建為一組小型、獨立服務的方式，這些服務通過網絡相互通信。每個微服務代表一個自包含的單元，封裝了特定的業務能力，例如用戶身份驗證、訂單處理或庫存管理。

請參見下面的圖示以供參考：

w_1456_75a5b45b-d180-4d7e-8bfc-f1f7f735072a_1600x1029.png

為了說明解耦服務的概念，讓我們考慮一個最初作為單體構建的電子商務應用程序。

在微服務架構中，這個應用程序可以拆分為以下服務：

用戶服務： 管理用戶註冊、身份驗證和個人資料管理。
產品服務： 處理產品目錄、庫存和定價。
訂單服務： 管理訂單創建、處理和跟踪。
支付服務： 處理支付處理和交易管理。
通知服務： 向用戶發送電子郵件、短信或推送通知。

每個服務都可以獨立開發、部署和擴展，從而實現更大的靈活性和效率。此外，這些不同的服務可以使用輕量級協議（如 HTTP/REST、gRPC 或消息系統如 RabbitMQ 或 Kafka）進行通信。通信協議的選擇取決於系統的具體要求和特徵。

通過將單體應用程序拆分為更小的、鬆散耦合的服務，微服務架構使團隊能夠獨立開發、部署和擴展服務，從而導致更快的開發周期和更高效的資源利用。

擴展 API 層的最佳實踐

實施最佳實踐對於確保 API 可擴展、可維護和安全至關重要。以下是一些理想上應遵循的實踐：

監控和日誌記錄

監控和日誌記錄是 API 管理的關鍵組成部分，使開發人員能夠獲得有關各種 API 的性能、健康狀況和使用模式的見解。

監控涉及跟踪和分析與 API 性能和使用相關的關鍵指標。一些需要監控的基本指標包括：

響應時間
錯誤率
請求量

為了促進有效的監控，各種工具和平台可用，例如 Prometheus、Grafana 和 ELK 堆棧（Elasticsearch、Logstash、Kibana）。

日誌記錄還涉及捕獲 API 交互的詳細記錄，包括請求和響應數據、時間戳和其他相關信息。

這些日誌對於解決調試問題、審計使用模式和理解客戶如何與 API 互動非常有價值。

API 版本控制

隨著 API 的演變，可能會引入新功能，修改現有功能或刪除不再使用的功能。

API 版本控制使開發人員能夠同時發布多個版本的 API，允許客戶繼續使用他們熟悉的版本，同時逐步過渡到更新版本。這種方法最小化了對現有集成的干擾，並確保客戶的平穩遷移過程。

常見的版本控制策略包括：

URI 版本控制
查詢參數版本控制
客戶標頭版本控制

API 安全性

API 通常暴露敏感數據和功能，因此實施強大的安全措施以防止未經授權的訪問、數據洩露和其他安全威脅至關重要。

API 安全的關鍵組成部分包括：

身份驗證： 驗證訪問 API 的用戶或應用程序的身份。常見的身份驗證方法包括 OAuth 2.0，這使得安全的委託訪問成為可能，以及 JSON Web Tokens (JWT)，這提供了一種緊湊且自包含的方式來傳輸身份驗證信息。
授權： 確定已驗證的用戶或應用程序的權限和訪問權限。基於角色的訪問控制 (RBAC) 和基於屬性的訪問控制 (ABAC) 是常用的以強制執行細粒度授權策略。
數據加密： 使用加密協議（如 HTTPS/TLS）保護傳輸和靜態數據，並使用加密算法保護數據存儲。

API 文檔

清晰、全面且最新的文檔對於減少學習曲線、最小化支持請求和促進 API 的採用至關重要。

有效的 API 文檔應包括：

端點詳細信息
身份驗證和授權指導
錯誤處理
使用示例

像 Swagger（OpenAPI 規範）和 Postman 這樣的工具可以大大簡化創建和維護 API 文檔的過程。

總結

API 是現代軟體開發的基石，允許分散式系統和應用程式之間的各個組件進行通信。

成功擴展應用程式在很大程度上依賴於 API 層的可擴展性。在這篇文章中，我們已經探討了幾種 API 擴展策略。讓我們簡要回顧一下：

API 層作為客戶端和後端服務之間的接口，處理請求、強制執行安全性和協調服務交互。
在 API 可擴展性的背景下，應該理解的關鍵概念是可擴展性、延遲和吞吐量的定義。
在 API 可擴展性方面，有多種策略，特別是在水平擴展方面。
無狀態架構是實現水平擴展的關鍵，因為它有助於設計 API，使其獨立於先前的請求。
負載均衡有助於將請求分配到多個實例，以防止過載。負載均衡器可以充當反向代理和 API 閘道器，為 API 層提供單一入口點。
速率限制是控制請求量的關鍵，以確保公平使用並保持 API 對有效用戶的可擴展性。
異步處理通過使用後台進程異步處理任務來幫助擴展 API。
微服務架構允許將單體 API 拆分為更易於擴展的單獨服務部署。
支持 API 可擴展性的一些最佳實踐包括監控和日誌記錄、版本控制、安全性和文檔。

20240822_關於擴展 API 的速成課程

Interactive graph

在此頁面

關於擴展 API 層的速成課程

關鍵概念

可擴展性

延遲

吞吐量

API 擴展策略

無狀態架構