譯者 | 布加迪

審校 | 重樓

在過去的15年里，我一直致力于設計不僅實用，還有彈性的API來適應意外故障，并在壓力環境下保持高性能。API彈性是指創建能夠在中斷（比如網絡中斷或流量突然猛增）后從容恢復的系統，確保它們保持可靠性和安全性。由于API是當今互聯系統的支柱，這一點變得至關重要。我的經驗包括應對一些挑戰，比如處理分布式架構中的服務故障以及緩解高需求系統中斷的級聯效應。我在本文中將介紹實用策略，以便設計可以擴展、有效處理錯誤并長期保持安全的API。

API架構的演變

多年來，API架構不斷發展，以堵住先前設計存在的缺口，并跟上日益緊迫的需求。然而它常在這個過程中引入新的挑戰。下面細述API架構方面的重大里程碑。

1. SOAP

簡單對象訪問協議（SOAP）開發于20世紀90年代末，是最早被廣泛使用的API協議之一。它為消息格式提供了嚴謹的結構，便于可靠安全的通信。它基于XML，確保了嚴格的協議和重量級的錯誤處理。它非常適合復雜的企業級系統集成（銀行和醫療保健等），一致的錯誤處理和嚴格的合規必不可少。然而，SOAP存在明顯的缺點：

• 復雜性：XML有嚴格的模式和消耗資源的冗長消息。
• 緊密耦合的服務：SOAP API傾向于創建緊密耦合的服務，這會降低靈活性和可擴展性。
• 高開銷：它依賴大量的元數據和處理，這影響了性能。

SOAP的局限性促使了更輕盈、更靈活的解決方案應運而生。

2. REST

2000年引入的代表狀態傳輸（REST）是API設計領域的一個重大轉變，它比SOAP更簡單、更輕巧。無狀態結構使其輕量級且易于使用，這有助于它流行起來，特別是用于構建Web和移動應用程序。開發人員很喜歡它使用HTTP方法（GET、POST、PUT、DELETE）以及JSON進行數據交換，因為這些方法易于理解和使用。

然而，REST存在自己的局限性：

• 過度抓取和抓取不足：客戶通常獲取過多或過少的數據，導致效率低下。
• 沒有實時支持：REST不是為實時交互構建的，因此需要為這些場景添加額外層。

REST今天仍然被廣泛使用，但日益與解決這些缺點的新方法相結合。開發出了像HATEOAS這樣的擴展，以幫助克服REST的一些限制，允許客戶使用鏈接來導航資源。盡管如此，HATEOAS并沒有得到廣泛的應用。相反，許多開發人員現在將REST與GraphQL之類的工具配對，以更好地滿足特定需求。

3. GraphQL

GraphQL于2015年由Facebook引入，旨在克服REST的一些限制。它允許客戶只請求所需的數據，從而防止獲取過多或過少的信息。使用單個端點，它簡化了在復雜應用程序中獲取數據的過程，尤其是在處理深度嵌套的關系時。

然而，GraphQL存在其弊端：

• 服務器管理：處理和優化GraphQL查詢可能需要在服務器端進行大量工作。
• 性能問題：設計不良或有害的查詢會給系統資源帶來沉重的負擔。

雖然GraphQL在某些情況下是一種強大的工具，但其復雜性意味著最好與REST一起工作，而不是完全取代它。

4. 微服務和事件驅動架構

從單體架構向微服務轉變帶來了模塊化和獨立的可擴展性，但也引入了利用API網關來處理通信的需求。在這種方法中，每個微服務專注于一個特定的任務，這減少了依賴系統其他部分的程度，并允許獨立擴展。為了協調這些服務，API網關管理和指導請求。

另一方面，對于不需要即時響應的任務，Kafka之類的事件驅動系統支持實時工作流。這種方法適用于消息傳遞平臺或物聯網應用程序等應用場景。

然而，這種架構也帶來了挑戰：

• 服務發現：在分布式系統中，動態識別和關聯服務是一個挑戰。Kubernetes等工具和Istio等服務網格通過自動化服務注冊和發現來幫助處理這個問題。它們還提供負載均衡和故障切換等功能，以保持服務順暢運行。
• 一致性模式：在分布式系統中維護一致性很棘手。最終的一致性模式可能允許過時的數據存留一段時間，而更嚴格的一致性可能會減慢系統的速度。開發人員需要權衡這些取舍，根據其應用最需要的因素來設計解決方案。
• 管理分布式事務：跨多個服務協調工作流需要深思熟慮的模式。Saga模式將事務分解為更小的步驟，每個步驟都有后備計劃，以防出現問題。CQRS（命令查詢責任分離）將讀寫操作分開，使擴展更容易，使架構更易于管理。

API設計的每一步都旨在改進系統的性能和適應性，不過這通常需要克服新的技術障礙。如果將強大的設計原則與合適的工具和模式相結合，團隊可以構建可擴展、有彈性的架構，同時有效地應對這些復雜性。

彈性對API意味著什么？

API的彈性指能夠在壓力環境下保持功能正常，并在不完全失效的情況下處理錯誤。這通過實施確保系統很少宕機的容錯機制來實現。彈性API可以不間斷地管理繁重的負載。比如說，支付網關應該在高流量期間繼續運行，即使某些服務暫時不可用。另一方面，缺乏彈性的API很可能在大流量或依賴服務宕機時失效。

構建彈性API的一個關鍵因素是可擴展性。可擴展性允許API處理不斷增加的流量。這可以通過縱向擴展（向現有服務器添加更多的資源，如內存或CPU）或橫向擴展（部署額外的服務器實例以分配負載）來實現。可擴展性還需要使用故障切換機制，其中API跨多個區域或服務器部署，以減小單個位置的中斷造成的影響。

負載測試在確保可擴展性方面起著至關重要的作用。通過模擬不同大小的流量，開發人員可以測量吞吐量和延遲等性能指標，并進行必要的優化。AWS負載均衡器等工具有助于評估API是否可以在沒有延遲或瓶頸的情況下處理需求。

簡而言之，可擴展性確保API可以管理高流量，而彈性確保可以有效地處理錯誤和故障。總之，這些原則對于設計穩健可靠的API至關重要。

API彈性：最佳實踐和常見陷阱

這節解釋如何構建可靠的API，并指出可能削弱它們的常見錯誤。這節介紹了使API更強大更安全的方法，以便可以在不影響系統的情況下處理問題。如果遵循下面的建議，你可以創建順暢運行的API，并保持用戶體驗的一致性，即使出現問題時也是如此。

1. 錯誤處理

在構建API時，以一種幫助開發人員并保持系統順利運行的方式處理錯誤很重要。使用清晰、標準化的錯誤代碼，比如400表示錯誤的請求，503表示服務不可用，這樣客戶就可以知道哪里出了問題，下一步該怎么做。此外，為這些代碼附上解釋問題并建議解決方法的詳細信息。比如說，不要返回模糊的“錯誤請求”，而是指定“缺少必填字段‘email’”。

為了防止級聯故障，不妨考慮使用斷路器之類的技術，這有助于停止對失效服務的重復調用，并讓系統有機會恢復、防止大范圍中斷。它可以很好地阻止對失效服務進行重復調用，從而防止更嚴重的問題。比如說，像Resilience4j for Java這樣的庫就可靠地實現了斷路器及其他容錯機制，因而更容易將這些實踐集成到你的應用程序中。

另一方面，忽略詳細的錯誤報告會使調試復雜又耗時。一般錯誤（比如“500內部服務器錯誤”）無法提供足夠的信息來快速解決問題。此外，不限制錯誤率可能會在出現問題時給系統帶來額外的負載。

2. 可擴展性和負載處理

在設計API時，重要的是通過跨多個實例分散流量來規劃可擴展性。實現這一目標的一種方法是，使用負載均衡器在多個實例之間分配流量。為了提高彈性，可以考慮跨不同區域使用故障切換系統，以減小本地中斷造成的影響。使用JMeter之類的工具運行負載測試有助于識別瓶頸，并驗證你的API在高流量環境下性能良好。

在擴展時，可以在自動擴展策略和手動擴展策略之間進行選擇。Kubernetes Horizontal Pod Autoscaler支持的自動擴展可以根據實時需求動態調整資源。這種方法減少了操作開銷，并確保在流量高峰期間有效地使用資源。然而，它可能會在配置和對突發需求變化的響應時間方面帶來復雜性。另一方面，手動擴展帶來了更強的控制性和可預測性，但可能導致響應意外流量模式出現延遲，可能需要持續監控。

避免過度依賴向單臺服務器添加資源也很重要，因為這種方法可能會變得昂貴、難以為繼。此外，跳過負載測試可能會使你的API在流量高峰期間容易受到攻擊，可能導致在最需要的時候偏偏停機。

3. 速率限制和節流

速率限制通過確保API不被濫用和資源被公平使用來幫助保護API。像令牌桶和漏桶算法這樣的方法適用于設置限制。令牌桶算法很靈活，允許在設定的限制內的流量突發，這使得它非常適合間歇性峰值的場景。相比之下，漏桶算法強制執行一致的流量速率，使其非常適合長時期保持穩定的資源消耗。選擇合適的方法取決于API的流量模式和用例。

向用戶清楚地傳達速率限制也很重要。當用戶達到速率限制時通知用戶，并指導如何調整使用量。為API端點設置適當的超時，并在重試期間使用指數回退方法，以防止在依賴項緩慢或沒有響應時發生級聯故障。

然而，如果速率限制設置不當，就會讓用戶感到沮喪。如果客戶覺得在為不夠大的訪問權付費，激進的限制（尤其是在貨幣化的API方面）可能會把他們趕走。比如說，如果沒有清楚地解釋限制，或者如果用戶沒有收到反饋，他們可能會感到困惑。此外，在流量高峰時不調整限制可能會影響用戶體驗。

4. 安全

在設計API時，安全是保護系統和用戶的關鍵環節。首先，從實現強身份驗證方法入手，比如OAuth 2.0和JSON Web令牌（JWT）。始終使用HTTPS進行安全通信，并對傳輸中或存儲的敏感數據進行加密。設置速率限制和IP白名單有助于防止未授權的訪問和蠻力攻擊，確保只有受信任的客戶端可以使用你的API。此外，定期的安全檢查（包括審計和滲透測試）對于識別和處理漏洞也很重要。

另一個重要的考量是保護API端點免受注入攻擊。始終驗證和清理所有輸入，使用參數化查詢，并限制輸入大小，以盡量降低風險，并防止SQL或命令注入等攻擊。部署速率限制措施，并使用Web應用防火墻（WAF）或專門針對API的入侵檢測和防御系統（IDS/IPS）之類的工具實時監控和緩解威脅，并保護系統免受分布式拒絕服務（DDoS）攻擊。

此外，還有一些常見的陷阱需要避免。直接在代碼中硬編碼API密鑰或秘密信息有風險，因為這會使它們暴露給未授權訪問者。另一個問題是沒有設置適當的令牌過期和輪換，這可能使系統容易受到攻擊。沒有清晰而詳細的安全文檔的API常常導致糟糕的實施，使它們容易受到攻擊。積極主動地對待安全也很重要，而不是只在出現問題后才被動反應。使用監控工具跟蹤異常活動，并接收有關潛在威脅的警報。

5. 版本控制和兼容性

API版本控制有助于防止更新破壞已經使用API的系統。常見的方法包括將版本添加到URL（比如/v1/resource）或在header中指定。這種方法使客戶很容易知道他們在使用哪個版本。為了避免干擾用戶，保持向后兼容性很重要。當你需要淘汰舊版本時，盡早溝通棄用計劃，并通過文檔、電子郵件更新或帶有棄用警告的API響應頭通知客戶，幫助他們順利換成新版本。版本控制讓開發人員可以在不給現有用戶帶來問題的情況下不斷改進API。

另一方面，跳過向后兼容可能會讓用戶感到沮喪，并將他們趕走。在沒有適當指導或溝通的情況下發布破壞現有系統的更新只會阻礙采用。此外，切莫將版本控制與環境（如登臺或生產環境）混在一起。這會造成混亂，并使順暢管理更新變得更困難。API網關之類的工具（比如Kong、APIgee和AWS API Gateway）可以簡化版本管理和監控使用情況，這將幫助你確定何時可以安全地淘汰舊版本。

6. 可觀察性

密切關注API的性能是確保其順利運行的關鍵。如果跟蹤請求率、錯誤計數和響應時間等指標，你就可以清楚地了解系統的健康狀況。AWS CloudWatch、Prometheus、Grafana和Datadog之類的工具支持實時監控，從而更容易發現問題并及早解決。為延遲、錯誤率和吞吐量等重要指標設置警報也很有幫助，以便在問題惡化之前解決問題。

日志記錄是可觀察性的另一個關鍵部分，它對調試和故障排除極其有用。使用適當的日志級別很重要——debug（調試）用于開發期間的詳細故障排除，info（信息）用于一般操作數據，warn（警告）用于警告潛在問題，error（錯誤）則用于需要立即注意的關鍵問題。使用適量的日志記錄也很重要；在較低級別添加過多的日志（比如生產環境中調試）將有助于迅速找到重要的趨勢，而另一方面，不足的日志可能讓你看不到潛在的問題。

使用OpenTelemetry之類的開放標準，在一個框架下統一度量、日志和跟蹤。這使得從系統的各個部分收集和連接數據變得更容易，從而使你清楚地了解API的行為方式。使用這種統一的方法還簡化了使用監控工具，并使調試問題變得更容易。最后，確保在測試和登臺環境中包含可觀察性。關注這些早期階段可以幫助你在性能問題或bug到達生產環境之前揪出它們。

構建彈性API的工具和技術

• API網關：AWS API Gateway、Kong和APIgee是一些領先的API管理和可擴展性綜合功能平臺。它們支持對路由、速率限制和身份驗證進行集中控制。
• 監控和日志記錄：AWS CloudWatch、Datadog和New Relic提供了強大的解決方案，用于監控API性能指標，并針對服務異常提供實時警報。
• 測試工具：Postman、JMeter和SoapUI之類的工具便于深度測試，并確保API將根據性能和彈性基準的要求來運行。Postman廣泛用于功能測試，JMeter用于負載測試，SoapUI用于SOAP測試和REST API測試。

API設計的未來

由于人工智能、機器學習、無代碼/低代碼平臺等的發展，API設計將繼續以不斷增長的速度變化。這些都旨在使API極其智能化、極具彈性，并可供更龐大的開發人員和非開發人員群體使用。

1. API設計中的AI和機器學習

人工智能和機器學習正在改變我們保持API順暢運行的方式。這些工具有助于監控系統、預測潛在問題和提高性能。通過研究過去的數據，人工智能可以識別可能導致中斷或減速的模式，這讓團隊有機會在問題變成更大的混亂之前解決問題。

此外，機器學習還有助于發現系統中的異常活動。它分析不同的指標，以發現一開始可能不明顯的問題。這使得修復性能問題更容易，并使系統總體上趨于更穩定。人工智能和機器學習共同提供了實用的方法來確保API保持可靠和高效。

實際使用：

• Netflix使用基于人工智能的混沌工程來測試系統，通過引入小故障來發現和修復弱點。
• AWS通過預測擴展提前調整資源，確保有效好滿足需求。
• Google Cloud Monitoring集成了基于機器學習的警報，可以在潛在的系統故障發生之前預測，幫助API提供商主動采取行動。

2. 無代碼和低代碼API平臺

無代碼和低代碼平臺讓沒有強大編程技能的人也可以創建和管理API。它們依賴簡單的可視化工具（如拖放功能），消除了過去需要高級編碼知識的任務復雜性。這種平臺向更多用戶（包括業務團隊）敞開了流程，從而加強了部門間的協作。

一大好處是加快開發。這些對用戶友好的工具減少了構建API所需的時間和精力。它們還使技術團隊和非技術團隊更容易協同工作，讓更多的人參與到API的創建和集成。

實際使用：

• ZAPIer：無代碼平臺讓用戶在不編寫代碼的情況下集成面向Google Sheets、Slack和Trello等流行服務的API。
• MuleSoft Anypoint Platform：將低代碼工具與高級功能相結合，幫助專業開發人員快速構建和部署易于擴展的API。

3. 自描述和可發現的API

如今API常常在其設計中包含理解它們所需的一切。這減少了對額外文檔的需求，并使其更容易集成。OpenAPI（以前名為Swagger）之類的工具可以幫助開發人員直接從API代碼創建準確且最新的文檔。這確保了一切保持一致、易于使用。它還使導入更快速、維護更簡單，并使API對開發人員更友好。RapidAPI之類的平臺還使查找和連接API變得更容易，省去了過程中不必要的步驟。

實際使用：

• Stripe API：采用OpenAPI規范生成詳細的、對用戶友好的文檔，開發人員可以一目了然和快速運用。
• RAPIdAPI Marketplace：充當集中式平臺，使開發人員能夠以最小的阻力發現和集成API。

4. 事件驅動架構

事件驅動API在創建實時工作且不依賴嚴格時間表的工作流中起著關鍵作用。它們尤其適合管理不斷變化的情形，這使得它們非常適合聊天應用程序、物聯網設備和股票交易系統之類的應用。這些API在事件發生時響應事件，從而改善了用戶體驗，簡化了系統運行，并且更容易從容應對增長。這種結構允許系統的不同部分獨立運行，這有助于在系統擴展時保持靈活性和可靠性。

除了使系統運行更順暢外，事件驅動API還支持即時通信和更新。它們確保用戶和系統都能沒有延遲地獲得所需的信息，這有助于一切系統更有效地運行。無論是支持消息傳遞應用程序，還是幫助微服務快速共享數據，這些API都在改變應用程序處理不斷變化的信息的方式。

實際使用：

• Slack實時消息API：這為機器人或其他應用程序提供了即時收發消息的能力，因此它減少了協作中的阻力。
• 事件流：在Apache Kafka和AWS EventBridge之類的平臺上，事件驅動API可以跨微服務實時高效地共享數據。

5. 無服務器

無服務器計算通過將基礎設施管理轉移到AWS Lambda和Google Cloud Functions等云平臺來改變API的處理方式。開發人員編寫觸發時才運行的代碼，而不是處理服務器。這種方法使操作更簡單，使成本得到控制，并自動調整資源以滿足需求。企業只需為所使用的資源付費，并獲得根據流量需求擴大或縮小規模的優勢。

實際使用：

• AWS Lambda支持流量模式不可預測的API，在不過度配置資源的情況下保持性能。
• Twilio使用無服務器計算來管理其通信API，在高需求期間實現無縫擴展。

6. 通過設計保證安全API

API正在適應日益加大的網絡安全挑戰。優先考慮安全可以幫助它們有效地應對攻擊，保護敏感信息。許多現代API現在使用人工智能等工具來檢測威脅，并運用零信任原則來確認每次交互。這些步驟提高了安全性，并確保API即使在有風險的情況下也保持可靠。

借助注重安全的方法，API可以防止未授權訪問或不尋常的流量模式等問題。通過使用嚴格的身份驗證方法，它們保護用戶數據并建立信任，使它們成為處理敏感信息的企業的重要資源。

實際使用：

• Microsoft Azure API管理：集成了基于人工智能的威脅檢測，以監控API使用情況，查找流量異常和未經授權的訪問活動。
• Twilio API：通過API密鑰、基于令牌的訪問和定期的令牌輪換策略實現最嚴格的身份驗證。

結論

我們需要精確而全面地設計API彈性，遵循錯誤處理、可擴展性和監控等方面的最佳實踐。隨著行業快速發展，開發人員必須密切關注，并始終跟蹤新的工具、技術和策略。只有不斷學習和創新，API開發人員才可以構建穩健的系統，能夠適應復雜的大規模需求，同時滿足用戶和企業不斷變化的需求。這種致力于不斷改進的做法確保API保持實用功能、適應未來形勢，并充當互聯數字生態系統的支柱。

原文標題：Best Practices for Designing Resilient APIs for Scalability and Reliability，作者：Parvin Gasimzade