dapr
dapr copied to clipboard
dapr
[propsal]Spring Cloud Integration - Overview
Background
As we described in the Overview of Dapr :
Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
For Java language, Dapr provides Java-SDK project. And in this SDK, Dapr provides a sub-project named "sdk-springboot" to integrated with spring boot. But this project is very simple and only provide a simple functionality as @topic annotation to do subscribe in pub/sub building block.
This is not enough for Java develoeprs, especially for spring cloud develoeprs.
Proposal
Principle
Although the spring cloud develoeprs can use Dapr by java-sdk in their spring cloud applications, the programming styles and habits are totally different to spring cloud.
And also this is hard for spring cloud developers to migrate their applications to dapr.
So we need to prorive a solution to using Dapr in the way of Spring Cloud, which is called "Spring Cloud Integration":
Similar to the Spring Cloud Netflix / Spring Cloud Alibaba / Spring Cloud Consul / Spring Cloud Kubernetes and other Spring Cloud XXX solution, we will bring a solution based on Dapr and we call it as "Spring Cloud Dapr":
In the solution of "Spring Cloud Dapr", the dapr java SDK and Dapr runtime play the same rule as Netfix OSS jars / Alibaba jars / Consul jars ...... The biggest different is that Spring Cloud Dapr is not pure Java solution but introducing a sidecar named Daprd which will make the Spring Cloud applications to be small and without too many dependencies.
In addtion, the solution of "Spring Cloud Dapr" can also bring all the distributed capabilities in Dapr to the spring cloud applications, but still keep the same programing style and habits as develpers used to do in normal spring cloud applications.
Therefore, from this point of view, Dapr is to extend spring cloud, not replace spring cloud.
Dapr and Spring Cloud are collaborators, not competitors.
Subprjects
In spring cloud, there are so many subprojects as listed in this URL:
https://spring.io/projects/spring-cloud
We need to do integration one by one, and in this proposal, we only list the subprojects which are suitable to integrate with Dapr and discuss about the priority.
For detail implementation design of each subproject, we will submit an individual sub-proposal for it named "[propsal] Spring Cloud Integration - spring cloud xxx".
spring cloud stream (high priority, ongoing)
Spring Cloud Stream is a framework for building highly scalable event-driven microservices connected with shared messaging systems.The framework provides a flexible programming model built on already established and familiar Spring idioms and best practices, including support for persistent pub/sub semantics, consumer groups, and stateful partitions.
Dapr provides a pub/sub building block:
Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publish messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
Current available pub/sub components in Dapr:
- apache kafka
- RabbitMQ
- Redis streams
- Pulsar
- AWS SNS/SQS
- gcp pub/sub
- Azure Event Hubs
- Azure Service Bus
Reference:
- RabbitMQ binder implementation provided by Spring Cloud Stream
- Apache Kafka binder implementation provided by Spring Cloud Stream
- Spring Cloud Stream Binder for Azure Event Hubs provided by Spring Cloud Azure
- Spring Cloud Stream Binder for Azure Service Bus Topic and Queue provided by Spring Cloud Azure
- Apache RocketMQ binder implementation provided by Spring Cloud Alibaba
- Google pubsub binder implementation provided by Spring Cloud GCP
This subproject is ongoing and it's the first subproject of spring cloud integration, for the detail please see the "[propsal] Spring Cloud Integration - spring cloud stream".
spring cloud config (high priority, planned)
Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. By default Spring Cloud Config uses git as the server storage backend.
Dapr provides a configuration building block:
The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store.
Current available configuration components in Dapr:
- Redis (alpha)
- Azure App Configuration (alpha)
Open source projects planned for support (to be confirmed)：
- Alibaba Nacos: an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.
- apollo config: Apollo is a reliable configuration management system suitable for microservice configuration management scenarios. BTW: this project is widely used in China.
- Consul: Consul is a service networking solution to automate network configurations, discover services, and enable secure connectivity across any cloud or runtime.
Reference Projects:
- Spring Cloud Config for Azure App Configuration (Preview) provided by Spring Cloud Azure
- spring-cloud-starter-alibaba-nacos-config: provided by spring-cloud-alibaba
- consul integration provided by spring cloud consul
- TODO: confirm if Apollo is integrated with spring cloud
- TODO: list other projects if any user has intresting
Spring Session (to be confirmed, low priority)
Spring Session provides an API and implementations for managing a user’s session information.
Dapr provides a state management building block:
Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence.
Spring Statemachine (to be confirmed, low priority)
Spring Statemachine is a framework for application developers to use state machine concepts with Spring applications.
if we add a state machine building block into Dapr, then we should consider to integrate with Spring Statemachine.
More subprojects to be added
We want to listen to the community to see if there is any subproject of spring cloud which is used by the end user and want to integrate with Dapr.
Meeting you needs is the key of this proposal.
Key Points
To let Spring cloud users to migrate to Dapr, we should provide some core values for the spring cloud users to resolve their problems or even Pain Points：
- Lightweight: make spring cloud applications simple and small since dapr can reduce the dependencies by sidecar model
- Polyglot: great helpful if users needs to support multiple languages and also work together with spring cloud
- Portability: easy to change to different components in runtime without code change on multi-cloud / hybird cloud
In addition to above, it would be useful to identify certain scenarios where Dapr is particularly suitable. Thus dapr can play a key role, even turning the impossible into the possible.
Function Computing and Serverless
This scenario is very suitable for Dapr because Java applications can be significantly slimmed down after introducing Dapr:
For historical reasons, Java was designed for long-running and large scale applications. But in the scenario of function computing and serverless, the granularity of the application is very very small and serverless requires the application to start and stop on demand. Java is strongly challenged in this area by languages like nodejs / go.
Dapr can help Java applications (or Functions) by removing many the 3rd dependencies and let dapr's sidecar to complete these tasks:
Java AOT Compile
AOT (Ahead Of Time) compile is a very good approach if the users are very sensitive to the startup speed and resource usage of the Java application, because AOT will skip java bytecode and compile Java source directly into machine code. This is also a key point that the Java community is currently working on improving in order to make Java better adapted to cloud native.
Note: since this is a propopsal of dapr spring cloud integration, I don't want to detailing Java AOT compile here with a lot of words. Please reference to related data and projects like GraalVM / Leyden / Quarkus / Micronaut / spring native.
Although AOT compile looks wonderful and can solve problems such as slow startup and high memory usage. But AOT compile requries Close World (see all the code to do points-to analysis) and NOT supports any dynamic langurange functionality of Java, while Java is a dynamic langurage with Open World: it has many dynamic langurange functionalities like reflection, class loading on runtime, dynamic proxy, generating code on runtime...
The conflicts between current status of Open World and the requirements of Close World make Java AOT to be very difficult to implement at the moment, since there are always many 3rd dependencies required by the applications. Current all projects based on various Java AOT technologies are unable to establish an perfect ecosystem which can cover all the dependencies involved in daily development in a short period of time.
Therefore, if we expect to solve some inherent problems of Java by AOT technology, we will have to wait for a long long time.
But dapr can help us at this stage by allowing us to implete the AOT compilation of Java applications by introducing sidecar and remove the 3rd dependencies:
Therefore, after completing the integration with several sub-projects of spring cloud, we plan to integrate with the spring native project in order to implement Java AOT compile with spring cloud and Dapr.
Our point is that until the ecology of Java AOT is perfected, the most realistic way to achieve Java AOT is to combine it with sidecar such as Dapr. And with the help of Dapr and Java AOT, Java will be able to support function computing and serverless scenarios very well.
We will try to bring a new cloud native style of Spring Cloud application for function computing and serverless:
- spring cloud: maintaining the existing development experience
- spring cloud dapr: integrate dapr with spring cloud
- dapr sidecar: make spring cloud applications small and easy to implement Java AOT
- Spring native: implement Java AOT for spring applications
BTW: Before we integrate Dapr with spring cloud, we have succeed to integrate Dapr with Quarkus by quarkiverse/quarkus-dapr project. To have a look you can try the pub/sub demo.
This is a great proposal. But I don't see a description of the support for RPC/Http-style microservice invocation, for the following functions, may dapr provide support ?
- Service registration and discovery
- Service-to-service calls
- Load balancing
- Circuit Breakers
Great proposal! this will power more users to migrate to dapr.
When we implemented the runtime-api, we also encountered such a problem: developers wanted to make changes to the original code as small as possible, so we also developed an adapter-layer-sdk, and then adapted it to the runtime-api sdk.
I will add a few questions and ideas we encountered here:
More adaptor layer scalability
In order to better adapt to different development framework systems in the future, when designing the adapter-layer-sdk, can the logic unrelated to spring-cloud be abstracted into a common-layer, so that it can be adapted to summer-cloud, dubbo and other systems.
For example, dapr-java-sdk's singleton acquisition, scalable annotation scanner and other logic. Put this logic into like dapr-adaptor-common-sdk.
In this way, I can also reuse these codes when adapting to the private middleware system. haha
User's custom logic
When we implement the code of the adapter-layer-sdk, we keep some hooks interface that users can customize logic.
In java, we implement it through the java SPI mechanism. Users can implement these hook interfaces and package them into a jar package.
After that, different hook logic can be loaded in different environments through the maven profile.
We may be able to retain some user-defined logic mechanisms when designing spring-cloud-dapr-sdk.
The intention of this is to provide Spring-cloud compatible annotations (i.e @EnableDiscoveryClient) using the dapr/java-sdk talk to Dapr instead of another service or library, right?
So, as a trivial example, if I already had an app that was using Consul for discovery (using the @EnableDiscoveryClient annotation) I should be able to instead swap out the spring-cloud-consul component for spring-cloud-dapr and then use Dapr + (consul / mDNS / service-discovery-over-stone-tablets) without having to make code changes. That seems like an easy win for Spring users to make the switch.
I assume that in the case where there is no existing generic abstraction (it's been a while since I look but I think the Netflix library has some Eureka-specific annotations, for example) we will have to provide something that is Dapr-specific.
This is a great proposal. But I don't see a description of the support for RPC/Http-style microservice invocation, for the following functions, may dapr provide support ?
- Service registration and discovery
- Service-to-service calls
- Load balancing
- Circuit Breakers
Yes, this is not included in the first version of this proposal, because we are still discussing about how to integrated with spring cloud rest.
The core problem is that should dapr take all the capalibilities that spring cloud rest provides as curerent service invoke api does ?or Just provides some of them, for example, service discovery (so that dapr need to add a service discovery api and building block).
Great proposal! this will power more users to migrate to dapr.
When we implemented the runtime-api, we also encountered such a problem: developers wanted to make changes to the original code as small as possible, so we also developed an adapter-layer-sdk, and then adapted it to the runtime-api sdk.
Yes, this is the core value of this proposal: using dapr in spring-cloud (or xxxx) style
More adaptor layer scalability
In order to better adapt to different development framework systems in the future, when designing the adapter-layer-sdk, can the logic unrelated to
spring-cloudbe abstracted into a common-layer, so that it can be adapted tosummer-cloud,dubboand other systems.For example, dapr-java-sdk's singleton acquisition, scalable annotation scanner and other logic. Put this logic into like
dapr-adaptor-common-sdk.In this way, I can also reuse these codes when adapting to the private middleware system. haha
Agree with you!
Yet we don't have too many practices in similar project integation and we can't do a pefect design at beginning, so we can start from spring cloud first. And for the common code we can later move into dapr java-sdk project by code refactory.
The intention of this is to provide Spring-cloud compatible annotations (i.e
@EnableDiscoveryClient) using thedapr/java-sdktalk to Dapr instead of another service or library, right?
Yes, this is a good use case and I want to implete.
But we need to make a desicion first that can dapr provide the capabilities and api in service invoke separately? Like service discovery (name resolver in service invoke).
@artursouza @yaron2 what's your suggestion about above question?
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.