前言
API生態或Open APIs的落地中，最關鍵的技術組件就是API治理（管理），其需要的是基於微服務的架構支撐和全新的關係理念，即使第三代的API管理，從代理/Proxies到微網關/Micro-Gateways。
正如SOA架構理念和體系一樣，SOA治理或服務治理是最後的關鍵，API化的結果，也必將落到API治理的角度。而最為關鍵的除了Discovery、Registration等，更關鍵是Gateway的存在。尤其是Open APIs的實現，全部的安全、流控、測試、路由等等，都是在此實現。
如上圖所示，不管航企內部是PSS還是SOA，還是其他架構及實現，其為了支撐Open APIs，必須現有微服務的落地。雖然其包含Gateway的部分，但是作為Open APIs的管理層，API Manager本身就具備（其實就是增強的Gateway）Gateway的功能，而且是唯一和必須的Entry。
API化是數字化轉型的必然趨勢
如今的航旅實體主鍵明白，為了在“Digital Disruptors”占主導地位的市場中保持競爭力，他們必須創新並獲得業務敏捷性和速度。為此各種規模的組織都在採用雲（SaaS、PaaS、IaaS），不僅作為降低TCO的手段，而且作為實現數字化轉型和以客戶為中心的工具。
然而，移動到雲計算並不意味著就是某個雲計算的採用。組織正在選擇多雲策略，而不是把所有的雞蛋放在單個雲供應商的籃子裡。這種採用雲技術的最佳方法意味著內部單體系統（如ERP）和其他內部應用程序作為獨立的SaaS應用程序在雲中重新實現，並與PaaS集成或擴展。
對於那些沒有云等價物或只是沒有滿足所需訴求的本地應用程序，許多組織也選擇在雲中進行應用程序開發。微服務架構已成為實現此類雲本地應用程序的主要架構樣式。為了做到這一點，一個整體被分解成更小的部分，每個部分代表業務能力，然後作為一個完全分離的服務（微服務）實現，通常在PaaS中實現。
隨著雲技術的不斷採用，信息不可避免地變得越來越聯合，不僅跨許多不同的SaaS和PaaS應用程序（來自不同的供應商），而且跨許多內部系統。為了實現數字化轉型，組織必須首先調整或增強其現有（內部）IT系統，或嘗試用現代IT系統（可能在雲端）取代它們，以便通過多個渠道（網絡、移動應用程序、信息亭、合作伙伴在線商店、機器人等）以數字化方式提供產品和服務。數字化轉型使同事能夠在移動中執行業務流程，同時通過不同的設備交互提供無縫的旅程，從而提高工作效率。它還通過向組織的合作伙伴提供對相關業務數據的按需訪問，並提供以電子方式執行業務事務的方法，增強了組織的合作伙伴生態系統。但是，如果無法訪問核心業務信息資產，並且信息已經聯合起來，那麼訪問可能是一個大問題。
集成平臺即服務（IPaas）解決方案解決了這個問題。他們的賣點是能夠連接到任何雲和/或本地系統並提供所需的訪問。一個強大的iPaas平臺應該能夠連接到任何雲和/或內部應用程序，通過RESTful應用程序編程接口（也稱為Web API）提供對信息的無縫訪問。使用API作為提供標準、一致和安全的信息訪問的手段，使多渠道應用程序能夠在需要時使用所需的資產。
但是，除非iPaas解決方案提供強大的第三代API平臺功能，否則它將難以滿足上述需求。API必須儘可能接近信息源。如果不是這樣，可能會出現諸如由於網絡延遲而導致響應緩慢以及暴露於其他網絡問題（即計劃外停機）的問題。如果信息分佈在多個雲和內部系統中，那麼API也必須如此。
第三代API平臺
隨著雲的採用和信息在地理上的分佈，獲取訪問變得更加重要。建立VPN以提供連接很快變得不切實際。在許多情況下，它無論如何也不能解決這個問題，因為SaaS供應商不會直接訪問他們的數據庫。相反，API將作為訪問信息的唯一手段提供。目前，第二代API平臺（基本上是通過API管理功能增強的ESB和/或XML設備）缺乏能力，難以滿足雲採用和數字轉換帶來的現代需求。
為了提供雲採用和數字轉換計劃成功所需的功能，需要一個更復雜的第三代API平臺：一個沒有單體架構技術包袱的平臺，因此：
- 可以在任何地方（在任何供應商的雲或內部）實施API，而不會帶來運營噩夢和巨大的成本
- 允許開發人員通過自助式開發人員門戶發現和訂閱API，從而增強開發人員社區的能力
- 首先為端到端API開發生命週期和API提供無縫工具，以便開發人員獲得設計、創建和測試其API所需的工具
- 通過讓信息所有者決定如何以及由誰訪問其資產，使其充分了解和控制其信息。
- 提供強大的安全性，以保護信息資產免受所有主要威脅（即OWASP Top 10）
- 重量輕，無設備/ESB，適用於微服務架構
- 具有彈性（即可以輕鬆縮放）
- 集中管理，不管網關、API的數量和位置如何
- 充分利用統計數據，使運營數據能夠用於獲得業務洞察力，而不僅僅是監控和故障排除。
- 基於訂閱，沒有基於CPU的許可
“Fat”中間件的結尾
當整體被分解成更小的部分並在SaaS或PaaS中重新實現為離散的雲應用程序時，包含在這些整體中的業務邏輯和信息也得到了分發。我們在第一代和第二代集成中間件中看到的越來越大的趨勢（其中包含大量的邏輯）會永遠逆轉，幾乎就像一個破裂的泡沫。
第三代API平臺真正標誌著軟件體系結構和軟件開發的拐點；不再能夠用層描述體系結構。這是一種範式轉換，通過比較不同的體系結構及其內部的信息流動方式，可以更好地理解這種轉換。
API能力模型
以下功能模型確定了第三代API平臺的一些預期功能。雖然並非所有的功能都是平臺的核心，但是相關的功能已經包括在內，因為它們被認為是實現端到端解決方案的關鍵。強烈建議使用這種模型，因為它提供了一個結構化框架來決定可以採用哪些技術來實現每種能力。
API網關起著中心作用，不僅因為它們是運行API的引擎，而且因為它們是信息資產的入口點和應用策略的地方。如果API是通向信息的門戶，那麼API網關當然就是門戶。雖然模型中沒有明確顯示，但有一些基本功能將第三代API網關與第一代和第二代API網關區分開來：
- 輕量：非單體、無設備、無ESB。它們應該是輕量級的，並且非常容易實現（在任何地方）。理想情況下，使用容器。
- 自給自足：應該由他們負責從中央管理單元檢索API、策略甚至系統補丁。
- 面向微服務：應能夠：
- 無狀態。不應為任何事務管理任何狀態。
- 以任何語言和/或選擇的技術實施服務。
- 根據不同的條件，彈性伸縮入口或出口。
- 通過與註冊表（如Consul、Eureka等）集成並動態地智能地確定活動的服務端點和路由來實現API負載均衡器。
- 通過不提供不屬於網關的功能，防止開發人員向網關添加邏輯。
結論
第三代API平臺都是為了提供有助於採用現代體系結構的功能，從而使企業能夠更快、更便宜地創新和交付新產品和產品，從而保持相關性和競爭力。對於像谷歌、LinkedIn或Amazon這樣的數字巨頭來說，這是一個老新聞。然而，對於全球大多數組織來說，雲技術、數字化轉型和以客戶為中心的旅程才剛剛開始。信息/功能聯合化的趨勢不會就此止步；分析師預測，到2020年，連接設備的數量將達到至少210億臺。各類企業將利用物聯網技術與客戶和合作夥伴更緊密地接觸，以完全改變交互方式。ONS的出現以及產品和服務的提供方式。因此，將需要一個第四代平臺，它超越了雲技術，為數十億互聯網設備提供管理和連接能力。
閱讀更多 AirlineDataPlus 的文章
