An example of using Dapr to simplify microservices from scratch

Preface

The existing microservice model requires integrating a large number of infrastructure modules into the business code, such as registration center, service discovery, service call link tracking, request circuit breaking, retry flow control, etc., making the system too bloated and heavyweight.

As a new generation of microservice model, Dapr uses the sidecar model to simplify the existing microservice system code and separate the infrastructure layer in the sidecar model, allowing developers to focus more on business logic writing.

This article builds a simple usage example of dapr based on net6 and dapr1.5.

1. Install Docker

Dapr's operation depends on the Docker environment.

As a learning environment, use Centos 7 system to install Docker.

It is recommended to use the daocloud one-click installation command to install Docker:

curl -sSL https://get.daocloud.io/docker | sh

After the installation is complete, run the command:

[root@localhost ~]# docker -v
Docker version 20.10.11, build dea9396

If the corresponding Docker version is displayed, the installation is successful.

2. Install Dapr CLI

Official explanation: Dapr CLI is your main tool for various Dapr-related tasks. You can use it to run an application with a Dapr sidecar, as well as view sidecar logs, list running services, and run the Dapr dashboard.

Download Dapr CLI

wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash

Verify the installation

dapr -v

The installation is successful if the following output is displayed.

CLI version: 1.5.0
Runtime version: 1.5.0

Due to domestic network problems, using the official Dapr installation method generally encounters various problems, so download dapr and install it through the script.

Modify the hosts file

vi /etc/hosts
140.82.114.4 github.com  
199.232.69.194 github.global.ssl.fastly.net
140.82.114.9 codeload.github.com

Refresh the cache

yum install -y nscd
service nscd restart

First you need to install Git, then execute the following command:

git clone -v https://gitee.com/Two-Twoone/dapr-installer.git
cd dapr-installer/
./install.sh

It's still slow, but it's better than not being able to download at all.

The above command starts several containers. Run the following operations to verify:

[root@localhost dapr-installer]# docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Ports}}"
CONTAINER ID NAMES PORTS
a0565f609846 dapr_placement 0.0.0.0:50005->50005/tcp, :::50005->50005/tcp
c392f5cf7a18 dapr_redis 0.0.0.0:6379->6379/tcp, :::6379->6379/tcp
2ee68c450b29 dapr_zipkin 9410/tcp, 0.0.0.0:9411->9411/tcp, :::9411->9411/tcp

3. Install Net6 SDK

rpm -Uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpm
 yum update
 yum install dotnet-sdk-6.0

4. Create an application

Create two projects, product and cart, and reference Dapr

dotnet add package Dapr.AspNetCore

The call to AddDapr in Program.cs registers DaprClient class with the ASP.NET Core injection system. With the client registered, you can now inject instances of DaprClient into your service code to communicate with Dapr sidecars, building blocks, and components.

builder.Services.AddControllers().AddDapr();

4.1 Service Call

In a microservice system, calls between services are essential. The difficulties mainly focus on the location of the service, how to retry when an error occurs, load balancing and other issues.

Dapr uses sidecar as a reverse proxy module for services to solve these problems.

Add the following code to the prodcut project

[Route("api/[controller]")]
    [ApiController]
    public class ProductController : ControllerBase
    {
        private ILogger<ProductController> _logger;

        public ProductController(ILogger<ProductController> logger)
        {
            _logger = logger;
        }
        private static readonly List<string> products = new List<string> { "aa", "bb", "cc", "dd", "ee", "ff", "gg", "hh", "ii", "jj", "kk", "ll", "mm", "nn" };
        [HttpGet]
        public ActionResult Get()
        {
            _logger.LogInformation($"The method to obtain products was called");
            string[] temps = new string[5];
            for (int i = 0; i < 5; i++)
            {
                Random random = new Random(Guid.NewGuid().GetHashCode());
                temps[i] = products[random.Next(0, products.Count - 1)];
            }
            return Ok( temps);
        }
    }

# Start the Product project dapr run --app-id ProductDemo --app-port 5010 --dapr-http-port 7015 -- dotnet /root/www/product/Dapr.Product.Sample.dll --urls http://*:5010

The cart project adds the following code. dapr supports http and grpc calling methods. Here we take the commonly used webapi as an example and use http to call.

The appid in the InvokeMethodAsync method corresponds to the appid in dapr run, regardless of the calling address.

[Route("api/[controller]")]
    [ApiController]
    public class CartController : ControllerBase
    {
        private readonly DaprClient _daprClient;
        private readonly ILogger<CartController> _logger;
        public CartController(DaprClient daprClient, ILogger<CartController> logger)
        {
            _daprClient = daprClient;
            _logger = logger;
        }

        [HttpGet]
        [Route("GetProducts")]
        public async Task<IActionResult> GetProducts()
        {
            _logger.LogInformation($"Cart Get Products");
            var products = await _daprClient.InvokeMethodAsync<List<string>>(HttpMethod.Get, "ProductDemo", "/api/Product/GetAll");
            return Ok(products);
        }
    }

Upload the program to the Linux server and run the program

# Start the Cart project dapr run --app-id CartDemo --app-port 5020 --dapr-http-port 7025 -- dotnet /root/www/cart/Dapr.Cart.Sample.dll --urls http://*:5020

Calling the interface, you can see that the Cart project implements the interface call with almost no code intrusion.

[root@localhost ~]# curl -X 'GET' 'http://192.168.2.110:5020/api/Cart/GetProducts'
["aa","bb","cc","dd","ee","ff","gg","hh","ii","jj","kk","ll","mm","nn"]

Dapr uses mDns internally for service registration, discovery and load balancing. After deploying multiple products, you can see the effect of polling calls.

In self-hosted mode, Dapr uses mDNS to look it up. When running in Kubernetes mode, the Kubernetes DNS service determines the address.

In the case of call failure and transient errors, the service call will be automatically retried. Dapr enables retries by default, so it is very dangerous for the interface to not support idempotence.

4.2. Publish and Subscribe

​ The publish-subscribe mode is mainly used for microservices to communicate with each other based on messages. You may also say, this also needs to be mentioned, I will just build a RabbitMQ/Kafka,

It turns out that we will introduce different SDKs according to the components used, and different message queue monitoring and consumption modes are different.

Dapr provides a building block that significantly simplifies the implementation of publish/subscribe functionality, thereby decoupling from the underlying infrastructure and eliminating the need to worry about message queues when writing business logic.

Add publish-subscribe support to Program

 app.UseCloudEvents();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapSubscribeHandler();
        });

Subscribe to messages, use the Topic feature, pass pubsub and topic name

 [Topic("pubsub", "newUser")]
        public ActionResult subUserInfo(UserInfo us)
        {
            _logger.LogInformation($"Received subscription message id:{us.id} name:{us.name}, age:{us.age}, sex:{us.sex}");
            return Ok("Processing completed");
        }

To publish a message, use the dapr public method PublishEventAsync, passing the pubsub and topic names, as well as the message body

[HttpPost]
        public async Task<IActionResult> PubUserInfo(UserInfo us)
        {
            await _daprClient.PublishEventAsync("pubsub", "newUser", us);
            return Ok();
        }

The message publishing and subscription component supports RabbitMQ, Redis, Kafka, etc.

4.3 State Management

​Dapr uses Redis as state storage by default. It also supports MongoDB, PostgreSQL, SQL Server, etc.

It does not expose the middleware used by the underlying layer to the upper layer, which means that the same set of code can be used to use different middleware in different environments.

[HttpPost]
       [Route("SaveUserList")]
        public async Task<IActionResult> SaveUserList()
        {
            var temps = new List<UserInfo>
            {
                new UserInfo("Xiaohong",1,true,Guid.NewGuid().ToString()),
                new UserInfo("小黄",1,true,Guid.NewGuid().ToString()),
                new UserInfo("小蓝",1,true,Guid.NewGuid().ToString())
            };
          	await _daprClient.SaveStateAsync("statestore", "UserList", temps);
            return Ok(1);
        }
        [HttpGet]
        [Route("GetUserList")]
        public async Task<IActionResult> GetUserList()
        {
            var list = await _daprClient.GetStateAsync<List<UserInfo>>("statestore", "UserList");
            return Ok(list);
        }
      	[HttpGet]
        [Route("DeleteUserList")]
        public async Task<IActionResult> DeleteUserList()
        {
            await _daprClient.DeleteStateAsync("statestore", "UserList");
            return Ok(1);
        }

        public record UserInfo(string name, int age, bool sex, string id);

4.4 Link Tracking

In traditional microservices, link tracking requires strong code intrusion.

Dapr adds an http/grpc middleware to Sidecar. Intercepts all application traffic and automatically injects correlation IDs to track distributed transactions.

Distributed tracing using the Zipkin protocol, without code instrumentation, automatically traces all traffic with configurable tracing levels.

 5. Summary

This article only gives a simple example of Dapr, and does not go into detail on the specific implementation principles of each component.

The biggest advantage of Dapr compared to traditional microservice frameworks is Sidecar. Previous microservice frameworks required code projects to reference some microservice-related class libraries. Whether it was service registration and discovery, circuit breaking, configuration, etc., they all had to call the corresponding class libraries for implementation. These class libraries ran in the microservice process, so these class libraries needed to be developed in the same (or compatible) language as the business code, so they were relatively heavy.

The Sidecar model separates the functions of microservices such as "registration discovery, circuit breaker, and configuration" into an independent process that accompanies the process of the business code. The business code communicates with the Sidecar process through http or grpc to complete the call of related services of the microservice.

Obviously, in the Sidecar mode, there are only a few codes in the business code that communicate with the Sidecar process, so it is very lightweight. In this way, services in the Sidecar process can be upgraded independently and modules can be combined freely without interfering with business code. At the same time, since the Sidecar process is an independent process, the business code and the Sidecar process communicate using language-independent protocols such as http and grpc, so the business code can be developed in any language.

This is the end of this article about using Dapr to simplify microservices from scratch. For more relevant Dapr simplified microservices content, please search for previous articles on 123WORDPRESS.COM or continue to browse the related articles below. I hope everyone will support 123WORDPRESS.COM in the future!