基于OpenTelemetry构建企业级可观测性：从设计到生产实践

1. 项目概述：从“黑盒”到“白盒”的工程实践

在分布式系统、微服务架构乃至复杂的单体应用开发中，我们常常面临一个共同的困境：系统内部的状态如同一个“黑盒”。当线上服务出现响应缓慢、内存泄漏或偶发性错误时，传统的日志（Logging）和指标（Metrics）往往只能告诉我们“哪里出了问题”的表象，却难以清晰地揭示“问题是如何一步步发生的”这一完整链路。尤其是在处理异步任务、并发请求或跨多个服务组件的复杂交互时，定位根因的难度呈指数级上升。这正是可观测性（Observability）要解决的核心问题，而“fkern4612-design/openclaw-telemetry”这个项目，从其命名上就直指了可观测性体系中的一个关键支柱——遥测（Telemetry）。

“OpenClaw Telemetry”这个名字本身就充满了工程隐喻。“OpenClaw”可以理解为“开放的爪子”，象征着一种能够深入系统内部、抓取并暴露关键信息的工具或能力；“Telemetry”则是遥测学，指从远程或难以直接访问的地点收集数据并传输到接收端进行处理的技术。结合起来，这个项目很可能是一个旨在为复杂软件系统（特别是像“OpenClaw”这样的可能代号项目）构建一套开放、可扩展的遥测数据采集、处理与导出框架。它关注的不是简单的日志打印，而是结构化的、包含丰富上下文（如TraceID、SpanID、Baggage）的追踪（Tracing）数据，以及与之紧密关联的高基数指标和事件。

对于一名开发者或SRE工程师而言，引入这样一套遥测系统，意味着能将系统的运行时行为从“黑盒”变为“白盒”。你不仅能知道一个API接口的总体耗时（指标），还能清晰地看到一个用户请求从进入网关、经过认证服务、查询数据库、调用缓存、再到返回响应的完整调用链（追踪），每一个环节的耗时、状态、甚至传递的业务参数（通过适当的采样和脱敏）都一目了然。这极大地提升了故障排查、性能优化和系统理解的效率。接下来，我将从设计思路、核心实现、实操集成到问题排查，完整拆解构建这样一套遥测体系需要关注的所有细节。

2. 核心设计思路与架构选型

构建一个遥测系统，绝非简单地引入一个开源库然后打点调用那么简单。它需要从全局视角进行设计，确保数据的完整性、低开销、可扩展性，并且与现有技术栈无缝融合。“OpenClaw Telemetry”的设计思路，必然围绕着以下几个核心原则展开。

2.1 遵循开放标准：拥抱OpenTelemetry

当前，遥测领域的事实标准是OpenTelemetry。它由CNCF孵化，旨在提供一套与供应商无关的、统一的API、SDK和工具集，用于生成、收集、处理遥测数据（追踪、指标、日志）。选择基于OpenTelemetry（OTel）构建“OpenClaw Telemetry”是几乎唯一正确的技术决策。

为什么是OpenTelemetry？

1. 厂商中立：OTel定义了数据模型和采集协议，你可以将数据发送到任何支持OTel的后端，如Jaeger、Zipkin、Prometheus、时序数据库或各大云厂商的监控服务，避免了供应商锁定。
2. 语言无关：它提供了Go、Java、Python、JavaScript等主流语言的SDK实现，确保了跨技术栈遥测数据的一致性。
3. 生态融合：绝大多数现代框架（如Spring Boot、Gin、Express）、中间件（如gRPC、HTTP客户端、数据库驱动）和云服务都提供了原生的OTel集成或插件，集成成本极低。
4. 上下文传播：OTel的核心价值在于其强大的上下文传播能力。一个Trace（追踪）可以跨进程、跨服务、跨异步边界进行传递，将分散的日志和指标串联成一个有意义的业务故事。

因此，“OpenClaw Telemetry”很可能不是一个从零造轮子的项目，而是基于OTel标准，为“OpenClaw”这个特定业务或技术体系定制的集成层、配置封装和最佳实践套件。它可能包含了预配置的TracerProvider/MeterProvider、自动化的仪器（Instrumentation）注入、自定义的采样策略、以及适配内部基础设施的导出器（Exporter）。

2.2 数据采集策略：自动与手动仪器结合

遥测数据的采集主要通过“仪器化”来完成。OTel定义了两种主要仪器：用于追踪的Tracer和用于指标的Meter。采集策略上需要平衡自动化与灵活性。

自动化仪器（Auto-instrumentation）： 这是降低接入成本的关键。通过Java Agent、Python的opentelemetry-instrumentation包或JavaScript的库封装，可以无侵入或低侵入地自动为常见的HTTP服务器/客户端、数据库驱动、消息队列等生成追踪跨度（Span）和指标。例如，一个HTTP服务器在被自动仪器化后，每个请求会自动创建一个Span，记录方法、路径、状态码和耗时。

注意：自动仪器虽好，但可能产生大量高基数的Span（例如，每个不同的URL路径都会产生不同的Span），这会给后端存储和查询带来压力。通常需要配合采样策略和Span属性过滤来管理数据量。

手动仪器（Manual instrumentation）： 对于核心业务逻辑，自动化仪器无能为力。这时需要在关键的业务函数、复杂的算法块或重要的异步任务处手动创建Span。手动仪器的价值在于能为Span添加丰富的、具有业务语义的属性（Attributes）。例如，在一个处理订单的函数中，可以手动添加order.id、payment.method等属性，使得在排查问题时，可以直接通过订单号过滤出相关的追踪链路。

# 示例：Python手动创建业务Span from opentelemetry import trace tracer = trace.get_tracer(__name__) def process_order(order_id: str): with tracer.start_as_current_span("process_order") as span: # 添加业务属性 span.set_attribute("order.id", order_id) span.set_attribute("business.unit", "e-commerce") # ... 业务逻辑 try: validate_order(order_id) span.add_event("order_validated") # ... 更多逻辑 except Exception as e: # 记录异常事件和状态 span.record_exception(e) span.set_status(trace.Status(trace.StatusCode.ERROR, str(e))) raise

手动仪器是体现遥测系统业务价值的核心，它让技术数据与业务上下文产生了关联。

2.3 采样策略：在数据量与保真度间权衡

全量采集每一个请求的追踪数据在大型系统中是不现实的，会产生巨大的性能和存储开销。因此，采样（Sampling）是生产环境遥测系统设计的重中之重。

常见的采样策略：

1. 头部采样（Head-based Sampling）：在Trace的起点（通常是入口服务）做出采样决策，决策结果（采样或不采样）会随着Trace上下文传播到所有下游服务。这是最常用的策略。
   • 固定概率采样：例如，采样率设置为0.1（10%）。简单，但可能错过重要的低概率错误。
   • 基于父级的采样：如果一个Span被采样，那么它的所有子Span都会被采样。保证了链路完整性。
   • 速率限制采样：每秒最多采样N个Trace，保护后端不被冲垮。
   • 智能采样（如Tail-based Sampling）：这是一种更高级的“尾部采样”，它先缓存所有Trace的片段，在请求完成后根据规则（如是否包含错误、耗时是否超长）决定是否保留并导出整个Trace。这能确保所有“有趣”的请求（错误、慢请求）都被捕获，但实现复杂，需要额外的聚合服务。

“OpenClaw Telemetry”项目很可能会封装一个适合其业务特点的采样器。例如，对于核心交易链路采用较高的采样率（如30%），对于后台管理类请求采用较低的采样率（如1%）；或者结合速率限制，确保系统在高并发下遥测数据不会成为瓶颈。

2.4 后端选型与导出器配置

采集到的数据需要发送到后端进行分析和存储。OTel通过导出器（Exporter）来解耦采集与后端。

追踪后端：

• Jaeger：开源，UI直观，适合开发和中小规模生产环境。使用OTLP（OpenTelemetry Protocol）或Jaeger原生协议导出。
• Tempo (Grafana)：云原生，专注于大规模分布式追踪，与Prometheus和Loki集成良好，构成Grafana的可观测性栈。
• 云服务：如阿里云ARMS、腾讯云APM等，提供开箱即用的托管服务。

指标后端：

• Prometheus：事实上的标准。OTel指标可以通过Prometheus导出器暴露一个/metrics端点，由Prometheus拉取。
• 各类时序数据库：如InfluxDB、TimescaleDB。

“OpenClaw Telemetry”的配置核心之一，就是定义好这些导出器。它可能会提供一个统一的配置中心或环境变量，让不同的部署环境（开发、测试、生产）轻松切换后端目标。

# 示例配置片段 (概念性) opentelemetry: exporters: tracing: otlp: endpoint: "http://jaeger-collector:4317" # 开发环境 # endpoint: "${TEMPO_ENDPOINT}" # 生产环境 metrics: prometheus: port: 9464 sampling: probability: 0.2 # 20%采样率 rate_limit: 100 # 每秒最多100个trace

3. 核心组件实现与集成细节

理解了设计思路后，我们深入到“OpenClaw Telemetry”项目可能包含的核心组件实现层面。这里我们将以微服务架构下的Go和Java服务为例，拆解集成过程中的关键步骤和代码细节。

3.1 全局遥测组件的初始化与生命周期管理

一个健壮的遥测系统必须在应用启动时正确初始化，并在关闭时优雅地关闭，确保缓冲中的数据能被安全刷新。这通常通过一个单例或依赖注入容器来管理TracerProvider和MeterProvider。

Go语言实现示例：在Go中，我们通常在main.go或一个独立的telemetry包中完成初始化。

// telemetry/setup.go package telemetry import ( "context" "fmt" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc" "go.opentelemetry.io/otel/exporters/prometheus" "go.opentelemetry.io/otel/propagation" "go.opentelemetry.io/otel/sdk/metric" "go.opentelemetry.io/otel/sdk/resource" sdktrace "go.opentelemetry.io/otel/sdk/trace" semconv "go.opentelemetry.io/otel/semconv/v1.21.0" "google.golang.org/grpc" "log" ) func InitProvider(serviceName, collectorEndpoint string) (func(context.Context) error, error) { ctx := context.Background() // 1. 创建资源，标识服务本身 res, err := resource.New(ctx, resource.WithAttributes( semconv.ServiceName(serviceName), semconv.ServiceVersion("v1.0.0"), semconv.DeploymentEnvironment("production"), ), ) if err != nil { return nil, fmt.Errorf("failed to create resource: %w", err) } // 2. 初始化追踪导出器 (OTLP gRPC) traceExp, err := otlptracegrpc.New(ctx, otlptracegrpc.WithEndpoint(collectorEndpoint), otlptracegrpc.WithInsecure(), // 生产环境应使用TLS otlptracegrpc.WithDialOption(grpc.WithBlock()), ) if err != nil { return nil, fmt.Errorf("failed to create trace exporter: %w", err) } // 3. 配置采样器和追踪处理器 // 使用父级采样+概率采样组合 sampler := sdktrace.ParentBased(sdktrace.TraceIDRatioBased(0.2)) // 批量处理器优化性能 bsp := sdktrace.NewBatchSpanProcessor(traceExp) tracerProvider := sdktrace.NewTracerProvider( sdktrace.WithSampler(sampler), sdktrace.WithResource(res), sdktrace.WithSpanProcessor(bsp), ) otel.SetTracerProvider(tracerProvider) // 4. 设置传播器，确保Trace上下文能在服务间传递 prop := propagation.NewCompositeTextMapPropagator( propagation.TraceContext{}, propagation.Baggage{}, ) otel.SetTextMapPropagator(prop) // 5. 初始化指标导出器 (Prometheus) metricExp, err := prometheus.New() if err != nil { return nil, fmt.Errorf("failed to create metric exporter: %w", err) } meterProvider := metric.NewMeterProvider( metric.WithResource(res), metric.WithReader(metricExp), ) otel.SetMeterProvider(meterProvider) // 返回一个关闭函数，用于优雅关闭 shutdownFunc := func(ctx context.Context) error { if err := tracerProvider.Shutdown(ctx); err != nil { log.Printf("Error shutting down tracer provider: %v", err) } if err := meterProvider.Shutdown(ctx); err != nil { log.Printf("Error shutting down meter provider: %v", err) } return nil } return shutdownFunc, nil }

在main函数中调用InitProvider，并将返回的shutdownFunc注册到系统的优雅关闭逻辑中（如监听SIGTERM信号）。

实操心得：务必在服务关闭时调用Shutdown。否则，还在批量处理器缓冲区中的Span数据会丢失。对于像Kubernetes滚动更新这样的场景，优雅关闭至关重要。

3.2 自动化仪器与中间件集成

自动化仪器能极大减少手动打点的工作量。对于Web框架，通常通过中间件（Middleware）或拦截器（Interceptor）来实现。

Gin框架（Go）的自动化追踪中间件：虽然OTel有官方的gin中间件，但“OpenClaw Telemetry”可能会封装一个增强版本，自动添加一些业务相关的默认属性。

// telemetry/gin_middleware.go package telemetry import ( "github.com/gin-gonic/gin" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/attribute" "go.opentelemetry.io/otel/propagation" semconv "go.opentelemetry.io/otel/semconv/v1.21.0" "go.opentelemetry.io/otel/trace" ) func OpenClawGinMiddleware() gin.HandlerFunc { return func(c *gin.Context) { tracer := otel.Tracer("openclaw-http-server") prop := otel.GetTextMapPropagator() // 从HTTP头部提取Trace上下文 ctx := prop.Extract(c.Request.Context(), propagation.HeaderCarrier(c.Request.Header)) // 创建Span spanName := c.FullPath() if spanName == "" { spanName = c.Request.URL.Path // 防止未匹配路由时为空 } ctx, span := tracer.Start(ctx, spanName, trace.WithSpanKind(trace.SpanKindServer), trace.WithAttributes( semconv.HTTPMethod(c.Request.Method), semconv.HTTPRoute(spanName), semconv.HTTPURL(c.Request.URL.String()), // 自定义业务属性 attribute.String("http.client_ip", c.ClientIP()), attribute.String("http.user_agent", c.Request.UserAgent()), ), ) defer span.End() // 将新的上下文设置到Gin中，供后续处理链使用 c.Request = c.Request.WithContext(ctx) // 处理请求 c.Next() // 请求完成后，记录状态码 statusCode := c.Writer.Status() span.SetAttributes(semconv.HTTPStatusCode(statusCode)) if statusCode >= 400 { span.SetStatus(trace.StatusError, "HTTP Error") } } }

然后在路由中使用：

r := gin.Default() r.Use(telemetry.OpenClawGinMiddleware())

Spring Boot（Java）的自动化集成：在Java生态中，集成更为简单。通常只需添加依赖和配置。

1. 添加Maven依赖:

   <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-spring-boot-starter</artifactId> <version>${opentelemetry.version}</version> </dependency>

2. 配置application.yaml:

   spring: application: name: order-service management: tracing: sampling: probability: 0.2 otlp: tracing: endpoint: http://jaeger-collector:4317

Spring Boot会自动为Web请求、JPA操作、RestTemplate调用等添加追踪。但“OpenClaw Telemetry”项目可能会通过@Configuration类，定制一些全局的Span处理器或属性添加器。

3.3 自定义指标与业务监控

除了框架自动生成的指标（如HTTP请求数、耗时），业务指标（Business Metrics）对于洞察系统健康度和业务状态至关重要。例如，订单创建成功率、支付处理时长、购物车平均商品数等。

在Go中定义和记录业务指标：

// telemetry/business_metrics.go package telemetry import ( "context" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/metric" ) var ( meter = otel.Meter("openclaw.business") // 定义一个计数器，记录订单创建总数，并附带状态标签 orderCounter, _ = meter.Int64Counter( "orders.created.total", metric.WithDescription("Total number of orders created"), metric.WithUnit("1"), ) // 定义一个直方图，记录订单处理耗时 orderDuration, _ = meter.Float64Histogram( "orders.process.duration", metric.WithDescription("Duration of order processing"), metric.WithUnit("ms"), ) ) func RecordOrderCreated(ctx context.Context, status string, amount float64) { // 为计数器添加属性（标签） orderCounter.Add(ctx, 1, metric.WithAttributes( attribute.String("order.status", status), attribute.String("payment.currency", "CNY"), )) // 可以同时记录一个代表金额的指标（如果需要） } func RecordOrderProcessTime(ctx context.Context, durationMs float64, orderType string) { orderDuration.Record(ctx, durationMs, metric.WithAttributes( attribute.String("order.type", orderType), )) }

在业务代码中，只需在适当的位置调用RecordOrderCreated和RecordOrderProcessTime即可。

注意事项：指标标签（Attributes）的基数（Cardinality）必须严格控制。高基数（如使用用户ID、订单号做标签）会导致指标数量爆炸，严重拖慢监控系统。业务指标应使用低基数的、可聚合的维度，如状态、类型、地域等。

4. 部署、配置与数据流实践

将遥测组件集成到代码中只是第一步。要让整个系统在生产环境跑起来，还需要考虑部署架构、配置管理和数据流的可靠性。

4.1 部署架构模式

典型的可观测性数据流涉及三个角色：应用程序（Instrumented Application）、收集器（Collector）和后端（Backend）。

1. 直连模式（不推荐用于生产）：应用直接通过OTLP/gRPC或HTTP将数据发送到后端的接收端点（如Jaeger Collector）。简单，但将网络可靠性、数据缓冲、重试等责任交给了每个应用实例，且难以统一管理数据转换和过滤。

2. 通过OpenTelemetry Collector代理模式（推荐）：这是生产环境的最佳实践。每个计算节点（物理机、虚拟机、Pod）部署一个OTel Collector作为代理（Agent）。应用将数据发送到本地的Agent（如通过localhost:4317），由Agent负责数据的批量处理、重试、过滤、转换，再统一发送到后端的收集器或存储。

   • 优势：
     • 应用解耦：应用无需关心后端地址和网络问题。
     • 统一处理：可以在Agent层统一实施采样、数据过滤（如移除敏感信息）、格式转换。
     • 资源优化：Agent可以批量发送数据，减少网络连接数。
   • 部署：在Kubernetes中，通常以DaemonSet形式部署，确保每个Node上都有一个Agent Pod。

3. 通过OpenTelemetry Collector网关模式：在更复杂的架构中，可能还会有一个中心化的Collector**网关（Gateway）**集群，接收来自多个Agent的数据，进行进一步的聚合、路由（发送到不同的后端），再持久化存储。

“OpenClaw Telemetry”项目很可能会提供Collector的配置模板（otel-collector-config.yaml），针对其业务预设好处理器（Processors）和导出器（Exporters）。

一个简化的Collector配置示例：

# otel-collector-config.yaml receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: # 批量处理，优化性能 timeout: 1s send_batch_size: 8192 memory_limiter: # 内存限制器，防止OOM check_interval: 1s limit_mib: 400 spike_limit_mib: 100 # 可以添加过滤处理器，例如移除某些健康检查的Span filter: spans: exclude: match_type: strict attributes: - key: http.target value: /healthz exporters: debug: verbosity: detailed otlp/jaeger: endpoint: "jaeger-collector:4317" tls: insecure: true prometheus: endpoint: "0.0.0.0:9464" namespace: openclaw service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, batch, filter] exporters: [debug, otlp/jaeger] metrics: receivers: [otlp] processors: [memory_limiter, batch] exporters: [debug, prometheus]

4.2 环境差异化配置

不同环境（开发、测试、预发、生产）的遥测配置应有差异。

• 开发/测试环境：可能使用更高的采样率（如100%或50%）以便调试，数据可能导出到本地部署的Jaeger或甚至只是控制台（logging导出器）。
• 生产环境：使用较低的采样率，数据导出到高可用的后端集群（如Tempo或云服务）。采样策略可能更复杂（如智能采样）。

“OpenClaw Telemetry”可以通过环境变量、配置中心或Kubernetes ConfigMap来管理这些差异。例如：

# 应用启动参数或环境变量 export OTEL_SERVICE_NAME=user-service export OTEL_TRACES_SAMPLER=traceidratio export OTEL_TRACES_SAMPLER_ARG=0.1 # 10%采样率 export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector-agent:4317 export OTEL_METRICS_EXPORTER=otlp

在Kubernetes的Deployment中，这些环境变量可以轻松地根据不同的命名空间（Namespace）进行配置。

4.3 数据关联：追踪、指标与日志的桥梁

可观测性的最高境界是Trace、Metric、Log的关联。当你在指标面板上看到一个突增的错误率时，能一键下钻到导致这些错误的具体追踪链路；在查看某个慢追踪时，能直接看到该请求在对应服务实例上打印的关键日志。

实现关联的关键是TraceID和SpanID。

1. 在日志中注入TraceID：配置你的日志框架（如Zap for Go, Logback for Java），从OTel的上下文（Context）中获取当前的TraceID和SpanID，并将其作为固定字段输出到每行日志中。

   // Go使用zap日志库的示例 import ( "go.uber.org/zap" "go.opentelemetry.io/otel/trace" ) func LoggerWithTrace(ctx context.Context) *zap.Logger { span := trace.SpanFromContext(ctx) logFields := []zap.Field{ zap.String("trace_id", span.SpanContext().TraceID().String()), zap.String("span_id", span.SpanContext().SpanID().String()), } return zap.L().With(logFields...) } // 在业务代码中使用 logger := LoggerWithTrace(ctx) logger.Info("Processing order", zap.String("order_id", orderID))

2. 在后端建立关联：像Loki（日志）、Tempo（追踪）和Prometheus（指标）这样的现代可观测性栈，通常支持通过TraceID进行关联查询。Grafana的Explore界面可以让你在一个面板中同时查询这三类数据。

“OpenClaw Telemetry”项目的最佳实践之一，就是提供统一的日志配置模板或工具函数，确保所有服务都以相同的方式在日志中输出TraceID。

5. 生产环境问题排查与性能调优

将遥测系统部署到生产环境后，挑战才真正开始。数据量、性能开销、存储成本和查询效率都是需要持续关注和优化的问题。

5.1 常见问题与排查清单

5.2 性能开销优化实践

引入遥测必然带来性能开销，目标是将开销控制在可接受的范围内（通常要求对P99延迟的影响<2%）。

1. 采样是最大的性能杠杆：这是控制数据量和后端负载最有效的手段。从固定概率采样开始，逐步过渡到满足业务需求的智能采样。
2. 优化Span属性：避免在Span属性中记录大字符串（如完整的请求/响应体）。只记录用于筛选和诊断的关键信息（如ID、状态码、错误消息）。可以使用事件（Event）来记录更详细但非索引的信息。
3. 使用异步和批量导出：确保使用SDK提供的异步BatchSpanProcessor，它会在后台批量发送数据，避免阻塞主业务线程。调整其队列大小和批处理间隔以平衡实时性和内存使用。
4. 谨慎使用自动仪器：某些过于“热心”的自动仪器可能会创建过多不必要的Span。仔细评估并选择性启用。例如，你可能不需要为每个数据库连接池的操作都创建Span。
5. 监控遥测系统自身：为OTel Collector和应用中的SDK暴露健康检查和指标端点，监控其队列深度、导出错误率、内存使用情况等，确保它本身是健康的。

5.3 安全与隐私考量

遥测数据可能包含敏感信息（如用户ID、邮箱、请求参数）。

1. 数据脱敏：在数据离开应用之前进行脱敏。可以在OTel SDK端使用Span处理器，或在Collector端使用attributes处理器，来删除或混淆（如哈希化）敏感属性。

   # 在Collector中配置脱敏处理器 processors: attributes/redact: actions: - key: http.request.header.authorization action: delete - key: http.request.body action: hash # 或使用自定义转换逻辑

2. 访问控制：确保追踪和指标的后端UI（如Jaeger、Grafana）有严格的访问控制，仅限于授权的运维和开发人员访问。
3. 合规性：根据数据保护法规（如GDPR），考虑设置数据的保留期限，并确保有数据清理机制。

构建像“OpenClaw Telemetry”这样的遥测体系，是一个从工具集成到文化建设的系统工程。它始于几行代码的接入，但最终价值体现在通过数据驱动的方式，让整个团队对系统的运行状态有了共同、清晰、可行动的认知。从“盲人摸象”到“全局俯瞰”，这种能力的提升，是应对现代复杂软件系统挑战的基石。在实际操作中，我个人的体会是，从小范围试点服务开始，快速展示价值（如快速定位一次线上故障），是推动团队广泛接纳和采用遥测技术的最佳方式。