面向.NET开发人员的Dapr——可观察性
目錄：
面向.NET開發(fā)人員的Dapr——前言
面向.NET開發(fā)人員的Dapr——分布式世界
面向.NET開發(fā)人員的Dapr——俯瞰Dapr
面向.NET開發(fā)人員的Dapr——入門
面向.NET開發(fā)人員的Dapr——參考應用程序
面向.NET開發(fā)人員的Dapr——狀態(tài)管理
面向.NET開發(fā)人員的Dapr——發(fā)布和訂閱
面向.NET開發(fā)人員的Dapr——綁定
The Dapr observability building block
Dapr 可觀察性構(gòu)建塊
Modern distributed systems are complex. You start with small, loosely coupled, independently deployable services. These services cross process and server boundaries. They then consume different kinds of infrastructure backing services (databases, message brokers, key vaults). Finally, these disparate pieces compose together to form an application.
現(xiàn)代分布式系統(tǒng)非常復雜。從小的，松耦合且可獨立部署的服務開始。這些服務跨進程和服務器邊界。然后，它們使用不同類型的基礎(chǔ)設(shè)施支持服務 (數(shù)據(jù)庫、消息代理、機密庫) 。最后，這些分散的部分組合在一起構(gòu)成應用程序。
With so many separate, moving parts, how do you make sense of what is going on? Unfortunately, legacy monitoring approaches from the past aren't enough. Instead, the system must be?observable?from end-to-end. Modern?observability?practices provide visibility and insight into the health of the application at all times. They enable you to infer the internal state by observing the output. Observability is mandatory for monitoring and troubleshooting distributed applications.
由于有許多不同的移動部件，您如何了解會發(fā)生什么呢？遺憾的是，過去的舊監(jiān)視方法還不夠。相反，系統(tǒng)必須是從端到端 可觀察?。現(xiàn)代?可觀察性?做法可隨時了解應用程序的運行狀況。它們允許您通過觀察輸出來推斷內(nèi)部狀態(tài)。可觀察性是監(jiān)視分布式應用程序和排查其問題所必需的。
The system information used to gain observability is referred to as?telemetry. It can be divided into four broad categories:
Distributed tracing?provides insight into the traffic between services and services involved in distributed transactions.
Metrics?provides insight into the performance of a service and its resource consumption.
Logging?provides insight into how the code is executing and if errors have occurred.
Health?endpoints provide insight into the availability of a service.
用于獲取可觀察性的系統(tǒng)信息稱為?遙測。它可以分為四大類：
分布式跟蹤?提供有關(guān)分布式事務中服務之間的通信的深入理解。
度量值可讓你深入了解服務的性能及其資源使用情況。
日志記錄可提供代碼的執(zhí)行方式以及錯誤發(fā)生的情況。
運行狀況終結(jié)點可讓你深入了解服務的可用性。
The depth of telemetry is determined by the observability features of an application platform. Consider the Azure cloud. It provides a rich telemetry experience that includes all of the telemetry categories. Without any configuration, most Azure IaaS and PaaS services propagate and publish telemetry to the?Azure Application Insights?service. Application Insights presents system logging, tracing, and problem areas with highly visual dashboards. It can even render a diagram showing the dependencies between services based on their communication.
遙測的深度取決于應用程序平臺的可觀測性。請考慮使用 Azure 云。它提供了豐富的遙測體驗，包括所有遙測類別。如果不進行任何配置，大多數(shù) Azure IaaS 和 PaaS 服務會傳播遙測數(shù)據(jù)到?Azure Application Insights服務?。Application Insights具有高度可視化儀表板的系統(tǒng)日志記錄、跟蹤和問題區(qū)域。它甚至可以根據(jù)服務的通信呈現(xiàn)服務之間的依賴關(guān)系的關(guān)系圖。
However, what if an application can't use Azure PaaS and IaaS resources? Is it still possible to take advantage of the rich telemetry experience of Application Insights? The answer is yes. A non-Azure application can import libraries, add configuration, and instrument code to emit telemetry to Azure Application Insights. However, this approach?tightly couples?the application to Application Insights. Moving the app to a different monitoring platform could involve expensive refactoring. Wouldn't it be great to avoid tight coupling and consume observability outside of the code?
但是，如果應用程序無法使用 Azure PaaS 和 IaaS 資源，又如何？是否仍可以利用Application Insights豐富的遙測數(shù)據(jù)？答案為"是"。非 Azure 應用程序可以導入庫、添加配置和檢測代碼，以將遙測數(shù)據(jù)發(fā)送到Azure Application Insights。但是，此方式 將使應用程序與Application Insights緊密耦合。將應用移動到其他監(jiān)視平臺可能涉及成本高昂的重構(gòu)。避免緊密耦合和使用代碼外部的可觀測性不是一個很好的方式嗎？
With Dapr, you can. Let's look at how Dapr can add observability to our distributed applications.
使用 Dapr，可以。讓我們看看 Dapr 如何為分布式應用程序添加可觀測性。
What it solves
它可解決的問題
The Dapr observability building block decouples observability from the application. It automatically captures traffic generated by Dapr sidecars and Dapr system services that make up the Dapr control plane. The block correlates traffic from a single operation that spans multiple services. It also exposes performance metrics, resource utilization, and the health of the system. Telemetry is published in open-standard formats enabling information to be fed into your monitoring back end of choice. There, the information can be visualized, queried, and analyzed.
Dapr 可觀測性構(gòu)建塊將可觀測性與應用程序分離。它自動捕獲由 Dapr 邊車和 Dapr 系統(tǒng)服務生成的通信，Dapr 系統(tǒng)服務是 Dapr 控制平面的一部分（復制過來的翻譯，這樣翻譯是否正確呢？）。構(gòu)建塊將跨多個服務的單個操作的流量相關(guān)聯(lián)。它還公開性能指標、資源利用率和系統(tǒng)的運行狀況。遙測以開放標準格式發(fā)布，使信息可以送入你選擇的監(jiān)視后端。在這里，可以對信息進行可視化、查詢和分析。
As Dapr abstracts away the plumbing, the application is unaware of how observability is implemented. There's no need to reference libraries or implement custom instrumentation code. Dapr allows the developer to focus on building business logic and not observability plumbing. Observability is configured at the Dapr level and is consistent across services, even when created by different teams, and built with different technology stacks.
由于 Dapr 抽象掉了該管道，因此如何實現(xiàn)可觀察性對應用程序來說是透明的（無需知道的）。無需引用庫或?qū)崿F(xiàn)自定義檢測代碼。Dapr 使開發(fā)人員能夠?qū)Ｗ⒂跇?gòu)建業(yè)務邏輯，而不是可觀察性的管道。可觀察性在 Dapr 級別配置，跨服務一致，即使是由不同的團隊創(chuàng)建，并使用不同的技術(shù)棧構(gòu)建。
How it works
工作原理
Dapr's?sidecar architecture?enables built-in observability features. As services communicate, Dapr sidecars intercept the traffic and extract tracing, metrics, and logging information. Telemetry is published in an open standards format. By default, Dapr supports?OpenTelemetry?and?Zipkin.
Dapr 的?邊車體系結(jié)構(gòu)?啟用內(nèi)置可觀察性功能。服務通信時，Dapr 邊車會截獲通信并提取跟蹤、指標和日志記錄信息。遙測以開放標準格式發(fā)布。默認情況下，Dapr 支持?OpenTelemetry?和?Zipkin。
Dapr provides?collectors?that can publish telemetry to different back-end monitoring tools. These tools present Dapr telemetry for analysis and querying. Figure 9-1 shows the Dapr observability architecture:
Dapr 提供可將遙測發(fā)布到不同后端監(jiān)視工具的?收集?器。這些工具提供了 Dapr 遙測用于分析和查詢。圖9-1 顯示了 Dapr 可觀察性體系結(jié)構(gòu)：
Figure 9-1. Dapr observability architecture.
圖 9-1。Dapr 可觀察性體系結(jié)構(gòu)。
Service A calls an operation on Service B. The call is routed from a Dapr sidecar for Service A to a sidecar for Service B.
When Service B completes the operation, a response is sent back to Service A through the Dapr sidecars. They gather and publish all available telemetry for every request and response.
The configured collector ingests the telemetry and sends it to the monitoring back end.
服務 A 調(diào)用服務 B 上的操作。調(diào)用將從服務 A 的 Dapr 邊車路由到服務 B 的邊車。
當服務 B 完成操作時，響應將通過 Dapr 邊車發(fā)送回服務 A。它們收集并發(fā)布每個請求和響應的所有可用遙測數(shù)據(jù)。
配置的收集器引入遙測數(shù)據(jù)，并將其發(fā)送到監(jiān)視后端。
As a developer, keep in mind that adding observability is different from configuring other Dapr building blocks, like pub/sub or state management. Instead of referencing a building block, you add a collector and a monitoring back end. Figure 9-1 shows it's possible to configure multiple collectors that integrate with different monitoring back ends.
作為開發(fā)人員，請記住，添加可觀察性不同于配置其他 Dapr 構(gòu)建基塊，如發(fā)布/訂閱或狀態(tài)管理。添加收集器和監(jiān)視后端，而不是引用構(gòu)建基塊。圖 9-1 顯示可以配置與不同監(jiān)視后端相集成的多個收集器。
At the beginning of this chapter, four categories of telemetry were identified. The following ps will provide detail for each category. They'll include instruction on how to configure collectors that integrate with popular monitoring back ends.
在本章開始時，標識了四種類別的遙測數(shù)據(jù)。以下部分將提供每個類別的詳細信息。其中將指導如何配置收集器與常用監(jiān)視后端相集成。
Distributed tracing
分布式跟蹤
Distributed tracing provides insight into the traffic that flows across services in a distributed application. The log of exchanged request and response messages is an invaluable source of information for troubleshooting issues. The hard part is?correlating messages?that originate from the same operation.
分布式跟蹤提供對在分布式應用程序中跨服務通信流動的洞悉。交換請求和響應消息的日志是排除故障問題的寶貴信息來源。困難的是源自同?一操作的關(guān)聯(lián)消息。?
Dapr uses the?W3C Trace Context?to correlate related messages. It injects the same context information into requests and responses that form a unique operation. Figure 9-2 shows how correlation works:
Dapr 使用?W3C 跟蹤上下文?來關(guān)聯(lián)相關(guān)消息。它將相同的上下文信息注入到構(gòu)成唯一操作的請求和響應中。圖 9-2 顯示了相關(guān)性的工作原理：
Figure 9-2. W3C Trace Context example.
圖 9-2。W3C 跟蹤上下文示例。
Service A invokes an operation on Service B. As Service A starts the call, Dapr creates a unique trace context and injects it into the request.
Service B receives the request and invokes an operation on Service C. Dapr detects that the incoming request contains a trace context and propagates it by injecting it into the outgoing request to Service C.
Service C receives the request and handles it. Dapr detects that the incoming request contains a trace context and propagates it by injecting it into the outgoing response back to Service B.
Service B receives the response and handles it. It then creates a new response and propagates the trace context by injecting it into the outgoing response back to Service A.
服務 A 調(diào)用服務 B 上的操作。當服務 A 開始調(diào)用時，Dapr 會創(chuàng)建唯一的跟蹤上下文，并注入到請求中。
服務 B 接收請求并調(diào)用服務 C 上的操作。Dapr 檢測到傳入請求包含跟蹤上下文，并傳播該上下文（通過將上下文注入到傳出請求（到服務C）中）。
服務 C 接收并處理請求。Dapr 檢測到傳入請求包含跟蹤上下文，并傳播該上下文（通過將上下文注入到傳出響應（返回到服務B）中）。
服務 B 接收并處理響應。然后，它會創(chuàng)建一個新響應，通過將跟蹤上下文注入到傳出響應中，將跟蹤上下文傳播回服務 A。
A set of requests and responses that belong together is called a?trace. Figure 9-3 shows a trace:
一次會話中的一系列請求和響應?稱為跟蹤。圖9-3 顯示了一個跟蹤：
Figure 9-3. Traces and spans.
圖 9-3。跟蹤和范圍（跨越）。
In the figure, note how the trace represents a unique application transaction that takes place across many services. A trace is a collection of?spans. Each span represents a single operation or unit of work done within the trace. Spans are the requests and responses that are sent between services that implement the unique transaction.
在圖中，請注意跟蹤如何表示在多個服務之間發(fā)生的唯一應用程序事務。跟蹤是范圍（跨越）的集合。每個范圍（跨越）都代表跟蹤內(nèi)完成的單個操作或工作單元。范圍（跨越）是在實現(xiàn)唯一事務的服務之間發(fā)送的請求和響應。
The next ps discuss how to inspect tracing telemetry by publishing it to a monitoring back end.
后續(xù)部分討論如何通過將跟蹤遙測數(shù)據(jù)發(fā)布到監(jiān)視后端來實現(xiàn)監(jiān)測。
Use a Zipkin monitoring back end
使用 Zipkin 監(jiān)視后端
Zipkin?is an open-source distributed tracing system. It can ingest and visualize telemetry data. Dapr offers default support for Zipkin. The following example demonstrates how to configure Zipkin to visualize Dapr telemetry.
Zipkin?是開源分布式跟蹤系統(tǒng)。它可以攝取和可視化遙測數(shù)據(jù)。Dapr 提供對 Zipkin 的默認支持。下面的示例演示如何將 Zipkin 配置為Dapr 可視化遙測。
Enable and configure tracing
啟用和配置跟蹤
To start, tracing must be enabled for the Dapr runtime using a Dapr configuration file. Here's an example of a configuration file named?tracing-config.yaml:
首先，必須通過修改 Dapr 配置文件為 Dapr 運行時啟用跟蹤。下面是名為?tracing-config.yaml?的配置文件的示例：
apiVersion: dapr.io/v1alpha1 kind: Configuration metadata:name: tracing-confignamespace: default spec:tracing:samplingRate: "1"zipkin:endpointAddress: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"The?samplingRate?attribute specifies the interval used for publishing traces. The value must be between?0?(tracing disabled) and?1?(every trace is published). With a value of?0.5, for example, every other trace is published, significantly reducing published traffic. The?endpointAddress?points to an endpoint on a Zipkin server running in a Kubernetes cluster. The default port for Zipkin is?9411. The configuration must be applied to the Kubernetes cluster using the Kubernetes CLI:
samplingRate屬性指定用于發(fā)布跟蹤的時間間隔。該值必須介于?0? (禁用跟蹤) 并?1?(發(fā)布每個跟蹤) 。例如，如果值為?0.5?，每隔一個跟蹤會被發(fā)布，大大減少發(fā)布的流量。?endpointAddress?指向在Kubernetes 群集中運行的 Zipkin 服務上的終結(jié)點。Zipkin 的默認端口為?9411?。必須使用 Kubernetes CLI 將配置應用于 Kubernetes 集群：
kubectl apply -f tracing-config.yamlInstall the Zipkin server
安裝 Zipkin 服務
When installing Dapr in self-hosted mode, a Zipkin server is automatically installed and tracing is enabled in the default configuration file located in?$HOME/.dapr/config.yaml?or?%USERPROFILE%\.dapr\config.yaml?on Windows.
在自承載模式下安裝 Dapr 時，會自動安裝 Zipkin 服務，并且會在位于 Windows的$HOME/.dapr/config.yaml或??%USERPROFILE%\.dapr\config.yaml默認配置文件中啟用跟蹤。
When installing Dapr on a Kubernetes cluster though, Zipkin isn't added by default. The following Kubernetes manifest file named?zipkin.yaml, deploys a standard Zipkin server to the cluster:
但是，在 Kubernetes 群集上安裝 Dapr 時，默認情況下不會添加 Zipkin。以下名為 ?zipkin.yaml?的 Kubernetes 清單文件將標準 Zipkin 服務部署到群集：
kind: Deployment apiVersion: apps/v1 metadata:name: zipkinnamespace: eshoplabels:service: zipkin spec:replicas: 1selector:matchLabels:service: zipkintemplate:metadata:labels:service: zipkinspec:containers:- name: zipkinimage: openzipkin/zipkin-slimimagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 9411protocol: TCP---kind: Service apiVersion: v1 metadata:name: zipkinnamespace: eshoplabels:service: zipkin spec:type: NodePortports:- port: 9411targetPort: 9411nodePort: 32411protocol: TCPname: zipkinselector:service: zipkinThe deployment uses the standard?openzipkin/zipkin-slim?container image. The Zipkin service exposes the Zipkin web front end, which you can use to view the telemetry on port?32411. Use the Kubernetes CLI to apply the Zipkin manifest file to the Kubernetes cluster and deploy the Zipkin server:
部署使用標準?openzipkin/zipkin-slim?容器鏡像。Zipkin 服務公開 Zipkin Web 前端，可用于在32411?端口上查看遙測數(shù)據(jù)。使用 Kubernetes CLI 將 Zipkin 清單文件應用到 Kubernetes 群集并部署 Zipkin 服務：
kubectl apply -f zipkin.yamlConfigure the services to use the tracing configuration
將服務配置為使用跟蹤配置
Now everything is set up correctly to start publishing telemetry. Every Dapr sidecar that is deployed as part of the application must be instructed to emit telemetry when started. To do that, add a?dapr.io/config?annotation that references the?tracing-config?configuration to the deployment of each service. Here's an example of the eShop ordering API service's manifest file containing the annotation:
現(xiàn)在，所有內(nèi)容已正確設(shè)置，可開始發(fā)布遙測數(shù)據(jù)。必須指示作為應用程序一部分部署的每一個 Dapr sidecar 在啟動時發(fā)射遙測數(shù)據(jù)。為此，請?zhí)砑右粋€?dapr.io/config?注解，該注解為每個服務的部署引用tracing-config配置。下面是包含注解的 eShop 訂購 API 服務的清單文件示例：
apiVersion: apps/v1 kind: Deployment metadata:name: ordering-apinamespace: eshoplabels:app: eshop spec:replicas: 1selector:matchLabels:app: eshoptemplate:metadata:labels:app: simulationannotations:dapr.io/enabled: "true"dapr.io/app-id: "ordering-api"dapr.io/config: "tracing-config"spec:containers:- name: simulationimage: eshop/ordering.api:linux-latestInspect the telemetry in Zipkin
檢查 Zipkin 中的遙測數(shù)據(jù)
Once the application is started, the Dapr sidecars will emit telemetry to the Zipkin server. To inspect this telemetry, point a web-browser to?http://localhost:32411. You'll see the Zipkin web front end:
應用程序啟動后，Dapr 邊車 會向 Zipkin 服務發(fā)射遙測數(shù)據(jù)。若要檢查此遙測，請在 Web 瀏覽器中打開?http://localhost:32411?。你將看到 Zipkin Web 前端：
On the?Find a trace?tab, you can query traces. Pressing the?RUN QUERY?button without specifying any restrictions will show all the ingested?traces:、
在?"查找跟蹤"?選項卡上，可以查詢跟蹤。點擊 "?運行查詢?" 按鈕而不指定任何條件將顯示所有引入?跟蹤：
licking the?SHOW?button next to a specific trace, will show the details of that trace:
單擊某個跟蹤旁邊的 "?顯示?" 按鈕將顯示該跟蹤的詳細信息：
Each item on the details page, is a span that represents a request that is part of the selected trace.
詳細信息頁上的每一項都是一個范圍（跨越），該范圍（跨越）表示作為所選跟蹤的一部分的請求。
Inspect the dependencies between services
檢查服務之間的依賴關(guān)系
Because Dapr sidecars handle traffic between services, Zipkin can use the trace information to determine the dependencies between the services. To see it in action, go to the?Dependencies?tab on the Zipkin web page and select the button with the magnifying glass. Zipkin will show an overview of the services and their dependencies:
由于 Dapr 邊車處理服務之間的通信，因此 Zipkin 可以使用跟蹤信息來確定服務之間的依賴關(guān)系。若要查看其工作方式，請在 Zipkin 網(wǎng)頁上，單擊 "?依賴項?" 選項卡，然后選擇帶有放大鏡的按鈕。Zipkin 將顯示服務及其依賴項的概述：
The animated dots on the lines between the services represent requests and move from source to destination. Red dots indicate a failed request.
服務之間的線條上的動畫點表示請求，并從源移動到目標。紅點表示失敗的請求。
Use a Jaeger or New Relic monitoring back end
使用 Jaeger 或 New Relic 監(jiān)視后端
Beyond Zipkin itself, other monitoring back-end software also supports ingesting telemetry using the Zipkin format.?Jaeger?is an open source tracing system created by Uber Technologies. It's used to trace transactions between distributed services and troubleshoot complex microservices environments.?New Relic?is a?full-stack?observability platform. It links relevant data from a distributed application to provide a complete picture of your system. To try them out, specify an?endpointAddress?pointing to either a Jaeger or New Relic server in the Dapr configuration file. Here's an example of a configuration file that configures Dapr to send telemetry to a Jaeger server. The URL for Jaeger is identical to the URL for the Zipkin. The only difference is the port on which the server runs:
除了 Zipkin 本身以外，其他監(jiān)視后端軟件也支持使用 Zipkin 格式的引入遙測。?Jaeger?是由 Uber 技術(shù)創(chuàng)建的開源跟蹤系統(tǒng)。它用于跟蹤分布式服務之間的事務，并對復雜的微服務環(huán)境進行故障排除。?New Relic?是一個?全棧?可觀察性平臺。它鏈接分布式應用程序中的相關(guān)數(shù)據(jù)，以提供完整的系統(tǒng)畫面。若要試用，請在 Dapr 配置文件中指定?endpointAddress?指向 Jaeger 或New Relic 服務的。下面是配置文件的一個示例，它將 Dapr 配置為將遙測數(shù)據(jù)發(fā)送到 Jaeger 服務。Jaeger 的 URL 與 Zipkin 的 URL 相同。唯一的區(qū)別是運行服務的端口：
apiVersion: dapr.io/v1alpha1 kind: Configuration metadata:name: tracing-confignamespace: default spec:tracing:samplingRate: "1"zipkin:endpointAddress: "http://localhost:9415/api/v2/spans"To try out New Relic, specify the endpoint of the New Relic API. Here's an example of a configuration file for New Relic:
若要試用New Relic，請指定 New Relic API 的終結(jié)點。下面是適用于New Relic的配置文件示例：
apiVersion: dapr.io/v1alpha1 kind: Configuration metadata:name: tracing-confignamespace: default spec:tracing:samplingRate: "1"zipkin:endpointAddress: "https://trace-api.newrelic.com/trace/v1?Api-Key=<NR-API-KEY>&Data-Format=zipkin&Data-Format-Version=2"Check out the Jaeger and New Relic websites for more information on how to use them.
請查看 Jaeger 和 New Relic 網(wǎng)站，詳細了解如何使用它們。
Metrics
衡量指標
Metrics provide insight into performance and resource consumption. Under the hood, Dapr emits a wide collection of system and runtime metrics. Dapr uses?Prometheus?as a metric standard. Dapr sidecars and system services, expose a metrics endpoint on port?9090. A?Prometheus scraper?calls this endpoint at a predefined interval to collect metrics. The scraper sends metric values to a monitoring back end. Figure 9-4 shows the scraping process:
指標提供性能和資源消耗的洞見。在底層，Dapr 發(fā)出廣泛的系統(tǒng)指標和運行時指標集合。Dapr 使用?Prometheus?作為指標標準。Dapr 邊車和系統(tǒng)服務在?9090?端口 上公開指標終結(jié)點。?Prometheus 抓取器?以預定義的間隔調(diào)用此終結(jié)點以收集指標。抓取器將指標值發(fā)送到監(jiān)視后端。圖 9-4 顯示了抓取過程：
Figure 9-4. Scraping Prometheus metrics.
圖 9-4。?抓取 Prometheus 指標。
In the above figure, each sidecar and system service exposes a metric endpoint that listens on port 9090. The Prometheus Metrics Scrapper captures metrics from each endpoint and published the information to the monitoring back end.
在上圖中，每個邊車和系統(tǒng)服務都公開一個偵聽9090?端口的指標終結(jié)點。Prometheus 指標抓取器從每個終結(jié)點捕獲指標，將信息發(fā)布到監(jiān)視后端。
Service discovery
服務發(fā)現(xiàn)
You might wonder how the metrics scraper knows where to collect metrics. Prometheus can integrate with discovery mechanisms built into target deployment environments. For example, when running in Kubernetes, Prometheus can integrate with the Kubernetes API to find all available Kubernetes resources running in the environment.
你可能想知道指標抓取器如何知道在何處收集指標。Prometheus 可以與目標部署環(huán)境中內(nèi)置的發(fā)現(xiàn)機制集成。例如，在 Kubernetes 中運行時，Prometheus 可以與 Kubernetes API 集成，以查找環(huán)境中運行的所有可用的 Kubernetes 資源。
Metrics list
指標列表
Dapr generates a large set of metrics for Dapr system services and its runtime. Some examples include:
Dapr 為 Dapr 系統(tǒng)服務及其運行時生成大量指標。示例包括：
| dapr_operator_service_created_total | System | The total number of Dapr services created by the Dapr Operator service. |
| dapr_injector_sidecar_injection/requests_total | System | The total number of sidecar injection requests received by the Dapr Sidecar-Injector service. |
| dapr_placement_runtimes_total | System | The total number of hosts reported to the Dapr Placement service. |
| dapr_sentry_cert_sign_request_received_total | System | The number of certificate signing requests (CRSs) received by the Dapr Sentry service. |
| dapr_runtime_component_loaded | Runtime | The number of successfully loaded Dapr components. |
| dapr_grpc_io_server_completed_rpcs | Runtime | Count of gRPC calls by method and status. |
| dapr_http_server_request_count | Runtime | Number of HTTP requests started in an HTTP server. |
| dapr_http/client/sent_bytes | Runtime | Total bytes sent in request body (not including headers) by an HTTP client. |
| dapr_operator_service_created_total | 系統(tǒng) | Dapr Operator 服務創(chuàng)建的 Dapr 服務總數(shù)。 |
| dapr_injector_sidecar_injection/requests_total | 系統(tǒng) | Dapr Sidecar-Injector 服務收到的邊車注入請求總數(shù)。 |
| dapr_placement_runtimes_total | 系統(tǒng) | 向 Dapr Placement服務報告的主機總數(shù)。 |
| dapr_sentry_cert_sign_request_received_total | 系統(tǒng) | Dapr Sentry 服務收到的證書簽名請求數(shù)。 |
| dapr_runtime_component_loaded | 運行時 | 已成功加載的 Dapr 組件數(shù)。 |
| dapr_grpc_io_server_completed_rpcs | 運行時 | 由方法和狀態(tài)的 gRPC 調(diào)用的計數(shù)。 |
| dapr_http_server_request_count | 運行時 | HTTP 服務器中啟動的 HTTP 請求數(shù)。 |
| dapr_http/client/sent_bytes | 運行時 | 由Http 客戶端請求正文中發(fā)送的總字節(jié)數(shù) (不包括標頭)。 |
For more information on available metrics, see the?Dapr metrics documentation.
有關(guān)可用指標的詳細信息，請參閱?Dapr 指標文檔。
Configure Dapr metrics
配置 Dapr 指標
At runtime, you can disable the metrics collection endpoint by including the?--enable-metrics=false?argument in the Dapr command. Or, you can also change the default port for the endpoint with the?--metrics-port 9090?argument.
在運行時，可以通過在?Dapr 命令中包含--enable-metrics=false?參數(shù)來禁用指標收集終結(jié)點。或者，還可以使用?--metrics-port 9090?參數(shù)來更改終結(jié)點的默認端口。
You can also use a Dapr configuration file to statically enable or disable runtime metrics collection:
還可以使用 Dapr 配置文件來靜態(tài)地啟用或禁用運行時指標收集：
apiVersion: dapr.io/v1alpha1 kind: Configuration metadata:name: dapr-confignamespace: eshop spec:tracing:samplingRate: "1"metric:enabled: falseVisualize Dapr metrics
可視化 Dapr 指標
With the Prometheus scraper collecting and publishing metrics into the monitoring back end, how do you make sense of the raw data? A popular visualization tool for analyzing metrics is?Grafana. With Grafana, you can create dashboards from the available metrics. Here's an example of a dashboard displaying Dapr system services metrics:
通過 Prometheus 抓取器收集指標并將其發(fā)布到監(jiān)視后端，你如何理解原始數(shù)據(jù)？用于分析指標的常用可視化工具是?Grafana。使用 Grafana 可以從可用指標創(chuàng)建儀表板。下面是一個顯示 Dapr 系統(tǒng)服務指標的儀表板示例：
The Dapr documentation includes a?tutorial for installing Prometheus and Grafana.
Dapr 文檔包含?用于安裝 Prometheus 和 Grafana 的教程。
Logging
日志記錄
Logging provides insight into what is happening with a service at runtime. When running an application, Dapr automatically emits log entries from Dapr sidecars and Dapr system services. However, logging entries instrumented in your application code?aren't?automatically included. To emit logging from application code, you can import a specific SDK like?OpenTelemetry SDK for .NET. Logging application code is covered later in this chapter in the p?Using the Dapr .NET SDK.
日志記錄提供了服務運行時發(fā)生了什么。運行應用程序時，Dapr 會自動從 Dapr 邊車和 Dapr 系統(tǒng)服務發(fā)出日志條目。但是，在應用程序代碼中檢測到的日志記錄項不會自動包括在內(nèi)。若要從應用程序代碼發(fā)出日志記錄，可以導入特定 SDK，如?OPENTELEMETRY sdk for .net。記錄日志的應用代碼將在本章后面的?使用 Dapr .NET SDK?部分中介紹。
Log entry structure
日志條目結(jié)構(gòu)
Dapr emits structured logging. Each log entry has the following format:
Dapr 發(fā)出結(jié)構(gòu)化日志記錄。每個日志條目都具有以下格式：
| time | ISO8601 formatted timestamp | 2021-01-10T14:19:31.000Z |
| level | Level of the entry (debug?|?info?|?warn?|?error) | info |
| type | Log Type | log |
| msg | Log Message | metrics server started on :62408/ |
| scope | Logging Scope | dapr.runtime |
| instance | Hostname where Dapr runs | TSTSRV01 |
| app_id | Dapr App ID | ordering-api |
| ver | Dapr Runtime Version | 1.0.0-rc.2 |
| time | ISO8601 格式的時間戳 | 2021-01-10T14:19:31.000Z |
| level | 條目級別?(debug?|?info?|?warn?|?error)? | info |
| type | 日志類型 | log |
| msg | 日志消息 | metrics server started on :62408/ |
| scope | 日志記錄范圍 | dapr.runtime |
| instance | Dapr 運行位置的主機名 | TSTSRV01 |
| app_id | Dapr 應用 ID | ordering-api |
| ver | Dapr 運行時版本 | 1.0.0-rc.2 |
When searching through logging entries in a troubleshooting scenario, the?time?and?level?fields are especially helpful. The time field orders log entries so that you can pinpoint specific time periods. When troubleshooting, log entries at the?debug level?provide more information on the behavior of the code.
在故障排除方案中搜索日志記錄條目時，time??和?level?字段尤其有用。time字段對日志條目進行排序，以便可以明確指出特定的時間段。進行故障排除時，dubug級別的日志?條目?提供有關(guān)代碼行為的詳細信息。
Plain text versus JSON format?
純文本與 JSON 格式
By default, Dapr emits structured logging in plain-text format. Every log entry is formatted as a string containing key/value pairs. Here's an example of logging in plain text:
默認情況下，Dapr 以純文本格式發(fā)出結(jié)構(gòu)化日志記錄。每個日志條目的被格式化為包含鍵/值對的字符串。下面是以純文本記錄的示例：
== DAPR == time="2021-01-12T16:11:39.4669323+01:00" level=info msg="starting Dapr Runtime -- version 1.0.0-rc.2 -- commit 196483d" app_id=ordering-api instance=TSTSRV03 scope=dapr.runtime type=log ver=1.0.0-rc.2 == DAPR == time="2021-01-12T16:11:39.467933+01:00" level=info msg="log level set to: info" app_id=ordering-api instance=TSTSRV03 scope=dapr.runtime type=log ver=1.0.0-rc.2 == DAPR == time="2021-01-12T16:11:39.467933+01:00" level=info msg="metrics server started on :62408/" app_id=ordering-api instance=TSTSRV03 scope=dapr.metrics type=log ver=1.0.0-rc.2While simple, this format is difficult to parse. If viewing log entries with a monitoring tool, you'll want to enable JSON formatted logging. With JSON entries, a monitoring tool can index and query individual fields. Here's the same log entries in JSON format:
雖然簡單，但此格式難以進行語法分析。如果使用監(jiān)視工具查看日志條目，需要啟用 JSON 格式的日志記錄。使用 JSON 條目，監(jiān)視工具可以檢索和查詢個別字段。下面是 JSON 格式的相同日志條目：
{"app_id": "ordering-api", "instance": "TSTSRV03", "level": "info", "msg": "starting Dapr Runtime -- version 1.0.0-rc.2 -- commit 196483d", "scope": "dapr.runtime", "time": "2021-01-12T16:11:39.4669323+01:00", "type": "log", "ver": "1.0.0-rc.2"} {"app_id": "ordering-api", "instance": "TSTSRV03", "level": "info", "msg": "log level set to: info", "scope": "dapr.runtime", "type": "log", "time": "2021-01-12T16:11:39.467933+01:00", "ver": "1.0.0-rc.2"} {"app_id": "ordering-api", "instance": "TSTSRV03", "level": "info", "msg": "metrics server started on :62408/", "scope": "dapr.metrics", "type": "log", "time": "2021-01-12T16:11:39.467933+01:00", "ver": "1.0.0-rc.2"}To enable JSON formatting, you need to configure each Dapr sidecar. In self-hosted mode, you can specify the flag?--log-as-json?on the command line:
若要啟用 JSON 格式設(shè)置，需要配置每個 Dapr 邊車。在自承載模式下，可以在命令行上指定?--log-as-json? 標志：
dapr run --app-id ordering-api --log-level info --log-as-json dotnet runIn Kubernetes, you can add a?dapr.io/log-as-json?annotation to each deployment for the application:
在 Kubernetes 中，可以將?dapr.io/log-as-json?注解添加到應用程序的每個部署：
annotations:dapr.io/enabled: "true"dapr.io/app-id: "ordering-api"dapr.io/app-port: "80"dapr.io/config: "dapr-config"dapr.io/log-as-json: "true"When you install Dapr in a Kubernetes cluster using Helm, you can enable JSON formatted logging for all the Dapr system services:
使用 Helm 在 Kubernetes 群集中安裝 Dapr 時，可以針對所有 Dapr 系統(tǒng)服務啟用 JSON 格式的日志記錄：
helm repo add dapr https://dapr.github.io/helm-charts/ helm repo update kubectl create namespace dapr-system helm install dapr dapr/dapr --namespace dapr-system --set global.logAsJson=trueCollect logs
收集日志
The logs emitted by Dapr can be fed into a monitoring back end for analysis. A log collector is a component that collects logs from a system and sends them to a monitoring back end. A popular log collector is?Fluentd. Check out the?How-To: Set up Fluentd, Elastic search and Kibana in Kubernetes?in the Dapr documentation. This article contains instructions for setting up Fluentd as log collector and the?ELK Stack?(Elastic Search and Kibana) as a monitoring back end.
Dapr 發(fā)出的日志可以饋入監(jiān)視后端進行分析。日志收集器是一個組件，用于從系統(tǒng)收集日志并將其發(fā)送到監(jiān)視后端。常用日志收集器是?Fluentd。請參閱 Dapr文檔中的如何：在 Kubernetes 中設(shè)置 Fluentd、Elastic search和 Kibana。?本文包含有關(guān)將 Fluentd 設(shè)置為日志收集器和?ELK Stack?(Elastic Search and Kibana) 作為監(jiān)視后端的說明。
Health status
運行狀況
The health status of a service provides insight into its availability. Each Dapr sidecar exposes a health API that can be used by the hosting environment to determine the health of the sidecar. The API has one operation:
服務的運行狀況提供其可用性的洞見。每個 Dapr sidecar 都公開一個運行狀況 API，宿主環(huán)境可以使用該 API 來確定 邊車的運行狀況。API 有一個操作：
GET http://localhost:3500/v1.0/healthzThe operation returns two HTTP status codes:
204: When the sidecar is healthy
500: when the sidecar isn't healthy
該操作返回兩個 HTTP 狀態(tài)碼：
204：邊車運行正常時
500：邊車運行不正常時
When running in self-hosted mode, the health API isn't automatically invoked. You can invoke the API though from application code or a health monitoring tool.
在自承載模式下運行時，不會自動調(diào)用運行狀況 API。不過，可以從應用程序代碼或運行狀況監(jiān)視工具調(diào)用 API。
When running in Kubernetes, the Dapr sidecar-injector automatically configures Kubernetes to use the health API for executing?liveness probes?and?readiness probes.
在 Kubernetes 中運行時，Dapr?sidecar-injector 會自動將 Kubernetes 配置為使用運行狀況 API 執(zhí)行存活探測?和?就緒探測。
Kubernetes uses liveness probes to determine whether a container is up and running. If a liveness probe returns a failure code, Kubernetes will assume the container is dead and automatically restart it. This feature increases the overall availability of your application.
Kubernetes 使用存活探測來確定容器是否已啟動并正在運行。如果存活探測返回失敗代碼，Kubernetes 將假定容器已死并自動重啟。此功能可提高應用程序的整體可用性。
Kubernetes uses readiness probes to determine whether a container is ready to start accepting traffic. A pod is considered ready when all of its containers are ready. Readiness determines whether a Kubernetes service can direct traffic to a pod in a load-balancing scenario. Pods that aren't ready are automatically removed from the load-balancer.
Kubernetes 使用就緒探測來確定容器是否已準備好通信。當 Pod 的所有容器都準備就緒時，它被視為已就緒。就緒探測確定 Kubernetes 服務是否可以與負載平衡方案中的 pod通信。未準備就緒的 pod 會自動從負載平衡器中刪除。
Liveness and readiness probes have several configurable parameters. Both are configured in the container spec p of a pod's manifest file. By default, Dapr uses the following configuration for each sidecar container:
存活和就緒探測具有多個可配置參數(shù)。這兩者都在 pod 的清單文件的 "容器規(guī)范" 部分中進行配置。默認情況下，Dapr 對每個邊車容器使用以下配置：
livenessProbe:httpGet:path: v1.0/healthzport: 3500initialDelaySeconds: 5periodSeconds: 10timeoutSeconds : 5failureThreshold : 3 readinessProbe:httpGet:path: v1.0/healthzport: 3500initialDelaySeconds: 5periodSeconds: 10timeoutSeconds : 5failureThreshold: 3The following parameters are available for the probes:
The?path?specifies the Dapr health API endpoint.
The?port?specifies the Dapr health API port.
The?initialDelaySecondsspecifies the number of seconds Kubernetes will wait before it starts probing a container for the first time.
The?periodSeconds?specifies the number of seconds Kubernetes will wait between each probe.
The?timeoutSeconds?specifies the number of seconds Kubernetes will wait on a response from the API before timing out. A timeout is interpreted as a failure.
The?failureThresholdspecifies the number of failed status code Kubernetes will accept before considering the container not alive or not ready.
以下參數(shù)可用于探測：
path指定 Dapr HEALTH API 終結(jié)點。
port指定 Dapr HEALTH API 端口。
initialDelaySeconds指定 Kubernetes 第一次開始探測容器前等待的秒數(shù)。
periodSeconds指定 Kubernetes 將在每個探測之間等待的秒數(shù)。
timeoutSeconds指定 Kubernetes 將在超時前等待 API 響應的秒數(shù)。超時被解釋為失敗。
failureThreshold指定在Kubernetes 認為容器失活或尚未就緒之前的次數(shù)。
Dapr dashboard
Dapr 儀表板
Dapr offers a dashboard that presents status information on Dapr applications, components, and configurations. Use the Dapr CLI to start the dashboard as a web-application on the local machine on port 8080:
Dapr 提供了一個儀表板，用于顯示Dapr 應用程序、組件和配置的狀態(tài)信息。使用 Dapr CLI 將儀表板作為本地計算機上的 web 應用程序在8080端口上啟動：
dapr dashboardFor Dapr application running in Kubernetes, use the following command:
對于在 Kubernetes 中運行的 Dapr 應用程序，請使用以下命令：
dapr dashboard -kThe dashboard opens with an overview of all services in your application that have a Dapr sidecar. The following screenshot shows the Dapr dashboard for the eShopOnDapr application running in Kubernetes:
打開儀表板，其中概述了應用程序中具有 Dapr 邊車的所有服務。以下屏幕截圖顯示了 Kubernetes 中運行的 eShopOnDapr 應用程序的 Dapr 儀表板：
The Dapr dashboard is invaluable when troubleshooting a Dapr application. It provides information about Dapr sidecars and system services. You can drill down into the configuration of each service, including the logging entries.
在對 Dapr 應用程序進行故障排除時，Dapr 儀表板非常有用。它提供 Dapr 邊車和系統(tǒng)服務的有關(guān)信息。可以向下鉆取到每個服務的配置，包括日志記錄條目。
The dashboard also shows the configured components (and their configuration) for your application:
儀表板還顯示應用程序已配置的組件 (及其配置)：
There's a large amount of information available through the dashboard. You can discover it by running a Dapr application and browsing the dashboard. You can use the accompanying eShopOnDapr application to start.
可以通過儀表板獲取大量信息。可以通過運行 Dapr 應用程序并瀏覽儀表板來發(fā)現(xiàn)它。可以使用隨附的 eShopOnDapr 應用程序來開啟。
Check out the?Dapr dashboard CLI command reference?in the Dapr docs for more information on the Dapr dashboard commands.
有關(guān)?Dapr 儀表板命令?詳細信息，請查看 Dapr 文檔中的 Dapr 儀表板 CLI 命令參考。
Use the Dapr .NET SDK
使用 Dapr .NET SDK
The Dapr .NET SDK doesn't contain any specific observability features. All observability features are offered at the Dapr level.
Dapr .NET SDK 不包含任何特定的可觀測性功能。所有可觀測性功能在 Dapr 級別提供。
If you want to emit telemetry from your .NET application code, you should consider the?OpenTelemetry SDK for .NET. The Open Telemetry project is cross-platform, open source, and vendor agnostic. It provides an end-to-end implementation to generate, emit, collect, process, and export telemetry data. There's a single instrumentation library per language that supports automatic and manual instrumentation. Telemetry is published using the Open Telemetry standard. The project has broad industry support and adoption from cloud providers, vendors, and end users.
如果要從 .NET 應用程序代碼發(fā)出遙測，應考慮?使用 OpenTelemetry SDK for .NET。Open Telemetry 項目是跨平臺、開源和供應商無關(guān)的。它提供端到端實現(xiàn)，用于生成、發(fā)出、收集、處理和導出遙測數(shù)據(jù)。每種語言有一個支持自動和手動檢測的檢測庫。遙測是使用開放遙測標準發(fā)布的。該項目受廣泛的行業(yè)（來自云提供商、供應商和最終用戶）支持和采用。
Reference application: eShopOnDapr
參考應用程序：eShopOnDapr
Observability in accompanying eShopOnDapr reference application consists of several parts. Telemetry from all of the sidecars is captured. Additionally, there are other observability features inherited from the earlier eShopOnContainers sample.
隨附的 eShopOnDapr 參考應用程序中的可觀測性由多個部分組成。捕獲來自所有 邊車的遙測數(shù)據(jù)。此外，還有其他可觀察性功能，這些功能繼承自早期的 eShopOnContainers 示例。
Custom health dashboard
自定義運行狀況儀表板
The?WebStatus?project in eShopOnDapr is a custom health dashboard that gives insight into the health of the eShop services. This dashboard doesn't use the Dapr health API but uses the built-in?health checks mechanism?of ASP.NET Core. The dashboard not only provides the health status of the services, but also the health of the dependencies of the services. For example, a service that uses a database also provides the health status of this database as shown in the following screenshot:
eShopOnDapr 中的 WebStatus 項目是一個自定義運行狀況儀表板，可讓你深入了解 eShop 服務的運行狀況。此儀表板不使用 Dapr health API，但使用 ASP.NET Core 的內(nèi)置?運行狀況檢查機制?。該儀表板不僅提供服務的運行狀況狀態(tài)，還提供服務依賴項的運行狀況。例如，使用數(shù)據(jù)庫的服務還提供此數(shù)據(jù)庫的運行狀況狀態(tài)，如以下屏幕截圖所示：
Seq log aggregator
Seq 日志聚合器
Seq?is a popular log aggregator server that is used in eShopOnDapr to aggregate logs. Seq ingests logging from application services, but not from Dapr system services or sidecars. Seq indexes application logging and offers a web front end for analyzing and querying the logs. It also offers functionality for building monitoring dashboards.
Seq?是在 eShopOnDapr 中用于聚合日志的常用日志聚合服務。Seq 從應用程序服務中攝入日志記錄，而不是從 Dapr 系統(tǒng)服務或邊車。Seq 檢索應用程序日志記錄，提供一個 web 前端用于分析和查詢?nèi)罩尽Ｋ€提供了用于構(gòu)建監(jiān)視儀表板的功能。
The eShopOnDapr application services emit structured logging using the?SeriLog?logging library. Serilog publishes log events to a construct called a?sink. A sink is simply a target platform to which Serilog writes its logging events.?Many Serilog sinks are available, including one for Seq. Seq is the Serilog sink used in eShopOnDapr.
eShopOnDapr 應用程序服務使用?SeriLog?日志記錄庫發(fā)出結(jié)構(gòu)化日志記錄。Serilog 將日志事件發(fā)布到"接收器"。接收器只是 Serilog 日志記錄事件的目標寫入平臺。有許多 Serilog 接收器都可供使用，包括 Seq 接收器。Seq 是 eShopOnDapr 中使用的 Serilog 接收器。
Application Insights
eShopOnDapr services also send telemetry directly to Azure Application Insights using the Microsoft Application Insights SDK for .NET Core. For more information, see?Azure Application Insights for ASP.NET Core applications?in the Microsoft docs.
eShopOnDapr 服務還使用適用于 .NET Core 的 Microsoft Application Insights SDK 將遙測直接發(fā)送到 Azure Application Insights。有關(guān)詳細信息，請參閱 Microsoft 文檔中的?Azure Application Insights?for ASP.NET Core 應用程序?。
Summary
總結(jié)
Good observability is crucial when running a distributed system in production.
在生產(chǎn)環(huán)境中運行分布式系統(tǒng)時，良好的可觀察性是至關(guān)重要的。
Dapr provides different types of telemetry, including distributed tracing, logging, metrics, and health status.
Dapr 提供不同類型的遙測，包括分布式跟蹤、日志記錄、指標和運行狀況。
Dapr only produces telemetry for the Dapr system services and sidecars. Telemetry from your application code isn't automatically included. You can however use a specific SDK like the OpenTelemetry SDK for .NET to emit telemetry from your application code.
Dapr 僅為 Dapr 系統(tǒng)服務和邊車生成遙測數(shù)據(jù)。不會自動包含來自應用程序代碼的遙測數(shù)據(jù)。但是，可以使用 OpenTelemetry SDK for .NET 等特定 SDK 從應用程序代碼發(fā)出遙測數(shù)據(jù)。
Dapr telemetry is produced in an open-standards based format so it can be ingested by a large set of available monitoring tools. Some examples are: Zipkin, Azure Application Insights, the ELK Stack, New Relic, and Grafana. See?Monitor your application with Dapr?in the Dapr documentation for tutorials on how to monitor your Dapr applications with specific monitoring back ends.
Dapr 遙測以基于開放標準的格式生成，因此可以被大量可用的監(jiān)視工具攝入（接收）。一些示例包括：Zipkin、Azure Application Insights、ELK Stack、New Relic和 Grafana。請參閱 Dapr 文檔中的使用 Dapr 監(jiān)視應用程序來了解演練如何使用特定監(jiān)控后端監(jiān)視Dapr應用。
You'll need a telemetry scraper that ingests telemetry and publishes it to the monitoring back end.
你需要一個遙測抓取器，攝入遙測數(shù)據(jù)并將遙測數(shù)據(jù)發(fā)布到監(jiān)視后端。
Dapr can be configured to emit structured logging. Structured logging is favored as it can be indexed by back-end monitoring tools. Indexed logging enables users to execute rich queries when searching through the logging.
Dapr 可以配置為發(fā)出結(jié)構(gòu)化日志記錄。結(jié)構(gòu)化日志記錄更受歡迎，因為它可以被后端監(jiān)視工具檢索。索引化日志記錄使用戶能夠在搜索日志記錄時執(zhí)行富查詢。
Dapr offers a dashboard that presents information about the Dapr services and configuration.
Dapr 提供一個儀表板，用于顯示有關(guān) Dapr 服務和配置的信息。
目錄：
面向.NET開發(fā)人員的Dapr——前言
面向.NET開發(fā)人員的Dapr——分布式世界
面向.NET開發(fā)人員的Dapr——俯瞰Dapr
面向.NET開發(fā)人員的Dapr——入門
面向.NET開發(fā)人員的Dapr——參考應用程序
面向.NET開發(fā)人員的Dapr——狀態(tài)管理
面向.NET開發(fā)人員的Dapr——發(fā)布和訂閱
面向.NET開發(fā)人員的Dapr——綁定
總結(jié)
以上是生活随笔為你收集整理的面向.NET开发人员的Dapr——可观察性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面向.NET开发人员的Dapr——机密
- 下一篇： 面向.NET开发人员的Dapr——绑定