最近几年,Java 的技术栈发展的非常快,成百上千的技术工具正不断地涌出来,这也造成了一个问题:
我们作为开发者,到底应该选哪些工具搭建出最合适的技术栈呢?
今天我就推荐一波我常用的、我了解的工具和框架。
一、项目工具
1.1 IDE
主流的 Java 开发工具现在非 IntelliJ IDEA 莫属。前几年,可能 Eclipse 还能和 IDEA 一争高下,到了现在已经基本是 IDEA 的天下了。
就拿我自己来说吧,我最早用 IDEA,后来用了几年 Eclipse,再后来又用回了 IDEA。
包括我身边的程序员,之前用 Eclipse 的人,这几年不少人都换成用 IDEA 了。
如果你问我用 IDEA 到底哪最爽,我觉得有 3 点:
- 代码智能提示,爽!
- 代码自动生成,爽!
- 代码调试,爽!
而这 3 点,恰恰就是能极大提高开发人员开发效率的 3 点。所以建议做 Java 后端开发的,可以优先考虑 IDEA 作为开发工具。
1.2 版本管理工具
对于项目中的代码版本管理工具,Git 已经处于垄断地位了,新项目的话不需要再考虑 SVN、CVS了。
之所以 Git 现在处于垄断地位,主要胜在 2 点:
-
Git 是分布式的,不会因为版本管理服务器崩溃导致完整的代码历史版本丢失。
-
Git 创建分支是非常廉价的操作,可以随意创建分支,从而使并行开发很容易落地。而 SVN、CVS 这些版本管理工具创建分支则非常笨拙,并行开发非常麻烦。
上述第 1 点大大提升了代码资产的安全可靠程度;第 2 点则完美适应当代的敏捷开发需求。也因此,Git 大行其道就不足为怪了。
分享一本非常不错的 Git 开源手册:
豆瓣9.1分的Git开源手册!
1.3 构建工具
Java 项目的构建工具现在是龙争虎斗,业内一般有两个选择:Maven 和 Gradle。
如果是后端的 Java 项目,那绝大部分用的还是 Maven 去构建项目。如果是前端的 Android 项目,则选择 Gradle。
Gradle 本身要比 Maven 先进很多:它配置灵活,性能优秀,真的是个非常优秀的构建工具。
那为什么在后端 Java 项目构建的时候,大部分用的还是 Maven 呢?
因为Gradle本身太过灵活了,这种灵活带来了两个和后端项目构建特性不太匹配的问题:
-
Gradle 因为灵活,所以用法规则多变,导致学习门槛过高——后端项目本身的构建流程,套路比较死板,变化非常少,所以不需要太多的构建特性、构建规则。也就是说,灵活本身引入的多种用法、规则、特性对后端项目意义不大,为了构建工具本身的使用,去投入时间学习,本身性价比不高。
-
上面说了,后端项目本身的构建流程是比较套路化的,需要进行一些强约束,去保证这种套路的可靠与稳定。而 Gradle 因为本身比较灵活的配置规则,反而失去了 Maven 的那种强约束,这就很可能因为失去了约束,从而造成团队在使用 Gradle 的时候,出现各种冲突和潜在的错误,造成项目构建的不稳定,这对后端项目来说是得不偿失的。
二、开发框架
2.1 Web 框架
现在的 Web 项目开发,大部分都转向了 SpringBoot 了。使用 SpringBoot 有三个最大的好处:
- 配置非常少,可以说是即插即用
- 基于 Spring 构建,入手门槛非常低
- 直接运行,不需要再考虑 Web 容器的问题
SpringBoot 大部分人都很熟了,不再赘述了。
2.2 持久层框架
项目开发中用到的持久层框架,基本有两类:
- Mybatis 系列衍生框架
- JPA 系列衍生框架
在国内来讲,大部分持久层框架还是首选 Mybatis,貌似在国外大部分项目是用的 JPA 框架。
在我看来,互联网项目、toC 的项目更适合 Mybatis,toB 的项目更适合 JPA。
toC 项目的业务需求经常是灵活多变的,所以,往往它需要项目的技术也要跟着灵活多变,而Mybatis本身就是 SQL 的简单封装,很容易加表加字段、改SQL。
而 toB 项目则不一样,需求基本比较稳定,设计好的数据模型不会频繁变化,所以不太需要 Mybatis 的灵活性的,反而更需要对随意修改模型进行一系列的强约束。而这也是 JPA 自身的特性:非常规范,且有众多约束,要改 JPA 的数据模型成本比较大。
因此,大家选持久层框架的时候,要看清项目的特性,根据实际情况选择用 Mybatis 还是 JPA。
2.3 RPC 框架
现在 Java 项目的架构,基本都在转向分布式架构。分布式系统的整合,核心就是 RPC,因此很多项目中都引入了 RPC 框架。
RPC 框架,现在用的比较多的是 Dubbo 框架。
Dubbo 性能非常好:
-
很多 RPC 框架底层使用的通信协议是 HTTP,而 Dubbo 则选择了 TCP 协议作为通信协议。仅从性能上来说,TCP 的性能肯定要比 HTTP 好上许多。
-
而且 Dubbo 自身还大量使用了 NIO 异步编程去进一步做了性能优化。
所以,如果项目中需要使用 RPC,可以首先考虑 Dubbo 框架。
三、中间件
3.1 Web 服务器
现在的 Java 开发,由于大部分使用了 SpringBoot,所以以前大家常用的什么 Tomcat、Jetty、Resin 等 Web 容器都不怎么单独部署使用了。
但是,有一个 Web 容器反而还愈加兴旺起来,这就是 Nginx。
Nginx 在 Java 项目开发里,地位是非常特殊的。它在 Java 项目架构里起到了两个作用:
-
处理静态资源请求的web容器——Nginx 在 Java 项目中,专门负责处理对图片、html、js、css等这类静态资源的 Http 请求。
-
反向代理做分发——除了做专门处理静态资源请求的 Web 容器之外,Nginx 同时还会把对 servlet、controller 等这些动态资源的请求,转发给后面的 SpringBoot 中内置的 Tomcat 容器。
多说一句,因为反向代理这个特性,Nginx 后面会被部署上集群,Nginx 在转发请求的时候,同时也会做负载均衡的请求分发的反向代理。
3.2 消息队列
如今,大家做架构越来越趋向分布式架构。分布式架构里,常用的通信手段,除了网络请求,就是消息队列了。
现在主流的消息队列框架有 RabbitMQ、RocketMQ、Kafka 等。
我之前写过一篇 RabbitMQ 和 Kafka 对比的文章,
RabbitMQ 性能虽然低一些,但是容易上手,更适合用在中小项目。
另外,做金融领域相关项目,用消息队列的话可以优先考虑 RabbitMQ,原因有以下两点:
-
RabbitMQ 是 AMQP 协议的实现,而 AMQP 协议本身就是来自于金融行业的软件专家们联手制定的,非常成熟和全面,已经成了工业标准。
-
RabbitMQ 是 Erlang 写的,Erlang 的虚拟机对内存和 CPU 过载的保护非常成熟,也因此塑造了 Erlang 应用本身的可靠和健壮。
大项目、非金融项目,大家可以在 RocketMQ、Kafka 这两者之间选择。
RocketMQ 和 Kafka 差不多 90% 的功能和概念都是相通的,只是 RocketMQ 在 Kafka 理念的基础上做了一些改进,更适用的业务场景也更广泛。
在流数据处理上,大家应该优先考虑 Kafka,原因是 Kafka 的流数据处理生态更加的完善周全。
3.3 数据库
互联网领域,主流数据库就是MySQL。在一些传统行业,比如银行,Oracle 用的不少。
Oracle 贵,互联网项目的一个特点就是数据库服务器数量贼多,如果用 Oracle 的话,成本太高了。
而且大家越来越有版权意识,国家对这方面也抓的越来越紧,所以,在互联网领域几乎都在用 MySQL。
使用 MySQL,常见的有 MHA 方案——MySQL 的高可用方案,基本架构就是一主两从。当主机出故障了,从机就会被提升为主机。
3.4 外置缓存
对于高并发的架构,外置缓存不可或缺,其中最最最常见的就是 Redis。
之所以大家都采用 Redis 做外置缓存,原因有三点:
-
Redis 本身性能非常好。
-
Redis 有很多数据结构去适配不同的业务缓存需求。
-
Redis 的集群高可用方案和分片存储的高性能方案相对成熟。
以上,就是 Java 开发中经常遇到的主流技术工具了。
由于篇幅所限,我也只列出了一些最核心(或者说每个人都会用到的)工具和中间件。
有一些重要的中间件,我觉得不是所有人都会用到,就没有提及,比如 ElasticSearch、MongoDB、Zookeeper 等(以后再写文章和大家介绍)。
希望这篇文章对大家有帮助,能帮大家快速精准的找到当今的主流技术工具,能帮大家提高开发效率。
你好,我是四猿外。
一家上市公司的技术总监,管理的技术团队一百余人。
我原创了不少文章,把其中的一些精华文章做了个汇总整理,搞了一份PDF——《爬坡》,其中包括了15篇技术文章(学习编程技巧、架构师、MQ、分布式)和 13 篇非技术文章(主要是程序员职场)。
这份文档的质量咋样?我就不多自吹了,很多人看完说”受益匪浅“。
想获取《爬坡》,可以扫下图的码,关注我的公众号「四猿外」,在后台回复:爬坡