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