网站收录提交入口大全,网络会议网站,网站建设服务器在国外如何打击,西安响应式网站简介#xff1a; 基于Java语言的Spring生态#xff0c;还能否适应新的开发方式#xff0c;比如Cloud Native、Serverless、Faas等#xff0c;它还会是云原生时代的最佳平台的选择吗#xff1f;本文将从5个角度来为你分析一下这个问题#xff0c;分别是#xff1a;Java和…简介 基于Java语言的Spring生态还能否适应新的开发方式比如Cloud Native、Serverless、Faas等它还会是云原生时代的最佳平台的选择吗本文将从5个角度来为你分析一下这个问题分别是Java和JDK的发展、充满良性竞争的JVM语言、成熟的面向服务架构的Spring Boot和Spring Cloud、让事件驱动架构更易使用的Spring Reactive。 作者 | 雷卷 来源 | 阿里技术公众号
大家好我是陈立兵花名雷卷Java/Kotlin工程师、 Alibaba RSocket Broker开发者Reactive基金会的初创成员。目前主要关注于Reactive/RSocket、Serverless、WebAssembly、 Deno/Rust等相关技术。
今天和大家聊聊为什么我认为Spring仍然会是云原生时代最佳平台之一。
时间回到2015年当时我在华盛顿参与SpringOne 2015大会主题演讲是Cloud Native Enterprise。那次大会的口号也是Cloud Native铺天盖地的海报都与Cloud Native有关。 你可能会感到奇怪那个时候容器还没有流行啊怎么就敢称为Cloud Native呢虽然不少同学对Cloud Native的理解可能不太一样但是越来越多的人相信“Cloud native is about culture, not containers”。可以肯定的是云原生不等于容器它是一种软件开发的文化即便后续有基于V8隔离的Serverless或者WebAssembly FaaS平台也还是云原生的范畴。
而在云原生的潮流下Spring做了很多事情比如支持分布式架构的Spring Cloud它基本是Java应用分布式和云化的必备框架各个云厂商都有Spring Cloud的对接版本比如Spring Cloud Alibaba、AWS、Azure、GCP等Spring Cloud极大地简化了Java应用和云服务的对接。
可以说在微服务逐渐流行的过程中Spring生态一直处于领先地位。很多人可能会疑惑Spring之前取得的这些成就我们都知道可这两年好像并没有什么发展Spring还能继续引领该技术趋势吗
其实之所以会有这样的疑惑是因为当我们谈到基于云和云原生环境的开发时普遍更关注的是技术栈的选择而这背后主要是费用的问题。
每一位开发者或中小公司都希望购买更少的云资源干更多的事情其中最主要的是内存和CPU。内存消耗要求小如果能编译为独立可执行程序就尽量选择一些轻量型的开发框架而且要考虑语言高效且全异步化的框架这样可以保证充分利用CPU避免线程等待等造成的浪费。
综合来看很多人会更倾向于选择Rust、Node.js、Golang等技术栈。而Java启动慢消耗内存多好像还比较费钱看起来已经不太适合接下来的云原生时代。
那么作为基于Java语言的Spring生态还能否适应新的开发方式比如Cloud Native、Serverless、Faas等它还会是云原生时代的最佳平台的选择吗
接下来我将从5个角度来为你分析一下这个问题分别是Java和JDK的发展、充满良性竞争的JVM语言、成熟的面向服务架构的Spring Boot和Spring Cloud、让事件驱动架构更易使用的Spring Reactive。
一 Java 和 JDK的发展
我们知道Spring基于的是Java框架而JDK又是运行Java程序的基础。要探讨“Spring还会不会是云原生的最佳平台之一”这个问题我们需要先来看看JDK这个底座怎么样是不是能为Spring与时俱进的发展提供良好的基础。
首先是版本迭代。现在OpenJDK的开发速度非常快之前是三年出一个重大版本现在半年就出一个版本。好多同学感叹现在都快Java 17了而自己还在用Java 1.8。我们都说软件开发要小步快跑这个是一个好的开发方式小步快跑、快速反馈、快速迭代开发。类似的还有JavaScript一年一版TypeScript一年三版Java一年两版可以说都是非常好的节奏。
其次是JDK特性的更新。如果你关注JDK的话就不难发现越来越多的特性被融入到JDK中比如类似协程的轻量级线程Loom项目、提升Native调用支持的Panama项目SIMD支持、更高级的GC算法等。
而针对我们前面提到的Java启动慢、消耗内存多的问题Oracle推出了基于OpenJDK的GraalVM它可以直接在JVM中运行JavaScript、Python、Ruby等语言是名副其实的Ployglot JVM。另外GraalVM还提供了Native Image特性可以将Java代码转换为独立可执行程序。Spring也推出Spring Native项目可以非常方便将Spring Boot应用native-image化这样Spring应用启动的速度更快消耗的内存也更少。native-image化后的Spring应用就可以满足每一位开发者或中小公司对“上云且费用更少”的需求。即便是Java的命令行应用GraalVM也有非常好的解决方案——Picocli GraalVM Native Image upx它可以将Java应用编译为更便捷的可执行程序。
下图就是GraalVM多语言和Native Image支持列表如下 此外各个云厂商也在积极JDK的开发如AliJDK、Amazon Corretto、Azul等这些都是对JDK发展有非常好的作用。
所以说对Spring而言JDK这个基础还是非常稳固的。
二 充满良性竞争的 JVM 语言
JDK并不是只能支持Java这一门编程语言相反它可以支持多种比如Kotlin、Scala、Groovy等这里我们统一称之为JVM语言。当下JVM语言正处于一个充满良性的竞争状态。
我们知道每种语言都有自己擅长的使用场景。在云原生时代多语言开发支持非常重要开发人员需要根据实际的业务场景选择不同的开发语言。无论JVM语言或者GraalVM支持的语言都可以和Spring直接整合方便开发人员充分利用Spring技术栈做开发。
其中对Spring支持最好的语言是Kotlin。Kotlin和Spring的整合已经渗透到框架的各个方面比如Spring Boot和Kotlin整合Spring Webflux对Kotlin Coroutines Flow的支持Spring Data、SpringIntegration、SpringCloud Function等也都包含对Kotlin的支持这些都实现了对Kotlin的深度整合目的就是让语言和框架结合得更好提升开发效率。此外Kotlin和Scala也是与Spring整合得比较好的语言。
因为Java、Kotlin和Scala这三种语言在Spring中的整合非常好所以接下来我就对它们具体说明一下帮助你对JVM语言当前的发展情况有一个比较清晰的认知。
Java
Java语言的发展还是非常快速的伴随着OpenJDK的开发Java半年就会推出一个版本每个版本都会伴随着语法的升级、标准库的升级等极大地方便了开发人员。从Java 9到16已经完成了很多语法和特性方面的提升比如大家知道var关键字局部变量类型推导、Text block、Pattern Matching for instanceof、Record、sealed interface等。
Kotlin
虽然说Kotlin不完全是针对JVM的它也包括Native、JavaScript等但是Kotlin对JVM和Android的支持目前是众多Kotlin平台中特性最多且稳定的。
现在Kotlin的发展势头非常迅速已经孵化了多个子项目比如最新的Kotlin Multiplatform Mobile一套代码支持多个手机平台、 Kotlin Compose for Desktop一套代码开发多操作系统的桌面端应用等。当然这些变化中最引入注目的是Kotlin 1.5推出的Kotlin intermediate representation (IR) 借助于新的IRKotlin的代码可以编译输出到各种目标平台且程序更优如大家都关注的Kotlin WebAssembly。
Scala
Scala 2是2006年3月发布的距今已经有非常长的时间了。好的消息是Scala 3.0已经于2021年5月发布啦。Scala 3在添加新特性的同时去除了Scala 2中一些晦涩的特性目的是让Scala更好使用。如果你有兴趣可以关注下Scala3的官网。
Scala 3还有一个核心的变化是编译器的调整名称为TASTy是 Typed Abstract Syntax Trees的缩写结构如下 借助于TASTy目前已经有Scala.js 后续有Scala WebAssembly也不奇怪。
Kotlin和Scala对函数编程都非常友好在这点上都弥补了Java的不足。此外Kotlin和Scala同时支持JavaScript编译输出这个对基于V8的Serverless平台帮助非常大比如Cloudflare的Serverless平台。此外Kotlin和Scala也在积极探索对WebAssembly支持这些都是支持Web开发的好消息。
当然JVM语言还有很多如Groovy、Clojure等也都在积极发展这些JVM语言彼此竞争彼此借鉴这对开发者来说都是非常好的消息。
Spring依赖的JDK和JVM语言说完了下面我们来聊聊Spring中非常成功的两个项目SpringBoot 和 Spring Cloud。
Spring Boot和Spring Cloud是非常成功的两个项目基于Java技术栈的互联网公司基本都在使用。此外近期如果你有关注Spring顶级布道师Josh Long的演讲的话就会发现他一直在讲Spring Reactive他还编写了一本书就叫《Spring Reactive》。
那为什么Spring Boot、Spring Cloud和Spring Reactive会如此备受关注呢
我们知道对于云原生来讲有两种非常重要的架构方案一个是面向服务化架构另一个是事件驱动架构。面向服务化架构通常基于同步的请求/响应模型Spring Boot、Spring Cloud的目标就是支持这一特性事件驱动架构则基于异步化的消息模型和消息路由而Spring Reactive这个项目的核心就是支撑这一架构。
接下来我就带你看看Spring具体是如何支持云原生里这两种重要的架构方案的借此你也会对Spring里重要的三个项目Spring Boot、Spring Cloud和Spring Reactive有一个比较清楚的认知。
三 成熟的面向服务架构的 Spring Boot 和 Spring Cloud
通常云原生下的应用都倾向于微服务设计而微服务设计的核心内容就是面向服务化架构设计和应用编程接口API管理Spring Boot和Spring Cloud的目标就是支持这一特性的而且这两个项目做得非常成功基于Java技术栈的互联网公司基本都在使用。
我们知道服务化接口最典型的结构就是请求(Request)/响应(Response)模式尤其是Web的Request/Response模式。当然了远程RPC的request/response也在此范畴比如HTTP REST、gRPC和Dubbo。
对应到Spring中面向服务架构设计SpringMVC可以非常好地支持Web和HTTP REST API还包括对OpenAPI的支持。其他RPC类的通讯也都有对应的Spring Boot starter支持在Spring Boot中也有对应的starter组件支持开发也非常便捷。如果要暴露其他形式服务如Web Service和SOAP等传统服务形式也可以哦通过Spring Web Servicesspring-ws项目达成。
另一个特性API管理主要涉及服务治理和服务消费端调用对应的核心技术栈主要是Spring Cloud项目。Spring Cloud为服务化架构和API管理提供了多种基础设置如服务注册发现、负载均衡、API Gateway、断路保护等这些技术栈方便我们更好地管理和治理服务同时也让消费端能更好地调用服务。
综合下来服务化架构和API管理对应到Spring Boot和Spring Cloud技术栈典型的架构如下 如果你的架构是面向服务的如涉及到服务编排、服务治理和API Gateway等那么Spring Cloud会是非常好的选择特性完备、框架稳定、文档完善、历经过诸如阿里巴巴等亲自实践。如果你的公司基于Java技术栈那么Spring Cloud是实现微服务架构最好的支持和实践。
阿里巴巴从2018年7月开始就开源了Spring Cloud Alibaba截止至今它已经获得了超过1.9万的star数已经超过了所有其他实现的总和。从X-lab 开放实验室发布的《2020年微服务领域开源数字化报告》中我们也看到Spring Cloud Alibaba已经成为最活跃、最受开发者欢迎、工具链最完善的Spring Cloud实现。大家在选型过程中可以考虑。
四 让事件驱动架构更易使用的 Spring Reactive
前面我们讲述了Spring对面向服务架构的支持还有另外一种架构模式就是事件驱动架构。事件驱动架构被普遍认为是云原生首选的架构方案那么Spring对这方面支持如何这就涉及到Spring Reactive这个项目了其核心就是支撑事件驱动架构。
Spring Reactive是面向异步化消息的消息或者事件是企业集成模式EIP首推的架构模式你可能听说过Spring企业集成SpringIntegration这个项目其主要就是负责企业集成。Spring Reactive的目的则是让事件驱动架构设计也能成为应用架构的首选而且要更加简单。
这里讲一个题外话我和一些资深的Spring Boot和Spring Cloud程序员交流过大家对各种服务化接口设计如数家珍甚至包括代码层级的细节但是一讨论到企业集成模式EIP都表示这是Martin Fowler的知名大做问及大家的系统中是否使用到诸如Apache Camel或者Spring Integration大家都表示现在面向服务结构已经满足业务需求啦。
那么这里就有一个问题如此知名的EIP、ESB或者EDA为何没有在架构设计中所采纳是灯下黑被遗忘、还是门槛太高、或者压根就是一个纯理论完全脱离实践
在面向服务化的架构设计中基本都是基于服务接口调用并且调用是同步的所以服务编排、API管理起着非常重要的作用。当然在面向服务化的架构设计中我们也会引入一些消息驱动设计借助像Kafka或者其他MQ系统处理一些异步化或者数据分析的场景如用户注册后发一封邮件、用户登录触发事件进行安全审计、商品信息或价格修改后触发搜索引擎增量索引、用户下单后触发各种通知等等。
面向服务有其好处但是要解决非常多的问题如非阻塞、服务注册和发现、高性能、易集成等这也是很多专家提出云原生场景中事件驱动架构才是主流。
事件驱动架构不涉及服务注册和发现这些负责的机制基于消息的路由也非常容易异步化消息通讯的性能更高当然你的账单也更小各种SaaS服务集成也更简单EventBridge产品、FaaS触发容易等等。如果你想了解更多可以看看《Building Event-Driven Microservices》这本书。这里贴一下Redhat推荐的基于微服务思想的事件驱动架构设计如下 从这张图中我们可以看出所有系统之间的交互都是通过消息进行通讯的微服务不再是面向接口的请求/响应设计处理来自不同的应用的Request/Response请求而是以一种异步化的方式不断地在处理来自Broker的消息。
说到这里你可能明白了如果说Cloud Native以事件驱动设计架构为核心那么Spring Reactive的目的是让事件驱动架构简单易用开发便捷这个就是Spring Boot和Cloud对面向服务架构的支持是一样的。此外这两种架构并不是矛盾的都是可以相互共存和相互补充的。
要实现更好的事件驱动架构两个基础少不了异步化和消息化。异步化可以解决线程等待的问题而消息及其消息路由可以很好地实现应用的松耦合。当前越来越多的产品使用异步化消息方案各种消息产品中间件自不必说大家熟知的HTTP/2都是基于异步消息通讯的。
那为何要异步化我们知道消息处理的模型和同步服务调用是不一样的如消息处理的Event Loop和Actor模型都是非常高效的消息处理方式如果我们在消息处理的过程中还要处理基于线程池的同步服务调用势必会影响模型和性能。当然也不是完全不能有同步只是尽量避免过多的服务同步调用的场景。
围绕异步化和消息的场景Spring要做非常多的工作我们都知道Java对异步化支持非常滞后。Java 1.8加入了CompletionStage接口Java 9添加了Reactive Stream支持介入了Flow。大家一直关注的轻量级线程的Loom项目还在开发中预计要到Java 17才能发布。
所以目前Java多数的项目项目都会选择Reactive框架当然Spring团队开发了Reactor框架增加了Reactor对Netty、Kafka等适配从而保证从底层开始就是异步化所以这也是起名为Spring Reactive的原因。
接下来就是大家都看到的场景Spring Webflux、Spring Integration、Spring Data等众多项目都添加了对异步化的支持所有的这些调整就是要确保从底层开始就是全异步化的你可以理解为5G的非独立组网和独立组网两种方式只是Spring选择了Reactive这种独立组网、独立生态的方式当然工作量也是非常大的。这其中就涉及了两个非常大的问题数据库和分布式通讯。
目前大多数NoSQL产品都提供了异步化的接口异步化访问NoSQL产品没有什么问题。虽然NoSQL发展很迅猛但是还是没有撼动数据库的地位我们都知道Java中数据库访问的规范是JDBC但是JDBC是同步的接口所以Spring启动了R2DBC项目目的就是能够以Reactive异步化接口访问数据库目前来说在Spring框架下使用JDBC和R2DBC的体验几乎是一致的。
这里我和同学们同步两个消息Spring 5.3已经内置R2DBC支持也就是spring-r2dbc和spring-jdbc并列。大家都喜欢使用的MySQL数据库也推出了mariadb-r2dbc 1.0.0稳定版Oracle也推出了R2DBC版本的驱动。当然Java中的DB框架Spring JPA、MyBatis等都添加了对R2DBC的适配。Hibernate也推出了hibernate-reactive项目(基于Vert.x database)虽然是不是基于R2DBC的但是也是全异步化的。
另外一个问题就是分布式通讯这个在微服务架构中扮演中非常重要的作用。一直以来Spring主要支持HTTP但是HTTP协议主要是针对浏览器设计的在后端服务之间通讯优势并不明显而且性能上也没有优势。当然基于HTTP/2异步消息通讯的gRPC是一个很好的选择但是Spring一直没有内置gRPC支持当然这对大多数开发者来说这不是什么大问题第三方的grpc-spring-boot-starter做的也非常好。
如果你关注Spring发布的话应该知道Spring 5.2后续版本选择RSocket通讯协议并将RSocket内置到spring-message项目中。为何RSocket是全异步的二进制消息通讯协议提供了完备的通讯模型而且是对等通讯的非常匹配事件驱动架构这也是Spring Reactive将RSocket纳入到Spring核心的原因当然RSocket背后的开发Spring和阿里团队起着主导作用。
CNCF下有一个CloudEvents规范主要解决异构系统的事件通讯消息和事件在数据结构上是一致的都是Headers和Payload(data)结构同时包含消息头的扩展。最新的cloudevents-java SDK 2.1Spring messaging添加了对CloudEvents的支持同时支持CloudEvent接口的编解码支持将消息和事件进行了统一和整合在Spring中处理CloudEvents和消息更简单。
和企业集成相关产品如Apache Camel, 基于Akka的Alpakk、MuleSoft的Mule 4、Spring Integration等这些产品都提供了对Reactive的集成可以说可以和Spring Reactive无缝对接。
五 总结
回到文章的问题为什么Spring 仍然会是云原生时代最佳平台之一总结下来Java和JDK的开发处以非常好的发展JVM语言良性发展且充满竞争。成熟的Spring Boot和Spring Cloud已经让面向服务的架构设计简单易用而Spring Reactive则将事件驱动架构更易被使用同时可以让更多的企业系统完成和Spring Reacitve对接无论是IoT设备、ESB产品、SaaS或者云服务等。
针对微服务的场景Spring Cloud提供了成熟的面向架构服务基础Spring Reactive则是面向未来的事件驱动架构当然这里并不是说面向服务的架构已经过时事实上面向服务的架构非常成功但是在云原生或新的Serverless环境下可能事件驱动架构可能更合理一些或者是两者的配合使用不用担心Spring在这两方面都做的非常好。
原文链接 本文为阿里云原创内容未经允许不得转载。
