Back in 2015
, the keynote at the SpringOne
2015 conference in Washington was Cloud Native Enterprise
. The slogan of that conference was also Cloud Native
and the posters were all over the place with Cloud Native
.
You may wonder how you could call it Cloud Native
when containers weren’t popular at that time. Although many people may not have the same understanding of Cloud Native
, more and more people believe that “Cloud native is about culture, not containers”. It is a culture of software development, and even if there is a Serverless
or WebAssembly FaaS
platform based on V8
isolation, it is still in the realm of cloud native.
And in the trend of cloud-native, Spring
has done a lot of things, such as supporting the distributed architecture of Spring Cloud
, which is basically a necessary framework for Java
applications to be distributed and cloud-based. Various cloud vendors have Spring Cloud
docking versions, such as Spring Cloud Alibaba
, AWS
, Azure
, GCP
, etc. Spring Cloud
greatly simplifies the docking of Java applications and cloud services.
It’s safe to say that the Spring
ecosystem has been at the forefront of the growing popularity of microservices. Many of you may wonder: we know all these previous achievements of Spring
, but there seems to be no development in the last two years, can Spring
continue to lead the technology trend?
In fact, the reason for this confusion is that when we talk about cloud-based and cloud-native environments for development, the general focus is more on the choice of technology stack, and the main issue behind this is the cost.
Every developer or small and medium-sized company wants to buy fewer cloud resources to do more things, the most important of which are memory and CPU. memory consumption requirements are small, try to choose some lightweight development framework if it can be compiled into a standalone executable; and consider a framework with efficient and fully asynchronous language, which can ensure full use of CPU and avoid waste caused by threads waiting, etc.
On balance, many people would prefer technology stacks such as Rust
, Node.js
, and Golang
. And Java
is slow to start, consumes a lot of memory, seems to be more expensive, and seems to be less suitable for the next cloud-native era.
So as the Spring
ecology based on the Java language, can it still adapt to new development methods such as Cloud Native
, Serverless
, Faas
, etc., and will it still be the best choice of platform in the cloud-native era?
Next, I’ll break this down for you from 5 perspectives: the evolution of Java
and JDK
, a JVM language full of healthy competition, Spring Boot
and Spring Cloud
for mature service-oriented architectures, and Spring Reactive
for making event-driven architectures easier to use.
1. Development of Java and JDK
We know that Spring
is based on the Java
framework, and that the JDK
is the foundation for running Java
programs. To explore the question “will Spring be one of the best platforms for cloud-native”, we need to see how the JDK
base is and whether it provides a good foundation for Spring
to evolve with the times.
The first is version iteration. Now the development speed of OpenJDK
is very fast, before it was a major version in three years, now it is a version in half a year. Many users lament that it is almost Java 17
and they are still using Java 1.8
. We all say that software development should be small steps, this is a good way to develop: small steps, fast feedback, rapid iterative development. Similarly there is JavaScript
a year a version, TypeScript
a year three versions, Java
a year two versions, can be said to be a very good pace.
The second is the update of JDK
features. If you pay attention to the JDK
, it is easy to find that more and more features are being incorporated into the JDK
, such as the lightweight thread Loom
project that resembles a concurrent thread, the Panama
project that improves the support for Native
calls (SIMD support), the more advanced GC
algorithm, and so on.
In response to the Java
slow startup and memory consumption problems we mentioned earlier, Oracle
has introduced GraalVM
based on OpenJDK
, which can run JavaScript
, Python
, Ruby
and other languages directly in JVM
, a veritable Ployglot JVM
. In addition, GraalVM
also provides the Native Image
feature, which can convert Java
code into standalone executable programs. Spring
has also introduced the Spring Native
project, which makes it very easy to native-image
a Spring Boot
application, so that Spring
applications start faster and consume less memory. A native-image
ized Spring
application will meet the needs of every developer or small and medium-sized company that wants to be cloud-based and less expensive
. Even for Java
command line applications, GraalVM
has a very good solution - Picocli
+ GraalVM Native Image
+ upx
, which compiles Java
applications into more convenient executables.
The following chart shows the list of GraalVM
multilingual and Native Image
support, as follows.
In addition, various cloud vendors are also active in JDK
development, such as AliJDK
, Amazon Corretto
, Azul
, etc. These are all very good for JDK
development.
So, for Spring
, the foundation of JDK
is still very solid.
2. A JVM language with healthy competition
The JDK
does not only support Java
as a programming language, on the contrary, it can support a variety, such as Kotlin
, Scala
, Groovy
, etc. Here we call it a JVM language in unison. At present, JVM languages are in a state of healthy competition.
We know that each language has its own usage scenario that it is good at. In the cloud native era, multi-language development support is very important and developers need to choose different development languages based on the actual business scenario. Both the JVM
languages and the languages supported by GraalVM
can be directly integrated with Spring
, making it easy for developers to make full use of the Spring
technology stack for development.
One of the best language support for Spring
is Kotlin
. The integration of Kotlin
and Spring
has penetrated into all aspects of the framework, such as Spring Boot
and Kotlin
integration, Spring Webflux
support for Kotlin Coroutines
& Flow
, Spring Data
, SpringIntegration
, SpringCloud Function
, etc. also include support for Kotlin
, these all achieve deep integration of Kotlin
, the purpose is to make the language and framework better combined to improve development efficiency. In addition, Kotlin
and Scala
are also languages that are well integrated with Spring
.
Because the three languages Java
, Kotlin
and Scala
are very well integrated in Spring
, I will specify them next to help you have a clearer perception of the current development of the JVM
language.
Java
The development of Java
language is still very fast, along with the development of OpenJDK
, Java
will launch a version in half a year, and each version will be accompanied by syntax upgrade, standard library upgrade, etc., which greatly facilitates the developers. From Java 9
to 16
, many syntax and feature enhancements have been completed, such as the var
keyword (local variable type derivation), Text block
, Pattern Matching for instanceof
, Record
, sealed interface
, etc.
Kotlin
Although Kotlin
is not exactly for JVM
, it also includes Native
, JavaScript
, etc., but Kotlin
support for JVM
and Android
is currently the most characteristic and stable among many Kotlin
platforms.
Now Kotlin
is growing very fast and has incubated several sub-projects, such as the latest Kotlin Multiplatform Mobile
(one set of code to support multiple mobile platforms), Kotlin Compose for Desktop
(one set of code to develop desktop applications for multiple operating systems) and so on. Of course, the most notable of these changes is the introduction of Kotlin intermediate representation (IR)
in Kotlin 1.5
. With the new IR
, Kotlin
code can be compiled and exported to a variety of target platforms with better programs, such as the Kotlin WebAssembly
.
Scala
Scala 2 was released in March 2006, which is a very long time ago. The good news is that Scala 3.0
has been released in May
, 2021. Scala 3
adds new features while removing some obscure features from Scala 2
, with the aim of making Scala
better to use. If you are interested, you can keep an eye on the official website of Scala3
.
Another core change in Scala 3
is the adjustment of the compiler, named TASTy
, which stands for Typed Abstract Syntax Trees
, with the following structure:
With the help of TASTy
, there is already Scala.js
and it is not surprising that Scala WebAssembly
will follow.
Kotlin
and Scala
are very friendly to functional programming, in this point are to make up for the shortcomings of Java
. In addition, Kotlin
and Scala
also support JavaScript
compiled output, which is very helpful for Serverless
platforms based on V8
, such as Cloudflare
’s Serverless
platform. In addition, Kotlin
and Scala
are also actively exploring WebAssembly
support, which are good news for supporting Web
development.
Of course, there are many more JVM
languages, such as Groovy
, Clojure
, etc., which are also actively developing. These JVM
languages compete with each other and learn from each other, which is all very good news for developers.
With the JDK
and JVM
languages that Spring
relies on out of the way, let’s talk about two very successful projects in Spring
, SpringBoot
and Spring Cloud
.
Spring Boot
and Spring Cloud
are two very successful projects that are basically used by Internet companies based on the Java
technology stack. In addition, if you have been following Spring
s top evangelist Josh Long
’s talks recently, you will see that he has been talking about Spring Reactive
and he has written a book called <<Spring Reactive>>
So why do Spring Boot
, Spring Cloud
and Spring Reactive
get so much attention?
We know that there are two very important architectural solutions for cloud native, one is service-oriented architecture and the other is event-driven architecture. The service-oriented architecture is usually based on a synchronous request/response model, which is the goal of Spring Boot
and Spring Cloud
to support this feature; the event-driven architecture is based on an asynchronous message model and message routing, which is the core of the Spring Reactive
project to support this architecture.
Next, I’ll show you exactly how Spring
supports these two important architectural solutions in cloud-native, and with that, you’ll also get a clearer picture of the three important projects in Spring
, Spring Boot
, Spring Cloud
and Spring Reactive
.
3. Mature Service-Oriented Architecture for Spring Boot and Spring Cloud
Usually, applications under cloud-native are inclined to microservice design, and the core elements of microservice design are service-oriented architecture design and application programming interface (API) management. Spring Boot
and Spring Cloud
aim to support this feature, and these two projects have been so successful that Internet companies based on the Java
technology stack are basically using them.
We know that the most typical structure of a service-oriented interface is the request/response pattern, especially the Request/Response pattern for the Web. Of course, remote RPC request/response is also in this category, such as HTTP REST, gRPC and Dubbo.
Corresponding to the service oriented architecture design in Spring
, SpringMVC
can support Web
and HTTP REST API
very well, and also includes support for OpenAPI
. Other RPC
classes of communication are also supported by the corresponding Spring Boot starter
and there is a corresponding starter
component in Spring Boot
which makes development very easy. If you want to expose other forms of services, such as Web Service
and SOAP
traditional services, you can also reach them through the Spring Web Services
(spring-ws) project.
Another feature, API
management, is mainly related to service governance and service consumer invocation, and the corresponding core technology stack is mainly the Spring Cloud
project. The Spring Cloud
provides various basic settings for service architecture and API
management, such as service registration discovery, complex balancing, API Gateway
, break protection, etc. These technology stacks facilitate better management and governance of services, and also allow better invocation of services on the consumer side.
Putting it all together, the typical architecture for service-oriented architecture and API management, corresponding to the Spring Boot
and Spring Cloud
technology stacks, is as follows:
If your architecture is service-oriented, such as involving service orchestration, service governance and API Gateway
, then Spring Cloud
is a very good choice, with complete features, stable framework, good documentation and hands-on experience such as Alibaba. If your company is based on Java
technology stack, then Spring Cloud
is the best support and practice to implement microservice architecture.
Alibaba has open sourced Spring Cloud Alibaba
since July 2018, and as of today, it has gained over 19,000 STARs, which is already more than all other implementations combined. As we can see from the <<2020 Open Source Digitization in Microservices Report>>
published by X-lab Open Labs, Spring Cloud Alibaba
has become the most active and popular Spring Cloud
implementation with the most complete tool chain. You can consider it in your selection process.
3. Making Event-Driven Architecture Easier to Use with Spring Reactive
While we talked about Spring’s support for service-oriented architecture earlier, there is another architectural pattern, which is event-driven architecture. Event-driven architecture is widely considered to be the preferred architectural solution for cloud natives, so how does Spring support this? This brings us to the Spring Reactive
project, the core of which is supporting event-driven architecture.
Spring Reactive
is geared towards asynchronous messaging, messaging or events is the premier architectural pattern for the Enterprise Integration Pattern (EIP), you may have heard of the Spring Enterprise Integration (SpringIntegration) project, which is primarily responsible for enterprise integration. The purpose of Spring Reactive
is to make event-driven architecture design the preferred application architecture, and to make it simpler.
Here’s an aside: I’ve talked to some senior Spring Boot
and Spring Cloud
programmers, and they’re all very familiar with various service-oriented interface designs, even down to the code level details, but when it comes to the Enterprise Integration Pattern (EIP), they all say it’s Martin Fowler
s famous masterpiece, and when asked if they use things like Apache Camel
or Spring Integration
in their systems, they all say the service-oriented architecture is now meeting business needs.
So here is a question, so well-known EIP, ESB or EDA why not adopted in the architecture design? Is the threshold too high, or is it just a pure theory, completely out of practice?
In the service-oriented architecture design, it is basically based on the service interface invocation, and the invocation is synchronous, so service orchestration and API management play a very important role. Of course, in the service-oriented architecture design, we will also introduce some message-driven design, with the help of Kafka or other MQ systems, to deal with some asynchronous or data analysis scenarios, such as sending an email after user registration, triggering events for security audit after user login, triggering incremental indexing of search engines after product information or price modification, triggering various notifications after users place orders, etc.
Service-oriented has its benefits, but there are very many problems to solve, such as non-blocking, service registration and discovery, high performance, and easy integration, which is why many experts have proposed that event-driven architecture is the mainstream in cloud-native scenarios.
Event-driven architectures don’t involve service registration and discovery as the responsible mechanisms, message-based routing is easy, asynchronous messaging is higher performance (and of course your bill is smaller), various SaaS services are simpler to integrate (EventBridge products), FaaS triggers are easy, and so on. If you want to learn more, check out the book <<Building Event-Driven Microservices>>
. Here is a posting of Redhat’s recommended event-driven architecture design based on microservices thinking, as follows:
From this diagram we can see that all interactions between systems are communicated through messages. Instead of an interface-oriented request/response design that handles Request/Response requests from different applications, microservices are constantly processing messages from Brokers in an asynchronous manner.
At this point, you may understand that if Cloud Native
is centered on event-driven design architecture, then Spring Reactive
aims to make event-driven architecture easy to use and convenient to develop, which is the same as Spring Boot
and Cloud's
support for service-oriented architecture. In addition these two architectures are not contradictory, they can coexist and complement each other.
To achieve a better event-driven architecture, two foundations are missing: asynchronization and messaging. Asynchronization can solve the problem of thread waiting, while the message and its message routing, can be a good way to achieve loose coupling of applications. Currently more and more products use asynchronous messaging solution, a variety of messaging products middleware since needless to say, we are familiar with the HTTP/2 are based on asynchronous message communication.
So why asynchronization? We know that the model of message processing and synchronous service calls are different, such as the Event Loop
and Actor model
of message processing, both of which are very efficient ways of processing messages, and if we have to deal with synchronous service calls based on thread pools in the process of message processing, it will inevitably affect the model and performance. Of course it is not completely impossible to have synchronization, just try to avoid too many scenarios of synchronous service calls.
There is a lot of work to be done in Spring
around asynchronization and messaging scenarios, and we all know that Java is very lagging behind on asynchronization support. Java 1.8
added the CompletionStage
interface, Java 9
added Reactive Stream
support intervened with Flow
. Everyone has been concerned about the lightweight threaded Loom
project is still under development and is expected to be released until Java 17
.
So most of the current Java project projects will choose Reactive
framework, of course Spring
team developed Reactor
framework, adding Reactor
to Netty
, Kafka
and other adaptations to ensure that from the bottom is asynchronous, so that is the reason for the name Spring Reactive
.
The next scenario is what we all see, Spring Webflux
, Spring Integration
, Spring Data
and many other projects have added support for asynchronization, all these adjustments, is to ensure that from the bottom is fully asynchronous, you can understand the 5G non-independent networking and independent networking two You can think of it as both non-standalone and standalone networking for 5G, but Spring
has chosen the Reactive
standalone networking, standalone ecological approach, and of course the workload is very large. This involves two very big problems: database and distributed communication.
Currently most NoSQL
products provide an asynchronous interface, asynchronous access to NoSQL
products without any problems. Although NoSQL
is developing rapidly, it still hasn’t shaken the position of database, we all know that the specification of database access in Java
is JDBC
, but JDBC
is a synchronous interface, so Spring
started R2DBC
project, the purpose is to be able to access the database with Reactive
asynchronous interface, at present, the experience of using JDBC and R2DBC in The experience of using JDBC
and R2DBC
under the Spring
framework is almost the same.
Here I synchronize two news with you: Spring 5.3
has built-in R2DBC
support, that is spring-r2dbc
, and spring-jdbc
side by side. We all like to use MySQL
database, also launched mariadb-r2dbc
1.0.0 stable version, Oracle
also launched R2DBC
version of the driver. Of course the DB
framework in Java
, Spring JPA
, MyBatis
, etc. have added adaptations to R2DBC
. Hibernate
also launched hibernate-reactive
project (based on Vert.x database
), although not based on R2DBC
, but is also fully asynchronous.
Another issue is distributed communication, which plays a very important role in the microservices architecture. Spring has always mainly supported HTTP
, but the HTTP
protocol is mainly designed for browsers and the advantages of communicating between back-end services are not obvious, and there is no performance advantage. Of course gRPC
based on HTTP/2
asynchronous messaging is a good choice, but Spring
has never had built-in gRPC
support, but of course this is not a big problem for most developers, and the third-party grpc-spring-boot-starter
does a very good job
If you follow Spring
releases you should know that subsequent versions of Spring 5.2
have chosen the RSocket
communication protocol and built RSocket
into the spring-message
project. Why? RSocket
is a fully asynchronous binary messaging protocol that provides a complete communication model and is peer-to-peer, which is a good match for event-driven architectures, which is why Spring Reactive
has incorporated RSocket
into the core of Spring
. Spring
and Ali team plays a leading role.
There is a CloudEvents
specification under CNCF
, which mainly addresses event communication in heterogeneous systems. Messages and events are consistent in data structure, both are Headers
and Payload(data)
structures, and include message header extensions. With the latest cloudevents-java SDK 2.1
, Spring messaging
adds support for CloudEvents
and supports codec support for the CloudEvent
interface, unifying and integrating messages and events to be handled in Spring
. CloudEvents
and messages in Spring
is much easier.
and enterprise integration-related products, such as Apache Camel
, Alpakk
based on Akka
, MuleSoft
’s Mule 4
, Spring Integration
, etc., which all provide integration with Reactive
and can be said to work seamlessly with Spring Reactive
.
5. Summary
Going back to the question of the article, why will Spring
remain one of the best platforms in the cloud-native era? To summarize, Java
and JDK
development is in a very good place, and the JVM
language is growing and competitive. Mature Spring Boot
and Spring Cloud
have made service-oriented architecture design easy to use, and Spring Reactive
has made event-driven architecture more accessible while allowing more enterprise systems to complete interfacing with Spring Reacitve
, whether it’s an IoT
device, ESB products
, SaaS
or cloud services, etc.
For microservices scenarios, Spring Cloud
provides a mature architecture-oriented service foundation, and Spring Reactive
is an event-driven architecture for the future, not to say, of course, that service-oriented architecture is obsolete, in fact service-oriented architecture is very successful, but in a cloud-native or new Serverless
environment, it may make more sense to have an event-driven architecture, or to use both together, don’t worry, Spring does a great job in both areas.
Reference https://mp.weixin.qq.com/s/RRy-nUGDeiSv-HWsXcAiYQ