最近幾年，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 等
本作品採用《CC 協議》，轉載必須註明作者和本文連結