dapr, which I have been following for some time, has been officially released in v1.0 (in fact, v1.0.1 was updated when this article was published), which means that
dapr has entered a stable state to some extent and can be tried in practice. As a project I’ve been following, I tried it out in the first place and tried to introduce it into a real project, and this article is some preliminary testing for that.
What is dapr?
dapr was first open sourced by Microsoft, a portable, event-driven program runtime that makes it easy for any developer to build resilient, stateless/stateful applications running in the cloud and on the edge, with the flexibility to support multiple development languages. In other words, in my opinion,
dapr can be seen and handled as a
serverless landing solution for programs that are only concerned with the provided store and message queue interfaces and don’t need to care about more than the architectural level.
However, in the official example tutorial, the environment used is a container environment to deploy and manage dapr. In fact,
dapr can be configured to run in self-hosted mode on the local machine, except in a container environment or container cluster environment.
dapr installation can be done with the official
dapr-cli, which can be quickly installed with the one-click install command.
You can confirm that the
dapr-cli program was installed successfully by entering the
Next, use dapr-cli to install all runtime and other applications.
In the official documentation, if you choose to initialize with the
dapr-cli will automatically try to use the container environment to manage related programs, and will only choose to run locally if you add the
-slim argument. See the
dapr help init help for more information on usage. By default, program-related content is installed in the
$HOME/.dapr directory, here I used the
root user for simplicity, so the program command directory is
/root/.dapr/bin, and the following commands are installed.
From the file name you can see that
daprd is the deamon process,
dashboard is the management panel, and
placement is the tool used to manage the
actor distribution scheme and key range. The official documentation mentions that
Reids will be used as the default storage and pub/sub components after installation, but my actual installation is actually not there, I don’t know if the documentation is a bit out of date. If you start the program and try to save the data in the store according to the official documentation example, you will get an error.
But actually adding components is relatively easy in
dapr, by adding the corresponding
yaml file under
Adding Redis as a component
We can find a
Redis component configuration template in the
official documentation that It can be quickly used to.
Of course, we can also use the
Redis Stream function to do pub/sub functions, although this function has been GA, but because of the characteristics of
Redis Stream, you need to be careful with this function, here just because it is a demonstration so it does not matter.
Here we have defined a
redis-store, so we need to modify the above command.
You can also get the content stored in
When we added
Redis as storage, we also added
Redis to support publish/subscribe functionality. Here you may need to write additional programs to implement it. Let’s use the official example here. There are two types of subscriptions in
dapr, one is in the form of a
yaml declaration component, and the other can be implemented by writing code. Of course, the first and second approaches have advantages and disadvantages, the former being more suitable for seamless integration and the latter for development control. Here, for the sake of intuitiveness, we directly use the code-writing approach.
Start the compiled
daprdemo with the following command, note that you need to fill in the path when specifying the file name or in
In the program startup log we can see that
dapr tries to access some default
endpoint to read possible configurations.
Next we try to use
dapr-cli to send a message to the
myapp we started earlier.
The output obtained in the program log is .
Of course, in addition to the pub/sub approach, we can also use the routing capabilities provided by
dapr to make service calls directly.
Other component functions can be configured by referring to the description in the official documentation.
dapr is a powerful
serverless runtime that, in addition to the above-mentioned message- and request-store-oriented features, can also control
HTTP requests and
gRPC requests of an application, etc. In addition to these features, service management is included, as well as observability support, making it a very promising runtime choice.