在微服務的架構下，對比單體應用架構的API安全有哪些新的挑戰呢？
1.1、更多的入口點，更高的安全風險
單體應用的場景下，入口點只有一個，所有的請求都會從這個入口點進來，在這個入口點去建立一組Filter或者Interceptor，就可以控制所有的風險。
微服務場景下，業務邏輯不是在一個單一的進程里，而是分散在很多的進程里。每一個進程都有自己的入口點，這就會導致防范的攻擊面，比原來大得多，風險也會高的多。
1.2、性能問題
單體應用的場景下，所有的業務邏輯都在同一個進程里面，關於安全的信息也都在這里面，想驗證身份權限，在這個進程里可以完成的。
微服務場景下，需要的安全信息，很可能在當前進程里是沒有的，比如說，訪問一個訂單服務的時候，用戶的信息、權限的信息，在訂單服務中是拿不到的。需要調用安全中心認證中心去獲取相關的這些信息。那么，每一個請求，不管是從外部進來的，還是服務間的調用，都要去做安全校驗時，這個遠程連接所帶來的延遲，有可能會導致服務產生一些性能問題。尤其是對性能極其敏感的一些服務。原來那個服務可能本身幾毫秒就能響應了。因為要做遠程調用來驗證安全，可能又增加了幾毫秒。
1.3、服務間通訊安全
單體應用的場景下，訂單調用價格，調用物流都是在同一個tomcat中，不需要考慮安全問題。
微服務場景下，當訂單去調用物流的時候，需要跨網絡，從一個進程進入另一個進程，要保證這個通訊也是安全的。
1.4、跨多個微服務的請求難以追蹤
對於一個服務來說，可觀測性是一個很重要的指標。可觀測性包含了三方面的意義：
1.4.1、log日志：在分布式的應用中，每一個進程會單獨記錄一些日志，這時候就需要有一個機制把所有的日志串起來。
1.4.2、Metrics指標監控：就是把日志的一些信息聚合起來，形成一個在一段時間上的某個指標的統計。比如說流量，在單體應用中很好控制。但是在微服務中，每個服務能承受的流量不同，需要有一個機制能控制整個系統的流控。
1.4.3、Tracing調用鏈監控：比如一個請求進來，在訂單服務耗時多少，庫存服務耗時多少，價格服務服務耗時多少。能看到整個服務的瓶頸在哪里，這也是需要解決的。
1.5、容器化部署問題
微服務場景下，最常用的部署手段那就是容器化，證書和IP訪問控制比以前復雜。
1.6、微服務間共享用戶的登錄狀態
微服務場景下，如何在多個應用之間共享用戶的登陸狀態，在這個請求中，所涉及到的微服務都可以知道當前用戶是誰。
1.7、多語言架構要求每個團隊都要有一定的安全經驗
微服務場景下，每個微服務都可以使用適合的語言開發，有可能訂單是java寫的，物流是用go寫的...。這種情況下，要求各個團隊都要有安全經驗。
2、常見的微服務安全整體架構
上圖為常見的微服務安全架構，這里我們主要學習安全中心、如何在網關上做安全處理。