第四章 網關安全
這一章從簡單的API的場景過渡到復雜的微服務的場景
4.1 概述
微服務安全面臨的挑戰：介紹中小企業的一個微服務架構，相比第三章的單體應用的簡單的API所面臨的哪些挑戰
OAuth2協議與微服務安全：介紹OAuth2中的各個角色，以及相互之間的關系，介紹具體的代碼實現
微服務網關安全：搭建網關，安全中心，兩個微服務，怎么將安全從微服務中解耦出來放到網關上，與OAuth協議聯系起來解決微服務安全面臨的新的挑戰。
4.2 微服務安全面臨的挑戰
更多的入口點，更高的安全風險
單體應用，入口點只有一個，有一個Filter/Interceptor 就能控制所有的安全風險。
微服務環境下，業務邏輯不再是在一個單一的進程里，分散在很多的進程里。如圖有很多的tomcat，每個tomcat都有自己的入口點，所以要防范的攻擊面要比原來大得多，風險也高得多。
性能問題
單體應用下，所有的業務邏輯 和 安全的信息 都在一個進程里，要驗一下用戶身份、權限都是在一個進程里完成的。
微服務環境下，比如在訪問一個訂單的時候，用戶的信息，權限信息，在訂單的tomcat 是拿不到的，需要一個遠程調用，調一下安全中心認證中心去或者這些信息。每一個請求，不管是外部進來的，還是服務之間的調用，需要安 全校驗的時候，這個遠程連接所帶來的延遲，有可能導致服務產生性能的問題，尤其是對性能極為敏感的服務。
服務間通訊安全
單體應用下，如訂單調庫存，訂單調物流，都在一個tomcat里，不需要考慮任何安全問題。
微服務環境下，訂單調物流，需要跨網絡，出我的進程，進到另一個進程，需要保證這個通訊也是安全的。
跨多個微服務的請求難以追蹤
對於一個服務來說，可觀測性是一個很重要的指標，可觀測性包含了三個方面的意義：
1、Log 日志，記錄了系統發生了什么。 在單體應用里，記錄日志很簡單，直接在代碼里寫就可以了。分布式的應用里，每一個進程會單獨去記一些日志。比如訪問訂單請求，訂單又去調庫存，調價格，日志是分散來記的，日志自己記了日志，庫存、價格也是自個記。這時候就需要一個機制把所有的日志串起來。
2、metrics 指標監控：在一個時間維度上聚合起來的一個數字。當你談論metrics 的時候，一定要有兩個關鍵要素，第一個就是時間窗口，第二個是一個數字。比如說流量，我們會說在1秒鍾有10個請求，一分鍾有200個請求，過去三小時下了50個單，我的成交額一天是100萬。談論metrics ，有兩個要素，時間窗口，如每秒鍾，過去三小時，每一天；第二個就是個數字，30個請求，200個請求，50個訂單，100萬成交額。這兩個聚合起來形成一個metrics 。最典型的metrics 就是流量，每秒鍾有多少個請求，在單體應用里很容易就能控制住流量。但是在分布式應用里，可能我的訂單能承受的並發量是500，物流能承受的並發量是700，庫存能承受的並發量是900。這個時候就需要有一個機制來控制整個的服務的流控，而不是單一的去控制某一個微服務的流控，這也是要解決的一個問題。
3，Tracing ，日志的聚合是一種Tracing，另外一種就是買吉克斯的Tracing，當一個請求進來，在訂單服務花了多長時間，在庫存服務花了多長時間，在價格服務花了多長時間，最后一眼能看見整個服務的瓶頸在哪里。
容器化部署導致的證書和訪問控制問題
~~
如何在微服務間共享用戶的登錄狀態
多語言架構要求每個團隊都要有一定的安全經驗