譯者 | 劉汪洋
API 在我們的數字世界中發揮著關鍵的作用，使各種不同的應用能夠相互通信。然而，這些 API 的可靠性是保證依賴它們的應用程序功能正常、性能穩定的關鍵因素。本文，我們將探討提高 API 可靠性的五種主要策略。
1.全面測試
要確保 API 的可靠性，第一步是進行全面的測試。需要進行的測試包括：功能測試以驗證 API 的正確運行，集成測試以確保 API 能與其他系統正常協同，以及負載測試以理解 API 在大規模使用下的表現。
自動化測試能在開發周期的早期發現問題，回歸測試能保證新的修改不會對現有功能造成破壞。使用虛擬化或模擬技術可以模擬 API 依賴，進行更深度的測試。此外，為了確保 API 的提供者和消費者都能滿足約定的接口，契約測試非常重要。
下面我們將使用 Go 的內置 testing 包，通過一個簡單的例子對一個假設的 API 端點（用于訪問 API 的 URI）進行測試。
假設我們有一個端點 GET /users/{id} ，用于返回用戶的詳細信息。
下面是我們可能編寫的測試代碼：
復制
package mAIn
import (
".NET/http"
"net/http/httptest"
"testing"
// 這是一個簡化的實際處理器函數示例
func UserHandler(w http.ResponseWriter, r *http.Request) {
// ... 處理器邏輯
}
func TestUserHandler(t *testing.T) {
req, err := http.NewRequest("GET", "/users/1", nil)
if err != nil {
t.Fatal(err)
}
rr := httptest.NewRecorder()
handler := http.HandlerFunc(UserHandler)
handler.ServeHTTP(rr, req)
if status := rr.Code; status != http.StatusOK {
t.Errorf("handler returned wrong status code: got %v want %v",
status, http.StatusOK)
}
// 你還可以檢查響應體是否符合預期的輸出
expected := `{"id": "1", "name": "John Doe"}`
if rr.Body.String() != expected {
t.Errorf("handler returned unexpected body: got %v want %v",
rr.Body.String(), expected)
}
}
這個測試創建了一個新的 HTTP 請求，模擬了對我們的 /users/{id} 端點的調用，然后把請求傳遞給了處理器函數。測試會檢查響應狀態是否為 200 OK（即我們期望的成功請求應返回的結果）以及響應體是否與預期的輸出一致。
這個例子只是一個簡單的示例，在實際應用中，你可能會面臨更復雜的場景，包括測試各種邊界條件、錯誤路徑等。此外，net/http/httptest 包提供了許多用于測試 HTTP 客戶端和服務器的工具。
總之，你可以結合單元測試、性能測試和持續的集成測試，為你的 API 構建一個全面的測試套件。
單元測試的目的是確保你的 API 中每個組件的正確性。它通過驗證每個部分的功能和隔離它們，使得你可以在早期發現并糾正問題。單元測試通常通過模擬依賴項并獨立測試函數來完成。在 Go 語言中，可以利用諸如 testify 等包來達成這一目標。
性能測試則是為了在高流量的情況下對 API 進行壓力測試。這種測試有助于你確定系統在高負載情況下的表現，識別瓶頸，并確保 API 能處理真實世界的使用情況。性能測試可以使用 JMeter 或Gatling 等工具進行。
最后，持續集成測試則通過模擬用戶或客戶端對 API 進行一系列連續操作，來測試系統的工作流程。這類測試能夠提供對端到端工作流程、潛在的障礙或延遲，以及整體用戶體驗的深入理解。這個過程可以自動化并集成到你的 CI/CD 流程中，使得你可以持續監控并及時反饋任何代碼更改的影響。
通過實施包括功能測試、單元測試、性能測試和持續合成測試在內的全面的測試策略，你可以確保你的 API 不僅穩定且高性能，還能為使用者提供無縫的體驗。而在問題出現時，這種多元化的測試方法可以幫助你快速定位并解決問題的根源。
2.版本控制
在維護軟件系統的穩定性方面，API 版本管理扮演了核心角色。隨著時間推移，API 可能會隨著需求變化和優化，如果沒有適當的版本管理，可能會對現有的客戶端應用造成破壞。這就是 API 版本管理的關鍵所在。通過維護 API 的各個版本，你可以在引入新功能和優化的同時，確保不影響使用舊版本 API 的應用。
這種策略提升了系統的穩定性，因為即使 API 經過改動和優化，客戶端應用依然可以穩定運行。它讓開發者能夠部署 API 更新，而不需要擔心這些變化會對正在運行的應用造成破壞，保障了系統的穩定性和正常運行。
保持向后兼容性是實現 API 穩定性的關鍵一環，也就是說，新系統應能與舊版 API 兼容。即使新的版本發布，使用舊 API 版本的應用依然可以正常運行。這避免破壞用戶體驗，并給了開發者足夠的時間，讓他們可以按照自己的節奏更新應用以適應新的 API ，而不是為了防止應用出錯而被迫升級。這樣做，有助于創建一個整體上更穩定、更強大和更具有彈性的系統。
示例
在 Go 語言中，我們可以使用多種方式來進行 API 的版本管理。
下面這個例子展示了如何通過在 URL 中嵌入 API 版本實現版本管理，這種方法通常被稱為"路徑版本控制"。
復制
package main
import (
"fmt"
"net/http"
func handleRequest(w http.ResponseWriter, r *http.Request) {
switch r.URL.Path {
case "/v1/users":
fmt.Fprintf(w, "You've hit the version 1 of the users API!")
case "/v2/users":
fmt.Fprintf(w, "You've hit the version 2 of the users API!")
default:
http.NotFound(w, r)
}
}
func main() {
http.HandleFunc("/", handleRequest)
http.ListenAndServe(":8080", nil)
}
在這個例子中，我們定義了一個處理函數，它根據請求的 URL 路徑來匹配響應的代碼。當訪問 "/v1/users" 路徑時，我們認為這是對我們 API 第一版本的請求。同樣地，"/v2/users" 則對應我們 API 的第二個版本。通過添加更多的分支，你可以輕松地擴展這種模式以適應更多版本和端點。
此外，你也可以通過自定義頭部或媒體類型版本管理（也稱為"內容協商"）來實現版本管理。
不論你選擇何種版本管理策略，都應為 API 的每個版本維護清晰且最新的文檔，這是一種良好的實踐。
但是，我們也需要謹慎使用版本管理。我們應盡可能地保持向后兼容性，并提供清晰的文檔。文檔應詳細說明每個新版本中的變化，并提供廢棄舊版本的合理時間表。
3. 面向失敗設計
在理想情況下，API 始終能夠正確運行。然而在實際操作中，出現失敗的情況并不罕見。在設計 API 的過程中，我們需要考慮其容錯能力，這可能涉及到諸如優雅降級（即系統繼續運行但是功能有所縮減）和故障轉移機制（即出現故障時，系統自動切換到備份系統）等策略。
將明確的錯誤消息和代碼納入 API，能有助于應用程序更好地理解問題所在以及采取應對策略。我們可以通過重試邏輯、速率限制和斷路器，讓系統從臨時性問題中恢復，避免故障級聯。
下圖顯示了應對各種故障類型的操作方法：
示例：斷路器模式
在斷路器模式中，Go 語言有一個叫 go-hystrix 的熱門庫，該庫專注于延遲和容錯處理。它主要是在服務停止時，通過快速失敗阻止故障級聯。以下是一個基本示例：
復制
package main
import (
"Github.com/afex/hystrix-go/hystrix"
"log"
"net/http"
"errors"
func main() {
hystrix.ConfigureCommand("my_command", hystrix.CommandConfig{
Timeout: 1000,
MaxConcurrentRequests: 100,
ErrorPercentThreshold: 25,
})
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
err := hystrix.Do("my_command", func() error {
// 調用其他服務
return nil
}, nil)
if err != nil {
log.Printf("Failed to talk to other services: %v", err)
http.Error(w, "Failed to talk to other services", http.StatusInternalServerError)
}
})
log.Fatal(http.ListenAndServe(":1234", nil))
}
在上述示例中，我們將一個命令封裝在 hystrix.Do() 中。如果基于我們設置的參數，傳入 Do() 的函數失敗或超時，斷路器就會被觸發，后續的調用將會立即失敗，而不再調用該函數。
請注意，這只是一個基本的示例，實際應用場景將涉及更多復雜的用法，需要針對這個庫以及其他的彈性實用程序庫涉及的各種參數進行細致調整。請務必閱讀各種庫的文檔，深入理解如何在你的代碼中有效地使用它們。
4. 監控與分析
實時監控與及時分析對于保證 API 的穩定性至關重要。執行一套全面的 API 監控策略可以包括對運行時間、性能以及錯誤的檢測，這有助于我們在問題擴散影響用戶前，及時發現并處理。
同時，深入分析 API 的使用模式可以讓我們得到重要的洞察。了解到高峰負載時段、最常使用的端點以及其他使用詳情后，您就可以主動地找出可能存在的弱點，并據此進行 API 優化。
選擇正確的指標去追蹤，對于了解你的 API 的健康狀態和性能至關重要。以下是一些需要考慮的關鍵指標：
1.吞吐量：您的 API 單位時間內處理的請求數量，可以進一步分為端點、HTTP 方法（如 GET、POST、PUT、DELETE 等）或響應狀態碼。
2.錯誤率：單位時間內的錯誤響應數量，通常是指含有 4xx 或 5xx 狀態碼的響應。同吞吐量一樣，這個指標也可以按端點、HTTP 方法或具體的狀態碼進行細分。
3.延遲：處理一個請求所需的時間，通常以一系列百分位數（如第 50、95 和 99 百分位）來追蹤，這可以幫助您了解典型和極端情況下的性能表現。您可能需要針對不同的端點或 HTTP 方法單獨追蹤此項。
4.流量：發送和接收的數據量，可以按端點、HTTP 方法或響應狀態碼進行細分。
5.可用性：您的 API 正常運行并能夠處理請求的時間占比，可以作為一個整體進行測量，或者針對每一個單獨的端點進行測量。
6.飽和度：系統達到最大容量的程度，這可以通過測量 CPU 使用率、內存使用率、磁盤 I/O 或其他可能限制系統處理更多負載的資源來了解。
7.斷路器觸發：如果您使用斷路器模式處理故障，您可能需要追蹤斷路器被觸發的頻率，這可以幫助您了解 API 或其依賴項失敗的頻率。
請記住，根據你的 API 特性和應用需求，選擇追蹤的具體指標可能會有所不同。關鍵是要選擇那些能為你提供有意義的 API 健康狀況和性能洞察力的指標。
以 Prometheus 為例：
Prometheus 是一款內建客戶端庫的開源系統監控和警告工具包，它支持用各種語言度量您的服務。下面就是一個示例，說明如何使用 Go 客戶端庫在 HTTP 端點上展示指標。
我們將使用 Prometheus 的 Go 客戶端 來展示和創建這些指標。
復制
package main
import (
"net/http"
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
var (
httpRequestsTotal = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Number of HTTP requests",
},
[]string{"path"},
httpRequestDuration = prometheus.NewSummaryVec(
prometheus.SummaryOpts{
Name: "http_request_duration_seconds",
Help: "Duration of HTTP requests in seconds",
},
[]string{"path"},
func init() {
// Register the metrics.
prometheus.MustRegister(httpRequestsTotal)
prometheus.MustRegister(httpRequestDuration)
}
func handler(w http.ResponseWriter, r *http.Request) {
// Increment the counter for the received requests.
httpRequestsTotal.WithLabelValues(r.URL.Path).Inc()
// Measure the time it took to serve the request.
timer := prometheus.NewTimer(httpRequestDuration.WithLabelValues(r.URL.Path))
defer timer.ObserveDuration()
// Handle the request.
w.Write([]byte("Hello, world!"))
}
func main() {
http.HandleFunc("/", handler)
// Expose the registered metrics via HTTP.
http.Handle("/metrics", promhttp.Handler())
http.ListenAndServe(":8080", nil)
}
在這個例子中，我們創建并注冊了兩個指標：http_requests_total 和 http_request_duration_seconds。前者是一個計數器，每接收到一個請求就增加一次計數，后者是一個匯總指標，用于記錄處理每個請求所花費的時間。
然后，我們創建了一個 HTTP 處理器，每處理一個請求，就會增加計數器并測量請求的執行時長。我們利用 promhttp.Handler() 在 /metrics 端點上展示這些指標。
現在，只要你啟動了服務器并向其發送請求，就可以通過訪問 http://localhost:8080/metrics 或者使用工具如 curl 來查看這些指標。
這只是一個基礎的示例，在實際應用中，你可能會希望追蹤更多的指標，并基于其他維度（如 HTTP 方法、響應狀態碼等）對它們進行細分。
5. 利用 API 網關
API 網關是一種強大的工具，能有效提升 API 的健壯性。作為系統的統一入口，API 網關能夠處理諸如路由、負載均衡、認證、限流等多項功能。通過將這些問題從 API 本體中抽離，你能更專注于業務邏輯，而非基礎設施。
另外，API 網關還可提供額外的彈性特性，如自動故障轉移、為提高性能而對響應進行緩存，以及在高負載時對請求進行緩沖或排隊。
下面列出了 API 網關能提供的部分功能，幫助你為技術棧選擇適合的 API 網關：
- 請求路由： API 網關可以依據請求中的路由信息將客戶端請求路由到合適的后端服務。
- API 版本管理： API 網關能管理多版本的 API，允許客戶端并行使用不同版本。
- 限流： 為了避免請求過量淹沒后端服務，API 網關能夠限制某個或某組客戶端的請求速率。
- 身份驗證和授權： API 網關通常處理客戶端請求的身份驗證和授權，確保只有經過驗證并授權的請求才能到達后端服務。
- API 密鑰管理： API 網關通常管理 API 密鑰，這些密鑰用于跟蹤和控制 API 的使用方式。
- 緩存： 為了提升性能并降低后端服務的負載，API 網關可以緩存后端服務的響應，并在收到相同的請求時返回緩存的響應。
- 請求和響應轉換： API 網關可以將請求和響應轉換為客戶端或后端服務所需的格式。
- 熔斷器功能： 當服務出現故障，API 網關可以通過將請求路由到正常運行的服務來防止應用程序崩潰。
- 監控和分析： API 網關能收集 API 的使用和性能數據，用于分析、監控和警報。
- 安全策略： API 網關可以執行安全策略，如 IP 白名單，同時防止 SQL 注入、跨站腳本攻擊（XSS）等安全威脅。
以下是一些知名的開源 API 網關：
- Kong：Kong 是一個云原生、快速、可擴展、分布式的微服務管理層（也稱為 API 網關或 API 中間件）。自 2015 年以來，它以開源項目的形式存在，其核心功能是用 Lua 編寫的，并運行在 Nginx 網絡服務器上。
- Tyk：Tyk 是一個開源的 API 網關，運行速度快且可擴展性強，既可以運行在獨立服務器上，也可與已有的 Nginx 安裝進行協同工作。
- Express Gateway：Express Gateway 是一個基于 Express.js 構建的微服務 API 網關。該網關完全可擴展，不依賴任何特定框架，能夠在短時間內提供強大且可擴展的解決方案。
- KrakenD：KrakenD 是一個高性能的開源 API 網關。KrakenD 消除了所有 SOA 架構的復雜性，以支持應用程序開發者快速發布新功能，同時保持出色的性能。
總的來說，提升 API 的可靠性不是一項一次性任務，而是需要持續投入的工作。這包括嚴格的測試、精確的版本控制、遵循好的設計原則，智能地使用如 API 網關這樣的工具，以及持續的監控和分析。有了這些策略，你就能構建出能經受住時間考驗并為你的應用程序提供可靠基礎的 API。
譯者介紹
劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 JAVA 工程師，擁有多個主流技術博客平臺博客專家稱號。
原文標題：5 Ways to Improve Your API Reliability，作者：CodeReliant 社區
