系統架構的公升級，需要引入服務註冊（如consul，入門見：服務間的互動方式也需要與之進行適配；
運維平台的公升級，建議引入日誌收集（如fluentd，入門見：分布式跟蹤（如zipkin，入門見：和儀錶盤（如vizceral/grafana）等；
運維效率和自動化水平的提公升也迫在眉睫，否則無法應對例項數量，變更頻率，系統複雜度的快速增長；
首先，監控配置的維護成本增加。以前我們做的電商系統大概有100個模組，每個模組都需要新增埠監控，程序監控，日誌監控和自定義監控；不同服務的監控指標，聚合指標，報警閾值，報警依賴，報警接收人，策略級別，處理預案和備註說明也不完全相同；如此多的內容，如何確保是否有效，是否生效，是否完整無遺漏。
當前針對維護成本，業界常用的幾種方法有：
其次，第三方依賴越來越多。例如docker的可靠性很大程度上取決於宿主機狀態，如果所在的宿主機發生資源爭用，網路異常，硬體故障，修改核心引數，作業系統補丁公升級等，都可能會讓docker莫名其妙地中招。
第三，服務故障的定位成本增加。假設故障是因為特定服務處理耗時增大導致的，那麼如何快速從上百個服務以及眾多的第三方依賴中把它找出來，進一步，又如何確認是這個服務的單個例項還是部分例項的異常，這些都讓故障定位變得更複雜。
在微服務架構下，提高故障定位效率的常用方法有：基於各類日誌分析，通過儀錶盤展示核心指標：資料流，異常的監控策略，變更內容，線上登入和操作記錄，檔案修改等內容，對於檔案的修改，是乙個必不可少的需要觀察的因素，因為目前很多客戶私有環境去修改產品的標準的時候，記錄需要監控。
首先，儲存功能的寫入壓力和可用性都面臨巨大挑戰。每秒寫入幾十萬採集項並且需要保證99.99%的可用性，對於任何儲存軟體來講，都不是一件輕鬆的事情。
對於寫入和可用性的壓力，業界常見的解決思路主要是基於如下方式的組合：
集群基於各種維度進行拆分（如地域維度、功能維度和產品維度等）；
增加快取服務來降低hbase的讀寫壓力；
調整使用頻率較低指標的採集週期；
通過批量寫入降低hbase的寫入壓力；
通過寫入兩套hbase避免資料丟失並做到故障後快速切換。
其次，監控的生效速度也面臨巨大挑戰。微服務架構下，基於彈性伸縮的加持，從服務擴容或者遷移完畢到接入流量的耗時降低到1min左右，且每時每刻都在不斷發生著。對於複雜監控系統來講，支援這樣的變更頻率絕非易事，而且例項變更如此頻繁，對監控系統自身來講，也會面臨可用性的風險。
常見的提高監控生效速度的思路主要有如下的幾種方式：
實時熱載入服務註冊資訊；
對監控配置的合規性進行強校驗；
增加例項數量的閾值保護；
支援配置的快速回滾。
其次，基礎設施的故障可能導致報警風暴的發生。基礎設施如idc故障，可能會在瞬時產生海量報警，進而導致簡訊閘道器擁塞較長時間。
解決這類問題的思路主要是如下方式：
其中因素及可解決策略：
網際網路轉型需要微服務架構
微服務出現的時間不短了，但是為什麼現在才這麼重視它?網際網路轉型要轉型什麼?第一，以職能為中心轉向以使用者為中心。我們過去的資訊化更多的是依照部門職能，有什麼樣的工作內容，有什麼樣的流程，然後去做系統。下一步的資訊化更多的是以使用者為中心。為什麼是以使用者為中心?我們要看使用者到底需要什麼，在什麼樣...
微服務架構下，DLI的部署和運維有何奧秘？
摘要 dli兩個問題 如何在生產環境中部署與運維實現快速迭代上線，如何實現監控告警來提公升整體運維能力。華為雲資料湖探索dli是支援多模引擎的serverless大資料計算服務，其很好的實現了serverless的特性 1.弱化了儲存和計算之間的聯絡 2.的執行不再需要手動分配資源 3.按使用量計費...
微服務架構下的監控需要注意哪些方面？
微服務架構雖然誕生的時間並不長，卻因為適應現今網際網路的高速發展和敏捷 devops等文化而受到很多企業的推崇。微服務架構在帶來靈活性 擴充套件性 伸縮性以及高可用性等優點的同時，其複雜性也給運維工作中最重要的監控環節帶來了很大的挑戰 海量日誌資料如何處理，服務如何追蹤，如何高效定位故障縮短故障時常...