微服務的環境下，我的業務邏輯不再是在一個單一的進程里，而是分散了很多的進程里。訂單、物流、庫存、價格。每一個tomcat都是一個進程。
每一個進程，每一個tomcat都有自己的入口點。那么就導致我防范的攻擊面比原來大的多 。那么風險也會高的多。
性能問題，原來的所有業務邏輯都在同一個進程里面。那么我需要的安全信息也都在這里面。比如請求進來以后，我想要驗一下用戶身份、權限。我都是在這個進程里面就可以完成的。
在微服務的架構下，我需要的關於安全信息很可能在我的這個進程里面是沒有的，比如說要訪問一個訂單的服務的時候，那么用戶的信息，權限的信息，在這個進程里面，這個tomcat里面是拿不到的，我可能需要一個遠程的調用。調用我的安全中心、認證中心去獲取相關的這些信息。那么每一個請求，不管是外部進來，還是服務之間的都要去做安全的校驗 。那么在做校驗的時候，這個遠程的鏈接導致的延遲可能會導致服務產生性能問題。尤其是對性能極端敏感的服務。可能原來我的服務本身幾毫秒就響應了。我現在我要做遠程調用來驗證安全，又增加了幾毫秒。增加的幾毫秒對於性能極端的服務來說，他的響應時間就增加了一倍。這種時候，這種性能問題也是微服務面臨的挑戰。
服務之間的安全，原來的時候只需要考慮外部進來的請求是不是安全的，進來以后，從訂單調物流，從訂單調庫存，這都是在我原來tomcat里面的，不需要考慮任何的安全的問題。
但是在微服務的場景下，當我從訂單去調用物流的時候，實際上我是需要跨網絡。出我的進程，進入另一個進程。這個時候我就要保證這個通訊是安全的。這也是微服務 面臨的挑戰
跨多個微服務的請求，難以追蹤。對於一個服務可觀測性，是一個很重要的指標。可觀測性包含了三個 log日志、
分布式里面每一個進程會自己記錄自己單獨的日志，日志是分散來記的。訂單自己記日志，庫存自己記日志。這時候我就需要一個機制，把所有的日志都串起來。
把日志聚合起來。最典型的就是流量，控制整個服務的留空，而不是單一的控制某一個服務。
一個請求進入每個服務所花的時間
容器化不可變是一個很重要的原則
多語言架構，每個微服務可以用自己適合的語言去創建。
結束