目錄
- 前言
- 1. 外部API的設計難題
- 1.1 FTGO應用程式的服務及客戶端
- 1.2 FTGO移動客戶端API的設計難題
- 1.3 其他型別客戶端API的設計難題與特點
- 2. API Gateway模式
- 2.1 API Gateway實作的功能
- 2.1.1 請求路由
- 2.1.2 API組合
- 2.1.3 協議轉換
- 2.1.4 能夠為每一個客戶端提供它們專用的API
- 2.1.5 實作邊緣功能
- 2.2 API Gateway的架構
- 2.3 API Gateway的所有者模式
- 2.4 API Gateway的后端前置模式
- 2.5 API Gateway模式的好處與弊端
- 2.6 API Gateway的設計難題
- 2.1 API Gateway實作的功能
- 3. 實作一個API Gateway
- 3.1 實作API Gateway的兩種方法
- 3.2 使用現成的API Gateway產品或服務
- 3.3 使用Netflix Zuul開發API Gateway
- 3.4 使用Spring Cloud Gateway開發API Gateway
- 3.5 Spring Cloud Gateway的關鍵部分
- 3.5.1 OrderConfiguration類
- 3.5.2 OrderHandlers類
- 3.5.3 OrderService類
- 3.5.4 ApiGatewayApplication類
- 3.6 使用GraphQL實作API Gateway
- 3.7 基于GraphQL的FTGO API Gateway的設計
- 4. 本章小結
- 最后
前言
不同客戶端通常需要不同資料；不同客戶端通過不同型別的網路訪問服務，擁有單一、適合所有客戶端的API通常沒有意義；
這是一本關于微服務架構設計方面的書，這是本人閱讀的學習筆記，下面對一些符號做些說明：
（）為補充，一般是書本里的內容；
[]符號為筆者筆注；
1. 外部API的設計難題
1.1 FTGO應用程式的服務及客戶端
- 使用服務API的客戶端一共有四種：
- Web應用程式；
- 在瀏覽器中運行的JavaScript應用程式；
- 移動應用程式；
- 由第三方開發人員撰寫的應用程式；
- 其弊端有：
- 細顆粒度服務API要求客戶端發出多個請求以檢索所需的資料，這樣做效率低，并且可能導致糟糕的用戶體驗；
- 由于客戶端了解每項服務以及服務的API從而導致封裝不足（緊耦合），因此今后很難更改服務的架構和API；
- 服務可能適用對客戶端而言不便或不能使用的行程間通信機制，尤其是防火墻外的客戶端；
1.2 FTGO移動客戶端API的設計難題
上述設計方案難處在于：
- 多次客戶端請求導致用戶體驗不佳 [考慮到移動網路的時延與多次請求的耗電量]；
- 缺乏封裝導致前端開發做出的代碼修改影響后端 [有時會破壞現有客戶端來修改API，導致舊版本不兼容]；
- 服務可能選用對客戶端不友好的行程間通信機制 [有些協議無法通過防火墻]；
1.3 其他型別客戶端API的設計難題與特點
- Web應用程式的API設計特點：
- 有較高的網路帶寬和較低的延遲；
- 可以使用非Web友好的協議訪問服務；
- 可以輕松更新Web應用程式；
- 基于瀏覽器JavaScript應用程式的API設計特點與難題：
- 服務API變化時，基于瀏覽器JavaScript應用程式很容易更新；
- 與移動端有相同的網路延遲問題；
- 基于瀏覽器的用戶界面，需要組合更多服務；
- 為第三方應用程式設計API：
- 組合API導致低效率；
- 必須花長時間維護舊版本；
2. API Gateway模式
使用API Gateway模式可以解決上述問題；
- API Gateway模式：實作一個服務，該服務是外部API客戶端進入基于微服務應用程式的入口點；
2.1 API Gateway實作的功能
2.1.1 請求路由
- 收到請求時，API Gateway會查詢路由映射，該映射指定將請求路由到哪個服務；
2.1.2 API組合
- 其提供粗顆粒度API，使移動客戶端能夠通過單個請求檢索所需的資料；
2.1.3 協議轉換
- 在需要時，某些API的操作實作在RESTful外部API和基于內部的gRPC API之間進行轉換；
2.1.4 能夠為每一個客戶端提供它們專用的API
- 可以為Android和iPhone移動應用程式提供不同的API，還將為第三方開發人員實作公共API；
2.1.5 實作邊緣功能
- 可以在三個不同位置實作邊緣功能：
- 在后端服務：相較于邊緣上進行身份驗證不安全；
- 在API Gateway上游的邊緣服務：好處是可以分隔問題、集中關鍵邊緣功能的職責；弊端是額外的請求跳躍增加網路延遲狀況、增加程式復雜性；
- 在API Gateway中實作邊緣服務：可以減少網路跳躍、改善延遲狀況、降低復雜性；提高安全性，詳情見【第11章 API Gateway與服務協作實作安全性】；
- 邊緣功能：
- 身份驗證：驗證發出請求的客戶端身份；
- 訪問授權：驗證客戶端是否有權執行該特定操作；
- 速率限制：限制特定客戶或所有客戶端每秒的請求數；
- 快取：快取回應以減少對服務的請求數；
- 指標收集：收集有關API使用情況的指標，以進行計費分析；
- 請求日志：記錄請求歷史；
2.2 API Gateway的架構
圖解：
- 兩層架構：
- API層：由一個或多個獨立的API模塊組成；
- 公共層：實作共享功能、邊緣功能，如身份驗證；
- 三個API模塊：
- 移動設備API：為FTGO移動客戶端實作API；
- 瀏覽器API：為瀏覽器中運行的JavaScript應用程式實作API；
- 公共API：為第三方開發人員實作API；
- 使用兩種方式實作每個API操作：
- 直接映射到單個服務API操作；
- 使用組合實作其他復雜API操作；
2.3 API Gateway的所有者模式
- 客戶端團隊擁有與他們有關的API模塊并公開API；
- API Gateway團隊負責開發公共模塊和API Gateway的運維；
- API Gateway的部署流水線必須完全自動化；否則，客戶端團隊不得不等待API Gateway團隊手工部署一個新的版本；
- 問題：多個團隊為相同的代碼庫做貢獻，職責模糊；
- 解決辦法：使用后端前置模式
2.4 API Gateway的后端前置模式
- 后端前置模式：為每種型別的客戶端實作單獨的API Gateway；
- 理想情況下，所有API Gateway都使用相同的技術堆疊；
- 公共層的功能由API Gateway團隊實作；
- 好處：明確界定職責、API彼此隔離提高可靠性、提高可觀測性、每個API獨立可擴展、減少啟動時間；
2.5 API Gateway模式的好處與弊端
好處：
- 封裝應用程式的內部；
- 減少客戶端與應用程式之間的往返次數；
- 簡化客戶端代碼；
弊端：
- 開發人員必須更新API Gateway才能對外公開服務的API；
- 更新API Gateway的程序盡可能輕量化；
2.6 API Gateway的設計難題
- 性能和可擴展性：影響性能和可擴展性的關鍵設計決策是API Gateway使用同步還是異步I/O；
- 同步I/O：每個網路連接由專用執行緒處理；限制是作業系統執行緒是重量級的，API Gateway可擁有的執行緒數量和并發連接數量存在上限；
- 異步（非阻塞）I/O：單個事件回圈執行緒將I/O請求分派給事件處理程式；具有可擴展性；弊端是比基于異步回呼的編程模型要復雜得多，代碼更難撰寫、理解和除錯；使用非阻塞I/O是否具有意義的整體優勢取決于API Gateway的請求處理邏輯特性；
- 使用回應式編程抽象撰寫可維護的代碼：
- 當服務之間沒有依賴關系時，應該盡可能同時呼叫服務，以縮短回應時間；
- 使用傳統的異步回呼方法撰寫API組合代碼會導致“回呼地獄”，可以以宣告式風格撰寫API組合代碼；
- 處理區域故障：
- 可以在負載均衡器后面運行多個API Gateway實體實作可靠性；
- 對于失敗服務未完成的請求可以使用斷路器模式提高可靠性，詳情見【第3章 斷路器模式】；
- 成為應用程式架構中的好公民：
- 與其他服務一樣API Gateway必須實作整個架構中選擇的各種模式；
- 如：服務發現模式【第三章】；可觀測性模式【第十一章】；
3. 實作一個API Gateway
3.1 實作API Gateway的兩種方法
- 使用現成的API Gateway產品或服務：幾乎不需要代碼開發，但靈活性最低；如：現成的API Gateway通常不支持API組合；
- 使用API Gateway框架或Web框架作為起點，開發屬于自己的API Gateway：最靈活的方法，但需要進行一些開發作業；
3.2 使用現成的API Gateway產品或服務
- AWS API Gateway
- AWS Application Load Balancer
- 使用產品化的API Gateway；
3.3 使用Netflix Zuul開發API Gateway
- 開發API Gateway需要解決兩個問題：
- 實作定義路由規則的機制以簡化復雜的代碼；
- 正確實作HTTP代理行為，包括如何處理HTTP標頭；
- Zuul使用過濾器的概念，可重用請求攔截器；
- Zuul通過一系列適用的過濾器來處理HTTP請求，然后轉換請求，呼叫后端服務，并在回應發送回客戶端之前轉換回應；
- 限制：它只能實作基于路徑的路由，無法實作【第7章】描述的查詢架構；
3.4 使用Spring Cloud Gateway開發API Gateway
- Spring Cloud Gateway是一個基于多個框架構建的API Gateway框架，屬于回應式Web框架，構建在Project Reactor之上；
- Project Reactor是一個基于NIO的JVM回應式框架；
- 其提供一種簡單而全面的方法執行以下操作：
- 將請求路由到后端；
- 實作執行API組合的請求處理程式；
- 處理邊緣功能，例如身份驗證；
3.5 Spring Cloud Gateway的關鍵部分
圖解：
- ApiGatewayMain包：定義API Gateway的主程式；
- 一個或多個API包：一個API包實作一組API端點；如，Orders包實作與Order相關的API端點；
- 代理程式包：由API程式包用于呼叫服務的代理類組成；
- OrderConfiguration類：定義了一些Spring beans，它們負責路由與Order相關的請求；
- orderProxyRoutes @Bean：定義了將API操作映射到后端服務URL的規則；路由規則可以匹配HTTP方法、標頭和路徑的某些組合；
- orderHandlers @Bean：定義了覆寫orderProxyRoutes的規則；這些規則描述了將API操作映射到處理程式的具體方法；
- orderHandlers類：實作各種請求處理程式方法，此方法使用API組合來獲取訂單詳細資訊；處理程式的方法使用遠程代理類（如OrderService）呼叫后端服務；
3.5.1 OrderConfiguration類
-
OrderConfiguration類是一個Spring @Configuration類，它定義了實作 /Orders端點的Spring @Bean；
-
OrderDestinations是一個Spring @ConfigurationProperties類，它支持后端服務URL的外部配置；
3.5.2 OrderHandlers類
- OrderHandlers類定義了實作自定義行為的請求處理程式方法，包括API組合；
3.5.3 OrderService類
- OrderService類是Order Service的遠程代理；
3.5.4 ApiGatewayApplication類
- ApiGatewayApplication類實作了API Gateway的main()方法，它是Spring Boot main類；
- @EnableGateway注解匯入Spring Cloud Gateway框架的Spring配置；
3.6 使用GraphQL實作API Gateway
GraphQL是一種基于影像的API框架，其旨在支持高效的資料提取；
圖解：
- 基于圖形的模式定義了一組節點（型別），它們具有屬性（欄位）和其他節點的關系；
3.7 基于GraphQL的FTGO API Gateway的設計
其關鍵部分：
- GraphQL模式：定義服務器端資料模型及其支持的查詢；
- 決議器函式：決議函式將模式的元素映射到各種后端服務；
- 代理類：代理類呼叫FTGO應用程式的服務；
4. 本章小結
- 應用程式的外部客戶端通常利用API Gateway訪問應用程式的服務，API Gateway為每個客戶端提供自定義API，它負責請求路由、API組合、協議轉換以及邊緣功能（如身份驗證）的實作；
- 應用程式可以具有單個API Gateway，也可以使用后端前置模式，該模式為每種型別的客戶端定義API Gateway，后端前置模式的主要優點是它為客戶端團隊提供了更大的自主權，因為他們可以開發、部署和運維自己的API Gateway；
- 可以使用許多種技術來實作API Gateway，包括現成的API Gateway產品，或者，也可以使用框架開發自己的API Gateway；
- Spring Cloud Gateway是一個易于使用的良好框架，用于開發API Gateway，它使用任何屬性（包括方法和路徑）路由請求，Spring Cloud Gateway可以將請求直接路由到后端服務或自定義處理程式方法，它采用可擴展、回應式的Spring Framework 5 和Project Reactor框架構建，可以使用，例如，Project Reactor的Mono抽象，以回應式風格撰寫自定義請求處理程式；
- GraphQL是一個提供基于圖形的查詢語言框架，是開發API Gateway的另一個很好的基礎，你可以撰寫一個面向圖形的模式來描述服務端資料模型及其支持的查詢，然后，通過撰寫檢索資料的決議器，將該模式映射到你的服務，基于GraphQL的客戶端對模式執行查詢，該模式準確指定服務器應回傳的資料，因此基于GraphQL的API Gateway可以支持不同的客戶端；
最后
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/299898.html
標籤：其他
上一篇：快應用技術架構及業務分析
下一篇：快應用技術架構及業務分析