微服務架構,數字時代信息化建設的解藥還是毒藥?

智能、互聯時代已經來臨,應用併發量激增,業務流程更加複雜,新技術迭代落地速度更快。採用傳統單體應用架構開發,控制代碼複雜度,保障系統可擴展性難度越來越大。微服務架構通過將獨立業務流程解耦的設計理念快速贏得了大量架構師的關注。更加靈活的部署方式和便捷的服務拼裝都使人眼前一亮。大量企業客戶,特別是互聯網企業基於微服務架構建設信息系統獲得了成功。然而,微服務是否適合所有類型的應用系統呢?是否是治癒日益膨脹數字系統開發、管理難題的解藥?

我們總是希望有完美的技術方案,然而,放之四海而皆準的應用架構並不存在。微服務架構是一把雙刃劍,一方面能大幅度緩解單體系統開發、部署複雜性問題;另一方面,爲客戶數字體驗保障,應用性能穩定性保障帶來了新的挑戰。不能解決負面影響,微服務就是一劑毒藥。

單體架構應用系統

微服務架構應用

微服務架構應用的主要特點是業務功能模塊鬆耦合,分佈式部署。大部分業務功能模塊都是單獨部署運行的,彼此通過數據總線交互,基本都是無狀態的服務,以確保能夠靈活擴展。在這種架構下,從前臺到後臺的業務流程會經過多個服務節點,其中可能包括多臺物理、虛擬機,容器和很多微服務進行處理、調用和傳遞。這種方式的主要優點是:

1、 業務邏輯複雜,系統龐大的應用系統能夠持續交付、持續部署;

2、 服務業務邏輯獨立,易於開發;

3、 服務之間相互耦合度低,可以獨立部署;

4、 服務可以獨立集羣擴容;

5、 使應用能夠快速引入新技術,支持多種語言開發的服務協同工作;

然而,微服務節點數量增速與業務複雜度成正比,微服務應用的複雜度使得通過手動管理維護應用拓撲結構已不現實。建設自動化、智能化程度更高的運維繫統,首先要找到人工運維困難、耗時的問題點。微服務架構應用系統在業務處理,出現性能、穩定性或業務異常排查的過程中經常遇到的問題主要包括:

1、 應用節點數快速增加,複雜度急劇膨脹,導致測試、運維成本增加;

2、 業務流程處理鏈路變長,保障客戶數字體驗難度增加;

3、 業務邏輯和中間件解耦,動態性提升,日常管理難度增加;

4、 監控目標類型多,數據來源分散,故障定位分析困難。

要解決或緩解這些問題對企業運維體系的影響,首先需要具備微服務節點自動探查發現能力,所有節點信息和運行狀態自動掃描錄入系統,所有服務節點運行狀態基於全景監控視圖統一展現。全景監控視圖重點突出風險探查、發現能力,發生風險第一時間重點突出顯示風險點和相關服務節點,過濾海量無用信息(正常狀態節點)。

總的來說,微服務應用運維運維難點主要有:1、服務節點衆多;2、部署模式多樣;3、故障定位困難;4、監控數據量激增;5、基礎組件衆多;6、代碼調用路徑變長。

微服務運維難點總結

目前開發運維團隊解決問題經常使用的主要手段是採用Prometheus、ElasticSearch、Skywalking、Zipkin、Zabbix等代碼鏈路追蹤、埋點、日誌分析、運行期應用指標監控開源工具自建設微服務應用監控系統。但實踐結果顯示,這種方式不但不能降低微服務監控運維成本,由於需要搭建多種監控系統協同工作,反而增加了系統複雜度,從多個系統接收告警,查詢相關數據使得故障定位分析成本更高。額外增加的監控系統維護、管理和定製開發成本反而讓事情變得更復雜。應對這些新技術帶來的問題與挑戰,解決問題的思路和方向需要轉變。運維微服務應用需要轉變的核心流程和建設方式,總結起來主要有以下四點:

建設關鍵點

業務優先一體化監控,提升系統可靠性

微服務應用運維,首先要轉變的是將以基礎設施、服務節點、接口可用性保障爲主的運行期監控維護工作,轉變爲以保障客戶數字體驗,探查、處理已發生或將要發生的潛在全局風險爲核心。將監控中心從指標、告警、工單轉移到服務質量目標、用戶體驗指標等反映整體態勢的聚合指標。這樣會大幅度降低快速複雜化的微服務應用日常監控、管理工作量。結合網絡、應用配置、部署結構等多種數據源監控數據拼接完整應用拓撲結構,能夠自動探測網絡拓撲、服務調用、部署依賴等多種應用拓撲關係,鏈路。進而圍繞客戶數字體驗保障服務質量目標,打造業務優先的全景監控系統,提升系統可靠性。

建設目標:
1、 全景化監控,簡化問題溯源

2、 業務狀態可視化,簡化定位分析

3、 全局態勢分析,實時感知潛在風險

4、 故障溯源,海量數據溯源分析

建設效果參考:

全景化監控視圖,故障風險一目瞭然

業務優先的全景化微服務應用

自動探查複雜應用架構,生成全景監控視圖

劃清責任邊界,有序運維管理

微服務應用依賴中間件、運行環境資源類型衆多。相關責任人職責明確,但指標告警和業務錯誤無法關聯,責任邊界難以界定。基於各自需求搭建分散監控系統,缺少全景化監控平臺,出現風險將導致問題排查認責困難。因此,需要在一體化監控平臺基礎上,通過場景化運維儀表盤、看板或報表,將微服務開發、基礎運維、應用運維、網絡運維、SRE等責任人圍繞風險發現、定位、處理將工作流程和數據關聯,從而實現責任清晰、運維有序。

建設目標:

1、 可視化層級視圖管理,明確職責邊界

2、 整合業務和監控指標,輔助風險根源定位

3、 有序關聯運維場景,簡化故障處理流程

建設效果參考:

開發運維一體化微服務監控管理

微服務應用代碼定位分析

業務流程複雜,故障排查耗時

微服務應用業務耦合度低,請求處理鏈條更長,部署方式多樣。導致故障追蹤、排查難度增加。常用監控工具,如zabbix、prometheus、grafana結合使用可以實現在開發期通過prometheus SDK定義業務指標,zabbix採集運行期環境狀態指標,並通過grafana可視化監控儀表盤關聯的方式實現。但是,這種方式需要開發人員介入做大量前期指標定義和代碼修改工作,運維人員排查特定業務流程運行期相關中間件、環境依賴資源非常困難。實際應用,需要轉變爲對開發影響更小,運維人員容易部署,能夠快速關聯業務流程和監控指標的監控系統。基於Google提出的Dapper理論,藉助海量數據關聯分析和人工智能算法,運行期定義業務流程,映射代碼鏈路,並自動關聯業務相關資源和指標將是大勢所趨。

建設目標:

1、 核心業務全景監控,一站管理業務狀態

2、 實時監控業務,業務故障自動發現

3、 打通業務和技術指標,壓縮故障分析過程

建設效果參考:

業務流程導向的微服務系統監控

微服務業務流程代碼調用鏈路

微服務業務流程代碼調用鏈路監控

監控數據分散,定位分析困難

採用過多監控、運維工具全量覆蓋微服務應用運行期指標,勢必造成多種監控數據採集工具採集的監控數據分散、告警獨立,定位分析問題需要查詢多個平臺數據,難度增加。有效的解決方案是圍繞業務,通過定製融合所有異構監控指標、代碼鏈路、網絡報文、日誌等數據爲一個運維數據中臺。通過統一的風險探查、定位系統從業務角度發現、定位海量監控數據中的問題。

建設目標:

1、 運維數據融合存儲,業務技術指標聯動

2、 應用全鏈路監控,方便故障關聯定位

3、 智能檢測定位異常,支撐運維提效減負

建設效果參考:

支持各種微服務基礎組件

海量數據快速檢索

智能根源問題分析定位

企業需要能夠精準應對微服務應用運維難點的智能化平臺,支持以全景化監控視圖整合應用監控數據,通過場景化儀表盤應對客戶數字體驗保障、業務流程監控、應用性能穩定性保障等場景,化繁爲簡,爲企業落地微服務保駕護航。總的來說,建設落地智能化運維平臺,需要考慮重點實現的核心能力項包括:

平臺核心功能

綜上所述,需要馴服微服務架構爲企業所用,必需要有行之有效的客戶體驗保障、微服務應用監控運維繫統。RealSight APM產品爲基礎的微服務應用全景監控解決方案對症下藥,在寶馬中國、蒙牛集團、中國航空、宜昌三峽雲、北京東城區等客戶現場上線應用,運維效率顯著提升,保障微服務架構發揮應有的價值。

作者介紹:

許 力,教授級高工,工學博士。2015年畢業於大連理工大學計算機應用專業;國家軟件架構新技術重點實驗室 研究員;現任東軟集團基礎軟件事業部 技術總監,兼任東軟智能化運維產品RealSight APM產品經理。十餘年平臺產品研發經驗,美國硅谷工作輪崗。大連理工大學企業特聘客座講師;大連海事大學信息科學技術學院教學指導委員會委員。中國計算機學會(CCF)高級會員;中國計算機學會大數據專委通訊委員;美國計算機學會(ACM)高級會員; 美國電子電氣工程協會(IEEE)會員。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章