日韩 亚洲一区二_久久vs国产综合色大全_国产精品福利在线_欧美在线一级A片免费观看欧美在线_女同性毛片60分钟

您現(xiàn)在所在的位置：首頁(yè) >常見(jiàn)問(wèn)題 > 課程問(wèn)題 > Java開(kāi)發(fā)中那些非常好用的工具

Java開(kāi)發(fā)中那些非常好用的工具

來(lái)源：奇酷教育 發(fā)表於：

Java開(kāi)發(fā)中那些非常好用的工具

　　Java開(kāi)發(fā)中那些非常好用的工具



　　一、項(xiàng)目工具
 
　　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。
 
　　包括我身邊的程式設(shè)計(jì)師，之前用 Eclipse 的人，這幾年不少人都換(huàn)成用 IDEA 了。
 
　　如果你問(wèn)我用 IDEA 到底哪最爽，我覺得有 3 點(diǎn)：
 
　　代碼智能提示，爽！
 
　　代碼自動(dòng)生成，爽！
 
　　代碼調(diào)試，爽！
 
　　而這 3 點(diǎn)，恰恰就是能極大提高程式設(shè)計(jì)師開(kāi)發(fā)效率的 3 點(diǎn)。所以建議做 Java 後端開(kāi)發(fā)的程式設(shè)計(jì)師，可以優(yōu)先考慮 IDEA 作為開(kāi)發(fā)工具。
 
　　1.2 版本管理工具
 
　　對(duì)於項(xiàng)目中的代碼版本管理工具，Git 已經(jīng)處於壟斷地位了，新項(xiàng)目的話(huà)不需要再考慮 SVN、CVS了。
 
　　之所以 Git 現(xiàn)在處於壟斷地位，主要勝在 2 點(diǎn)：
 
　　Git 是分布式的，不會(huì)因為版本管理伺服器崩潰導(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)一般有兩(liǎng)個(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 呢？
 
　　因為Gradle本身太過(guò)靈活了，這種靈活帶來(lái)了兩(liǎng)個(gè)和後端項(xiàng)目構(gòu )建特性不太匹配的問(wèn)題：
 
　　Gradle 因為靈活，所以用法規(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í)，本身性價(jià)比不高。
 
　　上面說(shuō)了，後端項(xiàng)目本身的構(gòu )建流程是比較套路化的，需要進(jìn)行一些強(qiáng)約束，去保證這種套路的可靠與穩(wěn)定。而 Gradle 因為本身比較靈活的配置規(guī)則，反而失去了 Maven 的那種強(qiáng)約束，這就很可能因為失去了約束，從而造成團(tuán)隊(duì)在使用 Gradle 的時(shí)候，出現(xiàn)各種衝突和潛在的錯誤，造成項(xiàng)目構(gòu )建的不穩(wěn)定，這對(duì)後端項(xiàng)目來(lái)說(shuō)是得不償失的。
 
 
　　二、開(kāi)發(fā)框架
 
　　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ā)中用到的持久層框架，基本有兩(liǎng)類(lèi)：
 
　　Mybatis 系列衍生框架
 
　　JPA 系列衍生框架
 
　　在國(guó)內(nèi)來(lái)講，大部分持久層框架還是首選 Mybatis，貌似在國(guó)外大部分項(xiàng)目是用的 JPA 框架。
 
　　在我看來(lái)，網(wǎng)際網(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 伺服器
 
　　現(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 )裡起到了兩(liǎng)個(gè)作用：
 
　　處理靜態(tài)資源請求的web容器——Nginx 在 Java 項(xiàng)目中，專(zhuān)門(mén)負(fù)責(zé)處理對(duì)圖片、html、js、css等這類(lèi)靜態(tài)資源的 Http 請求。
 
　　反向代理做分發(fā)——除了做專(zhuān)門(mén)處理靜態(tài)資源請求的 Web 容器之外，Nginx 同時(shí)還會(huì)把對(duì) servlet、controller 等這些動(dòng)態(tài)資源的請求，轉(zhuǎn)發(fā)給後面的 SpringBoot 中內(nèi)置的 Tomcat 容器。
 
　　多說(shuō)一句，因為反向代理這個(gè)特性，Nginx 後面會(huì)被部署上集群，Nginx 在轉(zhuǎn)發(fā)請求的時(shí)候，同時(shí)也會(huì)做負(fù)載均衡的請求分發(fā)的反向代理。
 
　　3.2 消息隊(duì)列
 
　　如今，大家做架構(gòu )越來(lái)越趨向分布式架構(gòu )。分布式架構(gòu )裡，常用的通信手段，除了網(wǎng)絡(luò)請求，就是消息隊(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ì)列的話(huà)可以優(yōu)先考慮 RabbitMQ，原因有以下兩(liǎng)點(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 這兩(liǎng)者之間選擇。
 
　　RocketMQ 和 Kafka 差不多 90% 的功能和概念都是相通的，只是 RocketMQ 在 Kafka 理念的基礎(chǔ)上做了一些改進(jìn)，更適用的業(yè)務(wù)場(chǎng)景也更廣(guǎng)泛。
 
　　在流數(shù)據(jù)處理上，大家應(yīng)該優(yōu)先考慮 Kafka，原因是 Kafka 的流數(shù)據(jù)處理生態(tài)更加的完善周全。
 
　　3.3 資料庫(kù)
 
　　網(wǎng)際網(wǎng)路領(lǐng)域，主流資料庫(kù)就是MySQL。在一些傳統(tǒng)行業(yè)，比如銀行，Oracle 用的不少。
 
　　Oracle 貴，網(wǎng)際網(wǎng)路項(xiàng)目的一個(gè)特點(diǎn)就是資料庫(kù)伺服器數(shù)量賊多，如果用 Oracle 的話(huà)，成本太高了。
 
　　而且大家越來(lái)越有版權(quán)意識，國(guó)家對(duì)這方面也抓的越來(lái)越緊，所以，在網(wǎng)際網(wǎng)路領(lǐng)域幾乎都在用 MySQL。
 
　　使用 MySQL，常見(jiàn)的有 MHA 方案——MySQL 的高可用方案，基本架構(gòu )就是一主兩(liǎng)從。當(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ù)緩存需求。