更新時間:2023-10-23 來源:黑馬程序員 瀏覽量:
自SpringCloud問世以來,微服務(wù)以席卷之勢風(fēng)靡全球,企業(yè)架構(gòu)都在從傳統(tǒng)SOA向微服務(wù)轉(zhuǎn)型。然而微服務(wù)這把雙刃劍在帶來各種優(yōu)勢的同時,也給運維、性能監(jiān)控、錯誤的排查帶來的極大的困難。
在大型項目中,服務(wù)架構(gòu)會包含數(shù)十乃至上百個服務(wù)節(jié)點。往往一次請求會設(shè)計到多個微服務(wù),想要排查一次請求鏈路中經(jīng)過了哪些節(jié)點,每個節(jié)點的執(zhí)行情況如何,就稱為了亟待解決的問題。于是分布式系統(tǒng)的APM管理系統(tǒng)應(yīng)運而生。
APM系統(tǒng)可以幫助理解系統(tǒng)行為、用于分析性能問題的工具,以便發(fā)生故障的時候,能夠快速定位和解決問題,這就是APM系統(tǒng),全稱是(Application Performance Monitor)。
谷歌公開的論文提到的 [Google Dapper](http://bigbully.github.io/Dapper-translation)可以說是最早的APM系統(tǒng)了,給google的開發(fā)者和運維團隊幫了大忙,所以谷歌公開論文分享了Dapper。
而后,很多的技術(shù)公司基于這篇論文的原理,設(shè)計開發(fā)了很多出色的APM框架,例如`Pinpoint`、`SkyWalking`等。
而SpringCloud官網(wǎng)也集成了一套這樣的系統(tǒng):`Spring Cloud Sleuth`,結(jié)合`Zipkin`。
目前大部分的APM系統(tǒng)都是基于Google的Dapper原理實現(xiàn),我們簡單來看看Dapper中的概念和實現(xiàn)原理。
先來看一次請求調(diào)用示例:
1. 服務(wù)集群中包括:前端(A),兩個中間層(B和C),以及兩個后端(D和E)
2. 當(dāng)用戶發(fā)起一個請求時,首先到達前端A服務(wù),然后A分別對B服務(wù)和C服務(wù)進行RPC調(diào)用;
3. B服務(wù)處理完給A做出響應(yīng),但是C服務(wù)還需要和后端的D服務(wù)和E服務(wù)交互之后再返還給A服務(wù),最后由A服務(wù)來響應(yīng)用戶的請求;
如何才能實現(xiàn)跟蹤呢?
Google的Dapper設(shè)計了下面的幾個概念用來記錄請求鏈路:
- Span:請求中的基本工作單元,每一次鏈路調(diào)用(RPC、Rest、數(shù)據(jù)庫調(diào)用)都會創(chuàng)建一個Span。大概結(jié)構(gòu)如下:
type Span struct { TraceID int64 // 用于標(biāo)示一次完整的請求id Name string // 單元名稱 ID int64 // 當(dāng)前這次調(diào)用span_id ParentID int64 // 上層服務(wù)的span_id,最上層服務(wù)parent_id為null,代表根服務(wù) Annotation []Annotation // 注釋,用于記錄調(diào)用中的詳細信息,例如時間 }
- Trace:一次完整的調(diào)用鏈路,包含多個Span的樹狀結(jié)構(gòu),具有唯一的TraceID
一次請求的每個鏈路,通過spanId、parentId就能串聯(lián)起來:
當(dāng)然,從請求到服務(wù)器開始,服務(wù)器返回response結(jié)束,每個span存在相同的唯一標(biāo)識trace_id。
APM的篩選標(biāo)準(zhǔn)
目前主流的APM框架都會包含下列幾個組件來完成鏈路信息的收集和展示:
- 探針(Agent):負責(zé)在客戶端程序運行時搜索服務(wù)調(diào)用鏈路信息,發(fā)送給收集器
- 收集器(Collector):負責(zé)將數(shù)據(jù)格式化,保存到存儲器
- 存儲器(Storage):保存數(shù)據(jù)
- UI界面(WebUI):統(tǒng)計并展示收集到的信息
因此,要篩選一款合格的APM框架,就是對比各個組件的使用差異,主要對比項:
- 探針的性能
主要是agent對服務(wù)的吞吐量、CPU和內(nèi)存的影響。如果探針在收集微服務(wù)運行數(shù)據(jù)時,對微服務(wù)的運行產(chǎn)生了比較大的性能影響,相信沒什么人愿意使用。
- collector的可擴展性
能夠水平擴展以便支持大規(guī)模服務(wù)器集群,保證收集器的高可用特性。
- 全面的調(diào)用鏈路數(shù)據(jù)分析
數(shù)據(jù)的分析要快,分析的維度盡可能多。跟蹤系統(tǒng)能提供足夠快的信息反饋,就可以對生產(chǎn)環(huán)境下的異常狀況做出快速反應(yīng),最好提供代碼級別的可見性以便輕松定位失敗點和瓶頸。
- 對于開發(fā)透明,容易開關(guān)
即也作為業(yè)務(wù)組件,應(yīng)當(dāng)盡可能少入侵或者無入侵其他業(yè)務(wù)系統(tǒng),對于使用方透明,減少開發(fā)人員的負擔(dān)。
- 完整的調(diào)用鏈應(yīng)用拓撲
自動檢測應(yīng)用拓撲,幫助你搞清楚應(yīng)用的架構(gòu)
接下來,我們就對比下目前比較常見的三種APM框架的各項指標(biāo),分別是:
- [Zipkin](https://link.juejin.im/?target=http%3A%2F%2Fzipkin.io%2F):由Twitter公司開源,開放源代碼分布式的跟蹤系統(tǒng),用于收集服務(wù)的定時數(shù)據(jù),以解決微服務(wù)架構(gòu)中的延遲問題,包括:數(shù)據(jù)的收集、存儲、查找和展現(xiàn)。
- [Pinpoint](https://pinpoint.com/):一款對Java編寫的大規(guī)模分布式系統(tǒng)的APM工具,由韓國人開源的分布式跟蹤組件。
- [Skywalking](https://skywalking.apache.org/zh/):國產(chǎn)的優(yōu)秀APM組件,是一個對JAVA分布式應(yīng)用程序集群的業(yè)務(wù)運行情況進行追蹤、告警和分析的系統(tǒng)。現(xiàn)在是Apache的頂級項目之一。
三者對比如下:
| 對比項 | zipkin | pinpoint | skywalking |
| ---------------- | ------ | -------- | ---------- |
| 探針性能 | 中 | 低 | 高 |
| collector擴展性 | 高 | 中 | 高 |
| 調(diào)用鏈路數(shù)據(jù)分析 | 低 | 高 | 中 |
| 對開發(fā)透明性 | 中 | 高 | 高 |
| 調(diào)用鏈應(yīng)用拓撲 | 中 | 高 | 中 |
| 社區(qū)支持 | 高 | 中 | 高 |
可見,zipkin的探針性能、開發(fā)透明性、數(shù)據(jù)分析能力都不占優(yōu),實在是下下之選。
而pinpoint在數(shù)據(jù)分析能力、開發(fā)透明性上有較大的優(yōu)勢,不過Pinpoint的部署相對比較復(fù)雜,需要的硬件資源較高。
Skywalking的探針性能和開發(fā)透明性上具有較大優(yōu)勢,數(shù)據(jù)分析能力上也還不錯,重要的是其部署比較方便靈活,比起Pinpoint更適合中小型企業(yè)使用。
Skywalking介紹
SkyWalking 創(chuàng)建與2015年,提供分布式追蹤功能。從5.x開始,項目進化為一個完成功能的Application Performance Management系統(tǒng)。
他被用于追蹤、監(jiān)控和診斷分布式系統(tǒng),特別是使用微服務(wù)架構(gòu),云原生或容積技術(shù)。提供以下主要功能:
- 分布式追蹤和上下文傳輸
- 應(yīng)用、實例、服務(wù)性能指標(biāo)分析
- 根源分析
- 應(yīng)用拓撲分析
- 應(yīng)用和服務(wù)依賴分析
- 慢服務(wù)檢測
- 性能優(yōu)化
官網(wǎng)地址:http://skywalking.apache.org/
主要的特征:
- 多語言探針或類庫
- Java自動探針,追蹤和監(jiān)控程序時,不需要修改源碼。
- 社區(qū)提供的其他多語言探針
- [.NET Core](https://github.com/OpenSkywalking/skywalking-netcore)
- [Node.js](https://github.com/OpenSkywalking/skywalking-nodejs)
- 多種后端存儲: ElasticSearch, H2
- 支持
OpenTracing
- Java自動探針支持和OpenTracing API協(xié)同工作
- 輕量級、完善功能的后端聚合和分析
- 現(xiàn)代化Web UI
- 日志集成
- 應(yīng)用、實例和服務(wù)的告警
Skywalking的安裝
先來看下Skywalking的官方給出的結(jié)構(gòu)圖:
大致分四個部分:
- skywalking-oap-server:就是Observability Analysis Platformd的服務(wù),用來收集和處理探針發(fā)來的數(shù)據(jù)
- skywalking-UI:就是skywalking提供的Web UI 服務(wù),圖形化方式展示服務(wù)鏈路、拓撲圖、trace、性能監(jiān)控等
- agent:探針,獲取服務(wù)調(diào)用的鏈路信息、性能信息,發(fā)送到skywalking的OAP服務(wù)
- Storage:存儲,一般選擇elasticsearch
Skywalking支持windows或者Linux環(huán)境部署。這里我們選擇在Linux下安裝Skywalking,大家要先確保自己的Linux環(huán)境中有elasticsearch在啟動中。
接下來的安裝分為三步:
- 下載安裝包
- 安裝Skywalking的OAP服務(wù)和WebUI
- 在服務(wù)中部署探針
下載安裝包
安裝包可以再Skywalking的官網(wǎng)下載,http://skywalking.apache.org/downloads/
目前最新版本是8.0.1版本:
下載好的安裝包:
安裝OAP服務(wù)和WebUI
安裝
將下載好的安裝包解壓到Linux的某個目錄下:
tar xvf apache-skywalking-apm-es7-8.0.1.tar.gz
然后對解壓好的文件夾重命名:
mv apache-skywalking-apm-es7 skywalking
進入解壓好的目錄:
cd skywalking
查看目錄結(jié)構(gòu):
幾個關(guān)鍵的目錄:
- agent:探針
- bin:啟動腳本
- config:配置文件
- logs:日志
- oap-libs:依賴
- webapp:WebUI
這里要修改config目錄中的application.yml文件,詳細配置見官網(wǎng):https://github.com/apache/skywalking/blob/v8.0.1/docs/en/setup/backend/backend-setup.md
配置
進入`config`目錄,修改`application.yml`,主要是把存儲方案從h2改為elasticsearch
可以直接使用下面的配置:
cluster: selector: ${SW_CLUSTER:standalone} standalone: core: selector: ${SW_CORE:default} default: role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator restHost: ${SW_CORE_REST_HOST:0.0.0.0} restPort: ${SW_CORE_REST_PORT:12800} restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/} gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0} gRPCPort: ${SW_CORE_GRPC_PORT:11800} gRPCSslEnabled: ${SW_CORE_GRPC_SSL_ENABLED:false} gRPCSslKeyPath: ${SW_CORE_GRPC_SSL_KEY_PATH:""} gRPCSslCertChainPath: ${SW_CORE_GRPC_SSL_CERT_CHAIN_PATH:""} gRPCSslTrustedCAPath: ${SW_CORE_GRPC_SSL_TRUSTED_CA_PATH:""} downsampling: - Hour - Day - Month # Set a timeout on metrics data. After the timeout has expired, the metrics data will automatically be deleted. enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close. dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day # Cache metric data for 1 minute to reduce database queries, and if the OAP cluster changes within that minute, # the metrics may not be accurate within that minute. enableDatabaseSession: ${SW_CORE_ENABLE_DATABASE_SESSION:true} topNReportPeriod: ${SW_CORE_TOPN_REPORT_PERIOD:10} # top_n record worker report cycle, unit is minute # Extra model column are the column defined by in the codes, These columns of model are not required logically in aggregation or further query, # and it will cause more load for memory, network of OAP and storage. # But, being activated, user could see the name in the storage entities, which make users easier to use 3rd party tool, such as Kibana->ES, to query the data by themselves. activeExtraModelColumns: ${SW_CORE_ACTIVE_EXTRA_MODEL_COLUMNS:false} # The max length of service + instance names should be less than 200 serviceNameMaxLength: ${SW_SERVICE_NAME_MAX_LENGTH:70} instanceNameMaxLength: ${SW_INSTANCE_NAME_MAX_LENGTH:70} # The max length of service + endpoint names should be less than 240 endpointNameMaxLength: ${SW_ENDPOINT_NAME_MAX_LENGTH:150} storage: selector: ${SW_STORAGE:elasticsearch7} elasticsearch7: nameSpace: ${SW_NAMESPACE:""} clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200} protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"} trustStorePath: ${SW_STORAGE_ES_SSL_JKS_PATH:""} trustStorePass: ${SW_STORAGE_ES_SSL_JKS_PASS:""} dayStep: ${SW_STORAGE_DAY_STEP:1} # Represent the number of days in the one minute/hour/day index. user: ${SW_ES_USER:""} password: ${SW_ES_PASSWORD:""} secretsManagementFile: ${SW_ES_SECRETS_MANAGEMENT_FILE:""} # Secrets management file in the properties format includes the username, password, which are managed by 3rd party tool. indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:1} # The index shards number is for store metrics data rather than basic segment record superDatasetIndexShardsFactor: ${SW_STORAGE_ES_SUPER_DATASET_INDEX_SHARDS_FACTOR:5} # Super data set has been defined in the codes, such as trace segments. This factor provides more shards for the super data set, shards number = indexShardsNumber * superDatasetIndexShardsFactor. Also, this factor effects Zipkin and Jaeger traces. indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0} # Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:1000} # Execute the bulk every 1000 requests flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10} # flush the bulk every 10 seconds whatever the number of requests concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2} # the number of concurrent requests resultWindowMaxSize: ${SW_STORAGE_ES_QUERY_MAX_WINDOW_SIZE:10000} metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:5000} segmentQueryMaxSize: ${SW_STORAGE_ES_QUERY_SEGMENT_SIZE:200} profileTaskQueryMaxSize: ${SW_STORAGE_ES_QUERY_PROFILE_TASK_SIZE:200} advanced: ${SW_STORAGE_ES_ADVANCED:""} h2: driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource} url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db} user: ${SW_STORAGE_H2_USER:sa} metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000} receiver-sharing-server: selector: ${SW_RECEIVER_SHARING_SERVER:default} default: authentication: ${SW_AUTHENTICATION:""} receiver-register: selector: ${SW_RECEIVER_REGISTER:default} default: receiver-trace: selector: ${SW_RECEIVER_TRACE:default} default: sampleRate: ${SW_TRACE_SAMPLE_RATE:10000} # The sample rate precision is 1/10000. 10000 means 100% sample in default. slowDBAccessThreshold: ${SW_SLOW_DB_THRESHOLD:default:200,mongodb:100} # The slow database access thresholds. Unit ms. receiver-jvm: selector: ${SW_RECEIVER_JVM:default} default: receiver-clr: selector: ${SW_RECEIVER_CLR:default} default: receiver-profile: selector: ${SW_RECEIVER_PROFILE:default} default: service-mesh: selector: ${SW_SERVICE_MESH:default} default: istio-telemetry: selector: ${SW_ISTIO_TELEMETRY:default} default: envoy-metric: selector: ${SW_ENVOY_METRIC:default} default: acceptMetricsService: ${SW_ENVOY_METRIC_SERVICE:true} alsHTTPAnalysis: ${SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS:""} prometheus-fetcher: selector: ${SW_PROMETHEUS_FETCHER:default} default: active: ${SW_PROMETHEUS_FETCHER_ACTIVE:false} receiver_zipkin: selector: ${SW_RECEIVER_ZIPKIN:-} default: host: ${SW_RECEIVER_ZIPKIN_HOST:0.0.0.0} port: ${SW_RECEIVER_ZIPKIN_PORT:9411} contextPath: ${SW_RECEIVER_ZIPKIN_CONTEXT_PATH:/} receiver_jaeger: selector: ${SW_RECEIVER_JAEGER:-} default: gRPCHost: ${SW_RECEIVER_JAEGER_HOST:0.0.0.0} gRPCPort: ${SW_RECEIVER_JAEGER_PORT:14250} query: selector: ${SW_QUERY:graphql} graphql: path: ${SW_QUERY_GRAPHQL_PATH:/graphql} alarm: selector: ${SW_ALARM:default} default: telemetry: selector: ${SW_TELEMETRY:none} none: prometheus: host: ${SW_TELEMETRY_PROMETHEUS_HOST:0.0.0.0} port: ${SW_TELEMETRY_PROMETHEUS_PORT:1234} configuration: selector: ${SW_CONFIGURATION:none} none: grpc: host: ${SW_DCS_SERVER_HOST:""} port: ${SW_DCS_SERVER_PORT:80} clusterName: ${SW_DCS_CLUSTER_NAME:SkyWalking} period: ${SW_DCS_PERIOD:20} apollo: apolloMeta: ${SW_CONFIG_APOLLO:http://106.12.25.204:8080} apolloCluster: ${SW_CONFIG_APOLLO_CLUSTER:default} apolloEnv: ${SW_CONFIG_APOLLO_ENV:""} appId: ${SW_CONFIG_APOLLO_APP_ID:skywalking} period: ${SW_CONFIG_APOLLO_PERIOD:5} zookeeper: period: ${SW_CONFIG_ZK_PERIOD:60} # Unit seconds, sync period. Default fetch every 60 seconds. nameSpace: ${SW_CONFIG_ZK_NAMESPACE:/default} hostPort: ${SW_CONFIG_ZK_HOST_PORT:localhost:2181} # Retry Policy baseSleepTimeMs: ${SW_CONFIG_ZK_BASE_SLEEP_TIME_MS:1000} # initial amount of time to wait between retries maxRetries: ${SW_CONFIG_ZK_MAX_RETRIES:3} # max number of times to retry etcd: period: ${SW_CONFIG_ETCD_PERIOD:60} # Unit seconds, sync period. Default fetch every 60 seconds. group: ${SW_CONFIG_ETCD_GROUP:skywalking} serverAddr: ${SW_CONFIG_ETCD_SERVER_ADDR:localhost:2379} clusterName: ${SW_CONFIG_ETCD_CLUSTER_NAME:default} consul: # Consul host and ports, separated by comma, e.g. 1.2.3.4:8500,2.3.4.5:8500 hostAndPorts: ${SW_CONFIG_CONSUL_HOST_AND_PORTS:1.2.3.4:8500} # Sync period in seconds. Defaults to 60 seconds. period: ${SW_CONFIG_CONSUL_PERIOD:1} # Consul aclToken aclToken: ${SW_CONFIG_CONSUL_ACL_TOKEN:""} exporter: selector: ${SW_EXPORTER:-} grpc: targetHost: ${SW_EXPORTER_GRPC_HOST:127.0.0.1} targetPort: ${SW_EXPORTER_GRPC_PORT:9870}
啟動
要確保已經(jīng)啟動了elasticsearch,并且防火墻開放8080、11800、12800端口。
進入`bin`目錄,執(zhí)行命令即可運行:
./startup.sh
默認的UI端口是8080,可以訪問:http://192.168.150.101:8080
部署微服務(wù)探針
現(xiàn)在,Skywalking的服務(wù)端已經(jīng)啟動完成,我們還需要在微服務(wù)中加入服務(wù)探針,來收集數(shù)據(jù)。
解壓
首先,將課前資料給的壓縮包解壓
將其中的`agent`解壓到某個目錄,不要出現(xiàn)中文,可以看到其結(jié)構(gòu)如下:
其中有一個`skywalking-agent.jar`就是一我們要用的探針。
配置
如果是運行一個jar包,可以在運行時輸入?yún)?shù)來指定探針:
java -jar xxx.jar -javaagent:C:/lesson/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name=ly-registry -Dskywalking.collector.backend_service=192.168.150.101:11800
本例中,我們用開發(fā)工具來運行和配置。
使用IDEA開發(fā)工具打開一個你的項目,在IDEA工具中,選擇要修改的啟動項,點擊右鍵,選擇`Edit Configuration`:
然后在彈出的窗口中,點擊`Environment`,選擇`VM options`后面對應(yīng)的展開按鈕
在展開的輸入框中,輸入下面的配置:
-javaagent:C:/lesson/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name=ly-registry -Dskywalking.collector.backend_service=192.168.150.101:11800
注意:
- `-javaagent:C:/lesson/skywalking-agent/skywalking-agent.jar`:配置的是skywalking-agent.jar這個包的位置,要修改成你自己存放的目錄
- `-Dskywalking.agent.service_name=ly-registry`:是當(dāng)前項目的名稱,需要分別修改為`ly-registry`、`ly-gateway`、`ly-item-service`
- `-Dskywalking.collector.backend_service=192.168.150.101:11800`:是Skywalking的OPA服務(wù)地址,采用的是GRPC通信,因此端口是11800,不是8080
啟動
Skywalking的探針會在項目啟動前對class文件進行修改,完成探針植入,對業(yè)務(wù)代碼零侵入,所以我們只需要啟動項目,即可生效了。
啟動項目,然后對項目中的的業(yè)務(wù)接口訪問,探針就開始工作了。
WebUI界面
訪問:http://192.168.150.101:8080可以看到統(tǒng)計數(shù)據(jù)已經(jīng)出來了:
服務(wù)實例的性能監(jiān)控:
服務(wù)拓撲圖:
某次請求的鏈路追蹤信息:
表格視圖:
本文版權(quán)歸黑馬程序員Java培訓(xùn)學(xué)院所有,歡迎轉(zhuǎn)載,轉(zhuǎn)載請注明作者出處。謝謝!
作者:黑馬程序員Java培訓(xùn)學(xué)院
首發(fā):https://java.itheima.com