“What will be hot and what to learn in 2022? This article is participating in the” Talk about 2022 Technology Trends “essay campaign.

原文 : Why You Should Use Microsoft Dapr to Build event-driven Microservices

By Dunith Dhanushka

Microservices architecture is distributed by nature. Building microservices has always been challenging, such as elastic service invocation, distributed transaction processing, on-demand scaling, and exact-once message processing. Putting microservices on Kubernetes is not a silver bullet to solve these problems because Kubernetes has no application logic. Frameworks like Spring Boot, Akka, and Quarkus are useful for building distributed microservices architectures, but they are coupled to specific programming languages.

Therefore, we are also looking for portable runtimes to build distributed, scalable, and event-driven microservices.

Dapr distributed application runtime

Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless, and stateful applications that run in the cloud and on the edge, and supports multiple languages and development frameworks.

Here, in my opinion, are the key points in which Dapr has an edge over its competitors.

Dapr has pre-built components to solve a common set of problems.

Dapr codifies best practices for building microservice applications into open, stand-alone building blocks to solve everyday problems such as state management, event handling, binding with external systems, actors, and more.

Each building block is completely independent, and you can use any part or all of it in your application.

The building blocks of Dapr

Dapr is portable

The building blocks mentioned above can be used as a portable runtime. Specifically, Dapr operates as a Sidecar, allowing our applications to interact with it through standard HTTP and gRPC interfaces. This allows developers to build portable applications in their preferred languages and frameworks.

Dapr is cross-platform

Dapr is cross-platform, which means we can run our application locally, in any Kubernetes cluster, and in any other hosted environment where Dapr is installed. This allows us to build microservices applications that run in the cloud and on the edge.

Dapr Ecosystem — source

Build event-driven microservices using Dapr

Typical event-driven architecture – Provenance

An event-driven system is made up of loosely coupled, self-contained components that leverage events to communicate with each other. We can group these components and assign them the following roles based on how they interact with events.

  • Event Producers – Who is producing events?
  • Event Consumers – Who is consuming events?
  • Event broker — who stores events until they are consumed

Building an event-driven system means determining which components will play these roles and carefully modeling their asynchronous interactions using events.

While being portable and cross-platform, here are five reasons why we should consider building our next event-driven system with Dapr.

1. Compose your system with loosely coupled, multilingual components

Dapr exposes its API as a Sidecar architecture, which can be either a container or a process, and does not require the application code to contain any Dapr runtime code.

As shown in the figure below, application code can communicate with Dapr apis through standard interfaces such as HTTP and gRPC.

This allows developers to choose their favorite programming language to build loosely-coupled, multilingual components that make up event-driven systems while taking advantage of the capabilities that Dapr brings.

For example, a Java-based order-processing component can communicate with a nodeJs-based email component through a common Dapr runtime.

2. Provide first-class support for production and consumption events with its building blocks

Dapr’s publish/subscribe component provides a platform-independent API to send and receive messages guaranteed at least once.

Publishing messages requires your service to make a network call to the Dapr publish/subscribe component, which is exposed as a Sidecar. This component then calls the Dapr publish/subscribe component, which encapsulates a specific message server (Broker) application. To receive messages, Dapr subscribes to Dapr publish/subscribe components on behalf of your service and delivers the messages to the corresponding terminals when they arrive.

This approach makes your service implementation portable and less dependent on the underlying messaging infrastructure. Dapr currently supports a wide range of messaging brokers, including Redis, Kafka, NATS, and cloud services like AWS SQS/SNS, Azure EventHubs, and Google Pub/ Sub.

In addition, you can trigger your service with an event from an external system, or connect to an external system with a Dapr Binding. Binding does not require template code to be written to connect and poll message systems such as message queues and message buses.

3. Harness the true power of Kubernetes with ease.

Dapr is platform independent and can run in any hosted environment, including on-premises, Kubernetes, and public clouds such as AWS, Azure, and GCP.

Deploying event-driven microservices on Kubernetes has some additional benefits in terms of on-demand scaling, high availability, and portability. For Kubernetes, Dapr integrates KEDA, an event-driven auto-scaling program for Kubernetes. Many of Dapr’s publish/subscribe components integrate seamlessly with KEDA’s scale-up program. This allowed us to delegate the need for automatic scaling to the underlying platform and focus on the business logic.

4. Dapr provides rich observability.

Event-driven applications are often criticized for not monitoring events. But with the right monitoring tools, the problem can be solved.

Dapr provides rich monitoring tracking tools to monitor events in the architecture. Through tools like Zipkin, Dapr provides distributed tracking for our services. Dapr automatically sends tracking data to Zipkin, so our service doesn’t need to write code manually. Dapr uses the OpenTelemetry standard to collect tracking data, so we can replace it with any compatible tracking tool.

Dapr provides trace collection compliant with OpenTelemetry — source

5. Dapr wraps events in the CloudEvents format

In event-driven systems, standardization of event formats is critical. This enables heterogeneous systems to exchange events in a common format.

CloudEvents is a specification that describes events. Its purpose is to simplify interoperability. With event-driven architectures on the rise, it’s not surprising that CloudEvent is popular.

Dapr uses the CloudEvents 1.0 specification for its message format to enable message routing and provide additional information for each message. Any message sent by an application to a topic that uses Dapr is automatically “wrapped” in a cloud event, using the Header value of the Content-Type as the data Type attribute. Dapr implements the following CloudEvent fields.

  • id
  • source
  • specversion
  • type
  • datacontenttype(optional)

The following example shows CloudEvent V1.0 serializing XML content to JSON.

{
"specversion" : "1.0"."type" : "xml.message"."source" : "https://example.com/message"."subject" : "Test XML Message"."id" : "id-1234-5678-9101"."time" : "2020-09-23T06:23:21Z"."datacontenttype" : "text/xml"."data" : "<note><to>User1</to><from>user2</from><message>hi</message></note>"
}
Copy the code

Writing at the end, Dapr has earned over 10K stars on Github. As a non-intrusive runtime environment, Dapr combines some of the concepts of Serverless and Server Mesh and is fairly portable. When learning to use it, you can even use Windows without installing containers like Docker. From a personal point of view, it’s quite developer-friendly, which means it has a low learning cost, except of course it has one parent that can be scolded: hard.

So what do you think of this technology after reading this article?