Daph源码位于gitee，地址是
https://gitee.com/dasea96/daph

概述

Daph的中文名称是大副，大副是职位仅低于船长的船舶驾驶员，甲板部（驾驶部）负责人，船长的主要助手。
Daph的英文名称，取自【有向无环图Directed Acyclic Graph】的第一个字母与最后三个字母。

Daph是一个通用的数据集成与数据处理平台级工具，可用于构建可视化配置化的数据集成与数据处理平台。

Daph，大道至简。
Daph的核心概念是节点，节点具有输入线与输出线，每条线中承载数据，节点承载任意数据处理逻辑。
Daph的核心构件是一个自创的通用DAG数据流引擎，可以流转任意Java/Scala数据结构，可以引入任何基于Java平台或具有Java客户端的数据计算组件作为数据流底层数据计算引擎。
Daph的核心功能是联接多个节点构成DAG图，并流转数据。

功能

• 全量增量整库整表数据集成
  ：以极简配置方式，完成全量增量整库整表数据集成
  
  • 已支持50多种数据源类型的全量整表同步
  • 已支持Flink-cdc所支持的所有数据源类型的cdc整表同步
  • 已支持mysql/postgresql/oracle/sqlserver/doris/starrocks到mysql/postgresql/oracle/sqlserver/doris/starrocks/hive/iceberg/kafka的全量增量整库同步
• 流批一体复杂数据处理
  ：以极简配置方式，完成流批一体任意复杂多表sql处理逻辑

价值

• 统一数据开发视图
  ：Daph既具有丰富的数据集成能力，又具有强大的数据处理能力
• 降低数据开发门槛
  ：通过配置文件，完成数据开发
• 缩短数据开发周期
  ：开箱即用的海量数据集成与数据处理能力，极简的安装部署方式，极简的二次开发过程

特点

• 通用
  ：可连接任意JVM类型的节点，构成DAG图，并流转任意Java/Scala数据结构。因此，不仅目前能够用于构建DAG数据流，而且具有潜在的任意粒度的DAG任务调度的潜力，可基于一个daph-core，统一任务开发与任务调度，实现一体化的可视化任务开发与任务调度平台。
• 简单
  ：概念简单，配置简单
  
  • 基于开源计算引擎，不引入新的复杂概念
  • 节点配置简单，比如daph-spark节点配置项，与Spark配置项几乎完全一致，不增加学习开销。
• 强大
  ：架构强大，功能强大
  
  • 架构层面具有多层环绕运行体系，可定制任意Job级/DAG级/节点级/方法级功能，比如节点数据预览功能、节点监控功能、前置后置SQL功能。目前所有节点均已支持前置后置建表功能，daph-spark所有节点已支持前置后置SQL功能
  • daph-spark仅有5个连接器、6个转换器，却已支持44种数据源的流批读写，且能随时扩充更多数据源；已支持对单表的map、filter、sql处理，对多表的join及任意复杂sql处理；且支持spark能支持的任何catalog
  • daph-flink仅有2个连接器、1个转换器，却已支持任何flink-sql支持的数据源的流批读写；已支持对单表与多表的任意复杂sql处理；且支持flink能支持的任何catalog。
• 聚焦
  ：聚焦于可视化配置化的数据集成与数据处理，聚焦于简化开源计算引擎的使用，不增加学习开销。
• 流转任意数据结构
  ：可流转任意JVM数据结构，比如Java/Scala List、Spark DataFrame、Flink DataStream。
• 支持多种计算引擎
  ：可引入任何基于Java平台或具有Java客户端的数据计算组件作为数据流底层数据计算引擎，比如Java/Scala/Spark/Flink，等等。
• 快速扩展节点
  ：可方便地扩展与部署具有任意逻辑的节点，比如扩展新的连接器节点，以支持读写新的数据库类型；比如扩展新的转换器节点，以便引入特定数据处理逻辑处理数据。只需要完成以下三点，即可完成：
  1）实现一个配置接口与一个功能接口
  2）将扩展的节点对应的jar放在服务器目录
  3）json文件中配置扩展节点信息

对比业界类似软件

Daph：

1. 既能用于数据集成，又能用于复杂的数据处理
2. 极致通用的DAG模型，能够流转任意JVM对象，引入任意符合Spark/Flink编程模型的计算引擎
3. 不重复造轮子，专注于简化开源计算引擎的使用，配置项几乎与开源计算引擎一一对应
4. 完美运用开源计算引擎的各项能力，包括且不限于流批处理能力、catalog能力、sql能力
5. 能够及时从开源计算引擎的生态系统中获益
   
   • 比如Spark，一旦新出现一种数据库连接器，在Daph中只需要在pom.xml中添加依赖，就能立刻使用

架构模型

数据流模型

Daph的数据流模型是DAG数据流模型，如下图所示：

例如一个数据集成与数据处理综合场景，如下图所示：

• 输入是一张MySQL表、一张Hive表，一张Oracle表
• 处理逻辑包含map、join、sql、自定义复杂逻辑
• 输出是一个Hudi表、一个Doris表、一个HBase表

运行模型

Daph通过节点包裹代码片段，将节点连成一个DAG图，并最终将DAG图形成一个完整的应用程序。

• 一个DAG图就是一个完整运行逻辑，比如当使用Spark作为底层计算引擎，一个DAG图就是一个完整的Spark应用程序。
• 一个DAG图中可以同时包含Java节点、Scala节点、Spark节点，也可以同时包含Java节点、Scala节点、Flink节点，但不能同时包含Spark与Flink节点。
• 底层计算引擎决定了应用程序的类型。
  JVM引擎对应的就是原生Java/Scala应用程序；
  Spark引擎对应的就是Spark应用程序；
  Flink引擎对应的就是Flink应用程序。

Daph运行模型如下图所示：

部署模型

Daph目前的部署模型非常简单，

• daph-jvm，就是部署原生java程序
• daph-spark，就是部署spark应用程序
• daph-flink，就是部署flink应用程序

PyInstaller会在打包时自动为我们收集一些依赖项，特别是我们在打包PyQt/PySide相关的应用时，PyInstaller会自动包含我们程序通常不需要的文件，如'tanslations'文件夹，'plugins/imageformats'等，通常这些文件会使我们最终的exe文件变大。在网上没有找任何好的方法来排除这些文件，从这个Issue
https://github.com/pyinstaller/pyinstaller/issues/5503
里我们可以看到一种方法就是在打包之前先删除PyQt安装目录中的不需要文件，这种做法能达到目的，但在我看来实在是不够优雅。

PyInstaller其实最终都依靠spec文件来获取依赖及其它配置项，而生成spec文件内容是由一个模板(
https://github.com/pyinstaller/pyinstaller/blob/develop/PyInstaller/building/templates.py
)控制, 所以我们可以在生成之前去修改(patch)下这个模板，就可以达到控制依赖项的目的。

以下假设我们是通过代码方式来调用Pyinstaller，并使用onefile模式(onedir模块可参照修改).

注意以下
Analysis
语句后面的代码即为处理datas和binaries的代码，在这里可以添加任何过滤逻辑

import PyInsatller.building.templates as pyi_spec_templates
from PyInstaller.__main__ import run as pyi_build

# copy from PyInsatller.building.templates.py
# add datas and binaries filter after Analysis
onefiletmplate = """# -*- mode: python ; coding: utf-8 -*-
%(preamble)s

a = Analysis(
    %(scripts)s,
    pathex=%(pathex)s,
    binaries=%(binaries)s,
    datas=%(datas)s,
    hiddenimports=%(hiddenimports)s,
    hookspath=%(hookspath)r,
    hooksconfig={},
    runtime_hooks=%(runtime_hooks)r,
    excludes=%(excludes)s,
    noarchive=%(noarchive)s,
    optimize=%(optimize)r,
)

# begin filter any datas you want
datas = []
for dest_name, src_name, res_type in a.datas:
    # 在这里添加过滤逻辑
    datas.append((dest_name, src_name, res_type))
a.datas = datas
# end filter datas

# begin filter any binaries you want
binaries = []
for dest_name, src_name, res_type in a.binaries:
    # 在这里添加过滤逻辑
    binaries.append((dest_name, src_name, res_type))
a.binaries = binaries
# end filter datas

pyz = PYZ(a.pure)
%(splash_init)s
exe = EXE(
    pyz,
    a.scripts,
    a.binaries,
    a.datas,%(splash_target)s%(splash_binaries)s
    %(options)s,
    name='%(name)s',
    debug=%(debug_bootloader)s,
    bootloader_ignore_signals=%(bootloader_ignore_signals)s,
    strip=%(strip)s,
    upx=%(upx)s,
    upx_exclude=%(upx_exclude)s,
    runtime_tmpdir=%(runtime_tmpdir)r,
    console=%(console)s,
    disable_windowed_traceback=%(disable_windowed_traceback)s,
    argv_emulation=%(argv_emulation)r,
    target_arch=%(target_arch)r,
    codesign_identity=%(codesign_identity)r,
    entitlements_file=%(entitlements_file)r,%(exe_options)s
)
"""

pyi_spec_templates.onefiletmplt = onefiletmplate  # ==> patch the template string here

# build exe
pyi_build(['main.py', '--onefile', ...])

一：背景

1. 讲故事

前些天有位朋友在微信上联系到我，说他们的程序在客户那边崩掉了，让我帮忙看下怎么回事，dump也拿到了，那就上手分析吧。

二：WinDbg 分析

1. 哪里的崩溃

既然是程序的崩溃，自然是有原因的，皮裤套棉裤，必定有缘故，不是皮裤太薄就是棉裤没毛，用
!analyze -v
观察下异常信息。

0:107> !analyze -v

CONTEXT:  (.ecxr)
rax=0000005e0dc7c4a0 rbx=0000005e0dc7c400 rcx=0000005e0dc7c4a0
rdx=0000000000000000 rsi=0000005e0dc7c3f0 rdi=0000005e0dc7c4a0
rip=00007ffb1ecfc223 rsp=0000005e0dc7c3c0 rbp=0000005e0dc7c4c0
 r8=00000000000004d0  r9=0000000000000000 r10=0000000000000000
r11=0000005e0dc7c4a0 r12=0000000000000000 r13=000002079d450220
r14=000002079b93aba0 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000200
coreclr!EEPolicy::HandleFatalError+0x7f:
00007ffb`1ecfc223 488d442440      lea     rax,[rsp+40h]
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ffb1ec6d70f (coreclr!ProcessCLRException+0x00000000000d9f7f)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000001
NumberParameters: 0

从卦中信息看这是一个经典的
访问违例
，但崩溃在
EEPolicy::HandleFatalError
处就有点匪夷所思了，HandleFatalError 方法主要是用来在抛异常之前修整异常上下文的，这个方法固若金汤，一般不会出问题的，但不管怎么样，还是看下
rsp+40h
到底是什么东西。

0:107> dp rsp+40h L1
0000005e`0dc7c400  00000001`c0000005

上面的
c0000005
很显然是访问违例，看样子这里有点混乱，也不是第一崩溃现场，这里就不过多纠结了，那怎么去找真正的崩溃点呢？还有一个方法就是去找
RaiseException
或者
KiUserExceptionDispatch
返回点之前的有用函数，参考如下：

0:107> .ecxr
0:107> k
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr               Call Site
00 0000005e`0dc7c3c0 00007ffb`1ec6d72e     coreclr!EEPolicy::HandleFatalError+0x7f [D:\a\_work\1\s\src\coreclr\vm\eepolicy.cpp @ 776] 
01 0000005e`0dc7c9d0 00007ffb`5235292f     coreclr!ProcessCLRException+0xd9f9e [D:\a\_work\1\s\src\coreclr\vm\exceptionhandling.cpp @ 1036] 
02 0000005e`0dc7cc00 00007ffb`52302554     ntdll!RtlpExecuteHandlerForException+0xf
03 0000005e`0dc7cc30 00007ffb`5235143e     ntdll!RtlDispatchException+0x244
04 0000005e`0dc7d340 00000000`6c942893     ntdll!KiUserExceptionDispatch+0x2e
05 0000005e`0dc7daf0 00007ffa`c066ed7b     libxxx_manage!get_clean_xxx
06 0000005e`0dc7db70 00007ffa`c06b73a4     0x00007ffa`c066ed7b
...

从卦中看，程序崩溃在
libxxx_manage!get_clean_xxx
中，看样子是一个 C++ 写的动态链接库，这就有点无语了。。。

2. C++ 库为什么会崩

要想寻找答案，最好的办法就是观察
000000006c942893
处的汇编代码，参考如下：

0:107> ub 00000000`6c942893
libxxx_manage!get_clean_xxx:
00000000`6c942876 55              push    rbp
00000000`6c942877 53              push    rbx
00000000`6c942878 4883ec68        sub     rsp,68h
00000000`6c94287c 488dac2480000000 lea     rbp,[rsp+80h]
00000000`6c942884 48894d00        mov     qword ptr [rbp],rcx
00000000`6c942888 c745dc00000000  mov     dword ptr [rbp-24h],0
00000000`6c94288f 488b4500        mov     rax,qword ptr [rbp]

0:107> u 00000000`6c942893
00000000`6c942893 488b00          mov     rax,qword ptr [rax]

0:107> dp rbp L1
0000005e`0dc7c4c0  00000000`00000000

从上面的汇编代码来看，这是 get_clean_xxx 方法的序幕代码，问题出在 rbp 的内容为0上，但 rbp 又来自于 rcx，根据 x64调用协定，rcx 即方法的第一个参数，看样子是这个参数为 null 导致的，参考如下：

0:107> !address rcx

Usage:                  Stack
Base Address:           0000005e`0dc78000
End Address:            0000005e`0dc80000
Region Size:            00000000`00008000 (  32.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000004          PAGE_READWRITE
Type:                   00020000          MEM_PRIVATE
Allocation Base:        0000005e`0db00000
Allocation Protect:     00000004          PAGE_READWRITE
More info:              ~107k

0:107> dp rcx L1
0000005e`0dc7c4a0  00000000`00000000

3. get_clean_xxx 参数为null吗

这个问题比较简单，继续用
!clrstack
观察下 Pinvoke 之上的 C# 代码。

0:107> !clrstack
OS Thread Id: 0x3508 (107)
        Child SP               IP Call Site
0000005E0DC7DBA0 00007ffac066ed7b [InlinedCallFrame: 0000005e0dc7dba0] xxx_LibPInvoke.xxx_clean_query(IntPtr)
0000005E0DC7DB70 00007ffac066ed7b ILStubClass.IL_STUB_PInvoke(IntPtr)
0000005E0DC7DC30 00007ffac06b73a4 xx+c__DisplayClass11_0.<xxxQueryClean>b__0(IntPtr)
...

接下来就是看下托管层的 C# 代码是如何写的，截图如下：

从图中可以清楚的看到，xxxChannel 传给C++ 的时候没有判断是否为null，导致崩溃的发生，那还有没有其他的佐证呢？其实也是有的，如果符号给力还可以使用
!clrstack -a
去找到
xxxChannel
传下去的值。

0:107> !clrstack -a
OS Thread Id: 0x3508 (107)
        Child SP               IP Call Site
0000005E0DC7DBA0 00007ffac066ed7b [InlinedCallFrame: 0000005e0dc7dba0] xxx_LibPInvoke.xxx_clean_query(IntPtr)
0000005E0DC7DB70 00007ffac066ed7b ILStubClass.IL_STUB_PInvoke(IntPtr)
    PARAMETERS:
        <no data>

0000005E0DC7DC30 00007ffac06b73a4 xxx+c__DisplayClass11_0.<xxxQueryClean>b__0(IntPtr)
    PARAMETERS:
        this (0x0000005E0DC7DC80) = 0x0000020a9d9ca8d8
        xxxChannel (0x0000005E0DC7DC88) = 0x0000000000000000
    LOCALS:
        0x0000005E0DC7DC6C = 0x0000000000000000
        0x0000005E0DC7DC68 = 0x0000000000000000

可以清楚的看到确实是 0，到这里就一切真相大白，对参数加一个判断即可，那这东西到底是谁的责任呢？我觉得双方都有问题吧。

1. 写托管层的人有点飘。
2. 写非托管层的人未作防御性编程，还是年轻太相信人了。

三：总结

这次生产事故彻底破坏了两个语言团队之间的相互合作的信任度，信任重建可就难了，不怕神一样的对手，就怕猪猪一样的队友，放在这里还是挺合适的，哈哈，开个小玩笑。

大屏Windows设置网卡开启热点后，经常收到反馈，手机端无法搜索到大屏热点、或者手机连接大屏热点失败

这类问题一般有以下几类情况：

1. 物理网卡IP与热点网卡IP相同

2. 热点网卡IP，非正常热点IP（192.168.137.X）

热点IP我们一般定为192.168.137.X，192.168.137.X是一个保留的IPv4地址范围。其中，X代表了特定设备在局域网中的唯一标识，通常是1到254之间的一个数字。

这个地址范围通常被用作局域网内部的私有IP地址，如Wi-Fi热点或者一些家庭网络

设置此私有IP地址范围为热点IP，可以避免与现有网络冲突。同时比较有特征的IP段可以让用户将局域网内的设备划分到特定的子网中，有利于管理和监控设备的连接和通信

针对上面2类情况，修复热点IP，

1. 物理网卡IP与热点网卡IP相同

-- 在物理网卡设置了某个热点IP如192.168.137.1时，热点网卡IP需要规避此IP。如果局域网中已经有DHCP服务器在分配IP地址，而热点设备也在尝试分配IP地址，可能会引起IP地址分配冲突，导致网络连接问题。虽然不建议物理网卡分配此IP，但出现问题我们貌似只能通过热点虚拟网卡来规避此冲突了

2. 热点网卡IP，非热点IP（192.168.137.X）

-- 热点为私有网络，建议用热点专有IP域，可以减少与局域网正常分配IP之间的冲突。

以下是修复代码，团队内部开发的网卡一部分业务逻辑：

1     /// <summary>
2     ///修复IP冲突3     /// </summary>
4     public asyncTask RepairIpConflictAsync()5 {6         var allNetworks = awaitGetAllNetworkInfosAsync();7         //获取到当前虚拟网卡
8         var virtualAdapter = allNetworks.FirstOrDefault(x => x.IPEnabled &&
9 x.Description.Contains(VirtualWifiDescription));10 
11         if (virtualAdapter == null) return;12         //实际网卡是否使用了热点IP
13         var physicalCardErrorIps = new List<string>();14         foreach (var x in allNetworks.Where(x => !x.Description.Contains(VirtualWifiDescription)))15 {16             physicalCardErrorIps.AddRange(x.Ipv4Array.Where(ip => ip.StartsWith("192.168.137.")));17 }18         var isVirtualCardCorrectIp = virtualAdapter.Ipv4Array.FirstOrDefault(x => x.StartsWith("192.168.137.")) != null;19         //物理网卡未使用热点IP，且虚拟网卡在使用热点IP,不需要修复IP
20         if (physicalCardErrorIps.Count == 0 &&isVirtualCardCorrectIp)21 {22             return;23 }24         var defaultHotspotIp = "192.168.137.1";25         if (physicalCardErrorIps.Count > 0)26 {27             for (var i = 1; i < 255; i++)28 {29                 var ip = $"192.168.137.{i}";30                 if (physicalCardErrorIps.Contains(ip)) continue;31                 defaultHotspotIp =ip;32                 break;33 }34 }35         var networkAdapter = newNetworkAdapterController(virtualAdapter.SettingID);36         networkAdapter.SetIPAddress(defaultHotspotIp, "255.255.255.0");37     }

先获取当前虚拟网卡"Microsoft Wi-Fi Direct Virtual Adapter"，virtual adapter一般会有多张，选择IPEnabled=true的那张(在网络适配器上绑定并启用 TCP/IP)。

物理网卡可能存在使用热点IP，所以接下来获取所有使用热点IP的IP列表，用于后续给热点网卡规避这些IP。

虚拟网卡是否采用热点IP，未采用的话也需要重新设置下。

所以，根据网卡ID标识，设置此虚拟网卡为192.168.137.X范围的热点IP、以及默认掩码"255.255.255.0"。同时跳过物理网卡已经使用的热点IP，规避IP冲突

1、Chaos Mesh 介绍

Chaos Mesh
是一个开源的混沌工程平台，旨在帮助用户在生产环境中测试、验证和优化其应用程序的可靠性和稳定性。通过引入故障注入和混沌工程原则，Chaos Mesh可以模拟各种故障场景，如网络延迟、节点故障、磁盘故障等，以帮助用户发现和解决系统中的潜在问题。

项目地址：

https://gitee.com/mirrors/Chaos-Mesh
https://github.com/pingcap/chaos-mesh

2、Chaos Mesh 特性：

1. 多样化的故障注入：
   Chaos Mesh支持多种故障注入方式，包括网络故障、节点故障、磁盘故障等，用户可以根据需求选择合适的故障注入方式进行测试。

2. 精细化的故障控制：
   用户可以通过Chaos Mesh提供的控制台对故障注入进行精细化配置，包括故障类型、注入时间、注入范围等，以便更好地模拟实际生产环境中的故障情况。

3. 可观测性和监控：
   Chaos Mesh提供了丰富的监控和可观测性功能，用户可以实时监控故障注入的效果，了解系统的稳定性和可靠性情况。

4. 容器化支持：
   Chaos Mesh可以与Kubernetes等容器化平台集成，支持在容器环境中进行混沌工程实验，帮助用户更好地了解容器化应用的稳定性和可靠性。

5. 灵活的调度策略：
   用户可以根据自己的需求定义故障注入的调度策略，包括定时触发、周期性触发等，以便更好地控制故障注入的时机和频率。

总的来说，Chaos Mesh是一个强大的混沌工程平台，可以帮助用户在生产环境中进行系统稳定性测试和故障模拟，从而提高系统的可靠性和稳定性。

3、Chaos Mesh 安装步骤

1、下载 Chaos Mesh： 可以从 Chaos Mesh 的 GitHub 仓库中获取最新版本的安装文件。
2、部署 Chaos Mesh： 可以使用 Helm 进行部署，执行以下命令：

helm repo add chaos-mesh https://charts.chaos-mesh.org
helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-testing --version=0.12.0

3、验证部署： 等待部署完成后，可以通过以下命令验证 Chaos Mesh 是否成功部署：

kubectl get pods -n chaos-testing

当前实验可支持用于故障注入的主要操作有：

• pod-kill：模拟 Kubernetes Pod 被 kill。
• pod-failure：模拟 Kubernetes Pod 持续不可用，可以用来模拟节点宕机不可用场景。
• network-delay：模拟网络延迟。
• network-loss：模拟网络丢包。
• network-duplication：模拟网络包重复。
• network-corrupt：模拟网络包损坏。
• network-partition：模拟网络分区。
• I/O delay：模拟文件系统 I/O 延迟。
• I/Oerrno：模拟文件系统 I/O 错误 。

4、Chaos Mesh 使用步骤

1、
创建故障注入实验
： 使用 Chaos Mesh 控制台或命令行工具创建故障注入实验，选择故障类型、目标应用程序、注入时间等参数。

比如：
创建网络延迟实验
： 使用
Chaos Mesh CLI
创建一个网络延迟实验，指定目标应用程序和需要模拟的网络延迟参数。可以使用以下命令创建一个网络延迟实验：

chaosctl create network-delay --time 30s --target myapp --duration 60s

• --time 参数指定延迟时间，这里设置为 30 秒。
• --target 参数指定目标应用程序，这里设置为 myapp。
• --duration 参数指定实验持续时间，这里设置为 60 秒。

2、
运行实验
： 使用 Chaos Mesh CLI 启动创建的网络延迟实验，实时观察目标应用程序在网络延迟情况下的表现。可以使用以下命令运行实验：

chaosctl start network-delay --name my-network-delay

3、
监控和观察
： 可以使用
Chaos Mesh
提供的监控和可观测性功能，实时监控网络延迟实验的效果，了解系统的稳定性和可靠性情况。

4、
分析结果
： 分析实验运行期间收集的数据和日志，评估系统的表现，并根据需要进行调整和优化。

5、
调整实验参数
： 根据实验结果和反馈，调整故障注入实验的参数，如故障类型、注入时间、注入范围等，以便更好地模拟真实生产环境中的故障情况。

6、
结束实验
： 在实验持续时间结束后，可以使用以下命令结束实验：

chaosctl stop my-network-delay

通过以上步骤，您可以安装和使用 Chaos Mesh 进行混沌工程实验，帮助提高系统的可靠性和稳定性。请确保在生产环境中谨慎使用混沌工程工具，以避免对系统造成不必要的影响。