微服務已經普及好多年，現在國內的公司基本都會採用微服務架構來搭建最新的系統或者改造已經現成的系統。這裏面，有個很重要的概念，就是網關，最近一段時間針對他，我們結合實戰來剖析該如何應用在系統上。
網關，又稱網間連接器、協議轉換器，一個網絡連接到另一個網絡的“關口”。
聽起來是不是很拗口，簡單理解一下：你有一塊地，你用圍牆圍起來，然後在裏面建造3個豬窩出售豬仔（沒錯，跟某場養豬一樣），一個養白豬，一個養黑豬，一個養黃豬，接着你在圍牆打一個門，裏面所有的豬仔的進出只能通過這個門進出，這個門就叫做網關，裏面的豬窩就是各個原子服務，專門提供不同的豬仔。
其中，原子服務爲了安全，一般不對外開放，好比你豬仔吃什麼，喝什麼，別人不用管，只需要知道有豬仔就行，所有買賣豬仔的行爲，只能通過這個門。如圖一所示
編輯搜圖
圖一：買豬仔的圖
這裏，我們可以看出，網關有幾個作用
1、重定向：要什麼顏色的豬仔，告訴我，我給你就行
2、鑑權：哪些人可以買，我說了算
3、日誌：今天誰來買，買了多少豬仔，買什麼顏色的豬仔，一清二楚
4、限流：每次只能限定多少人來買，超過的話，就等等吧，畢竟太忙豬仔媽媽生產不過來。
目前，普通的企業級開發用基本就會用到這些，高併發的情況很多時候並不常見，如果出現，此時做法就是：增加豬窩的數量，增加大門的數量，加上Nginx，一般都是足夠的。
接下來，我們來聊聊網關中的聚合服務。
現在網上的網關很少介紹到這方面，微服務在企業級開發落地中，有個很比較噁心的問題，因爲企業級併發量不大，但是業務複雜，把各個服務進行切分後，發現經常合起來展示數據。
有幾種做法參考一下
1、前端多次請求：
做法：前端訪問網關，然後根據需要的數據進行多次組合，多次數據轉換
問題：當前端與網關並不是在一個網段，此時會增加請求量，從而增加服務器的壓力，同時會導致數據難以維護，運維層面會增加，不建議這麼做。
2、搭建聚合原子服務：
做法：如圖二，搭建聚合服務，請求通過網關後，直接定位到聚合服務上，由聚合服務來請求後端的服務
問題：解決數據維護的問題，但是卻多了一個網絡請求，就是從網關-->聚合服務-->原子服務，俗話說：做多錯多。要想個法子來解決
編輯搜圖
圖二聚合服務
3、聚合網關服務：
做法：考慮到現實很多公司並沒有那麼大的併發量，沒有那麼多的資源等等，把聚合服務移動到網關上面來
問題：解決了前端多個請求問題，解決多了一個網絡請求的問題，但是這樣做會把網關變得很重，但是針對很多小公司，卻很實用。
以上三種做法，我其實最喜歡第二種，但是架構設計過程中，因地制宜纔是最重要，根據業務量不斷髮展，不斷優化，不斷更新架構設計，目前我們使用的是第二種，因爲量能關係。
但是在這系列文章中，我們將會介紹第二種方式的做法，採用的技術框架版本如下如下，應該都是最新版的
springboot：2.2.5.RELEASE
springcloud：Hoxton.SR1
網關：zuul
考慮到現在很多公司用zuul的比較多，就用這個來做，spring gateway目前用於生產的比較少，不坑大家了，基本上體量沒那麼大的，正常是夠用的。
從第二章開始我們將會一步一步搭建這個網關服務。