-
定位問題難
客服人員接到用戶反饋商品購買出現問題後，會交由技術人員排查解決。而微服務分佈式架構中的一個網站請求通常要經過多個服務/節點後返回結果。一旦請求出現錯誤，往往要在多臺機器上反覆翻看日誌才能初步定位問題，對簡單問題的排查也常常涉及多個團隊。
-
發現瓶頸難
當用戶反饋網站出現卡頓現象，很難快速發現瓶頸在哪裏：是用戶終端到服務端的網絡問題，是服務端負載過高導致響應變慢，還是數據庫壓力過大？即使定位到了導致卡頓的環節，也很難快速定位到代碼層面的根本原因。
-
架構梳理難
在業務邏輯變得逐漸複雜以後，很難從代碼層面去梳理某個應用依賴了哪些下游服務（數據庫、HTTP API、緩存），以及被哪些外部調用所依賴。業務邏輯的梳理、架構的治理和容量的規劃（例如“雙十一”促銷活動的準備過程中，需要爲每個應用準備多少臺機器）也變得更加困難。