架構師的初級技能，選組件！（2020更新版）

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

2020年新版，對部分組件的描述進行了更新。19年文章參見 這裏 。若是你在作選型方面的工做，或者想了解一些如今正在流行的技術，那麼這篇文章正好適合你。

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

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

1、消息隊列

• √ 推薦：(1) 吞吐量優先選擇kafka
• (2) 穩定性優先選擇RocketMQ
• (3) 物聯網：VerneMQ

一個大型的分佈式系統，一般都會異步化，走消息總線。 消息隊列做爲最主要的基礎組件，在整個體系架構中，有着及其重要的做用。異步一般意味着編程模型的改變，時效性會下降。

kafka是目前最經常使用的消息隊列，尤爲是在大數據方面，有着極高的吞吐量。而rocketmq和rabbitmq，都是電信級別的消息隊列，在業務上用的比較多。相比較而言，ActiveMQ使用的最少，屬於較老一代的消息框架。

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

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

相關文章：
「總體」分佈式消息系統，設計要點。畫龍畫虎難畫骨
「Kafka」Kafka基礎知識索引
「Kafka」 360度測試：KAFKA會丟數據麼？其高可用是否知足需求？
「Kafka」 使用多線程增長kafka消費能力
「AMQ」ActiveMQ架構設計與最佳實踐，須要一萬字
「MQ」開源一個kafka加強：okmq-1.0.0

2、緩存

• √ 推薦：(1) 堆內緩存使用默認的caffeine
• (2) 分佈式緩存採用redis的cluster集羣模式，但要注意使用限制

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

對於單機來講，guava的LoadingCache和ehcache都是些熟面孔，不過SpringBoot選擇了caffeine做爲它的默認堆內緩存，這是由於caffeine的速度比較快的緣由。

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

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

相關文章：
「Redis」這多是最中肯的Redis規範了
「Redis」與親生的Redis Cluster，來一次親密接觸
「Redis」redis的zset有多牛？請把耳朵遞過來
「Redis」好慌，Redis這麼多集羣方案，要用哪一種？
「協議」架構祕笈：移花接木。使用mysql模擬redis
「Redis」Redis都要老了，你還在用什麼古董客戶端？
「堆內」新一代緩存Caffeine，速度確實比Guava的Cache快

3、分庫分表

• √ 推薦：shardingsphere中的sharding-jdbc

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

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

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

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

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

相關文章：
「分庫分表」「分庫分表」 ？選型和流程要慎重，不然會失控
「數據同步」但願一個數據同步，包治百病
「分庫分表」分庫分表「實踐」大全
「HA」」MySQL官方驅動「主從分離的神祕面紗
「Sharding」 現實中的路由規則，可能比你想象中複雜的多
「Sharding」 非規範SQL的sharding-jdbc實踐

4、數據同步

• √ 推薦：canal

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

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

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

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

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

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

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

相關文章：
「雲庫」MySQL痿了，放不下這麼多數據！
「數據同步」由 Canal 組件分析集成中間件架構的通常過程
「雲庫」記一次操蛋的方案降級（雲上冷熱分離的坎坷之路）

5、通信

• √ 推薦：http+json，方便調試。高性能要求可選二進制協議

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

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

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

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

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

相關文章：
「網絡開發」使用Netty，咱們到底在開發些什麼？
「WS」WebSocket協議 8 問

6、微服務

• √ 推薦：（1） 註冊中心：consul
• （2）網關：nginx+Gateway
• （3）配置中心：Apollo
• （4）調用鏈：Skywalking
• （5）熔斷：resilience4j

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

默認的註冊中心eureka再也不維護，consul已經成爲首選，它使用raft協議開發開箱即用。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親生的，Spring Cloud 大力支持，基於 Spring5.0 的新特性 WebFlux 進行開發。底層網絡通訊框架採用的是 Netty，吞吐量高。

相關文檔：
「總體」此次要是講不明白Spring Cloud核心組件，那我就白編這故事了
「總體」微服務不是所有，只是特定領域的子集
「SCG」萬字Spring Cloud Gateway2.0，面向將來的技術，瞭解一下？
「Trace」2w字長文，讓你瞬間擁有「調用鏈」開發經驗
「熔斷」輕攏慢捻，微服務熔斷大總管

7、分佈式工具

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

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

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

8、監控系統

• √ 推薦：prometheus + grafana + telegraf
• 日誌收集：大量ELKB，小量loki

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

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

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

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

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

相關文檔：

「總體」這麼多監控組件，總有一款適合你
「日誌」elkb實踐經驗，再贈送一套複雜的配置文件
「日誌」日誌收集的「DNA」
「日誌」實踐一把Loki，體驗掌上起舞的輕盈
「日誌」你的野花，朕的kibana
「日誌」通常人不敢動系列之—基於logback的日誌「規範」和「脫敏」
「監控」 昔日教人類用火的prometheus，現在在努力報警
「APM」 2w字長文，讓你瞬間擁有「調用鏈」開發經驗
「APM」 這一輪，skywalking勝出
「底層」 冷門instrument包，功能d炸天
「底層」你的也是個人。3例ko多線程，局部變量透傳

9、調度

• √ 推薦：xxl-job

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

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

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

10、入口工具

• √ 推薦：lvs

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

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

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

11、OLT（A）P

• √ 推薦：ES

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

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

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

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

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

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

12、CI/CD

.jpg)

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

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

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

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

Harbor，在 docker registry 基礎上擴展了權限控制，審計，鏡像同步，管理界面等治理 能力，推薦使用。

調度方面，k8sGoogle 開源，社區的強力推進，有大量的落地方案。Rancher對k8s進行了功能的拓展，實現了和k8s集羣交互的一些便捷工具，包括執行命令行，管理多個 k8s集羣，查看k8s集羣節點的運行狀態等，推薦集成。

相關文章：
「持續集成」發佈系統有那麼難麼?
「流程」技術評審，你拿什麼來吐槽？
「流程」研發裏那隻看不見的手，勒的很疼
「規範」外來規範水土不服？手把手教你怎麼擴展阿里規範idea插件
「工具」有了MinIO，你還會用FastDFS麼？

十3、問題排查

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

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

固然，有大批量的linux工具進行支持。

相關文章：
《Linux上，最經常使用的一批命令解析（10年精選）》
最經常使用的一套「Vim「技巧
最經常使用的一套「Sed「技巧
最經常使用的一套「AWK「技巧

十4、本地工具

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

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

json方面，國內使用fastjson最多，三天兩頭冒出個漏洞；國外則使用jackson多一些。它們的api都相似，jackson特性多一些，但fastjson更加容易使用。鑑於fastjson頻繁出現安全問題，如今已經掀起了一股去fastjson的浪潮。

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

End

今天是2020年9月08日。

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

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

做者簡介：小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。