一、項目工具

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 大行其道就不足為怪了。

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 對比的文章：

懵了，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 的高可用方案，基本架構就是一主兩從。當主機出故障了，從機就會被提升為主機。

3.4 外置緩存

對于高并發的架構，外置緩存不可或缺，其中最最最常見的就是 Redis。

之所以大家都采用 Redis 做外置緩存，原因有幾點：

Redis 本身性能非常好。

Redis 有很多數據結構去適配不同的業務緩存需求。