Java开发中那些非常有用的工具

1。项目工具

1.1 IDE

现在主流的Java开发工具是IntelliJ IDEA。几年前，Eclipse或许还能和IDEA竞争，但现在基本都是IDEA了。 世界。

以我自己为例。我先用IDEA，然后用Eclipse几年，然后又回到IDEA。

包括我身边的程序员，以前用过Eclipse的人，这几年很多人都转用IDEA了。

如果你问我使用IDEA最享受的事情是什么，我想有三点：

• 智能代码提示，酷！
• 自动代码生成，酷！
• 代码调试，酷！

而这3点，正是能够大幅提升程序员开发效率的3点。因此，建议做Java后端开发的程序员优先考虑IDEA作为开发工具。

1.2 版本管理工具

Git 已经垄断了项目中的代码版本管理工具。对于新项目，不需要考虑SVN和CVS。

Git之所以现在处于垄断地位主要是因为2点：

• Git是分布式的，完整的代码历史版本不会因为版本管理服务器崩溃而丢失。
• 在Git中创建分支是一个非常廉价的操作，并且可以随意创建分支，使得并行开发很容易实现。然而SVN、CVS等版本管理工具创建分支非常笨拙，并行开发非常麻烦。

上面第一点大大提高了代码资产的安全性和可靠性；第二点完美适应当代敏捷开发需求。因此，Git 如此受欢迎也就不足为奇了。

1.3 构建工具

Java 项目的构建工具现在正在相互竞争。业界一般有两种选择：Maven和Gradle。

如果是后端Java项目，大部分还是使用Maven来构建项目。如果是前端Android项目，选择Gradle。

Gradle 本身比 Maven 先进得多：它配置灵活，性能优良，确实是一个非常好的构建工具。

那为什么大多数后端Java项目都使用Maven呢？

由于Gradle本身过于灵活，这种灵活性带来了两个不符合后端项目构建特点的问题：

摇篮 因为灵活，所以使用规则多变，这使得学习门槛太高——后端项目本身的构建过程比较僵化，变化很少，所以不需要太多的构建特性和构建规则。也就是说，Flexible本身引入的各种用法、规则、特性对于后端项目意义不大。为了建立工具本身的使用，投入时间学习并不划算。

如上所述，后端项目本身的构建过程是比较套路的，需要一些强约束来保证这个套路的可靠性和稳定性。 Gradle因其灵活的配置规则而失去了 Maven 的强约束，很可能团队因为失去约束而使用 Gradle。 这时就会出现各种冲突和潜在的错误，造成项目建设的不稳定，对于后端项目来说成本大于收益。

2。开发框架

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。中间件

3.1 Web 服务器

目前 Java 开发大多使用 SpringBoot，所以以前常用的 Web 服务器 容器很少单独部署和使用。

然而，有一个Web容器正在变得越来越繁荣，这就是Nginx。

Nginx 在 Java 项目开发中有着非常特殊的地位。它在Java项目架构中扮演两个角色：

处理静态资源请求的Web容器——Nginx。在Java项目中，专门负责处理图片、html、js、css等静态资源的Http请求。

反向代理分发 - 除了作为专门处理静态资源请求的 Web 容器之外，Nginx 还将处理 servlet 和控制器 这些动态资源的请求稍后会转发到SpringBoot内置的Tomcat容器中。

还有一点，由于反向代理的特性，后面会在集群上部署Nginx。 Nginx在转发请求时，也会做反向代理，以实现负载均衡请求分发。

3.2消息队列

现在大家的架构越来越分布式架构。在分布式架构中，最常用的通信方式除了网络请求之外就是消息队列。

目前主流的消息队列框架有RabbitMQ、RocketMQ、Kafka等

我之前写过一篇比较RabbitMQ和Kafka的文章：

我很困惑，Kafka和RabbitMQ该选哪一个？

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的高可用方案。基本架构是一主二从。当master出现故障时，slave将会提升为master。

3.4 外部缓存

对于高并发架构来说，外部缓存是必不可少的，最常见的就是Redis。

大家使用Redis做外部缓存有几个原因：

Redis 本身性能非常好。

Redis有多种数据结构，可以适应不同的业务缓存需求。