分布式服务追踪与调用链系统
如何構建新一代SkyWalking服務追蹤框架
1.生產環境調用接口報錯了，如何定位？
2.微服務服務追蹤框架構設計原理
3.Sleuth+zipkin實現分布式服務追蹤
4.SkyWalking超強大實現分布式服務追蹤
5.SkyWalking架構設計原理
產生的背景
在微服務系統中，隨著業務的發展，系統會變得越來越大，那么各個服務之間的調用關系也就變得越來越復雜。一個 HTTP 請求會調用多個不同的微服務來處理返回最后的結果，在這個調用過程中，可能會因為某個服務出現網絡延遲過高或發送錯誤導致請求失敗，這個時候，對請求調用的監控就顯得尤為重要了。Spring Cloud Sleuth 提供了分布式服務鏈路監控的解決方案。下面介紹 Spring Cloud Sleuth 整合 Zipkin 的解決方案。
服務追蹤常用框架
Sleuth簡單的介紹
Sleuth 每一次RPC遠程調用請求都會生成一個spanid記錄每一次rpc請求的信息，還有一個traceid 全局唯一id；
實現原理：
1.開始方調用接口的時候會生成一個全局的id ，traceid 放入到請求中；
2.每次調用rpc接口的時候會產生一個新的spanid，放入到請求中；
Sleuth可以結合Zipkin可以實現界面化的形式管理我們接口依賴信息。
Trace：類似于樹結構的Span集合，表示一條調用鏈路，存在唯一標識通過traceId（全局的跟蹤ID，是跟蹤的入口點，根據需求來決定在哪生成traceId）、spanI（請求跟蹤ID，比如一次rpc等）和parentId（上一次 請求跟蹤ID，用來將前后的請求串聯起來），被收集到的span會匯聚成一個tree，從而提供出一個request的整體流程。
Sleuth+Zipkin整合
ZipkinServer環境搭建
在 Spring Boot 2.0 版本之后，官方已不推薦自己搭建定制了，而是直接提供了編譯好的 jar 包。詳情可以查看官網：https://zipkin.io/pages/quickstart.html
注意：zipkin官網已經提供定制了，使用官方jar運行即可。
默認端口號啟動zipkin服務
java –jar zipkin.jar 默認端口號; 9411
http://127.0.0.1:9411
指定端口號啟動9411
java -jar zipkin.jar --server.port=8080
http://192.168.18.220:8080
ZipkinClient集成
Maven依賴
org.springframework.cloud
spring-cloud-starter-zipkin
org.springframework.cloud
spring-cloud-starter-sleuth
application.yml
spring:
application:
name: app-itmayiedu-member
zipkin:
base-url: http://192.168.18.220:9411/
###全部采集
sleuth:
sampler:
probability: 1.0
效果演示
http://127.0.0.1:9411/zipkin/?serviceName=all&spanName=all&lookback=3600000&startTs=1614853090850&endTs=1614856690850&annotationQuery=&minDuration=&limit=10&sortOrder=timestamp-desc
分析樣板采集json
1.訂單調用會員服務—
訂單服務
traceId=cc7ce1a30cc00c1a
Spanid=cc7ce1a30cc00c1a
會員服務
traceId=cc7ce1a30cc00c1a
Spanid=23be15d0026ae6a3
parentId=cc7ce1a30cc00c1a
會員服務調用SMS服務—
SMS服務
traceId=cc7ce1a30cc00c1a
Spanid=e5a6b88e90a8c9a3
parentId=23be15d0026ae6a3
Seata、lcn
Skywalking
skywalking基本介紹
SkyWalking是一個開源的觀測平臺，用于從服務和云原生等基礎設施中收集、分析、聚合以及可視化數據，SkyWalking 提供了一種簡便的方式來清晰地觀測分布式系統，甚至可以觀測橫跨不同云的系統，SkyWalking 更像是一種現代的應用程序性能監控（Application Performance Monitoring，即APM）工具，專為云原生，基于容器以及分布式系統而設計。
Aop
前置通知
業務方法—
后置通知
2.平臺后端：是一個支持集群模式運行的后臺，用于數據聚合、數據分析以及驅動數據流從探針到用戶界面的流程。平臺后端還提供了各種可插拔的能力，如不同來源數據（如來自 Zipkin）格式化，不同存儲系統以及集群管理。你甚至還可以使用觀測分析語言來進行自定義聚合分析。
3.存儲：是開放式的，可以選擇一個既有的存儲系統，如 ElasticSearch、H2 或 MySQL 集群（Sharding-Sphere 管理），也可以選擇自己實現一個存儲系統。
用戶界面：也就是SkyWalking的可視化界面，UI非常炫酷且強大，同樣它也是可定制以匹配你已存在的后端的
4.SkyWalking 為觀察和監控分布式系統提供了許多不同場景下的解決方案。例如為Java、C#及Node.js提供語言自動探針，無侵入式的收集。同時也為一些編譯型語言C++、GO等提供了手動打點 SDK（目前還未支持）。除此之外，還可以使用服務網格基礎探針來收集數據，以幫助了解整個分布式系統。
5.在SkyWalking中也存在服務、服務實例及端點概念，因為SkyWalking就是提供了這些概念的觀測能力：
6.服務（Service）：表示對請求提供相同行為的一系列或一組工作負載。在使用打點代理或 SDK 的時候，你可以定義服務的名字。如果不定義的話，SkyWalking 將會使用你在平臺上定義的名字，如 Istio。
7.服務實例（Service Instance）：上述的一組工作負載中的每一個工作負載稱為一個實例。就像 Kubernetes 中的 pods 一樣，服務實例未必就是操作系統上的一個進程。但當你在使用打點代理的時候， 一個服務實例實際就是操作系統上的一個真實進程。
端點（Endpoint）：對于特定服務所接收的請求路徑，如 HTTP 的 URI 路徑和 gRPC 服務的類名 + 方法簽名
綜上，SkyWalking 優勢如下：
8.多種監控手段，語言探針和服務網格（Service Mesh）
模塊化，UI、存儲、集群管理多種機制可選
支持告警
優秀的可視化方案：
http://skywalking.apache.org/
skywalking架構原理
在整個skywalking的系統中，有四個角色：
1.skywalking agent和業務系統關聯在一起，負責收集各種監控數據；
2.oapservice是負責處理監控數據的，比如接受skywalking agent的監控數據，并存儲在數據庫中（例如elasticsearch、mysql中等）;接受skywalking webapp的前端請求，從數據庫查詢數據，并返回數據給前端。，Skywalking oapservice通常以集群的形式存在；
3.skywalking webapp，前端界面，用于展示數據；
4.用于存儲監控數據的數據庫，比如mysql、elasticsearch等；
skywalking 環境安裝
對springboot實現監控
agent\config\agent.config 修改應用的名稱
agent.service_name=${SW_AGENT_NAME:mayiktAppDemo}
I5處理器 第10代
I7處理器 第11代
I7處理器 第8代
Skywalking RPC監控
Skywalking(6.5.0) 支持的Rpc框架有以下幾種：
Dubbo 2.5.4 -> 2.6.0
Dubbox 2.8.4
Apache Dubbo 2.7.0
Motan 0.2.x -> 1.1.0
gRPC 1.x
Feign客戶端
獲取追蹤的id
Java代碼：
@RequestMapping("/member")
public String orderToMember() {
// 獲取request對象
HttpServletRequest request = ((ServletRequestAttributes)
RequestContextHolder.getRequestAttributes()).getRequest();
getHeders(request);
// 獲取traceId
String traceId = TraceContext.traceId();
log.info(">>traceId:{}<<", traceId);
return “我是會員服務:” + traceId;
}
Maven依賴：
org.apache.skywalking apm-toolkit-trace 6.5.0過濾指定的端點
Endpoint過濾即url忽略，有時可能希望忽略部分特殊 URL 的追蹤，例如說，健康檢查的 HTTP API及其他我們不需要關注的url如/eureka/**,/consul/**等等。為此SkyWalking 提供 trace-ignore-plugin 插件，可以實現忽略部分 URL 的追蹤
步驟流程：
agent文件夾下plugins目錄
拷貝： plugins 目錄。
從新啟動命令：
F:\code\13719795\apache-skywalking-apm-bin\agent>java -javaagent:F:\code\13719795\apache-skywalking-apm-bin\agent\skywalking-agent.jar -Dskywalking.trace.ignore_path=/mayikt/api/* -jar F:\code\13719795\apache-skywalking-apm-bin\agent\mayikt-thymeleaf-1.0-SNAPSHOT.jar
啟動加上：-Dskywalking.trace.ignore_path=/mayikt/api/*
告警系統
基本的概念
SkyWalking 告警功能
SkyWalking 告警功能是在6.x版本新增的，其核心由一組規則驅動，這些規則定義在config/alarm-settings.yml文件中
SkyWalking 的發行版都會默認提供config/alarm-settings.yml文件，里面預先定義了一些常用的告警規則。如下：
1.過去3分鐘內服務平均響應時間超過1秒
2.服務成功率在過去2分鐘內低于80%
3.服務90%響應時間在過去3分鐘內低于1000毫秒
4.服務實例在過去2分鐘內的平均響應時間超過1秒
5.端點平均響應時間過去2分鐘超過1秒
接受數據的格式
[{
“scopeId”: 1,
“scope”: “SERVICE”,
“name”: “serviceA”,
“id0”: 12,
“id1”: 0,
“ruleName”: “service_resp_time_rule”,
“alarmMessage”: “alarmMessage xxxx”,
“startTime”: 1560524171000
}, {
“scopeId”: 1,
“scope”: “SERVICE”,
“name”: “serviceB”,
“id0”: 23,
“id1”: 0,
“ruleName”: “service_resp_time_rule”,
“alarmMessage”: “alarmMessage yyy”,
“startTime”: 1560524171000
}]
scopeId、scope：所有可用的 Scope 詳見
org.apache.skywalking.oap.server.core.source.DefaultScopeDefine
name：目標 Scope 的實體名稱
id0：Scope 實體的 ID
id1：保留字段，目前暫未使用
ruleName：告警規則名稱
alarmMessage：告警消息內容
startTime：告警時間，格式為時間戳
編寫告警系統接口
import com.mayikt.entity.AlarmMessageDto;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;
import java.util.ArrayList;
import java.util.List;
/**
-
報警接口
*/
@RestController
public class PoliceService {
private List<List> listAlarmMessage = new ArrayList<>();/**
- 存放告警信息
- @param alarmMessageList
*/
@RequestMapping(value = “/police”, method = RequestMethod.POST)
public void alarm(@RequestBody List alarmMessageList) {
listAlarmMessage.add(alarmMessageList);
}
/**
- 打印告警信息
- @return
*/
@RequestMapping("/getListAlarmMessageDto")
public List<List> getListAlarmMessageDto() {
return listAlarmMessage;
}
}
相關核心配置
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
“License”); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Sample alarm rules.
rules:
Rule unique name, must be ended with _rule.
service_resp_time_rule:
metrics-name: service_resp_time
op: “>”
threshold: 1000
period: 10
count: 3
silence-period: 5
message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.
service_sla_rule:
# Metrics value need to be long, double or int
metrics-name: service_sla
op: “<”
threshold: 8000
# The length of time to evaluate the metrics
period: 10
# How many times after the metrics match the condition, will trigger alarm
count: 2
# How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.
silence-period: 3
message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes
service_p90_sla_rule:
# Metrics value need to be long, double or int
metrics-name: service_p90
op: “>”
threshold: 1000
period: 10
count: 3
silence-period: 5
message: 90% response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes
service_instance_resp_time_rule:
metrics-name: service_instance_resp_time
op: “>”
threshold: 1000
period: 10
count: 2
silence-period: 5
message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes
Active endpoint related metrics alarm will cost more memory than service and service instance metrics alarm.
Because the number of endpoint is much more than service and instance.
endpoint_avg_rule:
metrics-name: endpoint_avg
op: “>”
threshold: 1000
period: 10
count: 2
silence-period: 5
message: Response time of endpoint {name} is more than 1000ms in 2 minutes of last 10 minutes
webhooks:
- http://127.0.0.1/notify/
- http://127.0.0.1:10002/police
數據的持久化
es環境安裝
docker run --name elasticsearch -p 9200:9200 -p 9300:9300 -e “discovery.type=single-node” -d elasticsearch:7.4.1
啟動skywalking
Config/application.yml
修改es配置連接為自定義即可。
總結
以上是生活随笔為你收集整理的分布式服务追踪与调用链系统的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java转义符
- 下一篇： 什么是分布式系统中的幂等性