quarkus 接触研究个人总结
quarkus 官网:https://quarkus.io
极客搜索:https://s.geekbang.org/search/c=0/k=quarkus/t=
书籍也有几本了,这个看个人接受程度了,大家自己可以去找。
另外我这边有 quarkus 技术群 qq(871808563)和微信(weirweiwei)都有,如果大家感兴趣可以找我加入讨论。
相关文章
在介绍 quarkus 是什么之前,你可以了解下云原生的相关知识和这篇文章(https://www.infoq.cn/article/IlPLGzhfWB1v7TejQIs5)。
当然还有红帽官方的一些介绍毕竟是亲儿子。
(https://www.redhat.com/zh/topics/cloud-native-apps/what-is-quarkus)
(https://developers.redhat.com/articles/2021/11/04/boost-throughput-resteasy-reactive-quarkus-22#)
如果你能看 YouTube 视频那可以去这里看 quarkus 的官方频道(https://www.youtube.com/c/Quarkusio/videos)
如果你没法看 YouTube 可以去这个地方看我把一部分视频搬到了 B 站(https://space.bilibili.com/36507008),这里不但有 quarkus 官方的视频,还有我总结的一些实践经验。
更多的参考资料还有:https://gitee.com/quarkus-microservice
https://gitee.com/weir_admin/weirblog-quarkus
公众号:爱威尔 会不定期的发布技术最近动态
进入介绍
那么 quarkus 有什么是非常吸引人的:启动速度,内存占用小,利用 graalvm 可以做到把 jar 应用转成二进制的可执行文件即 native 镜像,还有就是开发环境对开发人员的友好体现在只要代码保存就会快速生效,在开发测试环境的一键部署,更关键的是性能的极大提升(这个是相对的)。
为什么会有 quarkus 出现?其实它不是孤独的存在还有很多类似的框架,oracle 的 helidon,由 Grails 框架的创建者开发的 Micronaut 等等,那么这些框架的理念底层都是什么呢?
首先说理念
我认为是性能和前后端分离带来的后端服务的极简主义的需求,换句话说就是快速响应能力,一方面 golang 确实冲击了 java 的领域,另一方面 java 这么多年的发展使其太臃肿,Java 在跟上时代的同时也要甩开包袱,比如 jsp、servlet、j2ee 的诟病,其实 java 早已看出自生的问题,vert.x、MicroProfile 的出现就说明了这一点。
再说说反应式编程
也可以叫做响应式编程,叫什么名字不重要,重要的是异步编程范式走上了时代的舞台,golang 的发展让 java 开始着手自己的协程(https://wiki.openjdk.java.net/display/loom/Main),这是一个大工程,但是不要忘了 java 的杀手锏天花板级别的框架 netty,即便没有协程 Java 也不畏惧任何语言,vert.x 的出色表现就证明了这一点。
技术领先
而 quarkus 的出现正是站在 vert.x 和 MicroProfile 等一批异步编程范式的工具(SmallRye RESTEasy Hibernate Reactive)的肩膀上,可以这么说从技术的角度来看 quarkus 那就是被 java 宠上天的儿子,quarkus 利用的技术没有一个不是 java 语言里面的佼佼者,他们加在一起就是你在官网所看到的卓越的表现。
目前现状个人分析
当然对一个技术光有吹捧是不行的,我们关心的还是落地的问题,只要能落地就能普及这个道理我想都能想明白,那我就说说我目前的一些实践看法:
1.单应用部署:
前后端不分离
就需要用到 quarkus 里面的模板 qute,这个我的博客已经用上了大家可以去看源码,代码层面我用到的程度就是基于 Hibernate ORM with Panache + qute 这是主要的技术支撑,还有一些比如图片的导入、展示(这里涉及到上传下载的技术),对于我这个博客系统来说用到的技术点还真不多,如果要用到 excel 的导入导出还需要引入第三方的 jar 来实现,还比如缓存 redis 我所了解的目前对于 #user.id 这种方式的缓存获取方式还不支持,mongdb 是支持的,消息这块 kafka、amqp 都是支持的,但是具体的操作是有待验证的。
前后端读写分离
读写分离的,jwt 是没问题的,这个我开源出来的几个项目里面都有,其他方面跟上面情况一样,更多的是目前确实需要一个一个去踩坑,其实就是照这你们各自已有的技术体系看看 quarkus 能不能实现。
2.微服务应用
https://gitee.com/quarkus-microservice 这个是我专门开的专题,用来实验 quarkus 微服务这条路的,目前跑通的一个技术架构是结合 istio 来实现 quarkus 的微服务化,这个在 B 站我有分享,还有就是公众号:爱威尔 也会不定期发布一些技术成果。
那么对于没有 istio 甚至没有 kubernetes 的环境来说微服务这条路也可以玩,那就是用上 consul 和 spring cloud gateway(http://www.loveweir.com/view/112)这是我写的实践例子可以参考,当然微服务涉及的技术点很多比如分布式事务,这也是老大难的问题,我的建议是能不用就不用能规避就规避,在 quarkus 这种框架下如果非要用分布式事务可以考虑基于消息的最终一致性方案,另外也有些开源的中间件可以参考(https://github.com/eventuate-tram)。
虽说 quarkus 为云原生而生但是支撑云原生的基础可能是要成本的,大厂就不说了财大气粗,对于没有云基础设施的大部分公司来说那只能是通过购买云服务的方式来运为自己的项目,这恐怕也是云原生呼声大的原因,如果你们公司恰好是基于红帽的基础设施拿 quarkus 的优势还是很明显的,如果你们已经有 kubernetes 上 quarkus 也不是很难,如果你们连 istio 都掌握了 quarkus 更是锦上添花,相比 spring springcloud 也是有非常大的优势。
短板
quarkus 目前最大的问题是推广和研究学习,把 spring 里面成熟的技术,对开发帮助大的技术点都用 quarkus 实现一下,比如 redis key 的获取方式不能用 #user.id 这种获取方式显然是对实际需求考虑的不到位。
所以我在这里还是再次邀请一下,只要你感兴趣咱都可以成为
版权声明: 本文为 InfoQ 作者【weir威尔】的原创文章。
原文链接:【http://xie.infoq.cn/article/e1b70d0245652e394bf7f581b】。
本文遵守【CC BY-NC】协议,转载请保留原文出处及本版权声明。
评论