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

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

一、消息隊列

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

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

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

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

二、緩存

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

對于單機來說，guava的cache和ehcache都是些熟面孔。

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

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

三、分庫分表

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

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

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

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

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

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

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

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

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

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

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

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

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

五、通訊

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

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

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

對了，gRPC的序列化工具是protobuf，一個壓縮比很高的二進制序列化工具。

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

六、微服務(wù)

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

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

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

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

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

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

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

七、分布式工具

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

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

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

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

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

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

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

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

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

九、調(diào)度

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

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

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

十、入口工具

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

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

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

十一、OLT（A）P

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

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

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

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

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

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

十二、CI/CD

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

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

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

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

十三、問題排查

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

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

當然，有大批量的linux工具進行支持。比如下面這些：

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

十四、本地工具

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

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

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

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