服務在拆分成微服務之後，最顯著的特徵就是服務的數量增多了。由此導致原本只需要調用一個接口就能完成的任務現在需要調用多個接口了。拿電商的商品詳情界面為例。在商品詳情界面一般會顯示：商品詳情、購買數量、剩餘數量、評價和相關推薦等。在單應用的情況下，只調用一個產品詳情的接口就能夠獲取全部的信息。在拆分成多個微服務之後，服務的數量增多，商品詳情、購買數量、剩餘數量、評價和相關推薦等可能會被拆分成獨立的微服務。這個時候為了能夠完成商品詳情的展示，需要調用5個接口。無形增加了客戶端的複雜度。
調用事例
另外，這樣會導致客戶端與各個服務的耦合。如果後續發生服務的合併或者拆分都需要客戶端的修改。一般情況下，微服務都是多實例的，如果客戶端需要感知這些IP，那麼在服務重啟或者升級的時候，客戶端都需要更新這些連接信息。
為了解決上面的問題，API網關就出現了。API網關只需要提供一個粗粒度的接口就可以了。在查詢商品詳情的時候，客戶端直接向API網關發送查詢商品詳情的接口，由API網關進一步調用其他的微服務並匯聚響應。
API網關
API網關的出現，解耦了客戶端與各個微服務之間耦合關係。作為API網關，需要具備如下的特點：
1.高性能。API網關封裝了對後面微服務的調用，所以API網關不能成為性能瓶頸。
2.易用。微服務是需要註冊到API網關的，多個團隊都需要對其更改，如果修改難度大，會導致開發效率下降。
3.具備服務發現的能力。因為後臺微服務多實例的原因，API網關需要服務發現的能力。
4.具備容錯的能力。一個請求在API網關被拆分成多個請求，API網關需要有能力處理某個或者某幾個請求失敗的情況。比如，某個關鍵調用失敗，這個時候，API網關需要返回錯誤。對於一些次要的服務，在調用失敗的時候，可以選擇服務降級的處理。推薦服務失敗的情況下，可以返回一個默認的推薦列表。還有一些服務的失敗可能需要支持重試。另外，服務的熔斷器也需要實現在API網關。在服務故障時，觸發熔斷，對這個服務的調用，API網關直接返回失敗，避免浪費資源。
5.服務的編排。對於一些請求，是沒有依賴關係的，可以併發處理。對於另外一些請求，存在依賴關係，API網關在調用後臺服務的時候，需要按依賴順序進行調用。
6.協議轉換。一般情況，微服務的協議比較單一，rest+rpc的模式，是不需要協議轉換的。在存在協議不一致的情況下，API網關需要具備協議轉換的能力。但是要注意，儘量讓微服務的協議保持清爽。
現在有很多的開源的API網關。在開發資源資源有些的情況下，可以使用開源軟件。為了學習，也可以進行源碼的閱讀。
閱讀更多 java技術小碼農 的文章
