最近几年，Java 的技术栈发展的非常快，成百上千的技术工具正不断地涌出来，这也造成了一个问题：

我们作为开发者，到底应该选哪些工具搭建出最合适的技术栈呢？

今天我就推荐一波我常用的、我了解的工具和框架。

一、项目工具
1.1 IDE
主流的 Java 开发工具现在非 IntelliJ IDEA 莫属。前几年，可能 Eclipse 还能和 IDEA 一争高下，到了现在已经基本是 IDEA 的天下了。

就拿我自己来说吧，我最早用 IDEA，后来用了几年 Eclipse，再后来又用回了 IDEA。

包括我身边的程序员，之前用 Eclipse 的人，这几年不少人都换成用 IDEA 了。

如果你问我用 IDEA 到底哪最爽，我觉得有 3 点：

代码智能提示，爽！
代码自动生成，爽！
代码调试，爽！
而这 3 点，恰恰就是能极大提高开发人员开发效率的 3 点。所以建议做 Java 后端开发的，可以优先考虑 IDEA 作为开发工具。

eclipse 也有有点，免安装，不花钱，打开多个项目方便，配置上简单轻便

1.2 版本管理工具
对于项目中的代码版本管理工具，Git 已经处于垄断地位了，新项目的话不需要再考虑 SVN、CVS了。

之所以 Git 现在处于垄断地位，主要胜在 2 点：

Git 是分布式的，不会因为版本管理服务器崩溃导致完整的代码历史版本丢失。
Git 创建分支是非常廉价的操作，可以随意创建分支，从而使并行开发很容易落地。而 SVN、CVS 这些版本管理工具创建分支则非常笨拙，并行开发非常麻烦。
上述第 1 点大大提升了代码资产的安全可靠程度；第 2 点则完美适应当代的敏捷开发需求。也因此，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 大部分人都很熟了，不再赘述了。springboot springcloud项目大全 fhadmin.cn

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 等