Dapr - What's so good about this microservice framework used by major manufacturers?

(Reproduced from: SmartIDE Blog)

Dapr is a cloud native open source project led by Microsoft. It was first released in October 2019. Within less than a year after the official release of V1.0, the number of github stars reached 12,000 (now more than 17,000 stars), more than In the same period, kubernetes, istio, knative, etc. have developed rapidly, and the industry has paid a lot of attention.

The word Dapr is an acronym for "Distributed Application runtime", which explains very neatly what dapr is: dapr is a runtime that provides distributed capabilities for applications.

Dapr official website https://dapr.io

Dapr has supported the production environment in many large factories

With the expansion of the IT systems of major factories, the microservice architecture has become a necessity and standard, which has also spawned the use of non-intrusive (or SideCar) microservice development frameworks such as Dapr. According to the records in Dapr's official warehouse, there are already many large factories using Dapr in the production environment to support their own microservice development.

refer to:

• https://github.com/dapr/dapr/issues/3169
• https://github.com/dapr/community/blob/master/ADOPTERS.md

What are the advantages of Dapr compared to SpringCloud or Istio?

This question may be the first question for most people, and a few points are briefly summarized for your reference.

• Full-stack multi-language support : Dapr and Istio are equivalent at this point, because they both use the sidecar model, which is not intrusive with the application process. Compared with SpringCloud, it can only support the Java language (of course, there are many Other languages provide the invasive framework of SpringCloud SDK), which has inherent cross-language advantages. An important value brought by microservices to developers is that they can choose different development language frameworks for assembly at will. For enterprises, they can also avoid being bound by a certain technical framework, even when recruiting programmers. many choices. Therefore, when the concept of microservices becomes popular in the industry, the coexistence of multiple languages will inevitably appear in the adopter's team. When you face an application environment where Java/.Net/Python/Node/JavaScript/Golang coexist and depend on each other, you will find that SpringCloud cannot meet this requirement and becomes the bottleneck of the microservice support framework.
• Multi -cloud/non-cloud environment support : Dapr and SpringCloud are equivalent in this regard. As a framework that appeared before the cloud native era, SpringCloud itself is based on a non-cloud or virtual machine environment. Therefore, SpringCloud itself has cross-cloud/non-cloud environment support because it is not bound to the cloud environment. You can of course run SpringCloud in a container/k8s, but this just changes a package and deployment method for SpringCloud applications. Istio has a natural weakness in this regard, because Istio was born on the cloud-native infrastructure k8s from the very beginning, and it naturally takes advantage of many basic capabilities provided by k8s, which are for new applications. Very suitable, but faces retrofitting problems for legacy/existing applications. The design of Dapr is fundamentally compatible with multi-cloud/non-container and non-cloud environments, and also draws on the characteristics of cloud native environments for design, so you can get and Cloud-native platform-like microservices experience. This is a very important boon for traditional enterprises that already have a large number of existing applications. ×Note: Isitio has also started to support the integration with the virtual machine environment, please check the information yourself.

To put it simply, Dapr draws on and considers the respective advantages of the previous two similar frameworks from the design, and integrates all the advantages and eliminates the disadvantages; it is the most advanced and promising distributed microservice development framework at present.

Pain points of building a Dapr development environment

The following video shows the whole process of developing a Dapr application using VSCode WebIDE in a container
https://www.bilibili.com/video/BV1iv4y1A7v4/?aid=554298729&cid=727808079&page=1

Since it is a microservice-oriented development framework, the Dapr environment itself can become very complex. Because of the introduction of various types of middleware, many developers will find that to learn or build an application that can run and use Dapr, they may need to install a bunch of various services first. For example, the following Dapr sample application Dapr-Traffice-Control

• Codebase: https://github.com/SmartIDE/sample-dapr-traffic-control
  

Although the application itself is not particularly complicated and only uses 3 service components, there are as many as 5 middleware supporting these 3 services, including:

• Mosquitto as MQTT Broker
• Commonly used cache middleware Redis
• message queue RabbitMQ
• Email Sending Middleware SMTP Service
• Key Service Secrets

To briefly introduce the business background of this example, dapr-traffice-control simulates the implementation of a common speeding camera system, by detecting the time taken by the vehicle to pass between 2 cameras on the road, calculating the speed, and sending a ticket to the driver. As shown below:

There are only three business components used here, namely:

• TrafficControlService is a traffic control service and the main service. Its business logic is to calculate the speed of the vehicle passing the camera based on the data fed back by two fixed-position cameras on the road, so as to determine whether there is speeding behavior.
• FineCollectionService is a ticket processing service. According to the license plate data sent by TrafficControlService, it queries the vehicle registration database (VehicleRegistrationService) to obtain contact information and sends emails.
• VehicleRegistrationService is a vehicle registration database, which provides vehicle information query, and can obtain vehicle owner information, such as email address, through the license plate number.

This is actually a very common problem in microservice development: the underlying environment is often more complex than the application itself. This is actually consistent with the concept of microservices. Microservices hope to minimize the investment of developers on common components by abstracting different business components, and focus on the business itself. From this point of view, dapr-traffice-control perfectly interprets this concept; at the same time, it also shows this dilemma very directly.

From the developer's point of view, this brings about a very troublesome problem: in the single era, as long as you get the code, you can start debugging. The construction of the current application development environment is becoming more and more complicated. What developers need to know The range has also been enlarged.

In fact, the above problem has been perfectly solved in the field of operation and maintenance. The solution is actually the container and cloud native technology itself. However, developers, as users of cloud-native technologies, have not benefited from them, but have had more troubles.

Developers don't use containers?

First of all, what I am talking about here is not to use containers for deployment, but to use containers for development. The typical deployment mode of cloud native must be containerized, and developers do not struggle with this issue. The current situation of developers is that although the application will eventually run in the container, they do not want to develop in the container during development. The main reason is of course inconvenience and the operation is too cumbersome. The problems brought about by this are also very obvious. Because the development environment and the production environment are inconsistent, these inconsistencies must be solved through configuration and pipeline automation, resulting in the entire release system becoming more complex and difficult to maintain.

To solve this problem, we must lower the threshold for using containers and allow developers to use containers for development without knowing/learning container technology. SmartIDE is designed to solve this problem. Unlike cumbersome environment building scripts, SmartIDE allows you to use a simple command smartide start to start any application development and debugging environment, and this environment is containerized from the beginning.

For the above dapr-traffic-control, the startup command is as follows

 smartide start https://github.com/SmartIDE/sample-dapr-traffic-control

That is to say, developers can use smartide start plus the code base address to start the development and debugging of any application; moreover, if the developer has a cloud host that can run the Docker environment, he can roam the environment to this environment with one click On the host, the whole process only needs 2 instructions

 ## 添加主机到SmartIDE工具并获取 主机ID
smartide host add <Docker主机IP地址> --username <SSH登录用户名> --password < SSH登录用密码>
## 一键漫游环境到远程主机
smartide start --host <主机ID> https://github.com/SmartIDE/sample-dapr-traffic-control

After completing the above operations, the developer can start the entire dapr-traffic-control environment for development and debugging, the effect is as follows

Dapr-traffic-control development and debugging process

After using the above command to start the environment, the developer will first get a WebIDE interface similar to VSCode. SmartIDE will automatically start the browser and load the VSCode and application code. At this time, the developer can open the built-in terminal tool and use dapr init to initialize the Dapr development environment .

At this time, dapr will start three docker containers, namely dapr: 1.7.4, zipkin and redis. By default, dapr leverages docker to provide developers with the necessary middleware components. To complete the dapr init action, the developer must first install the docker environment locally, and in the previous operation, we used a container environment with docker pre-installed, that is, the support of docker is provided in the container, so that the development The environment of the developer is completely inside the container, and it is no longer necessary to install these services on the development machine or remote server. We call this environment VM Like Container (VMLC), which is a virtual machine-like container environment. We will specifically target VMLC in the future. for a more detailed introduction. This approach also ensures a consistent experience no matter where the developer launches the environment.

Now, type docker ps and you can see that these three containers have been started

Now, we use a pre-prepared PowerShell script to start other middleware environments of the Traffic-Control application. Similarly, you don't have to consider the existence of PowerShell tools in this process, because these have been provided through standardized developer images. . You just need to execute in terminal

 cd src/Infrastructure/
pwsh start-all.ps1

You will notice that we actually execute a series of docker build and docker run actions inside the container, completing the startup of three other middleware containers, namely:

• Maildev: 1.1.0 - Debugging tool responsible for simulating email sending and receiving
• Rabbitmq: 3-management-alpine - message queue service
• Mosquitto: 1.0 - MQTT Broker service

If you run docker ps again, you can see that we now have 6 containers running in the environment, forming the complete middleware environment for the current application. Now we can start the three business components in sequence to complete the development and debugging of the entire traffic-control application. Start three terminal windows respectively, enter src/TrafficControlService, src/VehicleRegistrationService, src/FineCollectionService, and run the startup command

 ## 使用PowerShell脚本启动服务
pwsh start-selfhosted.ps1

Finally, let's start the emulator. Go to the src/VisualSimulation directory and run the following commands

dotnet run

Now, we can open another 2 browser windows and open them separately

• http://localhost:5000 - Simulator window, you can see the scene of random cars passing through the camera, and at the same time call the above business services to simulate traffic flow.
• http://localhost:4000 - Email simulation application that can keep receiving emails/speeding tickets

So far, we have completed the debugging of the entire dapr-traffic-control sample application. In this process, the developer does not have to understand the various configurations of the Docker, remote SSH tunnel, and container image environment behind it; moreover, whether the developer starts this environment on his own local development machine, a remote host, or a k8s cluster, All can be done using the unified smartide start command.

The original design of SmartIDE is to minimize the complexity of developers getting started with an application, whether the application is a simple hello-world or a complex microservice application; and whether the environment required by the application is just a simple SDK , or various complex middleware and cumbersome network configuration, all only need one command: smartide start

SmartIDE supports cross-platform, full technology stack and multiple IDE tools (VSCode/JetBrains Family Pass/OpenSumi); it is completely free and open source for independent developers and small and medium enterprise users. If you want to try this new way of app development right now, please refer to the following links:

• GitHub open source address: https://github.com/smartide

---

Long press to identify the QR code

Follow Microsoft China MSDN