链路追踪需为请求分配唯一Trace ID并跨服务传递，Workerman因长连接特性需通过自定义协议或上下文管理传递ID，可选用SkyWalking等现成库或手动实现，结合采样与异步上报降低性能影响。
链路追踪，简单来说，就是搞清楚一个请求在你的分布式系统里都经历了哪些服务，每个服务花了多少时间。对于 Workerman 这种常驻内存的服务来说，链路追踪稍微有点不一样，因为连接通常是长连接，请求不是传统的 HTTP 请求那种“来一下就走”，所以需要一些特殊的处理。
链路追踪的关键在于给每个请求分配一个唯一的 ID，然后在服务之间传递这个 ID。这样，你就可以把所有相关的日志、指标关联起来，形成一条完整的链路。
解决方案
Workerman 本身并没有内置链路追踪的功能，但你可以通过一些库或者自己实现来完成。这里提供几种思路：
使用现成的链路追踪库： 比如 SkyWalking、Jaeger、Zipkin 等。这些库通常提供了 SDK，你只需要在你的 Workerman 应用里集成这些 SDK，然后配置好追踪服务器就可以了。
-
手动实现： 如果不想引入额外的依赖，也可以手动实现一个简单的链路追踪。
- 生成 Trace ID： 每次收到请求时，生成一个全局唯一的 Trace ID。
- 传递 Trace ID： 在你的服务内部，或者与其他服务交互时，把这个 Trace ID 传递下去。可以通过自定义协议、HTTP Header 等方式传递。
- 记录 Span： 在每个关键步骤，记录一个 Span。Span 包含 Trace ID、Span ID、开始时间、结束时间、服务名称、操作名称等信息。
- 上报数据： 把收集到的 Span 数据上报到追踪服务器。
利用日志系统： 如果你使用了 ELK Stack 或者其他日志系统，可以把 Trace ID 打印到日志里，然后通过日志系统来分析链路。
举个例子，假设你的 Workerman 应用需要调用另一个 HTTP 服务：
use Workerman\Worker;
use Workerman\Connection\TcpConnection;
use GuzzleHttp\Client;
require_once __DIR__ . '/vendor/autoload.php';
$worker = new Worker('tcp://0.0.0.0:2345');
$worker->onMessage = function(TcpConnection $connection, $data) {
$traceId = uniqid(); // 生成 Trace ID
$client = new Client();
$promise = $client->getAsync('http://another-service/api', [
'headers' => [
'X-Trace-Id' => $traceId, // 通过 HTTP Header 传递 Trace ID
]
]);
$promise->then(
function ($response) use ($connection, $traceId) {
// 记录 Span，这里可以记录请求的开始时间和结束时间
$startTime = microtime(true);
$body = $response->getBody();
$endTime = microtime(true);
// 假设你有一个日志服务，可以上报 Span 数据
logSpan([
'traceId' => $traceId,
'spanId' => uniqid(),
'serviceName' => 'workerman-service',
'operationName' => 'call-another-service',
'startTime' => $startTime,
'endTime' => $endTime,
]);
$connection->send('Response from another service: ' . $body);
},
function ($e) use ($connection, $traceId) {
// 记录错误 Span
logSpan([
'traceId' => $traceId,
'spanId' => uniqid(),
'serviceName' => 'workerman-service',
'operationName' => 'call-another-service',
'error' => $e->getMessage(),
]);
$connection->send('Error: ' . $e->getMessage());
}
);
};
$worker->runAll();
function logSpan(array $span) {
// 这里实现上报 Span 数据的逻辑，比如发送到 Kafka、Redis 等
// 实际情况会更复杂，需要考虑序列化、批量发送等问题
error_log(json_encode($span)); // 简单地打印到 error log
}如何选择合适的链路追踪方案？
选择链路追踪方案，需要考虑以下几个因素：
- 性能开销： 链路追踪会增加额外的计算和网络开销，需要选择性能开销小的方案。
- 易用性： SDK 是否易于集成，配置是否简单。
- 可扩展性： 是否支持大规模的分布式系统。
- 社区支持： 社区是否活跃，是否有完善的文档和示例。
- 与现有系统的集成： 是否能与你现有的日志系统、监控系统集成。
如果你的系统规模不大，可以选择手动实现一个简单的链路追踪。如果系统规模较大，建议使用现成的链路追踪库，比如 SkyWalking 或者 Jaeger。
Workerman 长连接场景下，如何处理 Trace ID 的传递？
Workerman 的长连接场景下，每次请求不一定是 HTTP 请求，所以不能简单地通过 HTTP Header 传递 Trace ID。
可以考虑以下几种方式：
- 自定义协议： 在你的自定义协议里，增加一个字段来传递 Trace ID。
- 上下文管理： 使用一个全局的上下文管理器，在每次处理请求时，把 Trace ID 放到上下文里。
- Thread Local Storage： 如果你的 Workerman 应用是多线程的，可以使用 Thread Local Storage 来存储 Trace ID。
需要注意的是，在使用上下文管理器或者 Thread Local Storage 时，要确保在协程切换或者线程切换时，正确地传递 Trace ID。否则，可能会导致链路追踪数据错乱。
如何避免链路追踪对性能的影响？
链路追踪会增加额外的计算和网络开销，所以需要采取一些措施来避免对性能的影响：
- 采样： 不是所有的请求都需要追踪，可以设置一个采样率，只追踪一部分请求。
- 异步上报： Span 数据不需要实时上报，可以先缓存在本地，然后异步批量上报。
- 减少 Span 的数量： 只记录关键步骤的 Span，避免记录过多的 Span。
- 优化数据结构： 使用高效的数据结构来存储 Span 数据。
- 使用轻量级的 SDK： 选择性能开销小的 SDK。
总而言之，Workerman 的链路追踪需要根据你的实际情况选择合适的方案。没有银弹，只有最合适的。
