mirror of https://github.com/dapr/docs.git
Merge branch 'v1.13' into issue_4025
This commit is contained in:
Hannah Hunter
GitHub
commit
60b68c42bb
|
|
@ -1,5 +1,7 @@
|
|||
# Dapr documentation
|
||||
|
||||
[](https://github.com/dapr/docs/blob/v1.13/LICENSE) [](https://github.com/dapr/docs/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) [](http://bit.ly/dapr-discord) [](https://youtube.com/@daprdev) [](https://twitter.com/daprdev)
|
||||
|
||||
If you are looking to explore the Dapr documentation, please go to the documentation website:
|
||||
|
||||
[**https://docs.dapr.io**](https://docs.dapr.io)
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ We welcome community members giving presentations on Dapr and spreading the word
|
|||
{{% alert color="primary" %}}
|
||||
If you're using the PowerPoint template with MacOS, please install the Space Grotesk font to ensure the text is rendered properly:
|
||||
```sh
|
||||
brew install --cask homebrew/cask-fonts/font-space-grotesk
|
||||
brew install --cask font-space-grotesk
|
||||
```
|
||||
{{% /alert %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -52,6 +52,12 @@ You would use Dapr Workflow when you need to define and orchestrate complex work
|
|||
|
||||
[Learn more about Dapr Workflow and how to use workflows in your application.]({{< ref workflow-overview.md >}})
|
||||
|
||||
## Actor types and actor IDs
|
||||
|
||||
Actors are uniquely defined as an instance of an actor type, similar to how an object is an instance of a class. For example, you might have an actor type that implements the functionality of a calculator. There could be many actors of that type distributed across various nodes in a cluster.
|
||||
|
||||
Each actor is uniquely identified by an actor ID. An actor ID can be _any_ string value you choose. If you do not provide an actor ID, Dapr generates a random string for you as an ID.
|
||||
|
||||
## Features
|
||||
|
||||
### Actor lifetime
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ scopes:
|
|||
|
||||
In the programmatic approach, the `routes` structure is returned instead of `route`. The JSON structure matches the declarative YAML:
|
||||
|
||||
{{< tabs Python Node "C#" Go PHP>}}
|
||||
{{< tabs Python JavaScript ".NET" Go PHP>}}
|
||||
|
||||
{{% codetab %}}
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -69,17 +69,17 @@ The table below shows which applications are allowed to publish into the topics:
|
|||
|
||||
| | topic1 | topic2 | topic3 |
|
||||
|------|--------|--------|--------|
|
||||
| app1 | X | | |
|
||||
| app2 | | X | X |
|
||||
| app1 | ✅ | | |
|
||||
| app2 | | ✅ | ✅ |
|
||||
| app3 | | | |
|
||||
|
||||
The table below shows which applications are allowed to subscribe to the topics:
|
||||
|
||||
| | topic1 | topic2 | topic3 |
|
||||
|------|--------|--------|--------|
|
||||
| app1 | X | X | X |
|
||||
| app1 | ✅ | ✅ | ✅ |
|
||||
| app2 | | | |
|
||||
| app3 | X | | |
|
||||
| app3 | ✅ | | |
|
||||
|
||||
> Note: If an application is not listed (e.g. app1 in subscriptionScopes) it is allowed to subscribe to all topics. Because `allowedTopics` is not used and app1 does not have any subscription scopes, it can also use additional topics not listed above.
|
||||
|
||||
|
|
@ -143,17 +143,17 @@ The table below shows which application is allowed to publish into the topics:
|
|||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | X | | |
|
||||
| app2 | X | X | |
|
||||
| app3 | X | X | |
|
||||
| app1 | ✅ | | |
|
||||
| app2 | ✅ | ✅ | |
|
||||
| app3 | ✅ | ✅ | |
|
||||
|
||||
The table below shows which application is allowed to subscribe to the topics:
|
||||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | | | |
|
||||
| app2 | X | | |
|
||||
| app3 | X | X | |
|
||||
| app2 | ✅ | | |
|
||||
| app3 | ✅ | ✅ | |
|
||||
|
||||
## Example 4: Mark topics as protected
|
||||
|
||||
|
|
@ -187,17 +187,17 @@ The table below shows which application is allowed to publish into the topics:
|
|||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | X | X | |
|
||||
| app2 | | X | |
|
||||
| app3 | | | X |
|
||||
| app1 | ✅ | ✅ | |
|
||||
| app2 | | ✅ | |
|
||||
| app3 | | | ✅ |
|
||||
|
||||
The table below shows which application is allowed to subscribe to the topics:
|
||||
|
||||
| | A | B | C |
|
||||
|------|---|---|---|
|
||||
| app1 | X | X | |
|
||||
| app2 | | X | |
|
||||
| app3 | | | X |
|
||||
| app1 | ✅ | ✅ | |
|
||||
| app2 | | ✅ | |
|
||||
| app3 | | | ✅ |
|
||||
|
||||
|
||||
## Demo
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ There are two ways to invoke a non-Dapr endpoint when communicating either to Da
|
|||
```
|
||||
|
||||
### Using appId when calling Dapr enabled applications
|
||||
AppIDs are always used to call Dapr applications with the `appID` and `my-method``. Read the [How-To: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}}) guide for more information. For example:
|
||||
AppIDs are always used to call Dapr applications with the `appID` and `my-method`. Read the [How-To: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}}) guide for more information. For example:
|
||||
|
||||
```sh
|
||||
localhost:3500/v1.0/invoke/<appID>/method/<my-method>
|
||||
|
|
|
|||
|
|
@ -537,7 +537,7 @@ Try getting state again. Note that no value is returned.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for saving and retrieving multiple states.
|
||||
|
||||
{{< tabs Dotnet Java Python Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -656,6 +656,56 @@ dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-g
|
|||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
// dependencies
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"math/rand"
|
||||
"strconv"
|
||||
"time"
|
||||
|
||||
dapr "github.com/dapr/go-sdk/client"
|
||||
)
|
||||
|
||||
// code
|
||||
func main() {
|
||||
const STATE_STORE_NAME = "statestore"
|
||||
rand.Seed(time.Now().UnixMicro())
|
||||
for i := 0; i < 10; i++ {
|
||||
orderId := rand.Intn(1000-1) + 1
|
||||
client, err := dapr.NewClient()
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer client.Close()
|
||||
ctx := context.Background()
|
||||
err = client.SaveState(ctx, STATE_STORE_NAME, "order_1", []byte(strconv.Itoa(orderId)), nil)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
keys := []string{"key1", "key2", "key3"}
|
||||
items, err := client.GetBulkState(ctx, STATE_STORE_NAME, keys, nil, 100)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
for _, item := range items {
|
||||
log.Println("Item from GetBulkState:", string(item.Value))
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To launch a Dapr sidecar for the above example application, run a command similar to the following:
|
||||
|
||||
```bash
|
||||
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-grpc-port 60001 go run OrderProcessingService.go
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```javascript
|
||||
//dependencies
|
||||
import { DaprClient, HttpMethod, CommunicationProtocolEnum } from '@dapr/dapr';
|
||||
|
|
@ -738,7 +788,7 @@ State transactions require a state store that supports multi-item transactions.
|
|||
|
||||
Below are code examples that leverage Dapr SDKs for performing state transactions.
|
||||
|
||||
{{< tabs Dotnet Java Python Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -893,6 +943,79 @@ dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-g
|
|||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
// dependencies
|
||||
package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"math/rand"
|
||||
"strconv"
|
||||
"time"
|
||||
|
||||
dapr "github.com/dapr/go-sdk/client"
|
||||
)
|
||||
|
||||
// code
|
||||
func main() {
|
||||
const STATE_STORE_NAME = "statestore"
|
||||
rand.Seed(time.Now().UnixMicro())
|
||||
for i := 0; i < 10; i++ {
|
||||
orderId := rand.Intn(1000-1) + 1
|
||||
client, err := dapr.NewClient()
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer client.Close()
|
||||
ctx := context.Background()
|
||||
err = client.SaveState(ctx, STATE_STORE_NAME, "order_1", []byte(strconv.Itoa(orderId)), nil)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
result, err := client.GetState(ctx, STATE_STORE_NAME, "order_1", nil)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
ops := make([]*dapr.StateOperation, 0)
|
||||
data1 := "data1"
|
||||
data2 := "data2"
|
||||
|
||||
op1 := &dapr.StateOperation{
|
||||
Type: dapr.StateOperationTypeUpsert,
|
||||
Item: &dapr.SetStateItem{
|
||||
Key: "key1",
|
||||
Value: []byte(data1),
|
||||
},
|
||||
}
|
||||
op2 := &dapr.StateOperation{
|
||||
Type: dapr.StateOperationTypeDelete,
|
||||
Item: &dapr.SetStateItem{
|
||||
Key: "key2",
|
||||
Value: []byte(data2),
|
||||
},
|
||||
}
|
||||
ops = append(ops, op1, op2)
|
||||
meta := map[string]string{}
|
||||
err = client.ExecuteStateTransaction(ctx, STATE_STORE_NAME, meta, ops)
|
||||
|
||||
log.Println("Result after get:", string(result.Value))
|
||||
time.Sleep(2 * time.Second)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To launch a Dapr sidecar for the above example application, run a command similar to the following:
|
||||
|
||||
```bash
|
||||
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3601 --dapr-grpc-port 60001 go run OrderProcessingService.go
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```javascript
|
||||
//dependencies
|
||||
import { DaprClient, HttpMethod, CommunicationProtocolEnum } from '@dapr/dapr';
|
||||
|
|
|
|||
|
|
@ -6,9 +6,6 @@ description: "Access Dapr capabilities from your Azure Functions runtime applica
|
|||
weight: 3000
|
||||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
The Dapr extension for Azure Functions is currently in preview.
|
||||
{{% /alert %}}
|
||||
|
||||
Dapr integrates with the [Azure Functions runtime](https://learn.microsoft.com/azure/azure-functions/functions-overview) via an extension that lets a function seamlessly interact with Dapr.
|
||||
- **Azure Functions** provides an event-driven programming model.
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ dapr run -f <dir_path>
|
|||
<!--kubernetes-->
|
||||
|
||||
```cmd
|
||||
dapr run -f -k <dir_path>
|
||||
dapr run -f <dir_path> -k
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ dapr run -f ./path/to/<your-preferred-file-name>.yaml
|
|||
<!--kubernetes-->
|
||||
|
||||
```cmd
|
||||
dapr run -f -k ./path/to/<your-preferred-file-name>.yaml
|
||||
dapr run -f ./path/to/<your-preferred-file-name>.yaml -k
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
|
|
@ -77,10 +77,27 @@ dapr run -f -k ./path/to/<your-preferred-file-name>.yaml
|
|||
|
||||
Once the multi-app template is running, you can view the started applications with the following command:
|
||||
|
||||
{{< tabs Self-hosted Kubernetes>}}
|
||||
|
||||
{{% codetab %}}
|
||||
<!--selfhosted-->
|
||||
|
||||
```cmd
|
||||
dapr list
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
<!--kubernetes-->
|
||||
|
||||
```cmd
|
||||
dapr list -k
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Stop the multi-app template
|
||||
|
||||
Stop the multi-app run template anytime with either of the following commands:
|
||||
|
|
@ -109,12 +126,12 @@ dapr stop -f ./path/to/<your-preferred-file-name>.yaml
|
|||
```cmd
|
||||
# the template file needs to be called `dapr.yaml` by default if a directory path is given
|
||||
|
||||
dapr stop -f -k
|
||||
dapr stop -f <dir_path> -k
|
||||
```
|
||||
or:
|
||||
|
||||
```cmd
|
||||
dapr stop -f -k ./path/to/<your-preferred-file-name>.yaml
|
||||
dapr stop -f ./path/to/<your-preferred-file-name>.yaml -k
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
|
|||
|
|
@ -75,15 +75,14 @@ spec:
|
|||
type: bindings.azure.servicebusqueues
|
||||
version: v1
|
||||
metadata:
|
||||
-name: connectionString
|
||||
secretKeyRef:
|
||||
- name: connectionString
|
||||
secretKeyRef:
|
||||
name: asbNsConnString
|
||||
key: asbNsConnString
|
||||
-name: queueName
|
||||
value: servicec-inputq
|
||||
- name: queueName
|
||||
value: servicec-inputq
|
||||
auth:
|
||||
secretStore: <SECRET_STORE_NAME>
|
||||
|
||||
```
|
||||
The above "Secret is a string" case yaml tells Dapr to extract a connection string named `asbNsConnstring` from the defined `secretStore` and assign the value to the `connectionString` field in the component since there is no key embedded in the "secret" from the `secretStore` because it is a plain string. This requires the secret `name` and secret `key` to be identical.
|
||||
|
||||
|
|
@ -95,7 +94,7 @@ The following example shows you how to create a Kubernetes secret to hold the co
|
|||
|
||||
1. First, create the Kubernetes secret:
|
||||
```bash
|
||||
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
|
||||
kubectl create secret generic eventhubs-secret --from-literal=connectionString=*********
|
||||
```
|
||||
|
||||
2. Next, reference the secret in your binding:
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Since you are running Dapr in the same host as the component, verify that this f
|
|||
|
||||
### Component discovery and multiplexing
|
||||
|
||||
A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
|
||||
A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs. During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
|
||||
|
||||
Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ The table below shows which resources are deployed to which namespaces:
|
|||
|
||||
| Resource | namespace-a | namespace-b |
|
||||
|------------------------ |-------------|-------------|
|
||||
| Redis master | X | |
|
||||
| Redis replicas | X | |
|
||||
| Dapr's PubSub component | X | X |
|
||||
| Node subscriber | X | |
|
||||
| Python subscriber | X | |
|
||||
| React UI publisher | | X |
|
||||
| Redis master | ✅ | ❌ |
|
||||
| Redis replicas | ✅ | ❌ |
|
||||
| Dapr's PubSub component | ✅ | ✅ |
|
||||
| Node subscriber | ✅ | ❌ |
|
||||
| Python subscriber | ✅ | ❌ |
|
||||
| React UI publisher | ❌ | ✅ |
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
All pub/sub components support limiting pub/sub topics to specific applications using [namespace or component scopes]({{< ref pubsub-scopes.md >}}).
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ spec:
|
|||
tracing:
|
||||
samplingRate: "1"
|
||||
otel:
|
||||
endpointAddress: "https://..."
|
||||
endpointAddress: "myendpoint.cluster.local:4317"
|
||||
zipkin:
|
||||
endpointAddress: "https://..."
|
||||
|
||||
|
|
@ -32,10 +32,10 @@ The following table lists the properties for tracing:
|
|||
|--------------|--------|-------------|
|
||||
| `samplingRate` | string | Set sampling rate for tracing to be enabled or disabled.
|
||||
| `stdout` | bool | True write more verbose information to the traces
|
||||
| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) server address.
|
||||
| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) target hostname and optionally port. If this is used, you do not need to specify the 'zipkin' section.
|
||||
| `otel.isSecure` | bool | Is the connection to the endpoint address encrypted.
|
||||
| `otel.protocol` | string | Set to `http` or `grpc` protocol.
|
||||
| `zipkin.endpointAddress` | string | Set the Zipkin server address. If this is used, you do not need to specify the `otel` section.
|
||||
| `zipkin.endpointAddress` | string | Set the Zipkin server URL. If this is used, you do not need to specify the `otel` section.
|
||||
|
||||
To enable tracing, use a configuration file (in self hosted mode) or a Kubernetes configuration object (in Kubernetes mode). For example, the following configuration object changes the sample rate to 1 (every span is sampled), and sends trace using OTEL protocol to the OTEL server at localhost:4317
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ turns on tracing for the sidecar.
|
|||
|
||||
| Environment Variable | Description |
|
||||
|----------------------|-------------|
|
||||
| `OTEL_EXPORTER_OTLP_ENDPOINT` | Sets the Open Telemetry (OTEL) server address, turns on tracing |
|
||||
| `OTEL_EXPORTER_OTLP_ENDPOINT` | Sets the Open Telemetry (OTEL) server hostname and optionally port, turns on tracing |
|
||||
| `OTEL_EXPORTER_OTLP_INSECURE` | Sets the connection to the endpoint as unencrypted (true/false) |
|
||||
| `OTEL_EXPORTER_OTLP_PROTOCOL` | Transport protocol (`grpc`, `http/protobuf`, `http/json`) |
|
||||
|
||||
|
|
|
|||
|
|
@ -45,6 +45,8 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
|
||||
| Release date | Runtime | CLI | SDKs | Dashboard | Status | Release notes |
|
||||
|--------------------|:--------:|:--------|---------|---------|---------|------------|
|
||||
| May 29th 2024 | 1.13.4</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.4 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.4) |
|
||||
| May 21st 2024 | 1.13.3</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.3) |
|
||||
| April 3rd 2024 | 1.13.2</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.2) |
|
||||
| March 26th 2024 | 1.13.1</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.1 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.1) |
|
||||
| March 6th 2024 | 1.13.0</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.0 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.0) |
|
||||
|
|
@ -136,6 +138,8 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h
|
|||
| 1.11.0 | N/A | 1.11.4 |
|
||||
| 1.12.0 | N/A | 1.12.4 |
|
||||
| 1.13.0 | N/A | 1.13.2 |
|
||||
| 1.13.0 | N/A | 1.13.3 |
|
||||
| 1.13.0 | N/A | 1.13.4 |
|
||||
|
||||
## Upgrade on Hosting platforms
|
||||
|
||||
|
|
|
|||
|
|
@ -177,7 +177,15 @@ Example:
|
|||
{
|
||||
"pubsubname": "pubsub",
|
||||
"topic": "newOrder",
|
||||
"route": "/orders",
|
||||
"routes": {
|
||||
"rules": [
|
||||
{
|
||||
"match": "event.type == order",
|
||||
"path": "/orders"
|
||||
}
|
||||
]
|
||||
"default" : "/otherorders"
|
||||
},
|
||||
"metadata": {
|
||||
"rawPayload": "true"
|
||||
}
|
||||
|
|
@ -197,7 +205,7 @@ Parameter | Description
|
|||
|
||||
### Provide route(s) for Dapr to deliver topic events
|
||||
|
||||
In order to deliver topic events, a `POST` call will be made to user code with the route specified in the subscription response.
|
||||
In order to deliver topic events, a `POST` call will be made to user code with the route specified in the subscription response. Under `routes`, you can provide [rules that match a certain condition to a specific path when a message topic is received.]({{< ref "howto-route-messages.md" >}}) You can also provide a default route for any rules that do not have a specific match.
|
||||
|
||||
The following example illustrates this point, considering a subscription for topic `newOrder` with route `orders` on port 3000: `POST http://localhost:3000/orders`
|
||||
|
||||
|
|
|
|||
|
|
@ -71,10 +71,10 @@ dapr init -s
|
|||
|
||||
**Specify a runtime version**
|
||||
|
||||
You can also specify a specific runtime version. Be default, the latest version is used.
|
||||
You can also specify a specific runtime version. By default, the latest version is used.
|
||||
|
||||
```bash
|
||||
dapr init --runtime-version 1.13.0
|
||||
dapr init --runtime-version 1.13.4
|
||||
```
|
||||
|
||||
**Install with image variant**
|
||||
|
|
|
|||
|
|
@ -175,7 +175,9 @@ az cosmosdb sql role assignment create \
|
|||
--role-definition-id "$ROLE_ID"
|
||||
```
|
||||
|
||||
## Optimizing Cosmos DB for bulk operation write performance
|
||||
## Optimizations
|
||||
|
||||
### Optimizing Cosmos DB for bulk operation write performance
|
||||
|
||||
If you are building a system that only ever reads data from Cosmos DB via key (`id`), which is the default Dapr behavior when using the state management API or actors, there are ways you can optimize Cosmos DB for improved write speeds. This is done by excluding all paths from indexing. By default, Cosmos DB indexes all fields inside of a document. On systems that are write-heavy and run little-to-no queries on values within a document, this indexing policy slows down the time it takes to write or update a document in Cosmos DB. This is exacerbated in high-volume systems.
|
||||
|
||||
|
|
@ -211,6 +213,18 @@ This optimization comes at the cost of queries against fields inside of document
|
|||
|
||||
{{% /alert %}}
|
||||
|
||||
### Optimizing Cosmos DB for cost savings
|
||||
|
||||
If you intend to use Cosmos DB only as a key-value pair, it may be in your interest to consider converting your state object to JSON and compressing it before persisting it to state, and subsequently decompressing it when reading it out of state. This is because Cosmos DB bills your usage based on the maximum number of RU/s used in a given time period (typically each hour). Furthermore, RU usage is calculated as 1 RU per 1 KB of data you read or write. Compression helps by reducing the size of the data stored in Cosmos DB and subsequently reducing RU usage.
|
||||
|
||||
This savings is particularly significant for Dapr actors. While the Dapr State Management API does a base64 encoding of your object before saving, Dapr actor state is saved as raw, formatted JSON. This means multiple lines with indentations for formatting. Compressing can signficantly reduce the size of actor state objects. For example, if you have an actor state object that is 75KB in size when the actor is hydrated, you will use 75 RU/s to read that object out of state. If you then modify the state object and it grows to 100KB, you will use 100 RU/s to write that object to Cosmos DB, totalling 175 RU/s for the I/O operation. Let's say your actors are concurrently handling 1000 requests per second, you will need at least 175,000 RU/s to meet that load. With effective compression, the size reduction can be in the region of 90%, which means you will only need in the region of 17,500 RU/s to meet the load.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
|
||||
This particular optimization only makes sense if you are saving large objects to state. The performance and memory tradeoff for performing the compression and decompression on either end need to make sense for your use case. Furthermore, once the data is saved to state, it is not human readable, nor is it queryable. You should only adopt this optimization if you are saving large state objects as key-value pairs.
|
||||
|
||||
{{% /alert %}}
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.0{{ else if .Get "cli" }}1.13.0{{ else }}1.13.0{{ end -}}
|
||||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.4{{ else }}1.13.4{{ end -}}
|
||||
|
|
@ -17,8 +17,8 @@ data:
|
|||
zpages:
|
||||
endpoint: :55679
|
||||
exporters:
|
||||
logging:
|
||||
loglevel: debug
|
||||
debug:
|
||||
verbosity: basic
|
||||
azuremonitor:
|
||||
endpoint: "https://dc.services.visualstudio.com/v2/track"
|
||||
instrumentation_key: "<INSTRUMENTATION-KEY>"
|
||||
|
|
@ -33,7 +33,7 @@ data:
|
|||
pipelines:
|
||||
traces:
|
||||
receivers: [zipkin]
|
||||
exporters: [azuremonitor,logging]
|
||||
exporters: [azuremonitor,debug]
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
|
|
@ -71,7 +71,7 @@ spec:
|
|||
spec:
|
||||
containers:
|
||||
- name: otel-collector
|
||||
image: otel/opentelemetry-collector-contrib:0.77.0
|
||||
image: otel/opentelemetry-collector-contrib:0.101.0
|
||||
command:
|
||||
- "/otelcol-contrib"
|
||||
- "--config=/conf/otel-collector-config.yaml"
|
||||
|
|
|
|||
Binary file not shown.
Loading…
Reference in New Issue