註冊中心與API網關不是這樣用的！

以前在作顧問和諮詢項目的時候，見到了一種很是經典的關於API網關和註冊中心的錯誤用法。這個案例在個人星球裏已經分享過，沒想到最近又碰到了兩個相似的使用姿式。也許這樣的問題還存在很多團隊的應用中，因此拿出來再分享一下，但願能夠幫助讀者更好的理解註冊中心與API網關的做用，並將它們用對地方！

在微服務架構中，咱們都會使用API網關來做爲暴露服務的惟一出口。這樣能夠將與業務無關的各項控制，集中的在API網關中進行統一管理，從而使得業務服務能夠更加專一於業務領域自己。

而在微服務構建的系統內部，各個服務之間的調度，咱們一般採用註冊中心和客戶端負載均衡的方式來實現服務之間的調用。

因此，大體的結構是這樣子的：

在這樣的架構實踐中，註冊中心和API網關的功能，主要有如下兩點：

1. API網關經過註冊中心發現全部後端服務，歷來實現動態代理
2. 後端服務集羣間，經過註冊中心互相發現對方，而實現直接調用（一般使用Ribbon、Feign這些框架）

下面就來具體說說今天的主角（錯誤案例），先上圖：

注意圖中的兩個地方：

1. 存在兩套網關，一套對內訪問、一套對外訪問
2. 對內訪問的網關實際就是起到了一個代理做用，較以前的圖對比如下，就知道，這個方案中並無利用到服務治理機制去直接讓服務A調用服務B，而是經過網關去作了一次代理。

更震驚的是，在我看到代碼的時候，他們竟然也是用feign來編寫服務間調用的，但在配置請求路徑的時候，是使用在內部API網關上配置的二級域名來實現（好比：http://service-name.didispace.com/api-path，這裏service-name對應不一樣的服務名），而熟悉Spring Cloud的讀者都知道，其實service-name.didispace.com這部分直接用服務名替代就能夠了...是否是瞬間有種脫褲子放x的感受？

若是這樣來使用的話，其實引入註冊中心的用處就很小了，實際上只有給兩個網關提供了集中的後端服務發現功能。若是要實現這種功能，其實註冊中心均可以不須要，每一個服務都直接上報地址給網關就行了，架構會更加簡單。

同時，在這樣的實現方式之下，內部調用都要通過內部網關多一跳的調度過程，除了要多出內部網關的部署資源以外，每一次內部調用的時間開銷實際上都大了。因此這樣的用法是很是不推薦的！

對於API網關的定位，仍是以做爲對外出口的管理爲最佳，內部的代理調用，均交給服務註冊與發現機制 + 客戶端負載均衡就ok了。沒有必要再增長一層代理，不但增長部署成本，同時還會下降的性能。徹底是賠了夫人又折兵的作法，很是不可取！

除非有一種狀況，若是你的業務集羣很大，對前端暴露用一套網關，同時後端服務有幾千幾萬，由不少個不一樣的團隊在維護，那麼在團隊的邊界處設立內部的網關，那仍是合理的。同時這種狀況下，對於註冊中心，按團隊作隔離也是有必要的。由於這樣能夠分而治之，更好的作好接口的訪問控制與管理。可是，若是你自己服務很少，團隊也不大，那就別折騰這麼複雜的架構了，越複雜穩定性就越難保障，這點必定要平衡好。

最後，你們結合本身團隊的註冊中心與API網關應用是否有犯同樣的問題呢？或者若是有其餘問題與疑問，不妨留言交流一下？也能夠加入咱們的技術交流羣一塊兒探討技術問題！

拓展閱讀

• 不三不四的微服務改造：分佈式單體
• SpringCloud專題資料
• 微服務專題資料

歡迎關注個人公衆號：程序猿DD，得到獨家整理的免費學習資源助力你的Java學習之路！另每週贈書不停哦～