1.1 IDE

 

　　主流的 Java 開(kāi)發(fā)工具現(xiàn)在非 IntelliJ IDEA 莫屬。前幾年，可能 Eclipse 還能和 IDEA 一爭(zhēng)高下，到了現(xiàn)在已經(jīng)基本是 IDEA 的天下了。

 

　　就拿我自己來(lái)說(shuō)吧，我最早用 IDEA，后來(lái)用了幾年 Eclipse，再后來(lái)又用回了 IDEA。

 

　　包括我身邊的程序員，之前用 Eclipse 的人，這幾年不少人都換成用 IDEA 了。

 

　　如果你問(wèn)我用 IDEA 到底哪最爽，我覺(jué)得有 3 點(diǎn)：

 

　　代碼智能提示，爽！

 

　　代碼自動(dòng)生成，爽！

 

　　代碼調(diào)試，爽！

 

　　而這 3 點(diǎn)，恰恰就是能極大提高程序員開(kāi)發(fā)效率的 3 點(diǎn)。所以建議做 Java 后端開(kāi)發(fā)的程序員，可以?xún)?yōu)先考慮 IDEA 作為開(kāi)發(fā)工具。

 

　　1.2 版本管理工具

 

　　對(duì)于項(xiàng)目中的代碼版本管理工具，Git 已經(jīng)處于壟斷地位了，新項(xiàng)目的話不需要再考慮 SVN、CVS了。

 

　　之所以 Git 現(xiàn)在處于壟斷地位，主要?jiǎng)僭?2 點(diǎn)：

 

　　Git 是分布式的，不會(huì)因?yàn)榘姹竟芾矸?wù)器崩潰導(dǎo)致完整的代碼歷史版本丟失。

 

　　Git 創(chuàng)建分支是非常廉價(jià)的操作，可以隨意創(chuàng)建分支，從而使并行開(kāi)發(fā)很容易落地。而 SVN、CVS 這些版本管理工具創(chuàng)建分支則非常笨拙，并行開(kāi)發(fā)非常麻煩。

 

　　上述第 1 點(diǎn)大大提升了代碼資產(chǎn)的安全可靠程度；第 2 點(diǎn)則完美適應(yīng)當(dāng)代的敏捷開(kāi)發(fā)需求。也因此，Git 大行其道就不足為怪了。

 

　　1.3 構(gòu)建工具

 

　　Java 項(xiàng)目的構(gòu)建工具現(xiàn)在是龍爭(zhēng)虎斗，業(yè)內(nèi)一般有兩個(gè)選擇：Maven 和 Gradle。

 

　　如果是后端的 Java 項(xiàng)目，那絕大部分用的還是 Maven 去構(gòu)建項(xiàng)目。如果是前端的 Android 項(xiàng)目，則選擇 Gradle。

 

　　Gradle 本身要比 Maven 先進(jìn)很多：它配置靈活，性能優(yōu)秀，真的是個(gè)非常優(yōu)秀的構(gòu)建工具。

 

　　那為什么在后端 Java 項(xiàng)目構(gòu)建的時(shí)候，大部分用的還是 Maven 呢？

 

　　因?yàn)镚radle本身太過(guò)靈活了，這種靈活帶來(lái)了兩個(gè)和后端項(xiàng)目構(gòu)建特性不太匹配的問(wèn)題：

 

　　Gradle 因?yàn)殪`活，所以用法規(guī)則多變，導(dǎo)致學(xué)習(xí)門(mén)檻過(guò)高——后端項(xiàng)目本身的構(gòu)建流程，套路比較死板，變化非常少，所以不需要太多的構(gòu)建特性、構(gòu)建規(guī)則。也就是說(shuō)，靈活本身引入的多種用法、規(guī)則、特性對(duì)后端項(xiàng)目意義不大，為了構(gòu)建工具本身的使用，去投入時(shí)間學(xué)習(xí)，本身性?xún)r(jià)比不高。

 

　　上面說(shuō)了，后端項(xiàng)目本身的構(gòu)建流程是比較套路化的，需要進(jìn)行一些強(qiáng)約束，去保證這種套路的可靠與穩(wěn)定。而 Gradle 因?yàn)楸旧肀容^靈活的配置規(guī)則，反而失去了 Maven 的那種強(qiáng)約束，這就很可能因?yàn)槭チ思s束，從而造成團(tuán)隊(duì)在使用 Gradle 的時(shí)候，出現(xiàn)各種沖突和潛在的錯(cuò)誤，造成項(xiàng)目構(gòu)建的不穩(wěn)定，這對(duì)后端項(xiàng)目來(lái)說(shuō)是得不償失的。

 

 

 

　　2.1 Web 框架

 

　　現(xiàn)在的 Web 項(xiàng)目開(kāi)發(fā)，大部分都轉(zhuǎn)向了 SpringBoot 了。使用 SpringBoot 有三個(gè)最大的好處：

 

　　配置非常少，可以說(shuō)是即插即用

 

　　基于 Spring 構(gòu)建，入手門(mén)檻非常低

 

　　直接運(yùn)行，不需要再考慮 Web 容器的問(wèn)題

 

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

 

　　2.2 持久層框架

 

　　項(xiàng)目開(kāi)發(fā)中用到的持久層框架，基本有兩類(lèi)：

 

　　Mybatis 系列衍生框架

 

　　JPA 系列衍生框架

 

　　在國(guó)內(nèi)來(lái)講，大部分持久層框架還是首選 Mybatis，貌似在國(guó)外大部分項(xiàng)目是用的 JPA 框架。

 

　　在我看來(lái)，互聯(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 的簡(jiǎn)單封裝，很容易加表加字段、改SQL。

 

　　而 toB 項(xiàng)目則不一樣，需求基本比較穩(wěn)定，設(shè)計(jì)好的數(shù)據(jù)模型不會(huì)頻繁變化，所以不太需要 Mybatis 的靈活性的，反而更需要對(duì)隨意修改模型進(jìn)行一系列的強(qiáng)約束。而這也是 JPA 自身的特性：非常規(guī)范，且有眾多約束，要改 JPA 的數(shù)據(jù)模型成本比較大。

 

　　因此，大家選持久層框架的時(shí)候，要看清項(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é)議。僅從性能上來(lái)說(shuō)，TCP 的性能肯定要比 HTTP 好上許多。

 

　　而且 Dubbo 自身還大量使用了 NIO 異步編程去進(jìn)一步做了性能優(yōu)化。

 

　　所以，如果項(xiàng)目中需要使用 RPC，可以首先考慮 Dubbo 框架。

 

 

 

　　3.1 Web 服務(wù)器

 

　　現(xiàn)在的 Java 開(kāi)發(fā)，由于大部分使用了 SpringBoot，所以以前大家常用的什么 Tomcat、Jetty、Resin 等 Web 容器都不怎么單獨(dú)部署使用了。

 

　　但是，有一個(gè) Web 容器反而還愈加興旺起來(lái)，這就是 Nginx。

 

　　Nginx 在 Java 項(xiàng)目開(kāi)發(fā)里，地位是非常特殊的。它在 Java 項(xiàng)目架構(gòu)里起到了兩個(gè)作用：

 

　　處理靜態(tài)資源請(qǐng)求的web容器——Nginx 在 Java 項(xiàng)目中，專(zhuān)門(mén)負(fù)責(zé)處理對(duì)圖片、html、js、css等這類(lèi)靜態(tài)資源的 Http 請(qǐng)求。

 

　　反向代理做分發(fā)——除了做專(zhuān)門(mén)處理靜態(tài)資源請(qǐng)求的 Web 容器之外，Nginx 同時(shí)還會(huì)把對(duì) servlet、controller 等這些動(dòng)態(tài)資源的請(qǐng)求，轉(zhuǎn)發(fā)給后面的 SpringBoot 中內(nèi)置的 Tomcat 容器。

 

　　多說(shuō)一句，因?yàn)榉聪虼磉@個(gè)特性，Nginx 后面會(huì)被部署上集群，Nginx 在轉(zhuǎn)發(fā)請(qǐng)求的時(shí)候，同時(shí)也會(huì)做負(fù)載均衡的請(qǐng)求分發(fā)的反向代理。

 

　　3.2 消息隊(duì)列

 

　　如今，大家做架構(gòu)越來(lái)越趨向分布式架構(gòu)。分布式架構(gòu)里，常用的通信手段，除了網(wǎng)絡(luò)請(qǐng)求，就是消息隊(duì)列了。

 

　　現(xiàn)在主流的消息隊(duì)列框架有 RabbitMQ、RocketMQ、Kafka 等。

 

　　我之前寫(xiě)過(guò)一篇 RabbitMQ 和 Kafka 對(duì)比的文章：

 

　　懵了，Kafka、RabbitMQ到底選哪個(gè)？

 

　　RabbitMQ 性能雖然低一些，但是容易上手，更適合用在中小項(xiàng)目。

 

　　另外，做金融領(lǐng)域相關(guān)項(xiàng)目，用消息隊(duì)列的話可以?xún)?yōu)先考慮 RabbitMQ，原因有以下兩點(diǎn)：

 

　　RabbitMQ 是 AMQP 協(xié)議的實(shí)現(xiàn)，而 AMQP 協(xié)議本身就是來(lái)自于金融行業(yè)的軟件專(zhuān)家們聯(lián)手制定的，非常成熟和全面，已經(jīng)成了工業(yè)標(biāo)準(zhǔn)。

 

　　RabbitMQ 是 Erlang 寫(xiě)的，Erlang 的虛擬機(jī)對(duì)內(nèi)存和 CPU 過(guò)載的保護(hù)非常成熟，也因此塑造了 Erlang 應(yīng)用本身的可靠和健壯。

 

　　大項(xiàng)目、非金融項(xiàng)目，大家可以在 RocketMQ、Kafka 這兩者之間選擇。

 

　　RocketMQ 和 Kafka 差不多 90% 的功能和概念都是相通的，只是 RocketMQ 在 Kafka 理念的基礎(chǔ)上做了一些改進(jìn)，更適用的業(yè)務(wù)場(chǎng)景也更廣泛。

 

　　在流數(shù)據(jù)處理上，大家應(yīng)該優(yōu)先考慮 Kafka，原因是 Kafka 的流數(shù)據(jù)處理生態(tài)更加的完善周全。

 

　　3.3 數(shù)據(jù)庫(kù)

 

　　互聯(lián)網(wǎng)領(lǐng)域，主流數(shù)據(jù)庫(kù)就是MySQL。在一些傳統(tǒng)行業(yè)，比如銀行，Oracle 用的不少。

 

　　Oracle 貴，互聯(lián)網(wǎng)項(xiàng)目的一個(gè)特點(diǎn)就是數(shù)據(jù)庫(kù)服務(wù)器數(shù)量賊多，如果用 Oracle 的話，成本太高了。

 

　　而且大家越來(lái)越有版權(quán)意識(shí)，國(guó)家對(duì)這方面也抓的越來(lái)越緊，所以，在互聯(lián)網(wǎng)領(lǐng)域幾乎都在用 MySQL。

 

　　使用 MySQL，常見(jiàn)的有 MHA 方案——MySQL 的高可用方案，基本架構(gòu)就是一主兩從。當(dāng)主機(jī)出故障了，從機(jī)就會(huì)被提升為主機(jī)。

 

　　3.4 外置緩存

 

　　對(duì)于高并發(fā)的架構(gòu)，外置緩存不可或缺，其中最最最常見(jiàn)的就是 Redis。

 

　　之所以大家都采用 Redis 做外置緩存，原因有三點(diǎn)：

 

　　Redis 本身性能非常好。

 

　　Redis 有很多數(shù)據(jù)結(jié)構(gòu)去適配不同的業(yè)務(wù)緩存需求。