前言
假設你正在開發一個電商網站，那么這里會涉及到很多后端的微服務，比如會員、商品、推薦服務等等，
那么這里就會遇到一個問題，APP/Browser怎么去訪問這些后端的服務? 如果業務比較簡單的話，可以給每個業務都分配一個獨立的域名(https://service.api.company.com)，但這種方式會有幾個問題:
- 每個業務都會需要鑒權、限流、權限校驗等邏輯，如果每個業務都各自為戰，自己造輪子實作一遍，會很蛋疼，完全可以抽出來，放到一個統一的地方去做，
- 如果業務量比較簡單的話，這種方式前期不會有什么問題，但隨著業務越來越復雜，比如淘寶、亞馬遜打開一個頁面可能會涉及到數百個微服務協同作業，如果每一個微服務都分配一個域名的話，一方面客戶端代碼會很難維護，涉及到數百個域名，另一方面是連接數的瓶頸，想象一下你打開一個APP，通過抓包發現涉及到了數百個遠程呼叫，這在移動端下會顯得非常低效，
- 每上線一個新的服務，都需要運維參與，申請域名、配置Nginx等，當上線、下線服務器時，同樣也需要運維參與，另外采用域名這種方式，對于環境的隔離也不太友好，呼叫者需要自己根據域名自己進行判斷，
- 另外還有一個問題，后端每個微服務可能是由不同語言撰寫的、采用了不同的協議，比如HTTP、Dubbo、GRPC等，但是你不可能要求客戶端去適配這么多種協議，這是一項非常有挑戰的作業，專案會變的非常復雜且很難維護，
- 后期如果需要對微服務進行重構的話，也會變的非常麻煩，需要客戶端配合你一起進行改造，比如商品服務，隨著業務變的越來越復雜，后期需要進行拆分成多個微服務，這個時候對外提供的服務也需要拆分成多個，同時需要客戶端配合你進行改造，非常蛋疼，
API Gateway
更好的方式是采用API網關，實作一個API網關接管所有的入口流量，類似Nginx的作用，將所有用戶的請求轉發給后端的服務器，但網關做的不僅僅只是簡單的轉發，也會針對流量做一些擴展，比如鑒權、限流、權限、熔斷、協議轉換、錯誤碼統一、快取、日志、監控、告警等，這樣將通用的邏輯抽出來，由網關統一去做，業務方也能夠更專注于業務邏輯，提升迭代的效率，
通過引入API網關，客戶端只需要與API網關互動，而不用與各個業務方的介面分別通訊，但多引入一個組件就多引入了一個潛在的故障點，因此要實作一個高性能、穩定的網關，也會涉及到很多點，
網關接入
業務方如何接入網關?一般來說有幾種方式，
- 第一種采用插件掃描業務方的API，比如Spring MVC的注解，并結合Swagger的注解，從而實作引數校驗、檔案&&SDK生成等功能，掃描完成之后，需要上報到網關的存盤服務，
- 手動錄入，比如介面的路徑、請求引數、回應引數、呼叫方式等資訊，但這種方式相對來說會麻煩一些，如果引數過多的話，前期錄入會很費時費力，
- 組態檔匯入，比如Eolinker的網關，可以直接匯入多種格式的檔案，支持包括swagger和yapi在內的各種軟體，我現在就在用：www.eolinker.com，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/288788.html
標籤：其他