Java程式設計師必備的工具和框架

四猿外發表於2022-03-22

最近幾年,Java 的技術棧發展的非常快,成百上千的技術工具正不斷地湧出來,這也造成了一個問題:

我們作為開發者,到底應該選哪些工具搭建出最合適的技術棧呢?

今天我就推薦一波我常用的、我瞭解的工具和框架。

一、專案工具

1.1 IDE

主流的 Java 開發工具現在非 IntelliJ IDEA 莫屬。前幾年,可能 Eclipse 還能和 IDEA 一爭高下,到了現在已經基本是 IDEA 的天下了。

就拿我自己來說吧,我最早用 IDEA,後來用了幾年 Eclipse,再後來又用回了 IDEA。

包括我身邊的程式設計師,之前用 Eclipse 的人,這幾年不少人都換成用 IDEA 了。

如果你問我用 IDEA 到底哪最爽,我覺得有 3 點:

  1. 程式碼智慧提示,爽!
  2. 程式碼自動生成,爽!
  3. 程式碼除錯,爽!

而這 3 點,恰恰就是能極大提高開發人員開發效率的 3 點。所以建議做 Java 後端開發的,可以優先考慮 IDEA 作為開發工具。

1.2 版本管理工具

對於專案中的程式碼版本管理工具,Git 已經處於壟斷地位了,新專案的話不需要再考慮 SVN、CVS了。

之所以 Git 現在處於壟斷地位,主要勝在 2 點:

  1. Git 是分散式的,不會因為版本管理伺服器崩潰導致完整的程式碼歷史版本丟失。

  2. Git 建立分支是非常廉價的操作,可以隨意建立分支,從而使並行開發很容易落地。而 SVN、CVS 這些版本管理工具建立分支則非常笨拙,並行開發非常麻煩。

上述第 1 點大大提升了程式碼資產的安全可靠程度;第 2 點則完美適應當代的敏捷開發需求。也因此,Git 大行其道就不足為怪了。

分享一本非常不錯的 Git 開源手冊:
豆瓣9.1分的Git開源手冊!

1.3 構建工具

Java 專案的構建工具現在是龍爭虎鬥,業內一般有兩個選擇:Maven 和 Gradle。

如果是後端的 Java 專案,那絕大部分用的還是 Maven 去構建專案。如果是前端的 Android 專案,則選擇 Gradle。

Gradle 本身要比 Maven 先進很多:它配置靈活,效能優秀,真的是個非常優秀的構建工具。

那為什麼在後端 Java 專案構建的時候,大部分用的還是 Maven 呢?

因為Gradle本身太過靈活了,這種靈活帶來了兩個和後端專案構建特性不太匹配的問題:

  1. Gradle 因為靈活,所以用法規則多變,導致學習門檻過高——後端專案本身的構建流程,套路比較死板,變化非常少,所以不需要太多的構建特性、構建規則。也就是說,靈活本身引入的多種用法、規則、特性對後端專案意義不大,為了構建工具本身的使用,去投入時間學習,本身價效比不高。

  2. 上面說了,後端專案本身的構建流程是比較套路化的,需要進行一些強約束,去保證這種套路的可靠與穩定。而 Gradle 因為本身比較靈活的配置規則,反而失去了 Maven 的那種強約束,這就很可能因為失去了約束,從而造成團隊在使用 Gradle 的時候,出現各種衝突和潛在的錯誤,造成專案構建的不穩定,這對後端專案來說是得不償失的。

二、開發框架

2.1 Web 框架

現在的 Web 專案開發,大部分都轉向了 SpringBoot 了。使用 SpringBoot 有三個最大的好處:

  1. 配置非常少,可以說是即插即用
  2. 基於 Spring 構建,入手門檻非常低
  3. 直接執行,不需要再考慮 Web 容器的問題

SpringBoot 大部分人都很熟了,不再贅述了。

2.2 持久層框架

專案開發中用到的持久層框架,基本有兩類:

  1. Mybatis 系列衍生框架
  2. 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 效能非常好:

  1. 很多 RPC 框架底層使用的通訊協議是 HTTP,而 Dubbo 則選擇了 TCP 協議作為通訊協議。僅從效能上來說,TCP 的效能肯定要比 HTTP 好上許多。

  2. 而且 Dubbo 自身還大量使用了 NIO 非同步程式設計去進一步做了效能優化。

所以,如果專案中需要使用 RPC,可以首先考慮 Dubbo 框架。

三、中介軟體

3.1 Web 伺服器

現在的 Java 開發,由於大部分使用了 SpringBoot,所以以前大家常用的什麼 Tomcat、Jetty、Resin 等 Web 容器都不怎麼單獨部署使用了。

但是,有一個 Web 容器反而還愈加興旺起來,這就是 Nginx。

Nginx 在 Java 專案開發裡,地位是非常特殊的。它在 Java 專案架構裡起到了兩個作用:

  1. 處理靜態資源請求的web容器——Nginx 在 Java 專案中,專門負責處理對圖片、html、js、css等這類靜態資源的 Http 請求。

  2. 反向代理做分發——除了做專門處理靜態資源請求的 Web 容器之外,Nginx 同時還會把對 servlet、controller 等這些動態資源的請求,轉發給後面的 SpringBoot 中內建的 Tomcat 容器。

多說一句,因為反向代理這個特性,Nginx 後面會被部署上叢集,Nginx 在轉發請求的時候,同時也會做負載均衡的請求分發的反向代理。

3.2 訊息佇列

如今,大家做架構越來越趨向分散式架構。分散式架構裡,常用的通訊手段,除了網路請求,就是訊息佇列了。

現在主流的訊息佇列框架有 RabbitMQ、RocketMQ、Kafka 等。

我之前寫過一篇 RabbitMQ 和 Kafka 對比的文章,

RabbitMQ 效能雖然低一些,但是容易上手,更適合用在中小專案。

另外,做金融領域相關專案,用訊息佇列的話可以優先考慮 RabbitMQ,原因有以下兩點:

  1. RabbitMQ 是 AMQP 協議的實現,而 AMQP 協議本身就是來自於金融行業的軟體專家們聯手製定的,非常成熟和全面,已經成了工業標準。

  2. 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 做外接快取,原因有三點:

  1. Redis 本身效能非常好。

  2. Redis 有很多資料結構去適配不同的業務快取需求。

  3. Redis 的叢集高可用方案和分片儲存的高效能方案相對成熟。

以上,就是 Java 開發中經常遇到的主流技術工具了。

由於篇幅所限,我也只列出了一些最核心(或者說每個人都會用到的)工具和中介軟體。

有一些重要的中介軟體,我覺得不是所有人都會用到,就沒有提及,比如 ElasticSearch、MongoDB、Zookeeper 等(以後再寫文章和大家介紹)。

希望這篇文章對大家有幫助,能幫大家快速精準的找到當今的主流技術工具,能幫大家提高開發效率。


你好,我是四猿外。

一家上市公司的技術總監,管理的技術團隊一百餘人。

我原創了不少文章,把其中的一些精華文章做了個彙總整理,搞了一份PDF——《爬坡》,其中包括了15篇技術文章(學習程式設計技巧、架構師、MQ、分散式)和 13 篇非技術文章(主要是程式設計師職場)。

這份文件的質量咋樣?我就不多自吹了,很多人看完說”受益匪淺“。

想獲取《爬坡》,可以掃下圖的碼,關注我的公眾號「四猿外」,在後臺回覆:爬坡

相關文章