前幾天，有個(gè)搞培訓(xùn)的朋友，和我要一份java后端的進(jìn)階路線圖，我就把這篇文章發(fā)給了他《必看！java后端，亮劍誅仙》。今天，又想要個(gè)java后端目前最常用的工具和框架，正好我以前畫過這樣一張圖，于是發(fā)給了他。雖然不是很全，但也希望得到他的夸獎(jiǎng)。沒想到…

本篇內(nèi)容涵蓋14個(gè)方面，涉及上百個(gè)框架和工具。會(huì)有你喜歡的，大概也會(huì)有你所討厭的家伙。這是我平常工作中打交道最多的工具，大小公司都適用。如果你有更好的，歡迎留言補(bǔ)充。

一、消息隊(duì)列

一個(gè)大型的分布式系統(tǒng)，通常都會(huì)異步化，走消息總線。  消息隊(duì)列作為最主要的基礎(chǔ)組件，在整個(gè)體系架構(gòu)中，有著及其重要的作用。

kafka是目前最常用的消息隊(duì)列，尤其是在大數(shù)據(jù)方面，有著極高的吞吐量。而rocketmq和rabbitmq，都是電信級(jí)別的消息隊(duì)列，在業(yè)務(wù)上用的比較多。2019年了，不要再盯著JMS不放了（說的就是臃腫的ActiveMQ）。

pulsar是為了解決一些kafka上的問題而誕生的消息系統(tǒng)，比較年輕，工具鏈有限。有些激進(jìn)的團(tuán)隊(duì)經(jīng)過試用，反響不錯(cuò)。

mqtt具體來說是一種協(xié)議，主要用在物聯(lián)網(wǎng)方面，能夠雙向通信，屬于消息隊(duì)列范疇。

二、緩存

數(shù)據(jù)緩存是減少數(shù)據(jù)庫壓力的有效途徑，有單機(jī)java內(nèi)緩存，和分布式緩存之分。

對(duì)于單機(jī)來說，guava的cache和ehcache都是些熟面孔。

對(duì)于分布式緩存來說，優(yōu)先選擇的就是redis，別猶豫。由于redis是單線程的，并不適合高耗時(shí)操作。所以對(duì)于一些數(shù)據(jù)量比較大的緩存，比如圖片、視頻等，使用老牌的memcached效果會(huì)好的多。

JetCache是一個(gè)基于Java的緩存系統(tǒng)封裝，提供統(tǒng)一的api和注解來簡(jiǎn)化緩存的使用。類似SpringCache，支持本地緩存和分布式緩存，是簡(jiǎn)化開發(fā)的利器。

三、分庫分表

分庫分表，幾乎每一個(gè)上點(diǎn)規(guī)模的公司，都會(huì)有自己的方案。目前，推薦使用驅(qū)動(dòng)層的sharding-jdbc，或者代理層的mycat。如果你沒有額外的運(yùn)維團(tuán)隊(duì)，又不想花錢買其他機(jī)器，那么就選前者。

如果分庫分表涉及的項(xiàng)目不多，spring的動(dòng)態(tài)數(shù)據(jù)源是一個(gè)非常好的選擇。它直接編碼在代碼里，直觀但不易擴(kuò)展。

如果只需要讀寫分離 ，那么mysql官方驅(qū)動(dòng)里的replication協(xié)議，是更加輕量級(jí)的選擇。

上面的分庫分表組件，都是大浪淘沙，最終的優(yōu)勝品。這些組件不同于其他組件選型，方案一旦確定，幾乎無法回退，所以要慎之又慎。

分庫分表是小case，準(zhǔn)備分庫分表的階段，才是重點(diǎn)：也就是數(shù)據(jù)同步。

四、數(shù)據(jù)同步

國內(nèi)使用mysql的公司居多，但postgresql憑借其優(yōu)異的性能，使用率逐漸攀升。

不管什么數(shù)據(jù)庫，實(shí)時(shí)數(shù)據(jù)同步工具，都是把自己模擬成一個(gè)從庫，進(jìn)行數(shù)據(jù)拉取和解析。 具體來說，mysql是通過binlog進(jìn)行同步；postgresql使用wal日志進(jìn)行同步。

對(duì)mysql來說，canal是國內(nèi)用的最多的方案；類似的databus也是比較好用的工具。

現(xiàn)在，canal、maxwell等工具，都支持將要同步的數(shù)據(jù)寫入到mq中，進(jìn)行后續(xù)處理，方便了很多。

對(duì)于ETL（抽取、清洗、轉(zhuǎn)換）來說，基本上都是source、task、sink路線，與前面的功能對(duì)應(yīng)。gobblin、datax、logstash、sqoop等，都是這樣的工具。

它們的主要工作，就是怎么方便的定義配置文件，編寫各種各樣的數(shù)據(jù)源適配接口等。這些ETL工具，也可以作為數(shù)據(jù)同步（尤其是全量同步）的工具，通常是根據(jù)ID，或者最后更新時(shí)間 等，進(jìn)行處理。

binlog是實(shí)時(shí)增量工具，ETL工具做輔助。通常一個(gè)數(shù)據(jù)同步功能，需要多個(gè)組件的參與，他們共同組成一個(gè)整體。

五、通訊

Java 中，netty已經(jīng)成為當(dāng)之無愧的網(wǎng)絡(luò)開發(fā)框架，包括其上的socketio（不要再和我提mina了）。對(duì)于http協(xié)議，有common-httpclient，以及更加輕量級(jí)的工具okhttp來支持。

對(duì)于一個(gè)rpc來說，要約定一個(gè)通訊方式和序列化方式。json是最常用的序列化方式，但是傳輸和解析成本大，xml等文本協(xié)議與其類似，都有很多冗余的信息；avro和kryo是二進(jìn)制的序列化工具，沒有這些缺點(diǎn)，但調(diào)試不便。

rpc是遠(yuǎn)程過程調(diào)用的意思 ，其中，thrift、dubbo、gRPC默認(rèn)都是二進(jìn)制序列化方式的socket通訊框架；feign、hessian都是onhttp的遠(yuǎn)程調(diào)用框架。

對(duì)了，gRPC的序列化工具是protobuf，一個(gè)壓縮比很高的二進(jìn)制序列化工具。

通常，服務(wù)的響應(yīng)時(shí)間主要耗費(fèi)在業(yè)務(wù)邏輯以及數(shù)據(jù)庫上，通訊層耗時(shí)在其中的占比很小?？梢愿鶕?jù)自己公司的研發(fā)水平和業(yè)務(wù)規(guī)模來選擇。

六、微服務(wù)

我們不止一次說到微服務(wù)，這一次我們從圍繞它的一堆支持框架，來窺探一下這個(gè)體系。是的，這里依然是在說spring cloud。

默認(rèn)的注冊(cè)中心eureka不再維護(hù)，consul已經(jīng)成為首選。nacos、zookeeper等，都可以作為備選方案。其中nacos帶有后臺(tái)，比較適合國人使用習(xí)慣。

熔斷組件，官方的hystrix也已經(jīng)不維護(hù)了。推薦使用resilience4j，最近阿里的sentinel也表現(xiàn)強(qiáng)勁。

對(duì)于調(diào)用鏈來說，由于OpenTracing的興起，有了很多新的面孔。推薦使用jaeger或者skywalking。spring cloud集成的sleuth+zipkin功能稍弱，甚至不如傳統(tǒng)侵入式的cat。

配置中心是管理多環(huán)境配置文件的利器，尤其在你不想重啟服務(wù)器的情況下進(jìn)行配置更新。目前，開源中做的最好的要數(shù)apollo，并提供了對(duì)spring boot的支持。disconf使用也較為廣泛。相對(duì)來說，spring cloud config功能就局限了些，用的很少。

網(wǎng)關(guān)方面，使用最多的就是nginx，在nginx之上，有基于lua腳本的openrestry。由于openresty的使用非常繁雜，所以有了kong這種封裝級(jí)別更高的網(wǎng)關(guān)。

對(duì)于spring cloud來說，zuul系列推薦使用zuul2，zuul1是多線程阻塞的，有硬傷。spring-cloud-gateway是spring cloud親生的，但目前用的不是很廣泛。

七、分布式工具

大家都知道分布式系統(tǒng)zookeeper能用在很多場(chǎng)景，與其類似的還有基于raft協(xié)議的etcd和consul。

由于它們能夠保證極高的一致性，所以用作協(xié)調(diào)工具是再好不過了。用途集中在：配置中心、分布式鎖、命名服務(wù)、分布式協(xié)調(diào)、master選舉等場(chǎng)所。

對(duì)于分布式事務(wù)方面，則有阿里的fescar工具進(jìn)行支持。但如非特別的必要，還是使用柔性事務(wù)，追尋最終一致性，比較好。

八、監(jiān)控系統(tǒng)

監(jiān)控系統(tǒng)組件種類繁多，目前，最流行的大概就是上面四類。

zabbix在主機(jī)數(shù)量不多的情況下，是非常好的選擇。

prometheus來勢(shì)兇猛，大有一統(tǒng)天下的架勢(shì)。它也可以使用更加漂亮的grafana進(jìn)行前端展示。

influxdata的influxdb和telegraf組件，都比較好用，主要是功能很全。

使用es存儲(chǔ)的elkb工具鏈，也是一個(gè)較好的選擇。我所知道的很多公司，都在用。

九、調(diào)度

大家可能都用過cron表達(dá)式。這個(gè)表達(dá)式，最初就是來自linux的crontab工具。

quartz是java中比較古老的調(diào)度方案，分布式調(diào)度采用數(shù)據(jù)庫鎖的方式，管理界面需要自行開發(fā)。

elastic-job-cloud應(yīng)用比較廣泛，但系統(tǒng)運(yùn)維復(fù)雜，學(xué)習(xí)成本較高。相對(duì)來說，xxl-job就更加輕量級(jí)一些。中國人開發(fā)的系統(tǒng)，后臺(tái)都比較漂亮。

十、入口工具

為了統(tǒng)一用戶的訪問路口，一般會(huì)使用一些入口工具進(jìn)行支持。

其中，haproxy、lvs、keepalived等，使用非常廣泛。

服務(wù)器一般采用穩(wěn)定性較好的centos，并配備ansible工具進(jìn)行支持，那叫一個(gè)爽。

十一、OLT（A）P

現(xiàn)在的企業(yè)，數(shù)據(jù)量都非常大，數(shù)據(jù)倉庫是必須的。

搜索方面，solr和elasticsearch比較流行，它們都是基于lucene的。solr比較成熟，穩(wěn)定性更好一些，但實(shí)時(shí)搜索方面不如es。

列式存儲(chǔ)方面，基于Hadoop 的hbase，使用最是廣泛；基于LSM的leveldb寫入性能優(yōu)越，但目前主要是作為嵌入式引擎使用多一些。

tidb是國產(chǎn)新貴，兼容mysql協(xié)議，公司通過培訓(xùn)向外輸出dba，未來可期。

時(shí)序數(shù)據(jù)庫方面，opentsdb用在超大型監(jiān)控系統(tǒng)多一些。druid和kudu，在處理多維度數(shù)據(jù)實(shí)時(shí)聚合方面，更勝一籌。

cassandra在剛出現(xiàn)時(shí)火了一段時(shí)間，雖然有facebook棄用的新聞，但生態(tài)已經(jīng)形成，常年霸占數(shù)據(jù)庫引擎前15名。

十二、CI/CD

為了支持持續(xù)集成和虛擬化，除了耳熟能詳?shù)膁ocker，我們還有其他工具。

jenkins是打包發(fā)布的首選，畢竟這么多年了，一直是老大哥。當(dāng)然，寫Idea的那家公司，還出了一個(gè)叫TeamCity的工具，操作界面非常流暢。

sonar不得不說是一個(gè)神器，用了它之后，小伙伴們的代碼一片飄紅，我都快被吐沫星子給淹沒了。

對(duì)于公司內(nèi)部來說，一般使用gitlab搭建git服務(wù)器。其實(shí)，它里面的gitlab CI，也是非常好用的。

十三、問題排查

java經(jīng)常發(fā)生內(nèi)存溢出問題。使用jmap導(dǎo)出堆棧后，我一般使用mat進(jìn)行深入分析。

如果在線上實(shí)時(shí)分析，有arthas和perf兩款工具。

當(dāng)然，有大批量的linux工具進(jìn)行支持。比如下面這些：

《Linux上，最常用的一批命令解析（10年精選）》

十四、本地工具

本地使用的jar包和工具，那就多了去了。下面僅僅提一下最最常用的幾個(gè)。

數(shù)據(jù)庫連接池方面，國內(nèi)使用druid最多。目前，有號(hào)稱速度最快的hikari數(shù)據(jù)庫連接池，以及老掉牙的dbcp和c3p0。

json方面，國內(nèi)使用fastjson最多，三天兩頭冒出個(gè)漏洞；國外則使用jackson多一些。它們的api都類似，jackson特性多一些，但fastjson更加容易使用。

工具包方面，雖然有各種commons包，guava首選。