安全相關的代碼和業務邏輯相關的代碼實際上是在一個應用里面的，在這個應用里面，我們需要去，這個應用本身的處理邏輯里面需要去處理令牌和用戶信息之間的轉換。
然后我們需要去知道認證服務器的地址，這些都是耦合。
雖然我們把server.resource這里面的代碼提煉成一個公用的jar包
把這些clientId和ClientSecret這些做成配置。然后讓各個應用去依賴這個jar包，寫不同的配置來實現這樣的效果。但實際上本質是沒變的。它的安全處理邏輯和你的業務邏輯仍然是在一個應用里面的。在一個應用里面，這就是一種耦合。我們之前說過在微服務環境下解耦是價值最大的一件事。
那么什么叫做安全處理和業務邏輯耦合呢？？？
舉個例子，以為大家剛開始接觸這個東西，用的是一個比較簡單的獲取令牌的方式，驗令牌的時候也需要驗證服務器，隨着我們的規模擴大，我們需要一種新的認證方式。，或者說比如我的令牌是存在數據庫的 可能以后會改成jwt或者其他的。或者我一開始下用的jwt，后來jwt有安全漏洞需要升級，不管是前面說的那種情況，只要你的安全相關的邏輯發生了變化，你就要升級你提煉出去的那個jar包，你要告訴所有的微服務的團隊，你們要升級你們的安全的扎包，這就意味着這些開發微服務的團隊在自己業務沒有變化的情況下，他要因為你安全處理這方面的邏輯變化，而重新部署，可能還要改相應的配置或者代碼等等一些東西。這個在一個比較復雜的微服務環境里面。一些互聯網企業可能有幾百上千甚至上萬的微服務是不可接受的。因為影響面太大了。我們說安全處理和業務邏輯是耦合的，一旦有變化，影響面會非常大。
二是隨着業務節點的增加認證服務的壓力變大。我們這里驗證token實際上是有一個http的請求連接過去的。當然我們可以通過連接池啊之類的技術來限制這個鏈接的數量，來控制服務器的壓力。但是你的微服務本身它是不斷的變化的。比如他原來是10個服務，可能過兩天，隨着業務的發展，10個服務拆成10個服務，或者拆成50個服務。某些服務在某些場景下它也會做去做擴充，比如說明天要大促，那你所有的節點，尤其是關鍵業務的節點。要部署的節點的數量要加倍。在這樣一個場景下的，你的服務器的數量，一直在增長增長。在某些情況下還會快速增長，比如說某些大促的活動。這時候可能你原來能撐住的服務器的壓力，因為你的微服務去增長去擴充容，結果他們連過來的連接數，超出了你認證服務器所能承受的連接數，把你認證服務器壓死了。把你認證服務器鏈接都占滿了。導致你的認證服務器不可用，然后所有需要依賴認證服務器的做的這些事情，全都不能做了整個都崩掉了。這也是一個在微服務環境下，一個很大的風險。
最后一個就是 多個服務同時暴露，增加了外部訪問的復雜性，
從圖上可以看到我們的客戶端應用和我們的服務是直接打交道的。如果我這是幾十個服務，每個服務都有自己的ip，或者說有自己的域名，那么對於我的客戶端應用來說，我要訪問訪問訂單服務，要訪問這個服務、那個服務，對於我的客戶端來說，我要記很多的東西。這就是增加了外部訪問的復雜性。
網關
由網關來解決上面的這些問題。所有安全處理的邏輯全都放在網關上面來了。在訂單服務里面不再有和安全處理相關的邏輯，它里面就只有業務邏輯。這個令牌怎么拿到，然后這個令牌是不是有效，全都在網關這里來做判斷，一旦過了在訂單服務這里只執行訂單相關的業務邏輯，
網管的擴縮容比微服務的頻率要小的多。
對個微服務現在只要 記住一個網關的地址，所有的請求和交互都是和網關交互，網關知道這些微服務在哪。
應用只知道客戶端應用，
網關的搭建
原來都拷貝進來。
先把oauth2的依賴去掉。
先把網關搭建起來，讓客戶端應用只訪問網關就可以訪問到認證服務器和微服務。注意的一點，認證服務器也是要放在網關后面的。
添加網關zuul的引用
建啟動類
加上@EnbaleZuulProxy它就是一個網關了。
那么代碼就寫完了。
配置
網關沒有什么業務邏輯，主要地方就是在配置，通用的已經被封裝好了。
首先來配置一下轉發的邏輯，路由 路由后面是一個Map，表示可以有多個。
首先是要轉發token ，轉發給9090端口
order的轉發
網關自己跑在9070的端口上。
敏感頭
設置為空表示沒有任何的頭對我來說是敏感頭。也就是說 頭里的任何信息都往后轉發。這樣的話，服務才能通。
如果不設置敏感頭的話，這個Authorization是轉發不過去的。
啟動網關服務
認證服務器啟動起來。
訂單服務 啟動起來。
發送到localhost:9070/token這個路徑下 后面的路徑 oauth/token才是認證服務的路徑。
200就說明轉發成功了。
拿這個token再來調用一下創建訂單的服務。
成功
結束