Workerman怎么进行链路追踪？Workerman分布式追踪？-Workerman-PHP中文网

链路追踪需为请求分配唯一trace id并跨服务传递，workerman因长连接特性需通过自定义协议或上下文管理传递id，可选用skywalking等现成库或手动实现，结合采样与异步上报降低性能影响。

workerman怎么进行链路追踪？workerman分布式追踪？

链路追踪，简单来说，就是搞清楚一个请求在你的分布式系统里都经历了哪些服务，每个服务花了多少时间。对于 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 服务：

baidu-map-jsapi-three

使用 MapV-Three 构建专业的 3D 地图和 GIS 应用 - 基于 Z-up 坐标系的 3D 地图库，支持地图编辑、测量工具、要素绘制、数据管理等地理可视化功能。适用于创建地图编辑器、测量工具、空间数据可视化等 Web-GIS 应用。

下载

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。否则，可能会导致链路追踪数据错乱。