首页
/ SkyWalking与OpenTelemetry生态集成

SkyWalking与OpenTelemetry生态集成

2026-02-04 04:11:51作者：田桥桑Industrious
skywalking
SkyWalking是一款面向应用程序的监控工具，可帮助开发人员诊断和优化应用程序性能。应用于分布式系统的监控和故障排除。
项目地址：https://gitcode.com/gh_mirrors/skyw/skywalking

SkyWalking作为成熟的APM系统，通过专门的OTLP接收器插件全面支持OpenTelemetry协议，能够无缝接收、处理和存储来自OpenTelemetry生态系统的追踪、度量和日志三大支柱数据。其模块化架构采用分层处理模式，实现了对OTLP gRPC协议的完整支持，包括所有核心度量数据类型、完整的属性/标签系统、资源和服务标识信息以及复杂的直方图和指数直方图。

OpenTelemetry协议兼容性分析

SkyWalking作为一款成熟的APM系统，对OpenTelemetry协议提供了全面的兼容性支持。通过专门的OTLP接收器插件，SkyWalking能够无缝接收、处理和存储来自OpenTelemetry生态系统的遥测数据，包括追踪、度量和日志三大支柱数据。

协议支持架构

SkyWalking通过模块化的设计实现了对OpenTelemetry协议的支持，其架构采用分层处理模式：

flowchart TD
    A[OpenTelemetry客户端] -->|gRPC OTLP协议| B[OTLP接收器插件]
    B --> C{数据类型路由}
    C -->|Traces| D[追踪处理器]
    C -->|Metrics| E[度量处理器]
    C -->|Logs| F[日志处理器]
    D --> G[Zipkin格式转换]
    E --> H[Prometheus格式转换]
    F --> I[SkyWalking日志格式]
    G --> J[核心分析引擎]
    H --> J
    I --> J

追踪数据兼容性

协议映射机制

SkyWalking的OpenTelemetry追踪处理器实现了完整的OTLP追踪协议支持，包括：

Span属性映射表：

OpenTelemetry字段 SkyWalking映射 转换规则
traceId traceId 128位转换为两个64位long值
spanId id 64位转换为long值
parentSpanId parentId 64位转换为long值
name name 直接映射
startTimeUnixNano timestamp 纳秒转微秒
endTimeUnixNano duration 计算时间差
kind kind + span.kind标签 类型转换和补充标签

Span类型转换：

flowchart LR
    A[OTLP Span Kind] --> B[SkyWalking Kind]
    SPAN_KIND_CLIENT --> CLIENT
    SPAN_KIND_SERVER --> SERVER
    SPAN_KIND_PRODUCER --> PRODUCER
    SPAN_KIND_CONSUMER --> CONSUMER
    SPAN_KIND_INTERNAL --> null + span.kind=internal

属性处理策略

SkyWalking采用智能的属性处理策略，将OpenTelemetry属性转换为Zipkin格式的标签：

// 属性转换示例代码
private Map<String, String> convertAttributeToMap(List<KeyValue> attributes) {
    return attributes.stream()
        .collect(Collectors.toMap(
            KeyValue::getKey,
            kv -> anyValueToString(kv.getValue())
        ));
}

// 多类型值支持
public static String anyValueToString(AnyValue value) {
    if (value.hasStringValue()) return value.getStringValue();
    if (value.hasIntValue()) return String.valueOf(value.getIntValue());
    if (value.hasDoubleValue()) return String.valueOf(value.getDoubleValue());
    if (value.hasBoolValue()) return String.valueOf(value.getBoolValue());
    if (value.hasArrayValue()) return value.getArrayValue().toString();
    return "";
}

特殊字段处理

状态码转换：

  • STATUS_CODE_ERROR → error=true 标签
  • 所有状态码都转换为 otel.status_code 标签
  • 状态描述信息转换为 otel.status_description 标签

链接和事件处理：

  • 事件转换为Zipkin注解格式
  • 链接信息转换为 otlp.link.{index} 标签格式

度量数据兼容性

度量类型支持

SkyWalking支持OpenTelemetry的所有核心度量类型：

度量类型映射表：

OTLP度量类型 SkyWalking类型 处理策略
Gauge Gauge 直接映射
Sum (Monotonic) Counter 累计计数器
Sum (Non-Monotonic) Gauge 作为瞬时值
Histogram Histogram 桶统计转换
ExponentialHistogram Histogram 指数直方图转换

标签映射机制

SkyWalking实现了智能的标签映射和重命名策略：

// 标签映射配置
private static final Map<String, String> LABEL_MAPPINGS = ImmutableMap.<String, String>builder()
    .put("net.host.name", "node_identifier_host_name")
    .put("host.name", "node_identifier_host_name")
    .put("job", "job_name")
    .put("service.name", "job_name")
    .build();

聚合时间性处理

支持不同的聚合时间性策略：

  • AGGREGATION_TEMPORALITY_DELTA：作为Gauge处理
  • AGGREGATION_TEMPORALITY_CUMULATIVE：根据单调性决定作为Counter或Gauge

指数直方图支持

SkyWalking实现了完整的指数直方图转换算法：

private static Map<Double, Long> buildBucketsFromExponentialHistogram(
    int positiveOffset, List<Long> positiveBucketCounts,
    int negativeOffset, List<Long> negativeBucketCounts, int scale) {
    
    double base = Math.pow(2.0, Math.pow(2.0, -scale));
    Map<Double, Long> result = new HashMap<>();
    
    // 处理负值桶
    for (int i = 0; i < negativeBucketCounts.size(); i++) {
        double upperBound = -Math.pow(base, negativeOffset + i);
        result.put(upperBound, negativeBucketCounts.get(i));
    }
    
    // 处理正值桶
    for (int i = 0; i < positiveBucketCounts.size() - 1; i++) {
        double upperBound = Math.pow(base, positiveOffset + i + 1);
        result.put(upperBound, positiveBucketCounts.get(i));
    }
    
    result.put(Double.POSITIVE_INFINITY, 
               positiveBucketCounts.get(positiveBucketCounts.size() - 1));
    return result;
}

日志数据兼容性

日志处理流程

SkyWalking的OpenTelemetry日志处理器提供完整的日志数据支持：

sequenceDiagram
    participant C as OTLP客户端
    participant H as 日志处理器
    participant A as 日志分析服务
    participant S as 存储引擎

    C->>H: ExportLogsServiceRequest
    H->>H: 解析资源属性
    H->>H: 提取服务名称
    H->>H: 构建日志数据
    H->>A: LogData对象
    A->>S: 存储处理结果
    H->>C: ExportLogsServiceResponse

日志属性转换

支持多种属性值类型的转换：

  • 字符串值：直接使用
  • 整数值：转换为字符串
  • 双精度值：转换为字符串
  • 布尔值：转换为字符串
  • 数组值：转换为JSON字符串

服务标识提取

从资源属性中智能提取服务标识信息：

  • service.name 作为主要服务标识
  • service.instance 作为服务实例标识
  • service.layer 作为服务层级信息

配置和扩展性

模块化配置

SkyWalking提供灵活的配置选项：

# 启用处理器配置
enabledHandlers: otlp-traces,otlp-metrics,otlp-logs

# 度量规则配置
enabledOtelMetricsRules: rule1,rule2,rule3

规则引擎支持

通过Prometheus规则引擎支持自定义度量处理规则，实现灵活的度量数据转换和聚合策略。

兼容性特性总结

完全支持的协议特性：

  • OTLP gRPC协议（追踪、度量、日志）
  • 所有核心度量数据类型
  • 完整的属性/标签系统
  • 资源和服务标识信息
  • 复杂的直方图和指数直方图

智能转换策略：

  • 自动服务名称发现
  • 智能标签映射和重命名
  • 多数据类型值处理
  • 错误处理和降级策略

性能优化：

  • 批量处理支持
  • 异步处理机制
  • 内存高效的数据结构
  • 错误恢复和重试机制

SkyWalking的OpenTelemetry协议兼容性设计充分考虑了生产环境的实际需求，提供了稳定、高效且功能完整的集成方案，使得用户能够无缝地将现有的OpenTelemetry生态系统与SkyWalking监控平台进行集成。

数据格式转换与标准化

在SkyWalking与OpenTelemetry生态集成中，数据格式转换与标准化是实现无缝对接的核心环节。OpenTelemetry作为云原生时代可观测性数据的标准协议，其数据格式与SkyWalking原生格式存在显著差异，需要通过精密的转换机制来实现数据的互操作性。

标签映射与标准化处理

SkyWalking通过预定义的标签映射规则，将OpenTelemetry中的资源属性（Resource Attributes）转换为SkyWalking可识别的标签格式。这一过程确保了不同数据源之间的标签一致性，为后续的数据分析和可视化提供了统一的基础。

private static final Map<String, String> LABEL_MAPPINGS =
    ImmutableMap
        .<String, String>builder()
        .put("net.host.name", "node_identifier_host_name")
        .put("host.name", "node_identifier_host_name")
        .put("job", "job_name")
        .put("service.name", "job_name")
        .build();

上述映射表展示了OpenTelemetry常用资源属性到SkyWalking标准标签的转换规则。这种映射不仅解决了命名差异问题，还确保了语义的一致性。

指标数据类型转换机制

OpenTelemetry支持多种指标数据类型，包括Gauge、Sum、Histogram、ExponentialHistogram和Summary。SkyWalking的转换处理器需要针对每种数据类型实现特定的转换逻辑：

flowchart TD
    A[OpenTelemetry Metric] --> B{数据类型判断}
    B --> C[Gauge]
    B --> D[Sum]
    B --> E[Histogram]
    B --> F[ExponentialHistogram]
    B --> G[Summary]
    
    C --> H[转换为Gauge指标]
    D --> I{是否为Delta聚合}
    I -- 是 --> J[转换为Gauge指标]
    I -- 否 --> K{是否为单调递增}
    K -- 是 --> L[转换为Counter指标]
    K -- 否 --> M[转换为Gauge指标]
    
    E --> N[转换为Histogram指标]
    F --> O[计算指数直方图桶边界]
    O --> P[转换为Histogram指标]
    G --> Q[转换为Summary指标]

复杂数据结构的特殊处理

对于OpenTelemetry中的复杂数据结构，如指数直方图（ExponentialHistogram），SkyWalking实现了专门的转换算法：

private static Map<Double, Long> buildBucketsFromExponentialHistogram(
    int positiveOffset, final List<Long> positiveBucketCounts,
    int negativeOffset, final List<Long> negativeBucketCounts, int scale) {
    
    final Map<Double, Long> result = new HashMap<>();
    double base = Math.pow(2.0, Math.pow(2.0, -scale));
    
    // 处理负值桶
    for (int i = 0; i < negativeBucketCounts.size(); i++) {
        double upperBound = -Math.pow(base, negativeOffset + i);
        result.put(upperBound, negativeBucketCounts.get(i));
    }
    
    // 处理正值桶
    for (int i = 0; i < positiveBucketCounts.size() - 1; i++) {
        double upperBound = Math.pow(base, positiveOffset + i + 1);
        result.put(upperBound, positiveBucketCounts.get(i));
    }
    
    result.put(Double.POSITIVE_INFINITY, 
               positiveBucketCounts.get(positiveBucketCounts.size() - 1));
    return result;
}

时间戳与数值精度转换

OpenTelemetry使用纳秒级时间戳，而SkyWalking使用毫秒级时间戳。转换过程中需要进行精度调整：

OpenTelemetry时间戳 SkyWalking时间戳 转换方式
1692684000000000000 1692684000000 除以1,000,000
1692684000000000 1692684000 除以1,000,000
1692684000000 1692684 除以1,000,000

数值类型也需要进行适当的转换处理，确保数据精度和范围的正确性。

错误处理与数据验证

在数据转换过程中，SkyWalking实现了完善的错误处理机制：

try {
    rules = Rules.loadRules("otel-rules", enabledRules);
} catch (IOException e) {
    throw new ModuleStartException("Failed to load otel rules.", e);
}

// 数据点级别的错误处理
.map(Function1.liftTry(Function.identity()))
.flatMap(tryIt -> MetricConvert.log(
    tryIt,
    "Convert OTEL metric to prometheus metric"
))

这种分层错误处理机制确保了单个数据点的转换失败不会影响整个数据处理流水线。

配置驱动的转换规则

SkyWalking支持通过配置文件动态加载和管理转换规则，提供了高度的灵活性：

# otel-rules.yaml 示例
rules:
  - name: http_requests_total
    metric_type: COUNTER
    labels:
      - from: method
        to: http_method
      - from: status
        to: http_status
  - name: http_request_duration_seconds
    metric_type: HISTOGRAM
    buckets: [0.1, 0.5, 1.0, 2.5, 5.0, 10.0]

这种配置驱动的 approach 允许用户根据具体需求定制转换规则，无需修改代码即可适应不同的监控场景。

通过上述精密的转换机制，SkyWalking能够将OpenTelemetry格式的观测数据无缝转换为内部标准格式，为分布式系统的全链路监控提供了坚实的数据基础。这种转换不仅保持了数据的完整性和准确性，还确保了不同数据源之间的一致性和互操作性。

多观测性数据源统一管理

在现代分布式系统中，观测性数据的来源日益多样化，从传统的应用性能监控（APM）数据到基础设施指标、日志数据以及第三方监控系统的数据。SkyWalking通过其强大的多数据源统一管理能力，为运维团队提供了一个集中式的观测数据管理平台。

统一数据接收架构

SkyWalking采用模块化的接收器架构，支持多种数据格式和协议的接入。核心架构基于插件机制，每个数据源类型都有对应的接收器插件进行处理：

flowchart TD
    A[多数据源输入] --> B[OpenTelemetry Receiver]
    A --> C[Prometheus Receiver]
    A --> D[Zipkin Receiver]
    A --> E[其他数据源]
    
    B --> F[数据格式转换]
    C --> F
    D --> F
    E --> F
    
    F --> G[统一数据模型]
    G --> H[指标数据处理]
    G --> I[链路数据处理]
    G --> J[日志数据处理]
    
    H --> K[存储引擎]
    I --> K
    J --> K

OpenTelemetry数据集成

SkyWalking对OpenTelemetry协议提供了原生支持，通过专门的接收器插件处理OTLP格式的数据。核心处理流程包括：

数据接收与解析

public class OpenTelemetryMetricHandler extends Handler {
    @Override
    public void export(ExportMetricsServiceRequest requests, 
                      StreamObserver<ExportMetricsServiceResponse> responseObserver) {
        // 处理指标数据
        metricRequestProcessor.processMetricsRequest(requests);
        responseObserver.onNext(ExportMetricsServiceResponse.newBuilder().build());
        responseObserver.onCompleted();
    }
}

数据格式转换机制 SkyWalking实现了从OpenTelemetry数据模型到内部统一数据模型的转换：

private Stream<? extends Metric> adaptMetrics(
    final Map<String, String> nodeLabels,
    final io.opentelemetry.proto.metrics.v1.Metric metric) {
    
    if (metric.hasGauge()) {
        return metric.getGauge().getDataPointsList().stream()
                     .map(point -> new Gauge(
                         metric.getName(),
                         mergeLabels(nodeLabels, buildLabels(point.getAttributesList())),
                         point.hasAsDouble() ? point.getAsDouble() : point.getAsInt(),
                         point.getTimeUnixNano() / 1000000
                     ));
    }
    // 其他指标类型处理...
}

多数据源标签统一管理

为了实现不同数据源之间的数据关联，SkyWalking建立了统一的标签映射体系：

原始标签 统一标签 说明
net.host.name node_identifier_host_name 主机名标识
host.name node_identifier_host_name 主机名标识
job job_name 任务名称
service.name job_name 服务名称

这种标签映射机制确保了来自不同数据源的相同语义信息能够被正确识别和关联。

数据处理管道

SkyWalking的数据处理管道支持多种数据处理操作：

sequenceDiagram
    participant C as 客户端
    participant R as Receiver
    participant P as Processor
    participant S as Storage
    
    C->>R: 发送观测数据
    R->>P: 数据格式转换
    P->>P: 标签标准化
    P->>P: 数据聚合
    P->>S: 存储处理结果

规则引擎配置

通过规则配置文件，用户可以灵活定义数据处理的逻辑：

# otel-rules 配置示例
rules:
  - name: http_requests_total
    metric_type: COUNTER
    labels:
      - service
      - method
      - status_code
    aggregation: sum
    storage: metrics

数据质量控制

SkyWalking在数据接收过程中实施了严格的质量控制措施：

  1. 数据验证：检查数据格式和完整性
  2. 重复数据处理：识别和处理重复数据点
  3. 异常值检测：过滤异常数据值
  4. 速率限制：防止数据洪峰冲击系统

性能优化策略

为了处理大规模数据流，SkyWalking采用了多项性能优化技术：

  • 批量处理：将多个数据点合并处理，减少IO操作
  • 异步处理：非阻塞的数据处理管道
  • 内存缓存：使用高效的内存数据结构
  • 压缩存储：减少存储空间占用

监控与告警集成

统一的数据管理平台还集成了监控告警功能：

stateDiagram-v2
    [*] --> 数据接收
    数据接收 --> 数据处理: 数据验证通过
    数据接收 --> 数据丢弃: 数据格式错误
    
    数据处理 --> 指标计算: 指标数据
    数据处理 --> 链路分析: 链路数据
    数据处理 --> 日志解析: 日志数据
    
    指标计算 --> 阈值检测
    阈值检测 --> 告警触发: 超过阈值
    阈值检测 --> 正常状态: 在阈值内
    
    告警触发 --> 通知发送
    通知发送 --> [*]

通过这种统一的多数据源管理架构，SkyWalking能够有效地整合来自不同监控系统和数据源的观测数据，为用户提供统一的观测视图和一致的数据分析体验。这种架构不仅提高了数据处理的效率，还大大降低了多系统集成的复杂性。

混合监控环境下的最佳实践

在现代分布式系统中，混合监控环境已成为常态，企业往往同时使用SkyWalking原生Agent和OpenTelemetry Collector等多种监控工具。在这种复杂环境下，如何实现高效、一致的监控数据采集和处理成为关键挑战。本节将深入探讨混合监控环境下的最佳实践。

统一数据采集策略

在混合监控环境中，首要任务是建立统一的数据采集标准。SkyWalking通过OpenTelemetry接收器插件提供了与OpenTelemetry生态系统的无缝集成。

# application.yml 配置示例
otel:
  enabled-handlers: metrics,logs,traces
  enabled-otel-metrics-rules: default

通过上述配置，SkyWalking可以同时处理三种类型的数据：

  • Metrics: 性能指标数据
  • Logs: 应用日志数据
  • Traces: 分布式追踪数据

数据格式转换与映射

OpenTelemetry使用OTLP（OpenTelemetry Protocol）格式，而SkyWalking有其原生数据格式。在混合环境中，需要建立有效的数据映射机制：

flowchart TD
    A[OpenTelemetry Collector] -->|OTLP/gRPC| B[SkyWalking OTel Receiver]
    B --> C{Data Type}
    C -->|Metrics| D[Metric Handler]
    C -->|Logs| E[Log Handler]
    C -->|Traces| F[Trace Handler]
    D --> G[Data Mapping & Conversion]
    E --> G
    F --> G
    G --> H[Unified Storage]

数据映射的关键在于保持语义一致性。SkyWalking的OpenTelemetry接收器会自动处理以下映射：

OpenTelemetry字段 SkyWalking字段 映射说明
otel.status_code status 状态码转换
otel.library.name component 组件标识
resource.attributes tags 资源属性转标签

性能优化策略

混合环境下的性能优化至关重要。以下是一些关键实践：

批量处理配置：

// 批量处理配置示例
public class BatchProcessorConfig {
    private int batchSize = 1000;      // 每批处理记录数
    private int bufferSize = 10000;    // 缓冲区大小
    private long flushInterval = 1000; // 刷新间隔(ms)
}

线程池优化：

# 线程池配置
thread-pool:
  core-size: 8
  max-size: 32
  queue-capacity: 10000
  keep-alive-time: 60s

监控数据质量管理

在混合环境中确保数据质量需要实施以下策略：

  1. 数据完整性检查：

    • 验证必需的字段存在性
    • 检查数据格式合规性
    • 实施数据采样策略

  2. 一致性保障：

    public void validateOtelData(ExportMetricsServiceRequest request) {
    // 验证指标名称格式
    requireNonNull(request.getResourceMetricsList(), 
                  "Resource metrics cannot be null");
    
    // 检查时间戳有效性
    request.getResourceMetricsList().forEach(metric -> {
        requireValidTimestamp(metric.getTimeUnixNano());
    });
}

故障恢复与容错机制

混合环境需要强大的容错能力：

flowchart LR
    A[数据接收] --> B{数据验证}
    B -->|有效| C[数据处理]
    B -->|无效| D[错误处理]
    C --> E[持久化存储]
    D --> F[错误日志记录]
    D --> G[重试机制]
    G -->|成功| C
    G -->|失败| H[死信队列]

实施重试机制和死信队列确保数据不丢失：

  • 瞬时错误自动重试（最多3次）
  • 持久性错误进入死信队列
  • 定期监控和人工干预机制

安全与访问控制

在混合监控环境中，安全是重中之重：

TLS加密配置：

security:
  tls:
    enabled: true
    key-store: /path/to/keystore.jks
    key-store-password: changeit
    trust-store: /path/to/truststore.jks
    trust-store-password: changeit

访问控制策略：

  • 基于IP地址的白名单
  • 客户端证书认证
  • 请求频率限制

监控与告警集成

建立统一的监控看板，集成来自不同来源的监控数据：

-- 示例：查询混合环境下的性能指标
SELECT 
    service_name,
    AVG(response_time) as avg_response_time,
    COUNT(*) as request_count,
    source_system
FROM unified_metrics
WHERE timestamp >= NOW() - INTERVAL '1 hour'
GROUP BY service_name, source_system
ORDER BY avg_response_time DESC;

配置管理最佳实践

使用版本控制的配置文件管理混合环境配置：

# 配置版本管理
/config/
├── base/
│   ├── application.yml
│   └── otel-receiver.yml
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
└── templates/
    └── otel-handler-template.yml

通过环境变量注入敏感配置：

otel:
  endpoint: ${OTEL_ENDPOINT:0.0.0.0:4317}
  enabled: ${OTEL_ENABLED:true}

性能测试与基准

建立性能基准测试套件，定期验证混合环境的性能表现：

@SpringBootTest
class MixedMonitoringPerformanceTest {
    
    @Test
    void testOtelMetricsThroughput() {
        // 模拟高并发OpenTelemetry指标数据
        simulateHighLoadOtelMetrics(10000);
        
        // 验证处理吞吐量和延迟
        assertThat(processingThroughput).isGreaterThan(5000); // 5000 req/s
        assertThat(avgLatency).isLessThan(100); // 100ms
    }
}

通过实施上述最佳实践，可以在混合监控环境中实现高效、可靠的数据采集和处理，确保监控系统的稳定性和数据的一致性。

在混合监控环境中，SkyWalking通过统一数据采集策略、数据格式转换与映射、性能优化、数据质量管理、故障恢复与容错机制、安全访问控制等最佳实践，实现了高效可靠的监控数据采集和处理。通过建立统一的监控看板和版本控制的配置管理，确保了监控系统的稳定性和数据的一致性，为分布式系统提供了完整的可观测性解决方案。

skywalking
SkyWalking是一款面向应用程序的监控工具，可帮助开发人员诊断和优化应用程序性能。应用于分布式系统的监控和故障排除。
项目地址：https://gitcode.com/gh_mirrors/skyw/skywalking
登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
27
11
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
532
3.75 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
336
178
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
886
596
pytorchpytorch
Ascend Extension for PyTorch
Python
340
405
flutter_flutterflutter_flutter
暂无简介
Dart
772
191
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台，包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分，采用java语言实现，可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
12
1
agent-studioagent-studio
openJiuwen agent-studio提供零码、低码可视化开发和工作流编排，模型、知识库、插件等各资源管理能力
TSX
986
247
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码，欢迎大家投稿，让全世界看到您的妙趣设计，也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
416
4.21 K
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
JavaScript
303
355