Can Dapr replace Spring Cloud? with Dapr, we can manage the deployment of a cloud-native application without any impact on the application itself. Dapr uses the sidecar pattern to off-load deployment concerns from the application, which allows us to deploy it into other environments (such as on-premise, different proprietary Cloud platforms, Kubernetes, and others) without any changes to the application itself. For more details, check out this overview on the Dapr website.

The difference between Dapr and Spring Cloud

Many people use Spring Boot and Spring Cloud to develop microservices. Dapr is also a framework for developing microservices. What is the difference between it and Spring Cloud? In fact, this is not a different issue. It is that different times require different frameworks.

Spring Cloud is a product that provides all the elements needed for distributed applications including service discovery, messaging/stream processing, distributed tracing, providing functionality from SpringBoot in a tractable form, and so far probably no other The product is easier to use than Spring Cloud. Spring Cloud does not repeat the manufacture of wheels, it just combines the mature and practical service frameworks developed by various companies, and repackages them through the Spring Boot style to shield the complex configuration and implementation principles, and finally give the development The author has left a set of distributed system development toolkits that are easy to understand, easy to deploy and easy to maintain.

Spring Cloud is an important product in distributed application development enough to influence language choice. If you want to use a language other than Java to develop microservices, such as golang, you want to use Spring Cloud + Spring Boot, and finally choose to use Java.

The emergence of Dapr is the development of language-independent microservices in distributed application development. Dapr is enough to replace Spring Cloud and become the choice for cloud-native distributed application development. Those familiar with Azure might think it’s actually more of an enhanced version of Service Fabric.

Let’s make some side-by-side comparisons between the components provided by Spring Cloud and the building blocks of Dapr: in

general, both Dapr and Spring Cloud‘s projects above aim to help developers build distributed applications easily and quickly. However, due to the background of the times, there are some differences in their starting points and realization forms.

Let’s compare Dapr and Spring Cloud in terms of the three pillars of distributed application capabilities:

• service call
• Deliver asynchronous messages
• Distributed tracing

1. Service call

First, compare the functionality of calling another application from an application.

Dapr calls use InvokeAPI

The source code looks like this:

@Value("${baseUrl}")
private String baseUrl;
@GetMapping("/invokeHello")
public Map<String, ?> invokeHello() {
  Map<?, ?> result = restTemplate.getForObject(baseUrl + "/hello", Map.class);
  return Map.of("baseUrl", baseUrl, "remoteMessage", result);
}

Can Dapr replace Spring Cloud?

baseUrl can be used to call the target application through Dapr by specifying the value of the calling API for Dapr.

https://znlive.com:${DAPR_HTTP_PORT}/v1.0/invoke/hello-app/method

Dapr uses mDNS (multicast DNS) in the local environment to find the host on which the target service is running from the application name, while k8s uses the name resolution function (CoreDNS) of k8s itself. In environments where neither is available, you must currently use Consul.

besides, The advantage of Dapr is that it basically works out of the box.

Spring Cloud service discovery

Spring Cloud uses Netflix Eureka for name resolution, it has a Eureka server (equivalent to the above) as the server for name resolution, each application registers itself with the Eureka server using the Netflix client, and uses it to build a client to resolve itself host. The service registry is useful because it allows client load balancing and isolates service providers from consumers without the need for DNS.

• The server-side Eureka server code looks like this:

@EnableEurekaServer
@SpringBootApplication
public class ServiceRegistrationAndDiscoveryServiceApplication {
  public static void main(String[] args) {
    SpringApplication.run(ServiceRegistrationAndDiscoveryServiceApplication.class, args);
  }

}

Can Dapr replace Spring Cloud?

Just start the application with the annotation @EnableEurekaServer. Of course, you can add configuration files for fine-grained setups or combine clusters.

• The Netflix client source code looks like this:

@Value("${baseUrl}")
private String baseUrl;
@GetMapping("/invokeHello")
public Map<String, ?> invokeHello() {
  Map<?, ?> result = restTemplate.getForObject(baseUrl + "/hello", Map.class);
  return Map.of("baseUrl", baseUrl, "remoteMessage", result);
}

Can Dapr replace Spring Cloud?

Same as the source code on the Dapr side.

baseUrl As long as the application name is specified, RestTemplate will use Eureka to discover clients to automatically access the application. Simply put, it’s easier to understand than using Dapr.

Heterogeneous service communication

Traditional distributed middleware is often locked in a certain language. For example, the Java system is usually implemented using Feign or Dubbo, but they do not provide libraries for other languages.

Therefore, if it is a multi-language environment, then communication needs to be based on some common protocol such as REST or GRPC, and additional registries and load balancers may be required.

Of course, the actual situation is often more complicated than this, and considering the introduction of additional middleware, the cost of operation and maintenance also needs to be carefully considered.

Dapr provides a multilingual SDK, such as .NET, Java, Go, Rust, Python, PHP, etc., which can Call between heterogeneous services using HTTP or GRPC, which can solve this problem very well.

Which is better for service invocation between Dapr and Spring Cloud?

While Dapr does not require a separate DNS, it is easier to use, but Spring Cloud requires the Eureka server to be set up in the local environment. Of course, it’s not that hard to build, so can’t say that’s a disadvantage.

Also, the URL when invoking is easier to understand in Spring Cloud, whereas Dapr’s invocation API can be quite long. Of course, this is not a big disadvantage.

Dapr and Spring Cloud have their own advantages, but in the Kubernetes environment, Dapr directly utilizes the Kubernetes Service, which is more suitable for the cloud-native environment and better supports heterogeneous service communication.

2. Deliver asynchronous messages

Dapr Pus/sub API

Dapr uses messaging’s Pub/sub API to send messages, just create a subscription profile and Web API to receive messages, In standard CloudEvents format.

The source code to send the message looks like this:

@Value("${pubsubUrl}")
private String pubsubUrl;
@PostMapping("/publish")
public void publish(@RequestBody MyMessage message) {
  restTemplate.postForObject(pubsubUrl, message, Void.class);
}

Can Dapr replace Spring Cloud?

You can send messages to the Message Broker by specifying an uppercase Pub/sub API named pubsubUrl.

https://znlive:${DAPR_HTTP_PORT}/v1.0/publish/rabbitmq-pubsub/my-message

Then there is the source code to receive the message. It looks like this:

@PostMapping("/subscribe")
public void subscribe(@RequestBody CloudEvent<MyMessage> cloudEventMessage) {
  System.out.println("subscriber is called");
  System.out.println(message);
}

Can Dapr replace Spring Cloud?

Just create a Web API to receive messages. To take advantage of this Web API, create a configuration file similar to the following:

apiVersion: dapr.io/v1alpha1
kind: Subscription
metadata:
  name: subscription
spec:
  pubsubname: rabbitmq-pubsub
  topic: my-message
  route: /subscribe
scopes:
- subscribe-app

Can Dapr replace Spring Cloud?

• The metadata. the name value is not particularly available, so you can give it any name.
• pubs name is the name of the pub/sub. Use pub/sub which is set by default.
• the topic is the message topic. The my-message specified in the publisher application is specified here.
• the route is the path to the web application to invoke. Because it is waiting on the path SubscribeController/subscribe
• scopes is the application id of the waiting application. This time, I’m going to start an app (the app’s app, called the subscript-side app), so I specify it to subscribe-app.

Multiple apps can receive the same message if their app ids are listed here.

The GitHub sample code is in this file. If you want to use it, copy it to the user directive.

subscribe/.dapr/components/subscription.yaml

Can Dapr replace Spring Cloud?

Spring Cloud Stream

Publish to the cloud using spring cloud stream.

Between spring cloud stream 2. x to 3. x the API has changed significantly and is now more specific to stream processing. Here, I will introduce the 3. x version.

The source code of the party sending the message:

@PostMapping("/publish")
public void publish(@RequestBody MyMessage message) {
  streamBridge.send("my-message-0", message);
}

Can Dapr replace Spring Cloud?

Send messages using class StreamBridge.

Also, write the message broker in the configuration file with the key to send to the message specified in the source code.

spring.cloud.stream.bindings.my-message-0.destination=my-message

Can Dapr replace Spring Cloud?

The value specified here is used as the name of the RabbitMQ exchange.

Then there is the source code to receive the message.

@Bean
public Consumer<MyMessage> subscribe() {
return (map) -> {
    System.out.println("subscriber is called");
    System.out.println(map);
  };
}

Can Dapr replace Spring Cloud?

Use the Consumer and Function of the package java.util.funciton instead of a standard Web API like Dapr.

Then, create a configuration file to call this method (Bean) when a message is received.

spring.cloud.stream.bindings.subscribe-in-0.destination=my-message

spring.cloud.stream.bindings.subscribe-in-0.group=my-message-subscribe

Can Dapr replace Spring Cloud?

The upper value is used as the name of the Exchange, and the lower value is used as the name of the queue. There are some issues with the setup that is just hard to understand.

However, there is a compelling feeling to think of the subscript side as a “function” rather than an “API” and implement it. You may have never read the source code for this version of Spring Cloud Stream, so you may have incorporated multiple calls into WebFlux’s non-blocking, rather than receiving and processing messages from the message broker one by one. This has performance advantages.

Dapr provides abstract interfaces for some basic services. Taking message middleware as an example, Dapr supports Pub/Sub of the following middleware:

The advantage of using the Dapr abstract interface to use the basic service capabilities is that when you need to replace the middleware, you can move less code. In other words, it can be said to increase the portability of the service. There is also a description in the article.

Dapr uses HTTP for messaging and internal communication via GRPC, but Spring Cloud Stream uses its own classes for messaging. So while Dapr is easier to replace with another process when testing, use the curl command to test.

Dapr would be better in terms of operability.

3. Distributed tracing

Dapr’s distributed tracing support

In Dapr, distributed tracing can be enabled simply by writing a configuration file.

The configuration file has the following contents.

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: daprConfig
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: https://znlive:9411/api/v2/spans

Can Dapr replace Spring Cloud?

Distributed tracing is enabled simply by specifying the sample rate for distributed tracing and the address of the Zipkin server.

However, you have to propagate the tracking ID yourself, so you need to write code like this:

@GetMapping("/invokeHello")
public Map<String, ?> invokeHello(@RequestHeader("traceparent") String traceparent) {
  HttpHeaders httpHeaders = new HttpHeaders();
  httpHeaders.set("traceparent", traceparent);
  HttpEntity<?> request = new HttpEntity<>(httpHeaders);
  Map<?, ?> result = restTemplate.exchange(helloUrl + "/hello", HttpMethod.GET, request, Map.class).getBody();
  return Map.of("baseUrl", helloUrl, "remoteMessage", result);
}

Can Dapr replace Spring Cloud?

The header value transparent received in the HTTP header will be passed to the HTTP header of the next request.

Spring Cloud Sleuth

Distributed tracing in Spring Cloud with Spring Cloud Sleuth.

Add Spring Cloud Sleuth to dependencies and create a configuration file as follows:

spring.sleuth.sampler.rate=100

spring.zipkin.sender.type=web

spring.zipkin.baseUrl=https://znlive.com

Can Dapr replace Spring Cloud?

With this setting, distributed tracing will be enabled and the tracking information will be sent to Zipkin.

Distributed tracing covers everything from HTTP communication with RestTemplate and WebClient, messaging with Spring Cloud Stream, and also automatically propagates Dapr’s problematic trace IDs.

Dapr does not need to modify the application on distributed tracing, and it can be easily adjusted through configuration.

Comprehensive comparison

So far, we have compared three features of Dapr and Spring Cloud, but overall, which is better?

Dapr has advantages in terms of clarity and lose coupling over HTTP, and in addition, considering not only these three functions, but also other functions, or the difference in the amount of information in the world,  Dapr can be said to be superior.

Pain associated with version upgrades

So why did I choose Dapr instead of Spring Cloud? An important factor is “version compatibility and version upgrade issues”.

For example, if your system is running an older version of Java and Spring Boot, and you try to develop with a newer version of Java and Spring Boot on the new system, if you try to use Spring Cloud on each system, each Spring Boot due to The corresponding Spring Cloud versions are different, sometimes losing compatibility. For example, with the version upgrade of Spring Cloud, the protocol has changed when the version of Eureka used internally is upgraded. As mentioned above, Spring Cloud Stream is an API terminal in 2. x.

If so, it’s best to keep updating Java, Spring Boot, and Spring Cloud to the latest versions. However, Spring Cloud tends to have large workloads associated with version upgrades.

This is because the corresponding products and trends in the field of Cloud Native have changed. When Spring Cloud tries to follow the trend, it has to lose compatibility.

In addition, as a slightly smaller problem, if you try to upgrade the version of Spring Boot due to the different speeds of Spring Boot and Spring Cloud, as well as the complexity of dependencies, Spring Cloud does not support sometimes referencing libraries. If the version is different, an error will be reported.

Rather than Spring Cloud being bad by experiencing this pain, the layer bordering the application providing the web API and the infrastructure supporting it is more loosely coupled, and each version is independent. Better to be able to upload it. “

That’s why it’s used in Dapr instead of Spring Cloud.

Dapr replace Spring Cloud Conclusion

• Dapr and Spring Cloud haven’t changed much when it comes to service invocation.
• In terms of messaging, Dapr is simpler and has better performance.
• For distributed tracing, Spring Cloud is more complex and easier to use than Dapr.

Spring Cloud version upgrades take a toll on you, and it’s a little hard to understand where and what Spring Cloud documentation is, which can become more complex as historical products with various features become more complex. Of course, the good thing about Spring is that there are many guides, blogs, demo materials, etc. that complement the field.

Microservice frameworks such as Spring Cloud bring many things from the microservice architecture to code development. Although Spring Cloud has done encapsulation and simplification, you will still be distracted to deal with it during development, and you can’t just focus on business. Dapr is the development direction of microservices. It simplifies the development of microservices and strips everything out of the microservice architecture into infrastructure. Development only needs to focus on specific business implementations.

So  Dapr of Mecha architecture can completely replace Spring Cloud. And it has more advantages:

• More cloud-native and better integrated with Kubernetes.
• The business code does not need to integrate the SDK, which determines that the SDK upgrade will be more convenient and reduce the coupling.

Dapr also provides many features in the Actor runtime, including concurrency control, state management, and lifecycle management such as Actor activation, by building some of the best practices needed to build microservice applications into an open, independent Building Block. /Disable and Timer and Reminder for waking up the Actor. Dapr allows developers to focus more on writing business logic code and can develop powerful microservice applications.

More importantly, Dapr also abstracts the runtime environment to avoid strong binding between microservice applications and the runtime environment(This is one of the reasons why many teams “fake the cloud” – only using VMs). And the operating environment that supports Dapr is not limited to Cloud, but also a vast Edge.

Reference: https://mp.weixin.qq.com/s/W7YfH92ZX_4dtRXBUKcw5A