學完這100多技術，能當架構師麼？（非廣告）

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

前幾天，有個搞培訓的朋友，和我要一份java後端的進階路線圖，我就把這篇文章發給了他《必看！java後端，亮劍誅仙》。今天，又想要個java後端目前最經常使用的工具和框架，正好我之前畫過這樣一張圖，因而發給了他。雖然不是很全，但也但願獲得他的誇獎。沒想到...

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

1、消息隊列
2、緩存
3、分庫分表
4、數據同步
5、通信
6、微服務
7、分佈式工具
8、監控系統
9、調度
10、入口工具
11、OLT（A）P
12、CI/CD
十3、問題排查
十4、本地工具
複製代碼

1、消息隊列

一個大型的分佈式系統，一般都會異步化，走消息總線。 消息隊列做爲最主要的基礎組件，在整個體系架構中，有着及其重要的做用。

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

pulsar是爲了解決一些kafka上的問題而誕生的消息系統，比較年輕，工具鏈有限。有些激進的團隊通過試用，反響不錯。

mqtt具體來講是一種協議，主要用在物聯網方面，可以雙向通訊，屬於消息隊列範疇。

2、緩存

數據緩存是減小數據庫壓力的有效途徑，有單機java內緩存，和分佈式緩存之分。

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

對於分佈式緩存來講，優先選擇的就是redis，別猶豫。因爲redis是單線程的，並不適合高耗時操做。因此對於一些數據量比較大的緩存，好比圖片、視頻等，使用老牌的memcached效果會好的多。

JetCache是一個基於Java的緩存系統封裝，提供統一的api和註解來簡化緩存的使用。相似SpringCache，支持本地緩存和分佈式緩存，是簡化開發的利器。

3、分庫分表

分庫分表，幾乎每個上點規模的公司，都會有本身的方案。目前，推薦使用驅動層的sharding-jdbc，或者代理層的mycat。若是你沒有額外的運維團隊，又不想花錢買其餘機器，那麼就選前者。

若是分庫分表涉及的項目很少，spring的動態數據源是一個很是好的選擇。它直接編碼在代碼裏，直觀但不易擴展。

若是隻須要讀寫分離 ，那麼mysql官方驅動裏的replication協議，是更加輕量級的選擇。

上面的分庫分表組件，都是大浪淘沙，最終的優勝品。這些組件不一樣於其餘組件選型，方案一旦肯定，幾乎沒法回退，因此要慎之又慎。

分庫分表是小case，準備分庫分表的階段，纔是重點：也就是數據同步。

4、數據同步

國內使用mysql的公司居多，但postgresql憑藉其優異的性能，使用率逐漸攀升。

無論什麼數據庫，實時數據同步工具，都是把本身模擬成一個從庫，進行數據拉取和解析。 具體來講，mysql是經過binlog進行同步；postgresql使用wal日誌進行同步。

對mysql來講，canal是國內用的最多的方案；相似的databus也是比較好用的工具。

如今，canal、maxwell等工具，都支持將要同步的數據寫入到mq中，進行後續處理，方便了不少。

對於ETL（抽取、清洗、轉換）來講，基本上都是source、task、sink路線，與前面的功能對應。gobblin、datax、logstash、sqoop等，都是這樣的工具。

它們的主要工做，就是怎麼方便的定義配置文件，編寫各類各樣的數據源適配接口等。這些ETL工具，也能夠做爲數據同步（尤爲是全量同步）的工具，一般是根據ID，或者最後更新時間 等，進行處理。

binlog是實時增量工具，ETL工具作輔助。一般一個數據同步功能，須要多個組件的參與，他們共同組成一個總體。

5、通信

Java 中，netty已經成爲當之無愧的網絡開發框架，包括其上的socketio（不要再和我提mina了）。對於http協議，有common-httpclient，以及更加輕量級的工具okhttp來支持。

對於一個rpc來講，要約定一個通信方式和序列化方式。json是最經常使用的序列化方式，可是傳輸和解析成本大，xml等文本協議與其相似，都有不少冗餘的信息；avro和kryo是二進制的序列化工具，沒有這些缺點，但調試不便。

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

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

一般，服務的響應時間主要耗費在業務邏輯以及數據庫上，通信層耗時在其中的佔比很小。能夠根據本身公司的研發水平和業務規模來選擇。

6、微服務

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

默認的註冊中心eureka再也不維護，consul已經成爲首選。nacos、zookeeper等，均可以做爲備選方案。其中nacos帶有後臺，比較適合國人使用習慣。

熔斷組件，官方的hystrix也已經不維護了。推薦使用resilience4j，最近阿里的sentinel也表現強勁。

對於調用鏈來講，因爲OpenTracing的興起，有了不少新的面孔。推薦使用jaeger或者skywalking。spring cloud集成的sleuth+zipkin功能稍弱，甚至不如傳統侵入式的cat。

配置中心是管理多環境配置文件的利器，尤爲在你不想重啓服務器的狀況下進行配置更新。目前，開源中作的最好的要數apollo，並提供了對spring boot的支持。disconf使用也較爲普遍。相對來講，spring cloud config功能就侷限了些，用的不多。

---

網關方面，使用最多的就是nginx，在nginx之上，有基於lua腳本的openrestry。因爲openresty的使用很是繁雜，因此有了kong這種封裝級別更高的網關。

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

7、分佈式工具

你們都知道分佈式系統zookeeper能用在不少場景，與其相似的還有基於raft協議的etcd和consul。

因爲它們可以保證極高的一致性，因此用做協調工具是再好不過了。用途集中在：配置中心、分佈式鎖、命名服務、分佈式協調、master選舉等場所。

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

8、監控系統

監控系統組件種類繁多，目前，最流行的大概就是上面四類。

zabbix在主機數量很少的狀況下，是很是好的選擇。

prometheus來勢兇猛，大有一統天下的架勢。它也可使用更加漂亮的grafana進行前端展現。

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

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

9、調度

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

quartz是java中比較古老的調度方案，分佈式調度採用數據庫鎖的方式，管理界面須要自行開發。

elastic-job-cloud應用比較普遍，但系統運維複雜，學習成本較高。相對來講，xxl-job就更加輕量級一些。中國人開發的系統，後臺都比較漂亮。

10、入口工具

爲了統一用戶的訪問路口，通常會使用一些入口工具進行支持。

其中，haproxy、lvs、keepalived等，使用很是普遍。

服務器通常採用穩定性較好的centos，並配備ansible工具進行支持，那叫一個爽。

11、OLT（A）P

如今的企業，數據量都很是大，數據倉庫是必須的。

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

列式存儲方面，基於Hadoop 的hbase，使用最是普遍；基於LSM的leveldb寫入性能優越，但目前主要是做爲嵌入式引擎使用多一些。

tidb是國產新貴，兼容mysql協議，公司經過培訓向外輸出dba，將來可期。

時序數據庫方面，opentsdb用在超大型監控系統多一些。druid和kudu，在處理多維度數據實時聚合方面，更勝一籌。

cassandra在剛出現時火了一段時間，雖然有facebook棄用的新聞，但生態已經造成，常年霸佔數據庫引擎前15名。

12、CI/CD

爲了支持持續集成和虛擬化，除了耳熟能詳的docker，咱們還有其餘工具。

jenkins是打包發佈的首選，畢竟這麼多年了，一直是老大哥。固然，寫Idea的那家公司，還出了一個叫TeamCity的工具，操做界面很是流暢。

sonar（注意圖上的錯誤）不得不說是一個神器，用了它以後，小夥伴們的代碼一片飄紅，我都快被吐沫星子給淹沒了。

對於公司內部來講，通常使用gitlab搭建git服務器。其實，它裏面的gitlab CI，也是很是好用的。

十3、問題排查

java常常發生內存溢出問題。使用jmap導出堆棧後，我通常使用mat進行深刻分析。

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

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

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

十4、本地工具

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

數據庫鏈接池方面，國內使用druid最多。目前，有號稱速度最快的hikari數據庫鏈接池，以及老掉牙的dbcp和c3p0。

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

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

End

今天是2019年8月13日。颱風利奇馬剛剛肆虐完畢。

這種文章，每年我都會整理一次。有些新面孔，也有些被我我的t出局。架構選型，除了你自己對某項技術比較熟悉，用起來更放心。更多的是須要進行大量調研、對比，直到掌握。

技術突飛猛進，新瓶裝舊酒，名詞一籮筐，程序員很辛苦。惟有那背後的基礎原理，大道至簡的思想，經久不衰。

做者簡介：小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。個人我的微信xjjdog0，歡迎添加好友，​進一步交流。​

近期熱門文章​

《必看！java後端，亮劍誅仙》
後端技術索引，中肯火爆

《Linux上，最經常使用的一批命令解析（10年精選）》 CSDN發佈首日，1k贊。點贊率1/8。

《此次要是講不明白Spring Cloud核心組件，那我就白編這故事了》 用故事講解核心組件，包你滿意

《Linux生產環境上，最經常使用的一套「Sed「技巧》 最經常使用系列Sed篇，簡單易懂。Vim篇更加易懂。