折腾 Quickwit，Rust 编写的分布式搜索引擎 - 可观测性之分布式追踪

于 2024-08-30 13:45:00 发布
阅读量320 收藏 9
点赞数 15
文章标签： rust 分布式 开发语言 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/o__cc/article/details/141730897
版权

概述

分布式追踪是一种跟踪应用程序请求流经不同服务(如前端、后端、数据库等)的过程。它是一个强大的工具，可以帮助您了解应用程序的工作原理并调试性能问题。

Quickwit 是一个用于索引和搜索非结构化数据的云原生引擎，这使其非常适合用作追踪数据的后端。

此外，Quickwit 本地支持 OpenTelemetry gRPC 和 HTTP(仅 protobuf)协议 以及 Jaeger gRPC API(仅 SpanReader)。这意味着您可以使用 Quickwit 存储追踪数据，并通过 Jaeger UI 查询这些数据。

image

将 Quickwit 连接到 Jaeger

Quickwit 实现了一个与 Jaeger UI 兼容的 gRPC 服务。您只需要将 Jaeger 配置为使用 grpc-plugin 类型的(跨度)存储，就能够查看存储在任何匹配模式 otel-traces-v0_* 的 Quickwit 索引中的追踪数据。

官方制作了一个关于 如何将 Quickwit 连接到 Jaeger UI 的教程，将引导您完成整个过程。

向 Quickwit 发送追踪数据

将 Quickwit 连接至 Jaeger

我们将 Quickwit 的追踪数据发送到 Jaeger 并进行分析，这将生成新的追踪数据以供分析 😃

启动 Quickwit

首先，启动一个启用了 OTLP 服务的 Quickwit 实例：

QW_ENABLE_OPENTELEMETRY_OTLP_EXPORTER=true \
OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:7281 \
./quickwit run

我们还设置了 QW_ENABLE_OPENTELEMETRY_OTLP_EXPORTER 和 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量，以便 Quickwit 将其自身的追踪数据发送给自己。

启动 Jaeger UI

让我们使用 Docker 启动一个 Jaeger UI 实例。在这里我们需要告知 Jaeger 使用 Quickwit 作为其后端。

由于一些与容器网络相关的特殊性，我们需要在 MacOS 和 Windows 上采用一种方法，在 Linux 上采用另一种方法。

MacOS 与 Windows

我们可以依赖 host.docker.internal 来获取指向我们 Quickwit 服务器的 Docker 桥接 IP 地址。

docker run --rm --name jaeger-qw \
    -e SPAN_STORAGE_TYPE=grpc-plugin \
    -e GRPC_STORAGE_SERVER=host.docker.internal:7281 \
    -p 16686:16686 \
    jaegertracing/jaeger-query:latest
Linux

默认情况下，Quickwit 监听 127.0.0.1，并且不会响应指向 Docker 桥接 (172.17.0.1) 的请求。解决此问题有多种方法。最简单的方法可能是使用主机网络模式。

docker run --rm --name jaeger-qw  --network=host \
    -e SPAN_STORAGE_TYPE=grpc-plugin \
    -e GRPC_STORAGE_SERVER=127.0.0.1:7281 \
    -p 16686:16686 \
    jaegertracing/jaeger-query:latest

在 Jaeger UI 中搜索追踪数据

由于 Quickwit 会索引其自身的追踪数据，因此在大约 5 秒后(这是 Quickwit 完成首次提交所需的时间)，您应该能够在 Jaeger UI 中看到这些数据。

打开位于 http://localhost:16686 的 Jaeger UI 并搜索追踪数据！通过执行搜索查询，您将看到 Quickwit 自身的追踪数据：

  • find_traces 是在 Jaeger UI 中搜索追踪数据时调用的端点，随后它会调用 find_trace_ids。
  • find_traces_ids 对跨度执行聚合查询以获取唯一的追踪 ID。
  • root_search 是 Quickwit 的搜索入口点。它会在每个分片(索引的一部分)上并行地或分布式地调用搜索，如果只有一个节点，则仅在本地调用。
  • leaf_search 是每个节点上的搜索入口点。它会在每个分片上调用 leaf_search_single_split。
  • leaf_search_single_split 是分片上的搜索入口点。它会依次调用 warmup 和 tantivy_search。
  • warmup 是搜索的预热阶段。它预取执行搜索查询所需的数据。
  • tantivy_search 是搜索的执行阶段。它使用 Tantivy 高速执行搜索查询。

image

使用 OTEL Collector

如果您已经有自己的 OpenTelemetry Collector 并希望将跟踪数据导出到 Quickwit，您需要在 config.yaml 中添加一个新的 OTLP gRPC 导出器：

macOS/Windows

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlp/quickwit:
    endpoint: host.docker.internal:7281
    tls:
      insecure: true
    # By default, traces are sent to the otel-traces-v0_7.
    # You can customize the index ID By setting this header.
    # headers:
    #   qw-otel-traces-index: otel-traces-v0_7

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/quickwit]

Linux

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlp/quickwit:
    endpoint: 127.0.0.1:7281
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/quickwit]

测试您的 OTEL 配置

  1. 安装 并启动一个 Quickwit 服务器： 
./quickwit run
  1. 使用之前的配置启动一个收集器：

macOS/Windows

docker run -v ${PWD}/otel-collector-config.yaml:/etc/otelcol/config.yaml -p 4317:4317 -p 4318:4318 -p 7281:7281 otel/opentelemetry-collector

Linux

docker run -v ${PWD}/otel-collector-config.yaml:/etc/otelcol/config.yaml --network=host -p 4317:4317 -p 4318:4318 -p 7281:7281 otel/opentelemetry-collector
  1. 使用 cURL 向收集器发送一个跟踪：
curl -XPOST "http://localhost:4318/v1/traces" -H "Content-Type: application/json" \
--data-binary @- << EOF
{
 "resource_spans": [
   {
     "resource": {
       "attributes": [
         {
           "key": "service.name",
           "value": {
             "string_value": "test-with-curl"
           }
         }
       ]
     },
     "scope_spans": [
       {
         "scope": {
           "name": "manual-test"
         },
         "spans": [
           {
             "time_unix_nano": "1678974011000000000",
             "observed_time_unix_nano": "1678974011000000000",
             "start_time_unix_nano": "1678974011000000000",
             "end_time_unix_nano": "1678974021000000000",
             "trace_id": "3c191d03fa8be0653c191d03fa8be065",
             "span_id": "3c191d03fa8be065",
             "kind": 2,
             "events": [],
             "status": {
               "code": 1
             }
           }
         ]
       }
     ]
   }
 ]
}
EOF

您应该会在 Quickwit 服务器上看到类似于以下的日志：

2023-03-16T13:44:09.369Z  INFO quickwit_indexing::actors::indexer: new-split split_id="01GVNAKT5TQW0T2QGA245XCMTJ" partition_id=6444214793425557444

这意味着 Quickwit 已经接收到跟踪并创建了一个新的分片。在搜索跟踪之前，请等待分片发布。

使用 OTEL SDK - Python

在本教程中，我们将向您展示如何使用 OpenTelemetry 为 Python Flask 应用程序进行仪器化，并将跟踪数据发送到 Quickwit。本教程受到 Python OpenTelemetry 文档的启发，感谢 OpenTelemetry 团队！

前提条件

  • 已安装 Python3
  • 已安装 Docker

启动一个 Quickwit 实例

安装 Quickwit 并启动一个 Quickwit 实例：

./quickwit run

启动 Jaeger UI

让我们使用 Docker 启动一个 Jaeger UI 实例。在这里我们需要告知 Jaeger 使用 Quickwit 作为其后端。

由于容器网络的一些特殊性，我们将在 MacOS 和 Windows 以及 Linux 上采用不同的方法。

MacOS 和 Windows

我们可以依赖 host.docker.internal 获取指向我们 Quickwit 服务器的 Docker 桥接 IP 地址。

docker run --rm --name jaeger-qw \
    -e SPAN_STORAGE_TYPE=grpc-plugin \
    -e GRPC_STORAGE_SERVER=host.docker.internal:7281 \
    -p 16686:16686 \
    jaegertracing/jaeger-query:latest
Linux

默认情况下，Quickwit 监听的是 127.0.0.1，并且不会响应指向 Docker 桥接 (172.17.0.1) 的请求。有多种方法可以解决这个问题。
最简单的方法可能是使用主机网络模式。

docker run --rm --name jaeger-qw --network=host \
    -e SPAN_STORAGE_TYPE=grpc-plugin \
    -e GRPC_STORAGE_SERVER=127.0.0.1:7281 \
    -p 16686:16686 \
    jaegertracing/jaeger-query:latest

运行一个简单的 Flask 应用

我们将启动一个 Flask 应用程序，该程序在每个 HTTP 调用 http://localhost:5000/process-ip 上执行三件事：

  • 从 https://httpbin.org/ip 获取 IP 地址。
  • 解析它，并使用随机休眠进行伪造处理。
  • 以随机休眠时间显示它。

我们首先安装依赖项：

pip install flask
pip install opentelemetry-distro
pip install opentelemetry-exporter-otlp

opentelemetry-distro 包会安装 API、SDK 以及您将使用的 opentelemetry-bootstrap 和 opentelemetry-instrument 工具。

以下是我们的应用代码：

import random
import time
import requests

from flask import Flask

app = Flask(__name__)

@app.route("/process-ip")
def process_ip():
    body = fetch()
    ip = parse(body)
    display(ip)
    return ip

def fetch():
    resp = requests.get('https://httpbin.org/ip')
    body = resp.json()
    return body

def parse(body):
    # Sleep for a random amount of time to make the span more visible.
    secs = random.randint(1, 100) / 1000
    time.sleep(secs)

    return body["origin"]

def display(ip):
    # Sleep for a random amount of time to make the span more visible.
    secs = random.randint(1, 100) / 1000
    time.sleep(secs)

    message = f"Your IP address is `{ip}`."
    print(message)

if __name__ == "__main__":
    app.run(port=5000)

自动 Instrumentation

OpenTelemetry 提供了一个名为 opentelemetry-bootstrap 的工具，它可以自动为您仪器化 Python 应用程序。

opentelemetry-bootstrap -a install

现在一切就绪，我们可以运行应用了：

# We don't need metrics.
OTEL_METRICS_EXPORTER=none \
OTEL_TRACES_EXPORTER=console \
OTEL_SERVICE_NAME=my_app \
python my_app.py

通过访问 http://localhost:5000/process-ip，您应该能在控制台看到相应的跟踪记录。

这已经很好了，但如果我们可以记录每个步骤所花费的时间、获取 HTTP 请求的状态码以及响应的内容类型，那就更好了。让我们通过手动仪器化我们的应用来实现这一点！

手动 Instrumentation

import random
import time
import requests

from flask import Flask

from opentelemetry import trace

# Creates a tracer from the global tracer provider
tracer = trace.get_tracer(__name__)

app = Flask(__name__)

@app.route("/process-ip")
@tracer.start_as_current_span("process_ip")
def process_ip():
    body = fetch()
    ip = parse(body)
    display(ip)
    return ip

@tracer.start_as_current_span("fetch")
def fetch():
    resp = requests.get('https://httpbin.org/ip')
    body = resp.json()

    headers = resp.headers
    current_span = trace.get_current_span()
    current_span.set_attribute("status_code", resp.status_code)
    current_span.set_attribute("content_type", headers["Content-Type"])
    current_span.set_attribute("content_length", headers["Content-Length"])

    return body

@tracer.start_as_current_span("parse")
def parse(body):
    # Sleep for a random amount of time to make the span more visible.
    secs = random.randint(1, 100) / 1000
    time.sleep(secs)

    return body["origin"]

@tracer.start_as_current_span("display")
def display(ip):
    # Sleep for a random amount of time to make the span more visible.
    secs = random.randint(1, 100) / 1000
    time.sleep(secs)

    message = f"Your IP address is `{ip}`."
    print(message)

    current_span = trace.get_current_span()
    current_span.add_event(message)

if __name__ == "__main__":
    app.run(port=5000)

我们现在可以启动新的仪器化应用：

OTEL_METRICS_EXPORTER=none \
OTEL_TRACES_EXPORTER=console \
OTEL_SERVICE_NAME=my_app \
opentelemetry-instrument python my_instrumented_app.py

如果您再次访问 http://localhost:5000/process-ip，您应该能看到带有名称 fetch、parse 和 display 的新跨度以及相应的自定义属性！

将跟踪数据发送到 Quickwit

要将跟踪数据发送到 Quickwit，我们需要使用 OTLP 导出器。这非常简单：

OTEL_METRICS_EXPORTER=none \ # We don't need metrics
OTEL_SERVICE_NAME=my_app \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:7281 \
opentelemetry-instrument python my_instrumented_app.py

现在，如果您访问 http://localhost:5000/process-ip，跟踪数据将被发送到 Quickwit，只需等待大约 30 秒即可完成索引。是时候休息一下喝杯咖啡了！

30 秒过去了，让我们查询服务的跟踪数据：

curl -XPOST http://localhost:7280/api/v1/otel-trace-v0/search -H 'Content-Type: application/json' -d '{
    "query": "resource_attributes.service.name:my_app"
}'

然后打开 Jaeger UI localhost:16686 并进行操作，现在您有了一个由 Quickwit 存储后端支持的 Jaeger UI！

image

image

将跟踪数据发送到您的 OpenTelemetry 收集器

按照 OpenTelemetry 收集器教程 中的说明启动一个收集器，并执行以下命令：

OTEL_METRICS_EXPORTER=none \ # We don't need metrics
OTEL_SERVICE_NAME=my_app \
opentelemetry-instrument python instrumented_app.py

跟踪数据将被发送到您的收集器，然后再发送到 Quickwit。

总结

在本教程中，我们学习了如何使用 OpenTelemetry 为 Python 应用程序进行仪器化，并将跟踪数据发送到 Quickwit。同时，我们也了解了如何使用 Jaeger UI 分析这些跟踪数据。

所有的代码片段都可在我们的 教程仓库 中找到。

请告诉我们您对本教程的看法，如有任何疑问，欢迎通过 Discord 或 Twitter 与我们联系。

OTEL service

Quickwit 本地支持 OpenTelemetry 协议 (OTLP)，并提供了一个 gRPC 端点来接收来自 OpenTelemetry collector 或直接从应用程序通过 exporter 发送的跨度数据。此端点默认是启用的。

当启用时，Quickwit 将启动 gRPC 服务，准备接收来自 OpenTelemetry collector 的跨度数据。这些跨度数据默认会被索引到 otel-trace-v0_7 索引中，并且如果该索引不存在，它将自动创建。索引文档映射在下一个section中描述。

如果由于任何原因，您想要禁用这个端点，您可以：

# ... Indexer configuration ...
indexer:
    enable_otlp_endpoint: false

在您选择的索引中发送跨度

您可以通过将 gRPC 请求的头部 qw-otel-traces-index 设置为目标索引 ID 来在您选择的索引中发送跨度。

跟踪和跨度数据模型

一个跟踪是一组跨度，表示一个单独的请求。一个跨度表示跟踪内的单个操作。OpenTelemetry 收集器发送跨度，Quickwit 默认将它们索引到 otel-trace-v0_7 索引中，该索引将 OpenTelemetry 的跨度模型映射到 Quickwit 中的索引文档。

跨度模型源自 OpenTelemetry 规范。

下面是 otel-trace-v0_7 索引的文档映射：

version: 0.7

index_id: otel-trace-v0_7

doc_mapping:
  mode: strict
  field_mappings:
    - name: trace_id
      type: bytes
      input_format: hex
      output_format: hex
      fast: true
    - name: trace_state
      type: text
      indexed: false
    - name: service_name
      type: text
      tokenizer: raw
      fast: true
    - name: resource_attributes
      type: json
      tokenizer: raw
    - name: resource_dropped_attributes_count
      type: u64
      indexed: false
    - name: scope_name
      type: text
      indexed: false
    - name: scope_version
      type: text
      indexed: false
    - name: scope_attributes
      type: json
      indexed: false
    - name: scope_dropped_attributes_count
      type: u64
      indexed: false
    - name: span_id
      type: bytes
      input_format: hex
      output_format: hex
    - name: span_kind
      type: u64
    - name: span_name
      type: text
      tokenizer: raw
      fast: true
    - name: span_fingerprint
      type: text
      tokenizer: raw
    - name: span_start_timestamp_nanos
      type: datetime
      input_formats: [unix_timestamp]
      output_format: unix_timestamp_nanos
      indexed: false
      fast: true
      fast_precision: milliseconds
    - name: span_end_timestamp_nanos
      type: datetime
      input_formats: [unix_timestamp]
      output_format: unix_timestamp_nanos
      indexed: false
      fast: false
    - name: span_duration_millis
      type: u64
      indexed: false
      fast: true
    - name: span_attributes
      type: json
      tokenizer: raw
      fast: true
    - name: span_dropped_attributes_count
      type: u64
      indexed: false
    - name: span_dropped_events_count
      type: u64
      indexed: false
    - name: span_dropped_links_count
      type: u64
      indexed: false
    - name: span_status
      type: json
      indexed: true
    - name: parent_span_id
      type: bytes
      input_format: hex
      output_format: hex
      indexed: false
    - name: events
      type: array<json>
      tokenizer: raw
      fast: true
    - name: event_names
      type: array<text>
      tokenizer: default
      record: position
      stored: false
    - name: links
      type: array<json>
      tokenizer: raw

  timestamp_field: span_start_timestamp_nanos

indexing_settings:
  commit_timeout_secs: 10

search_settings:
  default_search_fields: []

更多

1. Binance 如何使用 Quickwit 构建 100PB 日志服务(Quickwit 博客)

为为少
关注
  • 15
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
折腾 Quickwit，Rust 编写的分布式搜索引擎 - 可观测性之日志管理
o__cc的博客
08-29 567
Quickwit 从底层构建，旨在 高效地索引非结构化数据，并在云存储上轻松搜索这些数据。 此外，Quickwit 开箱即支持 OpenTelemetry gRPC 和 HTTP(仅 protobuf)协议，并提供了一个 REST API，可以接收任何 JSON 格式的日志。这让 Quickwit 成为了日志的理想选择！. https://quickwit.io/docs/guides/sc...
云原生之可观测性-OpenTracing、OpenSensus、OpenTelemetry
ixxqq的博客
01-20 1840
一、OpenTracing官网地址：https://opentracing.io/OpenTracing是CNCF（Cloud Native Computing Foundation pr...
Rust监控可观测性
m0_52796585的博客
06-26 1117
在监控章节的中，我们提到了老板、前端、后端眼中的监控是各不相同的，那么有没有办法将监控模型进行抽象、统一呢？喔，好像线索很明显哎，我们貌似可以把监控模型分为三种：指标 metric、日志 log 和 链路 trace。按照这个定义来看，三种类型几乎没有关联性，是不是意味着我们的监控模型非常成功？恭喜你，刚才总结出的监控模型正是这几年非常火热的可观测性监控的三大基础：Metrics / Log / Trace。
云原生可观测性平台deepflow部署
x10n9的博客
04-14 2892
可编程：DeepFlow 目前支持了对 HTTP、HTTPS、Dubbo、gRPC、ProtobufRPC、SOFARPC、MySQL、PostgreSQL、Redis、Kafka、MQTT、DNS协议的解析，并将保持迭代增加更多的应用协议支持。在云原生环境中，DeepFlow 的 AutoTagging 机制自动发现服务、实例、API的属性信息，自动为每个观测数据注入丰富的标签，从而消除数据孤岛，并释放数据的下钻能力。随着复杂度的增长，可观测性平台本身的可观测性能力同样也成为问题。
Apache SkyWalking Rust Agent：无处不在的可观测性解决方案
gitblog_00709的博客
08-06 739
Apache SkyWalking Rust Agent：无处不在的可观测性解决方案 skywalking-rustApache SkyWalking Rust Agent项目地址:https://gitcode.com/gh_mirrors/sk/skywalking-rust Apache SkyWalking Rust Agent 是一款强大的开源工具，为Rust应用和库提供了全面的可观测...
分布式链路追踪系统Skywalking_V9版本介绍
张军伟的技术博客
10-07 4579
skywalking分布式链路追踪
SkyWalking分布式系统应用程序性能监控工具-上
itxiaoshen博客
07-24 712
本篇从微服务监控三大要素，了解分布式链路追踪理论基础，SkyWalking与其他常见开源APM系统比较，介绍SkyWalking组成，部署基于ES持久化SkyWalking，通过两个微服务实战示例演示基于Java语言的无侵入Agent配置使用和SkyWalking UI几个常见功能，最后实现一个自定义链路追踪的示例。...
微服务的终极目标，Mecha分布式运行时之Dapr
dotNET跨平台
09-06 319
1. Mecha 是啥？微服务发展到今天，已经有很多公司多年前已经改造完毕，也有些公司还在路上，微服务的优势，有过了解的朋友应该也都能说出个一二三来，经历过微服务改造的，应该都知道其中的艰...
Rust 语言的全链路追踪库 tracing
DatenLord的博客
12-23 1880
在一个应用程序或库的开发过程中，除了其本身的逻辑以外，开发人员还需要做很多额外的工作，以保证编写的代码可以正确的运行，或者在出错时可以快速定位到错误的位置以及原因，这就需要引入一些额外的工具，trace 就是其中特别好用的一种，下文我将会简单介绍 trace，并以 Rust 为例，演示 trace 在 Rust 中的使用方法。
RustChinaConf2020-22.钟镇炽-《高性能 Rust tracing 库设计》.pdf
09-13
追踪是可观测性三大支柱之一，对于诊断、性能分析和问题排查至关重要。 追踪系统通常用于记录请求范围内的操作，如HTTP和RPC调用，并且能够跨越多个组件，如Redis和关系型数据库管理系统(RDBMS)。每个追踪操作被...
K8s 应用的网络可观测性： Cilium VS DeepFlow
每天都要开心呀(#^.^#)
03-25 1539
快速提高云原生应用开发者建设K8S网络可观测性能力
浅谈 Apache APISIX 的可观测性
weixin_45583158的博客
11-09 1009
可观测性是从系统外部去观察系统内部程序的的运行时状态和资源使用情况。衡量可观测性的主要手段包括：Metrics、Logging 和 Tracing，下图是 Metrics、Logging ...
【云原生】springboot 整合 OpenTelemetry
热门推荐
congge
01-14 1万+
springboot 整合 OpenTelemetry
NV GPU FMA指令测试
Hi20240217的博客
08-27 1017
本文测试了NV GPU FMA指令的行为。
＜Rust＞egui学习之小部件（八）：如何在窗口中添加滑动条slider部件？
最新发布
用沸腾的热血，支付我们的人生吧！
08-30 505
本专栏是关于Rust的GUI库egui的部件讲解及应用实例分析，主要讲解egui的源代码、部件属性、如何应用。
验证4个SMSP是否是串行访问ShareMemory的
Hi20240217的博客
08-27 635
原以为4个smsp中的warp在没有bank冲突的情况下,是可以并行访问共享内存的通过下面的测试发现,其实是串行的,share memory每个cycle只能处理一个请求。
＜Rust＞egui学习之小部件（三）：如何为窗口UI元件设置布局（间隔、水平、垂直排列）？
用沸腾的热血，支付我们的人生吧！
08-28 374
本专栏是关于Rust的GUI库egui的部件讲解及应用实例分析，主要讲解egui的源代码、部件属性、如何应用。
＜Rust＞egui学习之小部件（七）：如何在窗口中添加颜色选择器colorpicker部件？
用沸腾的热血，支付我们的人生吧！
08-30 380
本专栏是关于Rust的GUI库egui的部件讲解及应用实例分析，主要讲解egui的源代码、部件属性、如何应用。
rust 分布式系统
08-08
Rust是一种系统编程语言，它提供了强大的语言特性，使其成为构建分布式系统的理想选择。TiKV是一个使用Rust开发的分布式Key-Value存储系统，它使用Raft一致性协议来保证数据的强一致性和稳定性，并通过Raft的配置更改机制实现系统的可扩展性。尽管选择Rust对于没有Rust开发经验的团队来说具有风险，因为Rust具有陡峭的学习曲线并且在某些方面缺乏基础库，但是TiKV团队还是决定使用Rust来开发他们的系统，并通过开发适合他们需求的工具和库来弥补这些不足。因此，Rust是一个非常适合构建分布式系统的编程语言。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值