現代企業是高度以消費者為導向的。因此，為客戶提供價值應該是我們的首要任務。使客戶的任務更加方便和高效是我們的首要目標。要做到這一點，我們需要找出“什麼”可以使我們的客戶更有效率併為他們的工作帶來便利的方法。
這需要大量的反覆試驗。這要求我們構建並嘗試使用系統和功能，以查看這些功能是否確實為我們的客戶帶來了巨大的價值。這是促使企業體系結構更加分解和可組合的主要動機。聽說過“微服務”嗎？
這就是為什麼微服務變得非常流行的原因。微服務使傳統的企業（高度依賴整體資源）可以分解為更小的獨立單元。這使我們能夠更快地向系統中引入新功能，而對系統其他區域的影響則小得多。這就是創建一個平臺的原因，它可以幫助我們比以往更快，更輕鬆地發現“真正”為客戶帶來價值的“東西”。
儘管微服務可以極大地提高我們的業務的敏捷性和效率，但API才是為我們的消費者/客戶提供微服務價值的要素。API位於我們的客戶和微服務之間的邊緣，將兩者連接在一起可創建令人驚歎的用戶體驗。因此，API位於為客戶提供價值的最前沿。在本博客文章的其餘部分中，我們將探討作為成功的API系統的架構師，CxO和其他決策者需要考慮的內容。
顛覆傳統的API交付模式
作為向消費者交付API的組織/企業，您可能熟悉以下交付API的模型。
傳統API工作流程
在此模型中，我們首先使用門戶來設計，實現和記錄我們的API。然後，通過發佈將其部署到我們的網關和開發人員門戶。然後，API可供應用程序開發人員發現和使用。雖然此模型為我們提供了良好的服務，但現在它已成為我們為客戶提供價值的過程敏捷性的瓶頸。
我們提供微服務的流程效率更高，更易於自動化，並且在發生故障時易於回滾。我們還需要為我們的API採用類似的模型。為此，我們需要更改開發和部署過程，以遵循更多自下而上的方法，而不是自上而下的方法，如上所述。下圖說明了這是什麼。
自底向上的API開發方法
與部署代碼類似，我們的API從第一天起就需要進行持續集成和持續部署。我們需要授權API開發人員構建，部署和測試API，直到他們對結果滿意為止，然後才能將其部署到門戶和生產網關。API的代碼需要使用SCM（Github）進行版本控制和管理。
我們需要使用Jenkins，Travis CI等構建自動化工具來將API部署到各自的環境中進行自動化。我們需要確保開發人員從第一天起就具備所需的適當工具，以在API上啟用CI / CD並對其進行管理，類似於管理其應用程序的源代碼。
API治理
採用API的自底向上傳遞模型的關鍵瓶頸之一是對API缺乏治理。API產品經理擔心他們會失去正在發佈的API的權威和治理。這是一個真正要解決的問題。組織有責任確保其發佈的API遵循正確的標準，最佳實踐，以正確的方式進行保護等等。否則將對組織產生負面影響。那麼，我們如何以敏捷的方式交付API，同時又對API進行適當的管理？
API工作流程
在這裡，API的良好“控制平面”的價值變得很重要。API控制平面需要支持API的良好生命週期管理功能，以便API產品經理可以在API發佈到門戶並通過CI / CD傳播到上層環境之前進行審核和同意。通過可配置的工作流程批准API的設計以及驗證用於最佳實踐和安全性的架構的能力是必不可少的功能。
可組合性
API的可組合性
API不再是HTTP（僅）微服務的簡單接口。現代企業體系結構由許多不同類型的微服務組成。您可以讓團隊開發微服務，這些微服務作為無服務器功能（例如AWS Lambda）在gRPC，WebSockets上公開。
但是，需要使用這些服務的應用程序需要一個易於理解的統一界面來訪問這些服務。應用程序將需要一個單一的身份驗證終結點，以授予對服務的所需訪問權限，一個用於這些服務的單一SDK，一個具有統一文檔來源的統一界面等。
這些都是由API層授予應用程序的。因此，API並不是一組服務的簡單代理。它是一個處理集成異構微服務的細微差別並將其組成可暴露的統一接口以供應用程序使用的細微差別的單元。
API安全
API的成功鼓勵了許多組織將其業務功能公開為公共API。許多人會開始僅出於內部目的公開API，然後再將它們擴展為公開展示。在過去幾年中，對API的這種廣泛採用已實現了巨大的增長，並導致API獲得了極大的普及。
這自然使API成為攻擊者嘗試竊取敏感信息或以其他可能的方式對組織造成危害的豐富狩獵場。因此，我們需要對API的安全性問題保持高度警惕，並應將API安全性視為高度優先事項。無論何時部署API（即使是第一次），都絕不要事後思考，並且應該始終是一個醒目的複選框。
幾乎總是以基於OAuth2.0的身份驗證和授權的形式來考慮API安全性。OAuth2.0確實已經確立了自己作為API安全的事實上的標準，但是必須充分考慮API的安全性，而不是認證和授權。我將API的安全性分為3個方面。
- 防止惡意內容和DOS攻擊。
- 身份驗證和授權。
- 通過不斷學習異常模式識別來保證安全性。
API安全工作流程
惡意內容和DOS攻擊
向API發出請求的客戶端（攻擊者）可以完全控制其發送的消息。這些消息可以經過許多服務層，如果是惡意的，則可能對系統造成潛在的危害。這些消息可能是旨在執行注入攻擊（SQL注入）的消息，非常大的消息（導致消耗大量服務器資源），包含XML炸彈的消息等。
惡意客戶端應用程序還可能發出大量API請求，從而導致服務器用盡資源來為系統的真正用戶提供服務（DOS攻擊）。可以使用Web應用程序防火牆或API網關來防止對API的此類攻擊。這些系統可以檢查消息的內容，並根據預定義的架構或規則（模式）驗證消息的內容，並且僅接受屬於定義範圍內的消息。它們還能夠限制客戶端請求的速率，以防止客戶端在非常短的時間內發送大量消息，從而防止潛在的DOS攻擊。
儘管從技術上來說可以使用API網關或Web應用程序防火牆來防止這些類型的攻擊，但是Web應用程序防火牆更適合於此目的。這是因為Web應用程序防火牆專用於這些類型的安全域，而API網關通常負責這些系統中的許多任務。
安全是一個應該專門化的領域，並且需要專職致力於研究和創新。一旦發現新的漏洞併為其發佈了補丁程序，則應立即更新安全網關。這是專門針對領域的系統最好的方法。Alissa Knight撰寫的此博客文章詳細比較了每個角色的職責，並討論了為什麼在企業體系結構中使用這兩個層次很有意義。
身份和訪問控制的驗證是我們在API領域中大多數人所熟悉的東西。這是關於基於有效憑證授予對API資源的訪問權限，該憑證的範圍可以是OAuth2.0訪問令牌，API密鑰，基本身份驗證標頭，客戶端證書等之間的任何內容。
它還涉及檢查所提供的憑據是否具有訪問所請求資源所需的權限級別。系統不應僅基於有效憑證就允許全局訪問其資源。它的系統設計應檢查或至少保留執行進一步訪問控制的規定。
例如，任何具有有效用戶名和密碼的用戶都應被允許在在線零售商店上閱讀產品詳細信息。但是，應僅允許具有管理員權限的用戶更新產品詳細信息。訪問控制有時遠遠超出基於角色的檢查範圍。也有一些系統會根據日期和時間（工作日僅在上午8點至下午5點之間允許訪問），基於請求配額等進行訪問控制。
API網關專門從事這些類型的身份驗證和授權檢查。他們將這些要求抽象為標準規範和協議，並允許客戶端應用程序使用這些機制（例如OAuth2.0）與它們進行交互。大多數API網關解決方案還能夠將用戶上下文傳播到下游（後端）API。
由於這些身份驗證和授權檢查在API網關處終止，因此默認情況下，下游API將不具有發出這些請求的用戶的上下文。下游API有時需要知道訪問API的用戶的詳細信息，以執行其自己的邏輯。因此，API網關有責任將用戶上下文傳播到下游API。
持續學習以識別模式並檢測異常
憑證被盜很難追蹤。如果有人入侵了您的API密鑰或訪問令牌，僅我們的防火牆或身份驗證層不足以檢測到有人正在使用被入侵的憑據。這就是為什麼與API密鑰或基本身份驗證憑據相比，OAuth2.0訪問令牌在使用上更加安全的原因之一。OAuth2.0訪問令牌的時間跨度相對較短，即使被黑客入侵，也只能在令牌過期之前使用。只有通過觀察用戶的訪問模式，才能檢測到被盜憑證或憑證使用不當。如果某個特定國家/地區的用戶使用了令牌，並且幾分鐘後另一個國家/地區的某人使用了同一令牌，
API網關本身無法保護系統免受這些類型的攻擊。API網關通常跨不同網絡進行群集，它們之間不一定會共享用戶的狀態和訪問歷史記錄。但是，API網關可以與數據分析解決方案一起使用，其中包括某種形式的機器學習和模式分析解決方案。這些系統將跟蹤用戶訪問歷史記錄和模式，並在出現問題時向API網關發出警報。然後，網關可以採取有關驗證用戶請求的適當措施。
規模
擴展API
許多組織正在將其基礎架構遷移到雲中。此舉是免費的。在第三方IaaS提供商（例如AWS，Google，Azure等）上運行全部或大部分企業IT的成本很高。所有IaaS提供商都採用按需付費模式。這意味著您需要為使用的資源付費。
因此，至關重要的是，以最少的服務器超額配置來消耗運行系統所需的最佳資源量。對於傳統的企業IT，我們將對系統進行容量規劃，以應對峰值負載。如果我們的系統需要10臺服務器來滿足平均系統負載，但又需要10臺服務器來滿足峰值負載，那麼為了安全起見，我們將以20臺服務器運行系統。
當組織本身擁有基礎架構時，這將不是問題。但是，當使用來自第三方IaaS提供商的基礎架構時，這意味著我們正在花錢購買幾乎不使用的東西。為了解決這個問題，我們需要我們的API（和API網關）能夠快速按需擴展和縮小。自動擴展是雲原生企業架構的關鍵特徵之一。幾乎所有的IaaS提供商都提供自動擴展功能。但是，要使自動縮放有效，我們的軟件還必須能夠快速縮放。擴展我們的軟件時需要考慮以下幾點：
- 開機延遲。
- 對其他系統的依賴性。
- 狀態複製。
進程啟動速度越快，擴展系統規模就越容易。如果某個進程需要30秒或更長時間才能啟動，則需要至少在30秒之前開始擴展系統，然後才能真正啟動並運行該進程。一個過程開始花費的時間越長，開始縮放過程的時間就越早。
有時無法僅對單個進程進行縮放。您的API和API網關可能依賴於其他幫助程序進程來執行其功能。這意味著您還需要考慮擴大/縮小這些幫助程序。您的API和API網關越獨立，就越容易擴展系統。
如果您的API和API網關在其內部或外部維護狀態，則在擴展API時將需要考慮複製系統狀態。與有狀態系統相比，無狀態系統通常更易於擴展。因此，快速啟動，獨立且無狀態的API是自動縮放系統的理想選擇。
可用性
在當今世界，系統的可用性變得至關重要。停機造成的對企業的影響越來越難以忍受。因此，我們的目標是使我們的API做到100％可用，這絕非易事。假設我們已經處理了前面討論的與規模相關的問題，那麼此處重點關注的是
彈性。我們都自然地擅長於創建強大的系統。但是，我們必須承認和接受的是，在某個時間點上，某些事情將會失敗。您未曾預料到的事情一定會發生並引起麻煩。因此，至關重要的是，我們要考慮發生故障時會發生什麼情況，如何恢復，為API配備什麼樣的備份系統？
我們討論的有關規模的一切對於構建彈性系統都很重要。除此之外，我們還需要考慮：
- 當系統出現故障時，我們可以以多快的速度恢復系統。
- 系統的高可用性（數據中心可用性，區域可用性和IaaS提供程序可用性）。
恢復系統可能比看起來困難。系統具有的依賴性越多，發生故障時恢復的難度就越大。在這個區域中，容器和平臺（例如Kubernetes）可以成為救生員。這些平臺具有自動修復功能，可為系統提供急需的魯棒性。
當然，它們有其自身的複雜性和侷限性，但是它們提供給我們的API的健壯性和易於管理的水平是值得的。與擴展一樣，API的啟動時間，它們的獨立性和有狀態性是恢復API系統的重要因素。您的API的原生雲越多，一旦出現故障，它們越容易恢復。
高可用性是我們都熟悉的東西。它只是意味著為系統中的每個服務器，進程，文件系統，數據庫等都有一個備份。但是，我們還需要考慮數據中心和區域可用性區域。如果我們的整個數據中心或區域出現故障，會發生什麼？如果要在內部運行基礎結構，則需要計劃在其他物理位置上具有備份基礎結構。
您的API需要同時部署在這兩個位置。為此，您需要構建系統和流程，以使您可以輕鬆地在多個數據中心之間部署API，而不會給API開發人員增加更多的開銷。這些需要通過儘可能多的自動化來有效地完成。即使您依賴IaaS提供商的基礎架構，也是如此。您需要考慮可用性區域，以及如何在儘可能少的工作開銷下輕鬆地跨多個可用性區域複製數據。
最近，雲服務提供商的可用性也受到很多質疑。如果IaaS提供商的特定服務在全球範圍內（即使是很短時間內）失敗，會發生什麼情況？您的系統是否具有足夠的彈性，以便可以在可以切換到的其他IaaS提供程序上運行備份？例如，如果AWS RDS服務在給定區域上短時間失敗怎麼辦？您是否可以備份Azure上的備份？將所有雞蛋放在一個籃子裡絕對不是一個好主意。
我與許多客戶合作，這些客戶已成功在不同地區的IaaS提供商之間部署了他們的API。聽起來像是一個不可能的問題的昂貴替代方案。是的，除非經過深思熟慮和精心設計，否則一切都會如此。此處的關鍵是構建可擴展的系統，該系統可在IaaS提供程序之間分佈，並在整個基礎架構中分佈系統負載。這樣，您只需為使用的商品付費。並在必要時保留規定以按比例縮放。
見解
API是當今許多數字企業的經濟/收入背後的驅動力。因此，瞭解API的性能，瞭解有效的方法，無效的方法以及擁有良好的數據集以進行準確的課程更正對於API至關重要。基於API的見解可以分為3個不同類別，例如
- 運營洞察力。
- 錯誤診斷。
- 業務見解。
運營見解
運營洞察力（也稱為監視）對於任何組織確保其API正常運行，從而確保業務平穩運行都是至關重要的。擁有針對API的監視系統通常可以使您“在發生問題之前”知道問題。當然，相反的情況是，缺少監視系統只會讓您意識到發生故障後的故障，通常是通過客戶投訴！
不用說，在故障發生之前就知道故障，這將使您更輕鬆地處理故障，並且所承受的壓力也更少。最好的部分是，您將採取必要措施消除此類故障對客戶的影響，因此您的客戶永遠不會知道故障。
假定您的服務/ API之一開始耗盡內存的情況。一個好的監視系統將檢測API的內存消耗的逐漸增長，並在超過特定閾值時發出警報。這為系統管理員打開了立即採取行動的機會，可防止您的客戶受到此事件的影響。
在這種情況下，通常的做法是啟動一些備份過程。由於我們尚未發現並解決故障的根本原因，因此備份程序很有可能也會在一段時間後開始耗盡內存。
但是，擁有一組備份流程使我們有機會繼續重新啟動有故障的流程，讓備份流程處理客戶的請求，並以循環方式繼續執行此操作，直到確定並解決了根本原因。因此，儘管我們的流程有問題，但由於該事件，對客戶的影響為零，這從業務角度來說是一個重大勝利。
錯誤診斷
一旦發生了事件並通過運營監控或客戶投訴確定了事件，下一步應立即採取的措施是確定事件的根本原因並加以解決。錯誤診斷在確定根本原因中起著關鍵作用。出於診斷目的而獲取數據的速度，這樣做的難易程度以及您收集的有關故障的數據量都是要考慮和實施的重要因素。
首先要查看系統日誌以識別事件原因。因此，從API和服務收集所有運行時日誌並使其具有索引形式以便於快速輕鬆地進行搜索非常重要。獲取特定時間範圍內發生的系統事件日誌的能力也很重要。
掌握事件日誌後，日誌本身可能會揭示事件的原因，例如磁盤空間錯誤不足。但是，在某些情況下，日誌僅給出原因的暗示，而不一定揭示實際原因本身。在這種情況下，有必要啟用進一步的日誌記錄，跟蹤，獲取內存轉儲，網絡（tcp）轉儲，等等。
您應該致力於構建能夠以理想的零故障率或最小的客戶影響率進行故障排除的系統。這樣做的一種流行模式是將一組故障節點隔離到一個單獨的群集中，該群集要麼不接收客戶流量，要麼僅接收一小部分客戶流量，並對它們執行故障排除。
商業見解
如前所述，API是當今許多數字企業的主要收入來源。因此，企業自然會通過使用和採用其API來衡量業務的成功和增長。使API成為組織業務策略的驅動力也很有意義。
為此，我們需要確保我們的API能實現我們期望的業務價值和增長。為此，衡量API的“業務影響”至關重要。我們需要一個系統來捕獲與實現我們的業務目標相關的所有API數據。諸如上個月的新API使用者數量，基於我們的API構建的新應用程序數量，響應時間改進，特定區域內的用戶增長（在針對該區域的營銷活動之後）等等。
由於API是組織數字服務的切入點，因此它們是衡量業務KPI的重要來源。
結論
在本文中，我們瞭解到：
- 為客戶提供價值是我們的第一要務。基於微服務的體系結構旨在以更快的速度交付可靠的軟件，從而為客戶提供更高的價值。
- API是企業體系結構的基礎層，可以創建數字體驗。
- 現代API是自下而上開發的，從而使API開發人員和CI / CD流程更加突出。
- API治理在確保正確交付API和正確交付API方面發揮著重要作用。
- API應該是可組合的。組織應具有將服務的異構集合組合到API中的能力。
- API安全性有三方面。內容檢查，身份驗證和授權，異常的模式分析。
- API應該具有可擴展性，可以滿足雲原生時代的需求。
- 9的可用性不再存在。需求是100％的可用性。
- API見解對於維持和發展數字企業至關重要。
閱讀更多 一名小白人員 的文章
