Java開發(fā)中那些非常好用的工具
來源：
奇酷教育 發(fā)表于：
Java開發(fā)中那些非常好用的工具
Java開發(fā)中那些非常好用的工具
一、項目工具
1.1 IDE
主流的 Java 開發(fā)工具現(xiàn)在非 IntelliJ IDEA 莫屬。前幾年，可能 Eclipse 還能和 IDEA 一爭高下，到了現(xiàn)在已經(jīng)基本是 IDEA 的天下了。
就拿我自己來說吧，我最早用 IDEA，后來用了幾年 Eclipse，再后來又用回了 IDEA。
包括我身邊的程序員，之前用 Eclipse 的人，這幾年不少人都換成用 IDEA 了。
如果你問我用 IDEA 到底哪最爽，我覺得有 3 點：
代碼智能提示，爽！
代碼自動生成，爽！
代碼調試，爽！
而這 3 點，恰恰就是能極大提高程序員開發(fā)效率的 3 點。所以建議做 Java 后端開發(fā)的程序員，可以優(yōu)先考慮 IDEA 作為開發(fā)工具。
1.2 版本管理工具
對于項目中的代碼版本管理工具，Git 已經(jīng)處于壟斷地位了，新項目的話不需要再考慮 SVN、CVS了。
之所以 Git 現(xiàn)在處于壟斷地位，主要勝在 2 點：
Git 是分布式的，不會因為版本管理服務器崩潰導致完整的代碼歷史版本丟失。
Git 創(chuàng)建分支是非常廉價的操作，可以隨意創(chuàng)建分支，從而使并行開發(fā)很容易落地。而 SVN、CVS 這些版本管理工具創(chuàng)建分支則非常笨拙，并行開發(fā)非常麻煩。
上述第 1 點大大提升了代碼資產(chǎn)的安全可靠程度；第 2 點則完美適應當代的敏捷開發(fā)需求。也因此，Git 大行其道就不足為怪了。
1.3 構建工具
Java 項目的構建工具現(xiàn)在是龍爭虎斗，業(yè)內(nèi)一般有兩個選擇：Maven 和 Gradle。
如果是后端的 Java 項目，那絕大部分用的還是 Maven 去構建項目。如果是前端的 Android 項目，則選擇 Gradle。
Gradle 本身要比 Maven 先進很多：它配置靈活，性能優(yōu)秀，真的是個非常優(yōu)秀的構建工具。
那為什么在后端 Java 項目構建的時候，大部分用的還是 Maven 呢？
因為Gradle本身太過靈活了，這種靈活帶來了兩個和后端項目構建特性不太匹配的問題：
Gradle 因為靈活，所以用法規(guī)則多變，導致學習門檻過高——后端項目本身的構建流程，套路比較死板，變化非常少，所以不需要太多的構建特性、構建規(guī)則。也就是說，靈活本身引入的多種用法、規(guī)則、特性對后端項目意義不大，為了構建工具本身的使用，去投入時間學習，本身性價比不高。
上面說了，后端項目本身的構建流程是比較套路化的，需要進行一些強約束，去保證這種套路的可靠與穩(wěn)定。而 Gradle 因為本身比較靈活的配置規(guī)則，反而失去了 Maven 的那種強約束，這就很可能因為失去了約束，從而造成團隊在使用 Gradle 的時候，出現(xiàn)各種沖突和潛在的錯誤，造成項目構建的不穩(wěn)定，這對后端項目來說是得不償失的。
二、開發(fā)框架
2.1 Web 框架
現(xiàn)在的 Web 項目開發(fā)，大部分都轉向了 SpringBoot 了。使用 SpringBoot 有三個最大的好處：
配置非常少，可以說是即插即用
基于 Spring 構建，入手門檻非常低
直接運行，不需要再考慮 Web 容器的問題
SpringBoot 大部分人都很熟了，不再贅述了。
2.2 持久層框架
項目開發(fā)中用到的持久層框架，基本有兩類：
Mybatis 系列衍生框架
JPA 系列衍生框架
在國內(nèi)來講，大部分持久層框架還是首選 Mybatis，貌似在國外大部分項目是用的 JPA 框架。
在我看來，互聯(lián)網(wǎng)項目、toC 的項目更適合 Mybatis，toB 的項目更適合 JPA。
toC 項目的業(yè)務需求經(jīng)常是靈活多變的，所以，往往它需要項目的技術也要跟著靈活多變，而Mybatis本身就是 SQL 的簡單封裝，很容易加表加字段、改SQL。
而 toB 項目則不一樣，需求基本比較穩(wěn)定，設計好的數(shù)據(jù)模型不會頻繁變化，所以不太需要 Mybatis 的靈活性的，反而更需要對隨意修改模型進行一系列的強約束。而這也是 JPA 自身的特性：非常規(guī)范，且有眾多約束，要改 JPA 的數(shù)據(jù)模型成本比較大。
因此，大家選持久層框架的時候，要看清項目的特性，根據(jù)實際情況選擇用 Mybatis 還是 JPA。
2.3 RPC 框架
現(xiàn)在 Java 項目的架構，基本都在轉向分布式架構。分布式系統(tǒng)的整合，核心就是 RPC，因此很多項目中都引入了 RPC 框架。
RPC 框架，現(xiàn)在用的比較多的是 Dubbo 框架。
Dubbo 性能非常好：
很多 RPC 框架底層使用的通信協(xié)議是 HTTP，而 Dubbo 則選擇了 TCP 協(xié)議作為通信協(xié)議。僅從性能上來說，TCP 的性能肯定要比 HTTP 好上許多。
而且 Dubbo 自身還大量使用了 NIO 異步編程去進一步做了性能優(yōu)化。
所以，如果項目中需要使用 RPC，可以首先考慮 Dubbo 框架。
三、中間件
3.1 Web 服務器
現(xiàn)在的 Java 開發(fā)，由于大部分使用了 SpringBoot，所以以前大家常用的什么 Tomcat、Jetty、Resin 等 Web 容器都不怎么單獨部署使用了。
但是，有一個 Web 容器反而還愈加興旺起來，這就是 Nginx。
Nginx 在 Java 項目開發(fā)里，地位是非常特殊的。它在 Java 項目架構里起到了兩個作用：
處理靜態(tài)資源請求的web容器——Nginx 在 Java 項目中，專門負責處理對圖片、html、js、css等這類靜態(tài)資源的 Http 請求。
反向代理做分發(fā)——除了做專門處理靜態(tài)資源請求的 Web 容器之外，Nginx 同時還會把對 servlet、controller 等這些動態(tài)資源的請求，轉發(fā)給后面的 SpringBoot 中內(nèi)置的 Tomcat 容器。
多說一句，因為反向代理這個特性，Nginx 后面會被部署上集群，Nginx 在轉發(fā)請求的時候，同時也會做負載均衡的請求分發(fā)的反向代理。
3.2 消息隊列
如今，大家做架構越來越趨向分布式架構。分布式架構里，常用的通信手段，除了網(wǎng)絡請求，就是消息隊列了。
現(xiàn)在主流的消息隊列框架有 RabbitMQ、RocketMQ、Kafka 等。
我之前寫過一篇 RabbitMQ 和 Kafka 對比的文章：
懵了，Kafka、RabbitMQ到底選哪個？
RabbitMQ 性能雖然低一些，但是容易上手，更適合用在中小項目。
另外，做金融領域相關項目，用消息隊列的話可以優(yōu)先考慮 RabbitMQ，原因有以下兩點：
RabbitMQ 是 AMQP 協(xié)議的實現(xiàn)，而 AMQP 協(xié)議本身就是來自于金融行業(yè)的軟件專家們聯(lián)手制定的，非常成熟和全面，已經(jīng)成了工業(yè)標準。
RabbitMQ 是 Erlang 寫的，Erlang 的虛擬機對內(nèi)存和 CPU 過載的保護非常成熟，也因此塑造了 Erlang 應用本身的可靠和健壯。
大項目、非金融項目，大家可以在 RocketMQ、Kafka 這兩者之間選擇。
RocketMQ 和 Kafka 差不多 90% 的功能和概念都是相通的，只是 RocketMQ 在 Kafka 理念的基礎上做了一些改進，更適用的業(yè)務場景也更廣泛。
在流數(shù)據(jù)處理上，大家應該優(yōu)先考慮 Kafka，原因是 Kafka 的流數(shù)據(jù)處理生態(tài)更加的完善周全。
3.3 數(shù)據(jù)庫
互聯(lián)網(wǎng)領域，主流數(shù)據(jù)庫就是MySQL。在一些傳統(tǒng)行業(yè)，比如銀行，Oracle 用的不少。
Oracle 貴，互聯(lián)網(wǎng)項目的一個特點就是數(shù)據(jù)庫服務器數(shù)量賊多，如果用 Oracle 的話，成本太高了。
而且大家越來越有版權意識，國家對這方面也抓的越來越緊，所以，在互聯(lián)網(wǎng)領域幾乎都在用 MySQL。
使用 MySQL，常見的有 MHA 方案——MySQL 的高可用方案，基本架構就是一主兩從。當主機出故障了，從機就會被提升為主機。
3.4 外置緩存
對于高并發(fā)的架構，外置緩存不可或缺，其中最最最常見的就是 Redis。
之所以大家都采用 Redis 做外置緩存，原因有三點：
Redis 本身性能非常好。
Redis 有很多數(shù)據(jù)結構去適配不同的業(yè)務緩存需求。
