到目前為止已經實現了一個基於OAuth2的認證和授權的流程（如下圖），訂單還是一個單一的節點，還沒有進入到微服務的環境下。
實際場景下，類似訂單服務的服務，可能有幾十個，每個服務是一個集群，有幾十個節點，如下圖，
在這種場景下，當前微服務架構下的問題：
問題1：安全處理和業務邏輯耦合，增加了復雜性和變更成本
在之前的架構中，訂單服務 ，同時又是 資源服務器（如下圖），訂單服務需要知道認證服務器的地址，去校驗令牌，通過token轉換為用戶信息。也就是安全相關的代碼，和業務的代碼耦合在了一塊。雖然可以把這些資源服務器相關代碼提成一個jar包，把跟認證相關的代碼做成配置，然后每個服務依賴這個jar包，但本質上是沒變的，安全相關的代碼還是和業務代碼在一塊。在微服務環境下，解耦是價值最大的，其他的都要為解耦讓路。這樣耦合在一塊，如果你修改了安全相關的代碼，那么依賴這個安全的jar包的服務，都要升級這個jar包，在業務代碼沒變的情況下，因為安全而要修改配置、重新部署，這如果是在一線互聯網企業，有幾百、上千、上萬的微服務環境下，影響面非常大，這樣是不能接受的。
問題2：隨着業務節點增加，認證服務器壓力增大
隨着業務場景的變化，之前的10個微服務，可能拆分成20個服務、50個微服務，某些場景下，比如商城有大促，某些服務要做擴縮容，關鍵的業務節點要部署加倍，這些個微服務都要到認證服務器驗token，可能之前認證服務器能撐住原來那么多服務，但是隨着服務節點的增多，超過了認證服務器的最大連接數，把認證服務器的連接都占滿了，導致認證服務器不可用，所有依賴認證服務器的服務都不可用，導致這些服務都崩掉了，這也是很大的風險。
問題3：多個微服務同時暴露，增加了外部訪問的復雜性
客戶端直接和各個服務打交道，增加了客戶端訪問的復雜性
添加網關：
上邊說的三個問題，都可以在添加網關后解決：
1，解決安全處理和業務邏輯耦合：獲取令牌、校驗令牌等，所有跟安全相關的邏輯，都放在了網關上處理，一旦請求過了，訂單服務里只有頂單相關的業務邏輯。
2，解決隨着業務節點增加，認證服務器壓力增大：頂單等服務，跟認證服務器沒有任何交互，不管各個微服務怎么擴，認證服務器是不受影響的。雖然網管也會擴，但是網關擴縮容的頻率和幅度，都遠不及各個服務。微服務可能是10到20，20到40的擴容，但是網關可能是2個變4個，4個變8個。網關的擴容幅度和頻率，遠遠小於微服務，再怎么擴，網關的數量是遠遠小於微服務的。
3，解決外部訪問的復雜性：所有的請求都只和網關打交道，客戶端應用只知道一個網關的地址，由網關轉發到各個微服務。
搭建Zuul網關
新建項目：nb-server-gateway
pom加入zuul依賴:
<!-- 網飛的zuul網關 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>
網關端口：9070
yml網關配置
這樣配置了之后，訪問 http://localhost:9070/token/aaa/bbb ，會被轉發到 http://localhost:9090/aaa/bbb
訪問 http://localhost:9070/token/ccc/ddd ，會被轉發到 http://localhost:9060/ccc/ddd
啟動類加上 @EnableZuulProxy 注解
分別啟動三個服務：
現在，客戶端訪問網關， http://localhost:9070/token/oauth/token ,會被轉發到認證服務器（端口9090）的 http://localhost:9090/oauth/token ,來獲取令牌，postman實驗：
可以成功獲取token，說明zuul網關已經幫你把請求轉發到了認證服務器9090 。
拿token 訪問網關 創建頂單：http://localhost:9070/order/orders
創建成功，說明網關已經將請求轉發到了頂單服務。
網關已經初步搭建好了，但是只解決了問題3，客戶端訪問的復雜性，下面解決兩外兩個問題。
代碼github:https://github.com/lhy1234/springcloud-security/tree/chapt-4-8-gateway01
歡迎關注個人公眾號一起交流學習：
