微服務網關——需求篇

微服務網關——需求篇

概念

API Gateway（API GW / API 網關），顧名思義，是企業 軟件系統在系統邊界上提供給外部訪問內部接口服務的統一入口。網關並不是微服務所特有的，實際上網關在微服務之前就已經存在很久了，例如銀行、證券等領域常見的前置機系統，它實際就是一個網關。

API 網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API 網關封裝了系統內部架構，爲每個客戶端提供一個定製的 API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理、流量控制、日誌、重試、熔斷等。

在微服務場景下，網關的功能基本沒有變化，即網關是微服務的入口，處理所有的非業務功能。

網關功能性需求

路由

對於微服務架構來說，一般都是由多個微服務共同對外提供服務，每個服務對外提供部分接口，這些接口提供的功能，共同組成完整的可用的系統功能。

當用戶發送一個請求後，對於傳統的單體架構來說，因爲只有一個服務來對外提供服務（負載均衡見下文），所以根據請求的地址即可定位到對應的服務。但是對於微服務來說，因爲有多個服務對外提供服務，所以系統需要有能力分辨出對應的請求應該委託給哪個具體的服務來處理，這就是路由的功能。

網關作爲系統的入口，需要提供路由功能。同時考慮到，網關是整個系統的入口，一旦網關停止服務，則整個系統都無法對外提供服務。所以網關不能夠頻繁的啓停，故路由模塊需要能夠動態的配置規則。

負載均衡

一般情況下，爲了可用性，每個服務都需要做集羣部署，即每個服務至少需要部署兩個實例對外提供服務，避免單個實例時，由於服務本身的問題，導致該實例無法對外提供服務。

當一個服務進行了集羣部署後，請求來訪問時，需要確定由哪個服務來處理該請求，即負載均衡。

注意，此處「確定處理請求的服務」的邏輯和上面的路由邏輯不是一個概念。路由是根據請求來匹配到目標服務，此處是從多個不同功能的服務中確定服務；而負載均衡是在其之後，當匹配了目標服務後，由於有多個目標實例，需要從中選擇一個來處理，此處是從多個相同功能的服務中選擇一個來處理該請求。

對於網關來說，需要提供負載均衡的功能，至於是否需要支持動態負載均衡算法的調整，考慮到負載均衡算法確定後，一般不會變化，所以不需要動態調整負載均衡算法的功能。至於是否需要支持多種負載均衡算法，可以視具體情況而定。

聚合服務

上面的「路由」處理的是一個請求直接由對應服務來處理的場景。

前面說了，微服務中每個服務提供的是系統的一部分功能，所以可能一個完整的功能需要由多個微服務來提供服務，這可能就需要客戶端爲了完成某個功能發送多次請求。這會導致幾個問題：

所以，網關需要提供「聚合服務」的功能，即客戶端只需要發送一個請求到網關，網關針對該請求，向多個目標微服務發送請求，將請求結果整合後返回給客戶端。

服務聚合有如下優缺點：

優點：

缺點：

具體哪些接口需要進行聚合，哪些直接進行委託，需要視具體接口而定。故網關，需要支持聚合服務的可編碼功能。同時爲了網關的穩定性，最好能支持聚合服務的動態發佈。

認證授權

網關作爲系統的入口，需要做好安全防護，否則後端的所有服務都會存在安全隱患。除了基本的網絡安全防護外（算法簽名，SSL 加密等），網關需要處理整個系統的認證（Authentication）和授權（Authorization）。

權限是資源的集合，在微服務裏資源可以認爲就是對外提供的接口服務。具體的權限配置上，可以將權限分爲：操作權限和數據權限。

操作權限：用戶在系統中的任何動作、交互都是操作權限，如增刪改查等。

數據權限：一般系統，都有數據私密性的要求，即哪些人可以看到哪些數據，不可以看到哪些數據。例如：不同租戶下的用戶只能看到對應租戶下的數據；相同租戶下的不同角色看到的數據也有差異，比如：普通角色只能看自己的薪資信息，會計角色可以看到所有人的薪資信息。

如果對數據權限細化的話，還可以細分出一個「頁面權限」：所有系統都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱爲頁面權限。

另外，操作權限還可以細化一個「菜單權限」：即哪些用戶可以看到 / 操作哪些菜單。

對於網關來說，需要提供較完善的「認證」和「授權」功能，以保障整個系統的安全。

過載保護

系統在設計之初就會有一個預估容量，超過系統所能承受的容量閾值稱爲過載。長時間超過系統能承受的容量閾值，系統可能會被壓垮，最終導致整個服務不可用。

爲了避免這類情況的發生，需要對系統進行過載保護。一般方式有：流量控制、熔斷和服務升降級。

流量控制

流量控制的目的是通過對「併發訪問請求數量進行控制」或者「一個時間窗口內的的請求數量進行控制」來保護系統，一旦達到控制速率則可以拒絕服務、排隊或等待。

流量控制可以針對整個系統，也可以針對單個接口來進行控制。

網關需要控制單位時間內接口允許被調用次數，以保護後端服務，實現用戶分級。 可以根據接口的重要程度來配置不同流控，從而保障重要業務的穩定運行；支持用戶、應用和例外流控，可以根據用戶的重要性來配置不同流控，從而可以保證大用戶的權益； 流控粒度：分鐘、小時、天。

熔斷

當一個服務對外無響應或者響應時間很長時，此種情況下可能會導致請求的大量積壓，繼而影響整個系統對外提供服務。熔斷可以避免此類問題的發生。

當一個服務對外無響應或者響應時間過長時，對該服務進行熔斷操作。即對該服務的請求立即返回特定的結果，避免請求積壓。等一段時間後，恢復服務對外提供服務。如果服務還是無法對外服務，則再次觸發熔斷。

服務升降級

上面的流量控制和熔斷都是相對比較「公平」的方法，主要是爲了保證系統的可用性。在系統過載的情況下，無差別的對待所有的服務 / 接口。

不過對於一個系統來說，有些服務是核心服務而有些服務是非核心服務，對於核心服務來說，即使在系統過載的情況下也不能拒絕對外服務，否則這個系統實際就失去了它原有的價值。這個時候就需要非核心業務爲核心業務讓路，即在系統過載的時候，非核心服務讓出系統資源，即服務降級，保障核心服務能穩定的對外提供服務。待系統負載正常後，再恢復非核心服務。

緩存

對於經常調用的接口，且結果基本不會出現變化的接口，可以對這些接口進行緩存。緩存後的接口，由於請求不會到達目標服務端，可以給系統帶來如下好處：

同時也帶來了如下劣勢：

在後端併發和處理能力不夠的情況下，將緩存前置來提供更好的服務，而且是從網關層統一處理，可簡化後端服務處理的複雜度。

服務重試

對於某些服務，可能會由於某些原因導致服務短時間內沒有響應，例如網路波動。當出現這些情況的時候，默認情況下客戶端會直接收到錯誤消息。對於某些服務，可以通過重試的方式來降低 / 避免此類問題。即如果某次請求，對應的服務在規定時間內，沒有得到響應，則自動再嘗試一次 / n 次，如果成功則返回結果。如果多次嘗試後，依然失敗，則再返回錯誤消息。

服務重試在某些情況下能提高系統的可用性。

日誌

日誌記錄是對整個微服務的要求，需要記錄請求訪問日誌，便於後期對請求訪問的統計分析、問題定位。

管理

對於上面的功能，爲了方便操作，最好能提高管理界面。例如：

網關的非功能性需求

安全性

系統把服務暴露給外部使用時，首先要確保服務使用的安全，防止外部的惡意訪問對業務的影響，特別是涉及交易方面的服務，更是要全面考慮安全性。爲確保安全，需要考慮在通訊鏈路的建立、通訊數據的加密、數據的完整性、不可抵賴性等方面的安全。

性能

網關作爲整個系統的入口，所有的請求都會先經過網關，或由網關直接處理、或從緩存獲取數據、或轉發給後面的微服務進行具體的業務處理、或轉換爲多個請求由服務處理後再整合結果。

可以看出，網關是整個系統中訪問壓力最大的組件，如果設計不當，無法保證高性能，則很容易成爲整個系統的瓶頸。同時，爲了保障系統容量，則可能需要投入大量的硬件設備，通過橫向擴容的方式來提高網關層的容量。這無疑增加了系統的投入成本。

所以保障網關的高性能，是保證整個系統高性能的前提條件。

高可用

網關作爲整個系統的入口，一旦發生問題，將造成這個系統的不可用。所以必須保障網關的高可用，可用性需要達到 4 個 9 以上，即 99.99% 以上。儘量達到 5 個 9，即 99.999%。

也就是說需要保障網關全年故障時間在 50 分鐘以內，最好能達到 5 分鐘以內，保證網關可用性不會影響整個系統的可用性。

擴展性

前面說到，網關需要提供例如日誌、安全、負載均衡策略、鑑權等功能。對於這些功能，需要能方便的擴展，以適應業務的不斷髮展。同時由於這些功能會隨着業務邏輯或規模的變化，不斷進行強化與調整。以及系統的可用性考慮，建議網關層能提供熱部署機制，使得可以靈活地進行這些調整和變化，而不用頻繁對網關進行改動，確保網關的穩定性。

伸縮性

上面說了，網關是整個系統的入口，爲了保證系統能快速的伸縮，網關必須要提供方便的伸縮能力，這就需要保證網關是無狀態的。

服務監控

能夠對服務接口進行監控，包括：調用量、調用方式、響應時間、錯誤率等。能夠清楚的瞭解服務接口的運行狀況和用戶的行爲習慣。

支持自定義報警規則，來針對異常情況進行報警，降低故障處理時間。提供可訂閱的數據分析報表和智能分析。

需求優先級

網關作爲整個系統的入口，核心功能包括：

同時需要保障：

對於聚合服務，緩存，服務重試，擴展性（熱加載）功能，管理等需求，是優化性需求，提高網關的易用性，可以延後實現。

對於日誌、服務監控功能作爲網關的基礎支撐類需求，可以通過開源項目快速實現，後續迭代的方式進行改進。

總結

本文梳理了微服務網關的需求，下一篇將對微服務網關進行設計。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://www.toutiao.com/i6901239029547909643/?group_id=6901239029547909643

猜你喜歡