【云駐共創】云原生應用架構之企業核心業務未來架構演進路線及華為云方案
前言

云原生分兩大部分:一部分是遵循微服務化和容器化原則的云原生應用,另一個部分是用于構建和運行云原生應用的云原生平臺。云原生應用和云原生平臺,共同構成了一個云原生的完整體系。在這個體系上,可以實踐敏捷開發、DevOps、容器編排、微服務和容器化等理論和方法。
云原生應用架構的發展得益于以下幾點原因:
云原生經過多年發展,已經逐漸為企業所接受。
隨著容器技術相關應用持續深化,逐漸擴展至容器編排、微服務、DevOps、服務運維監控、應用管理的完整閉環。
企業核心業務的應用架構將逐步演進,充分利用公有云平臺和服務的優勢,獲得靈活性、彈性和高可用性,滿足業務快速發展、不斷創新的需求。
一、企業核心業務架構演進
1.企業核心業務應用架構和集成架構發展歷程
1.1 企業核心業務應用架構發展歷程
企業核心業務應用架構發展歷程主要有如下四個階段:
單體架構
垂直架構
SOA面向服務架構
這種將所有功能都部署在一個web容器中運行的系統就叫做單體架構(也叫:巨石型應用)。
1、所有的功能集成在一個項目工程中。
2、所有的功能打一個war包部署到服務器。
3、應用與數據庫分開部署。
4、通過部署應用集群和數據庫集群來提高系統的性能。
1、項目架構簡單,前期開發成本低,周期短,小型項目的首選。
1、全部功能集成在一個工程中,對于大型項目不易開發、擴展及維護。
2、系統性能擴展只能通過擴展集群結點,成本高、有瓶頸。
3、技術棧受限。
垂直架構相較于單體架構而言,進行了部分解耦,但是不夠徹底,在各個子系統相互依賴的代碼和模塊中,存在重復代碼拷貝和模塊功能重復開發的情況。
垂直架構按功能進行MVC劃分和按職能進行前后端分離模式,通過分層來規范職責和定義邊界。
1、以單體結構規模的項目為單位進行垂直劃分項目即將一個大項目拆分成一個一個單體結構項目。
2、項目與項目之間的存在數據冗余,耦合性較大。
3、項目之間的接口多為數據同步功能,如:數據庫之間的數據庫,通過網絡接口進行數據庫同步。
1、項目架構簡單,前期開發成本低,周期短,小型項目的首選。
2、通過垂直拆分,原來的單體項目不至于無限擴大。
3、不同的項目可采用不同的技術。
1、全部功能集成在一個工程中,對于大型項目不易開發、擴展及維護。
2、系統性能擴展只能通過擴展集群結點,成本高、有瓶頸。
面向服務的架構(SOA)是一個組件模型,它將應用程序的不同功能單元(稱為服務)進行拆分,并通過這些服務之間定義良好的接口和協議聯系起來。
面向服務的架構主要由兩種:以企業服務總線(ESB)為代表的SOA和以RPC為代表的SOA。
1、基于SOA的架構思想將重復公用的功能抽取為組件,以服務的方式給各個系統提供服務。
2、各個項目(系統)與服務之間采用webservice、rpc等方式進行通信。
3、ESB企業服務總線作為項目與服務之間通信的橋梁。
1、將重復的功能抽取為服務,提高開發效率,提高系統的可重用性、可維護性。
2、可以針對不同服務的特點制定集群及優化方案。
3、采用ESB減少系統中的接口耦合。
1、系統與服務的界限模糊,不利于開發及維護。
2、雖然使用了ESB,但是服務的接口協議不固定,種類繁多,不利于系統維護。
3、抽取的服務的粒度過大,系統與服務之間耦合性高。
微服務架構是一種架構模式,它提倡將單一應用程序劃分成一組小的服務,服務之間互相協調、互相配合,為用戶提供最終價值。每個服務運行在其獨立的進程中,服務和服務間采用輕量級的通信機制互相溝通(通常是基于HTTP的RESTful API)。每個服務都圍繞著具體業務進行構建,并且能夠被獨立地部署到生產環境、類生產環境等。另外,應盡量避免統一的、集中式的服務管理機制,對具體的一個服務而言,應根據業務上下文,選擇合適的語言、工具對其進行構建。
1、將系統服務層完全獨立出來,并將服務層抽取為一個一個的微服務。
2、微服務遵循單一原則。
3、微服務之間采用RESTful等輕量協議傳輸。
1、服務拆分粒度更細,有利于資源重復利用,提高開發效率。
2、可以更加精準的制定每個服務的優化方案,提高系統可維護性。
3、微服務架構采用去中心化思想,服務之間采用RESTful等輕量協議通信,相比ESB更輕量。
4、適用于互聯網時代,產品迭代周期更短。
1、微服務過多,服務治理成本高,不利于系統維護。
2、分布式系統開發的技術成本高(容錯、分布式事務等),對團隊挑戰大。
1.2 企業集成架構發展歷程
“企業”是指由一整套可識別的、互為作用的業務功能構成的商業組織。企業架構是企業的基礎框架,它定義和描述了企業實現經營目的和商業愿景的平臺。企業架構是與企業經營戰略、信息需求緊密相連的一整套原則、方針、政策、模型、標準以及流程,它結合企業未來發展方向,為企業各項解決方案的設計、選擇和執行提供指導。
企業架構可以分為兩大部分:業務架構和IT架構
業務架構:是把企業的業務戰略轉化為日常運作的渠道,業務戰略決定業務架構,它包括業務的運營模式、流程體系、組織結構、地域分布等內容。
IT架構:指導IT投資和設計決策的IT框架,是建立企業信息系統的綜合藍圖,包括數據架構、應用架構和技術架構三部分。
企業架構發展歷程如圖:
隨著大數據、人工智能、云計算等數字技術的快速發展,技術革命進入“云時代”,企業上云(私有云或公有云)成為趨勢,云平臺以及企業應用上與之相關的移動應用、微服務、大數據、人工智能、物聯網等若干技術手段的出現,以“云”為主要特征,具有更加開放、實時、靈活的“云架構”逐漸代替傳統架構,成為新一代的企業架構。
2.應用架構演進
應用架構的演進就是:普通架構->云架構的發展歷程。
常見的云服務有幾種方式:
IaaS(Infrastructure as a Service):基礎設施即服務。提供云端的基礎設施為主,比如提供主機、存儲、網絡、CDN、域名解析等功能。
PaaS(Platform):平臺即服務。提供云端的發布、數據庫服務、文件存儲、緩存服務、容器管理等基礎存儲和管理組件,自動化了程序的配置、發布、管理–Heroku、Google App Engine、Force.com等。
SaaS(Software as a Service):軟件即服務。提供云端的應用服務,ERP、HR、CRM等在線系統,每個賬戶或者每家公司有獨立的數據存儲,通過賬戶進行權限和訪問隔離,知名廠商有Salesforce、Successfactor、Zendesk等。
BaaS(Backen as a Service):后端即服務,起初專指針對移動端的研發提供的云服務,降低移動研發的復雜度,讓開發者關注與移動端開發即可。流行的服務有幾大類:綜合類,Parse、Kinvey;分析類,友盟、TalkingData、神策數據;支付類,Beecloud、Ping++;IM類,環信、網易;消息類,極光、個推等。
二、華為云方案
1.應用架構演進之云服務總覽
1.1 應用架構方案
華為云應用架構方案組成:客戶端、前端應用、業務應用、技術平臺、數據平臺、混合云平臺、IaaS。
1.2 讓企業應用上云更簡單,數字化轉型更智能
華為云智能應用平臺,構建在云基礎設施之上,提供一個Cloud Native應用底座和三個應用創新平臺,秉承了此前應用上云更簡單的理念,為企業的數字化轉型和智能化升級提供了系統的解決方案。將應用管理能力延伸到多云&混合云、打造更豐富的開放生態、由技術平臺向行業使能平臺發展。
企業應用上云有如下特性:
開放
中國唯一CNCF初創成員和白金會員
K8S社區貢獻度全球前三
微服務ServiceComb:Apache社區唯一微服務
源項目并已順利畢業
智能
全球唯一基于K8S的GPU共享Al容器實例
Al訓練速度較自建K8S提升53%
企業級
安全,可靠,高性能
微服務框架單實例吞吐量30萬TPS,時延低于1ms
1.3 ServiceStage-應用管理運維平臺
華為云微服務平臺ServiceStage提供應用全生命周期管理,實現業務敏捷DevOps,并通過獨有的契約能力實現了微服務治理與業務代碼分離,幫助企業開發者聚焦業務邏輯。
1.4 最高性能、開放開源微服務解決方案
微服務的解決方案主要有:開箱即用的微服務框架、非入侵式微服務接入、開放兼容。
備注:具體詳細說明看3.6小節。
1.5 立體運維-全方位掌控系統運行狀態,快速響應
華為云立體運維解決方案是為云上客戶量身定制的一個解決方案,包含AOM(應用運維管理服務)、APM(應用性能管理服務)、LTS(日志服務)。覆蓋IaaS層的基礎設施狀態,Paas層的中間件及數據庫狀態,應用層的各類應用狀態及指標這三層,形成立體化運維分析能力。華為云立體化運維解決方案遵循DevOps標準,可以敏捷高效的獲取云上應用的各類異常,并輔助運維人員快速定位。同時立體化運維解決方案以應用為中心,展示應用指標、拓撲、狀態信息,提供應用視角的監控運維模式,滿足日常巡檢、故障排查等多種運維場景。
1.6 華為云K8S全棧容器服務
華為云全棧容器服務包含云容器引擎CCE、云容器實例CCI、服務網格Istio、應用編排服務AOS、應用運維管理AOM、容器鏡像服務SWR、智能邊緣平臺IEF及基因容器服務GCS等一系列容器相關服務,其中CCI、IEF和GCS是全球首發,CCE和Istio屬于國內首發。同時,該服務還推出了裸金屬容器、GPU容器、Windows容器,豐富了客戶的選擇。
華為云全棧容器服務向下對接高性能IaaS資源,向上為AI、移動、區塊鏈、邊緣計算等服務提供業務運行平臺,為客戶提供容器應用的全生命周期管理,加速客戶應用容器化上云過程,目前在互聯網、AI、游戲、生信領域應用廣泛。
此外,華為作為CNCF基金會的領導者,也正在將集群聯邦、高級調度策略、IPVS負載均衡、容器存儲快照等先進技術貢獻給社區,以及開源KubeEdge和KubeGene兩個項目,推動K8S生態的快速發展。
1.7 ROMA聯接企業的現在與未來
ROMA聯接企業的現在與未來主要分為兩方面:一方面通過邊緣ROMA Site配合,實現多云環境部署,完善多云、混合云集成能力。一方面通過Link打破空間鴻溝,實現IT&OT融合,真正全面的打破一切空間鴻溝。
ROMA提供的50+種主流適配器、100家行業應用資產、無縫的對接SAP、金蝶等商用軟件實現了老舊系統100%接入,打破時間鴻溝,實現企業IT系統平滑演進。
ROMA方便地為企業和他的伙伴提供接入私有協議的應用與數據的能力,開放所有ROMA的經驗資產給企業,打破開放鴻溝,幫助企業和伙伴快速構建新的創新業務與應用。
2.應用架構演進之高性能中間件
2.1 為什么要用云中間件服務
企業自己開發或使用開源中間件的弊端:
硬件故障:企業需要自己保證底層硬件設施的可靠性和故障替換。
軟件安裝部署:中間件自身的安裝部署、補丁、升級等需要耗費企業大量的人力物力。
中間件軟件bug和安全修復:需要投入大量人力維護中間件代碼和安全補丁。
使用云中間件服務的好處:
開箱即用:完全不需要考慮軟硬件安裝部署,購買完畢即可使用。
可靠安全:由云中間件服務保證服務可靠性和故障切換。
升級和補丁:由云中間件專業團隊負責代碼維護和bug修復。
2.2 傳統應用的挑戰及應用策略
傳統應用的挑戰主要有兩個點:非高并發、非高可用。
要解決傳統應用應用的問題,可以通過分布式應用解決。解決高并發主要的技術點有:緩存、隊列、分庫、同步異步、處理、全局鎖、線程池。解決高可用主要的技術點有:主備HA、數據多副本、限頻、限流。
2.3 使用云中間件構建分布式云化應用
傳統應用All in one的架構導致資源利用率低、可擴展性差、可靠性也無法得到保證。舉例:一個電商系統,如果是All in one架構下,大促來臨之前只能按照整系統的倍數去擴展。而不能按照緩存擴展5倍(登陸次數暴增)、數據庫擴展2倍(實際的用戶數據增長約2倍)比例去擴展。
這種封閉的架構,如果要做業務改動或新增業務模塊都是比較困難的,因為所有的模塊與數據庫都是直接串行交互的。整系統的可靠性也比較差,如果數據庫故障了,所有的業務流程都會受阻。增加了分布式消息隊列以后,可以將各個應用模塊做解耦,當某個業務模塊故障時,不影響與其并行操作的其他模塊。大大增強了系統的可靠性。
2.4 快速構建云上企業級分布式應用
華為云快速構建云上企業級分布式應用主要依賴于以下技術:分布式消息服務(DMS)、分布式緩存服務(DCS)、分布式數據庫中間件服務(DDM)。
完全托管的高性能消息隊列服務,100%兼容開源Kafka&RabbitMQ,為分布式應用系統提供靈活可靠的異步通信機制。
兼容Redis、Memcached等主流緩存引擎,基于雙機熱備的高可用架構,提供單機、主從、集群等豐富類型的緩存類型,滿足用戶高讀寫性能及快速數據訪問的業務訴求。
專注于解決數據庫分布式擴展問題,突破傳統數據庫的容量和性能瓶頸,通過讀寫分離、數據分片等實現海量數據高并發訪問。
2.5 分布式緩存典型應用場景及云服務特點
DCS即一種分布式緩存數據庫服務,將現在很火的幾類內存數據庫Redis、Memcached和內存數據網格進行包裝,提供即開即用、安全可靠、彈性擴容、便捷管理的在線分布式緩存能力。DCS提供單機、主備、集群等豐富的實例類型,滿足用戶高并發及快速數據訪問的業務訴求。
為應用系統提供高性能的Key-Value的緩存數據庫服務,支持Redis開源引擎。有效提升熱點數據訪問速度,并大幅降低數據庫的壓力。
Redis云服務特點:
高性能:單實例QPS10+萬
應用0改動:支持Redis3.0/4.0/5.0開源主流版本
數據安全:租戶間物理隔離,支持跨AZ、跨Region部署,確保數據安全可靠
規格靈活:可選擇128MB~1TB多種緩存規格,并提供單機/主備/集群等多種實例類型,滿足不同應用場景對緩存的需求
彈性擴展:緩存規格一鍵式在線擴容,無縫配合業務規模發展
為應用系統提供異步的消息隊列服務。通過高可用的消息緩沖隊列,實現應用解耦、突發流量處理及與第三方的互通和集成。
關鍵特性:
100%兼容開源:提供提供多種規格,按需使用,支持Kafka&RabbitMQ引擎
安全保證:VPC隔離,支持SSL通道加密和消息存儲數據加密。深度修改消息引擎內核,按電信級標準修復開源安全問題
增強功能:一鍵擴容、消息查詢,消息轉儲,消息存儲加密等豐富的消息能力
億級消息堆積:存儲和實例規格可動態擴展,支持千萬級并發支持企業級高性能應用
可靠消息存儲:節點反親和部署,支持跨AZ,同步落盤及多副本冗余,集群化部署確保數據和服務高可靠
2.6 DDM典型應用場景及特性
分布式數據庫中間件(Distributed Database Middleware,簡稱DDM),專注于解決數據庫分布式擴展問題,一個實現了Mysql協議棧的數據庫代理服務器,通過代理服務器將底層數據庫存儲引擎以集群方式管理起來。DDM提供分庫分表、讀寫分離、彈性擴容等能力,而且服務器集群管理對用戶完全透明,用戶通過DDM管理控制臺進行數據庫運維,使用JDBC等驅動服務或SQL客戶端連接數據庫,進行數據讀寫。
作為RDS前置的分布式數據訪問服務,徹底解決了數據庫的擴展性問題,對應用透明地實現海量數據的高并發訪問
關鍵特性:
業務不中斷,自動完成水平拆分、平滑擴容
可承受PB級數據量、百萬級并發量,十倍于單機數據庫連接數
集群高可用,秒級故障自動恢復
兼容MySQL協議,業務代碼零改動,透明讀寫分離
3.應用架構演進之微服務
3.1 微服務范圍
微服務是以不斷提高交付效率、縮短交付周期為核心,基于云原生的方式,對架構優化的結果。當自動化測試、持續集成、持續部署、環境管理、數據管理等都完成局部優化后,架構的優化與解耦成為縮短交付周期所不可回避的問題。演進式架構(Neal Ford,2015/Thoughtworks)的核心是提高架構應對變化的響應力,從而適應未來日益加劇的業務競爭和多元化的IT變化。
微服務范圍主要包含三方面:自組織團隊、技術實踐、流程與工具。
康威定律-產品或系統的設計(架構)受到其生產組織自身溝通結構的制約
You build it,youRuni小團隊、完成服務的分析、開發、測試、部署和運維
不斷識別交付中的瓶頸,采用精益的方式快速驗證和優化,小步快跑
通過高度成熟的自動化體系建立可靠且可重復的交付過程
良好的持續集成、代碼review、團隊內技術分享等實踐
在滿足驗收標準的條件下,鼓勵擁抱新技術解決業務問題,試點性驗證并推廣
積極引入外部工具,同時不斷優化內部工具
保障持續集成、持續部署流水線的穩定且高效
加強基礎設施的構建與管理,加快監控、告警、日志聚合等反饋效率
3.2 微服務優勢
微服務優勢主要有以下三點:服務模塊的邊界更清晰、支持獨立部署、允許技術多樣性。
微服務強調模塊化結構(REST接口調用),這對大型團隊非常重要。
單服務更易部署,由于服務是自治的出現問題之后不會引起系統崩潰。
有了微服務,你可以混合使用多種編程語言、開發框架和數據存儲技術。
3.3 微服務帶來的挑戰
微服務帶來的挑戰主要有以下三點:
微服務架構復雜、依賴關系多
需處理分布式系統的一致性
增加運維復雜性
開發的服務數量增加,遠程調用更慢且總存在失敗風險。
各微服務都管理自己的數據,數據不再集中保持一致性非常困難,意味著大家都要處理最終一致性。
無狀態、調用鏈長需要一個成熟的運維團隊(機制)來管理大量需要頻繁部署的服務。
3.4 微服務全生命周期管理
微服務開發生命周期有:創建、編碼、編譯、構建、部署、測試、驗收、發布、刪除。
微服務運維生命周期有:部署/啟動、日志/監控、告警、診斷、治理/配置、擴容、縮容、回滾、停止/卸載。
3.5 微服務的價值
微服務的價值主要有以下三點:上線更快、運行更穩、成本更經濟。
業務上線:年>月>周>隨時上線
系統SLA:3個9>4個9>5個9>永不斷服
資深成本:細粒度按需伸縮
3.6 最高性能、開放開源微服務解決方案
華為微服務產品包含一套微服務開發框架、一站式微服務監控與治理平臺以及一系列配套的微服務開發工具,主要功能如下:
基于契約(Open API)的開發模式:讓微服務的開發、測試、文檔、協作和管控活動標準化、自動化
高性能REST/RPC微服務開發框架:打包了微服務注冊、發現、通信和治理等基礎能力,開箱即用
一站式微服務治理控制臺:提供微服務負載均衡、限流、降級、熔斷、容錯、錯誤注入等治理能力
非侵入式微服務:提供Mesher服務,可實現多語言微服務解決方案,以及遺留系統零改造微服務化
多樣化微服務安全管控能力:提供認證鑒權、黑白名單等能力保障微服務訪問安全
灰度發布支持業務平滑升級:支持使用接口任意參數(例如用戶群組、用戶類別、用戶所屬區域等等)定義微服務灰度發布規則
微服務調用追蹤:提供微服務實例和接口級吞吐量、時延和成功率的實時監控及調用鏈分析
3.7 華為云微服務,來自華為全面云化轉型成功經驗
華為全面云化轉型成功經驗主要來源于三個方面:易用、開放、企業級。
3.8 典型場景一-以契約為中心的微服務開發模式
以契約為中心的微服務開發模式的特點:
設計人員通過OpenAPI或者Native APl的方式設計接口。可以通過Native APl生成Open APl,轉換是雙向的
使用“代碼生成”工具,輸入Open APl,生成NativeAPl。Native API可以有多種形式,一種是給開發人員實現的接口;一種是給測試人員實現的測試接口
使用“文檔生成”工具,輸入Open APl,生成PDF或者Word文檔
管理人員/用戶等使用文檔對產品進行宣傳、備案或者接受第三方審計
開發人員根據Native API實現業務邏輯
測試人員根據Native API實現測試邏輯
實施人員根據Open APl,錄入接口網關,配置接口的流控、計費、開發策略等
開發和運維人員基于Open API定義微服務健康運行的參數,統稱為服務治理
運維人員基于OpenAP|觀察接口的監控狀態,并通過配置管理平臺,對具體接口進行限流、降級等
3.9 典型場景二-微服務持續交付流水線
微服務持續交付流水線有:開發->自驗->集成驗證->開發->上線
3.10 典型場景三-微服務治理
微服務治理分為主要有四方面:自動負載均衡、自動容錯、服務降級、服務限流
3.11 典型場景四-調用鏈跟蹤和監控
調用鏈跟蹤的優點主要有:
1、低侵入性
監控系統應盡可能減少對業務系統的侵入,保持對使用方的透明性,減少開發人員的負擔,降低接入門檻和難度。
2、低性能影響
由于全鏈路監控系統需要對各種應用中間件進行日志數據采集,大多都需要在業務系統內進行“埋點”或放置agent,一般都是在核心業務流程。
因此應盡可能降低對業務系統造成的性能影響,一般來說,對CPU的耗用低于2%可以作為一個參考閾值。
3、靈活全面的接入策略
為了盡可能降低接入成本,應該提供靈活的監控配置策略,讓業務方決定是否接入,以及收集數據的范圍和粒度,并提供對應的技術方案保障監控策略生效。
4、時效性
實時有效的監控數據展示功能,幫助相關人員理解系統行為,為流程、架構、代碼優化,以及擴容縮容、服務限流降級提供正確客觀的數據參考。
3.12 ServiceComb首個Apache微服務頂級項目
ServiceComb致力于幫助企業、用戶和開發者將企業應用輕松微服務化上云,并實現對微服務應用的高效運維管理。其提供一站式開源微服務解決方案,融合SDK框架級、0侵入ServiceMesh場景并支持多語言。
ServiceComb的基本原則有:中立、開放、標準化、無商業Lock-in、社區健康發展
4.應用架構演進之立體運維
4.1 云上運維目標與挑戰
隨著企業應用的逐步上云可以享受到標準化的服務,高效、省錢、省力、安全。但對于一些有特殊要求的應用場景,還需要相關體系進一步完善。
上云后就不是傳統的監、管、控的運維,面對更復雜的運維環境,需要解決以下問題。
1、實現統一運維。
上云后面臨的相對復雜的環境,不是傳統意義上的單個機房或者一個IDC,而是一個多云的環境,私有云、公有云,還有虛擬化平臺和未來的容器平臺等,不同的平臺有不同的邏輯,需要用不同的技能進行運維,導致對運維人員技術要求比較高。打破不同平臺之間的差異,用同一種方式對所有平臺進行運維。
2、打破運維隔離。
平臺的對象監控,要避免運維孤島,有助于用戶對基礎監控的全面把控。
3、規避手工運維。
傳統運維過程中存在非常多手工運維的操作,這會導致效率問題和安全問題。頻繁地登錄服務器去做一些命令操作,也存在安全隱患。平臺代替人工去做此類重復勞動,避免人為的重復勞動和過多的登錄服務器。
4、持續更新知識庫。
知識庫問題更新,故障解決方法。運維人員知識固化,個人依賴性強,干貨包的分享,降低人員依賴,保證故障妥善解決。
4.2 AOP/APM架構簡介
APM(Application Performance Management)即應用性能管理(應用性能監控)。
APM主要是針對企業 關鍵業務的IT應用性能和用戶體驗的監測、優化,提高企業IT應用的可靠性和質量。旨在確保最終用戶獲得高質量的體驗,降低IT總擁有成本(TCO)。
TCO(Total Cost of Ownership),即總擁有成本,包括產品采購到后期使用、維護的成本。這是一種公司經常采用的技術評價標準。
4.3 資源、應用、業務一站式監控與分析
通過集群與虛機、虛機與應用、應用與資源統一建模,將集群、虛機、網絡、磁盤、數據庫、應用、容器及業務等上百種指標監控起來,并提供各種指標智能關聯分析,運維人員通過統一的告警入口即可下鉆找到問題根因。
4.4 AOM應用 & 資源關聯分析
應用、服務、實例、資源相關聯,可以直接查看到異常影響范圍。針對應用異常,可以直接查看其指標,通過指標找到原因。針對資源異常,可以查看其資源對象拓撲圖及告警情況等信息來定位原因。
4.5 AOM海量日志管理
將虛機上的應用、開源組件、系統等日志集中采集起來,通過清洗、實時分析、智能聚類等處理,實現了日志的高性能搜索和業務分析。同時,支持自定義采集路徑、實時刷新、上下文查看、秒級搜索、日志下載、轉儲等常用功能,滿足日常所需。
4.6 APM全鏈路監控-覆蓋從端側到數據中心全鏈路
調用鏈跟蹤、記錄業務的調用過程,還原業務請求在分布式系統中的執行軌跡和狀態,可以分鐘識別異常原因。在業務方法被調用時,可自動捕獲該方法的調用者、詳細的堆棧以及各類參數,幫助開發人員快速鎖定問題現場。
4.7 APM應用拓補
應用拓撲是對應用間調用關系和依賴關系的可視化展示,包括應用狀態、時延、錯誤、負載、依賴關系等指標,支持數據庫、緩存、消息中間件、NOSQL等各類開源組件的情況。同時可以按照時間、服務、事務、top等維度進行篩選查看。在應用拓撲中,針對異常也可直接下鉆查看調用關系,定位異常根因。
4.8 APM事務監控
從運營視角,了解每個業務的運行狀況,包括交易次數、時延、錯誤率,并通過調用鏈找到異常代碼,同時可以幫助運營人員了解活動期間的交易體驗情況。
總結
隨著互聯網、數據時代的不斷發展,企業的發展越發趨向于智慧化經營,以信息化數字化賦能產業發展,實現企業數字化轉型。云技術也在不斷的更新技術創新,為企業提供著更為專業的計算、存儲、數據庫等綜合服務,為各行業的實現數字化轉型提供“云”支持。華為云強大可靠的運維能力將助力互聯網企業上云無憂,更能抓住5G紅利,搶先擁抱數字化和智能化時代。
本文主要講述了:
企業核心業務未來架構演進路線以及基于華為云的應用架構方案
華為云應用服務在云基礎設施之上提供覆蓋端、邊、云全棧的云原生應用使能平臺,為企業數字化轉型和智能化升級提供系統的解決方案
本文整理自華為云社區【內容共創】活動第14期。
查看活動詳情:https://bbs.huaweicloud.com/blogs/336904
相關任務詳情:任務16.企業核心業務未來架構演進路線及華為云方案
上云必讀 運維 微服務
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。