摘要：**dli兩個問題：如何在生產環境中部署與運維實現快速迭代上線，如何實現監控告警來提公升整體運維能力。華為雲資料湖探索dli是支援多模引擎的serverless大資料計算服務，其很好的實現了serverless的特性：
1.弱化了儲存和計算之間的聯絡；
2.**的執行不再需要手動分配資源；
3.按使用量計費。
那麼如何才能更好的實現serverless化的服務，同時又避免成為傳統單體分布式的應用，微服務架構無疑是最優的選擇。dli基於微服務架構模式下的整體部署架構如下：
即對外以純api形式提供服務，通過以api gateway作為應用的入口，基於領域模型按子域進行微服務劃分，從而實現serverless化的大資料計算服務。
對於這樣乙個基於微服務架構實現的serverless服務，我們是如何在生產環境來部署與運維，從而在保證服務sla的前提下實現快速迭代上線的呢？
隨著技術的發展，部署的流程和架構都發生了根本性的變化，如今已經走入了輕量級、短生命週期的技術時代。
從最初部署在物理機上的大資料計算平台，到基於公有雲的彈性計算雲伺服器部署大資料平台，再到dli這樣的serverless服務，其很好展現了大資料計算服務的演變。那麼如何才能更好的實現serverless化的大資料計算服務的部署呢，dli的答案就是基於kubernetes+docker來部署各微服務。
kubernetes部署是在不停機的情況下部署服務的好方法，但是如何應對在接收生產流量後出現的錯誤，使新版本的服務更可靠呢？這可以通過將問題一分為二來看：
1.部署，即將服務上線到生產環境中執行；
2.發布，即使服務可用於處理生產流量。
傳統上，分離部署流程與發布流程一直是乙個挑戰。但現在我們有了很好的選擇，那就是基於服務網格。在dli的部署中我們結合了kubernetes+istio，利用istio的流量管理實現了服務發現、流量路由，從而輕鬆的將部署與發布分開，使新版本的服務更加可靠。
免運維也是dli作為serverless雲服務面向客戶時的乙個重要的特性，我們是如何實現整個服務的運維呢？今天就說說dli是如何實現監控告警來提公升整體運維能力，從而為客戶更好的提供serverless的dli。
上圖是dli服務的整體部署架構，作為serverless服務其全面擁抱雲原生技術，無論是對外提供任務管理的微服務還是最終執行任務的計算單元，其都是基於kubernetes來部署，這也更好的實現了serverless的快速彈性伸縮。
對於dli服務的監控告警我們當前主要從以下幾個方面來考慮：
1.全域性維度，主要是整體api的qps、成功率和響應時延
dli作為serverless大資料計算服務，其對外均以rest api的形式提供服務，因此api的qps和響應時延直接反映了服務對外的能力，而成功率更是服務sla的直接體現。
2. os維度，主要是容器宿主的cpu使用率、記憶體使用率、磁碟使用率、上下行流量
無論部署的架構、技術如何演進，對基礎資源的監控都是最基本和必須的。
3.容器維度，主要是cpu使用率、記憶體使用率、k8s空間和使用者空間使用率、pod的健康度
容器是虛擬機器的演進，因此對於容器的資源監控也是最基本的。我們的微服務或計算單元都是以容器執行在kubernetes集群上，因此對於pod的健康狀態的監控也是必須的。
4.微服務維度，主要是流量、效能、健康檢查和關鍵日誌等
監控是為了更好的發現和解決問題，因此核心還是業務層面的監控。dli是乙個複雜的分布式serverless應用，其內部根據不同領域模型又分為不同的微服務，因此對於微服務內部的流量、效能等的監控則是衡量各微服務可靠性的重要指標。乙個好的系統往往有完善的日誌體系，通過對關鍵日誌進行監控則能夠幫助我們快速發現和定位問題，因此這也是我們在業務維度的監控上的重點。
上述幾個方面的監控，是實現雲服務自動化運維的一些關鍵步驟，通過這些我們能夠做到更好的先於客戶發現問題，保障服務sla。當然這些遠遠不夠，正所謂「路漫漫其修遠兮，吾將上下而求索」，更加自動化、智慧型化的運維才是serverless服務的目標。
華為雲828企業上雲節，可能是入手dli的最好時機，感受一下它的智慧型化部署和運維。
點選關注，第一時間了解華為雲新鮮技術~
從部署和運維說說DLI（1）
dli是支援多模引擎的serverless大資料計算服務，其很好的實現了serverless的特性 1.弱化了儲存和計算之間的聯絡 2.的執行不再需要手動分配資源 3.按使用量計費。那麼如何才能更好的實現serverless化的服務，同時又避免成為傳統單體分布式的應用？微服務架構無疑是最優的選擇。d...
微服務架構轉型需要關注的運維監控的技術和建議
系統架構的公升級，需要引入服務註冊 如consul，入門見 服務間的互動方式也需要與之進行適配 運維平台的公升級，建議引入日誌收集 如fluentd，入門見 分布式跟蹤 如zipkin，入門見 和儀錶盤 如vizceral grafana 等 運維效率和自動化水平的提公升也迫在眉睫，否則無法應對例項...
微服務架構下的監控問題
用一句話概括就是服務特別多，服務間的呼叫也變得非常複雜 我們其實是微服務的受害者，其實業內很多人做的架構只是服務化，並不夠 微 而我們做的比較徹底，我們線上很多服務都只有乙個 api，但這樣造成線上指標非常多，告警也非常多，讀和寫的壓力都非常大。第二個是智慧型化的監控和告警，運用合適的演算法並加上機...