如果你在做選型方面的工作，或者想了解一些現(xiàn)在正在流行的技術(shù)，那么這篇文章正好適合你。

[[342127]]

圖片來自 Pexels

 

本篇內(nèi)容涵蓋 14 個方面，涉及上百個框架和工具。會有你喜歡的，大概也會有你所討厭的家伙。

這是我平常工作中打交道最多的工具，大小公司都適用。如果你有更好的，歡迎留言補充：

• 消息隊列
• 緩存
• 分庫分表
• 數(shù)據(jù)同步
• 通訊
• 微服務(wù)
• 分布式工具
• 監(jiān)控系統(tǒng)
• 調(diào)度
• 入口工具
• OLT(A)P
• CI/CD
• 問題排查
• 本地工具

消息隊列

推薦：

 

• 吞吐量優(yōu)先選擇 Kafka。
• 穩(wěn)定性優(yōu)先選擇 RocketMQ。
• 物聯(lián)網(wǎng)：VerneMQ。

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

Kafka 是目前最常用的消息隊列，尤其是在大數(shù)據(jù)方面，有著極高的吞吐量。而 RocketMQ和 RabbitMQ，都是電信級別的消息隊列，在業(yè)務(wù)上用的比較多。

相比較而言，ActiveMQ 使用的最少，屬于較老一代的消息框架。Pulsar 是為了解決一些 Kafka 上的問題而誕生的消息系統(tǒng)，比較年輕，工具鏈有限。有些激進的團隊經(jīng)過試用，反響不錯，但實際使用并不多。

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

緩存

 

推薦：

• 堆內(nèi)緩存使用默認的 Caffeine。
• 分布式緩存采用 Redis 的 Cluster 集群模式，但要注意使用限制。

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

對于單機來說，Guava 的 LoadingCache 和 ehcache 都是些熟面孔，不過 SpringBoot 選擇了 Caffeine 作為它的默認堆內(nèi)緩存，這是因為 Caffeine 的速度比較快的原因。

對于分布式緩存來說，優(yōu)先選擇的就是 Redis，別猶豫。由于 Redis 是單線程的(6.0 支持多線程，但默認不開啟)，并不適合高耗時操作。

所以對于一些數(shù)據(jù)量比較大的緩存，比如圖片、視頻等，使用老牌的 Memcached 效果會好的多。

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

分庫分表

 

推薦：ShardingSphere 中的 Sharding-JDBC。

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

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

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

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

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

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

 

推薦：Canal。

國內(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ù)同步功能，需要多個組件的參與，他們共同組成一個整體。

通訊

推薦：HTTP+Json，方便調(diào)試。高性能要求可選二進制協(xié)議。

 

Java 中，Netty 已經(jīng)成為當(dā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ù)

推薦：

 

• 注冊中心：Consul。
• 網(wǎng)關(guān)：Nginx+Gateway。
• 配置中心：Apollo。
• 調(diào)用鏈：Skywalking。
• 熔斷：Resilience4j。

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

默認的注冊中心 Eureka 不再維護，Consul 已經(jīng)成為首選，它使用 Raft 協(xié)議開發(fā)開箱即用。Nacos、Zookeeper 等，都可以作為備選方案。其中 Nacos 帶有后臺，比較適合國人使用習(xí)慣。

熔斷組件，官方的 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 親生的，Spring Cloud 大力支持，基于 Spring 5.0 的新特性 WebFlux 進行開發(fā)。底層網(wǎng)絡(luò)通信框架采用的是 Netty，吞吐量高。

分布式工具

 

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

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

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

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

 

推薦：

• Prometheus+Grafana+Telegraf。
• 日志收集：大量 ELKB，小量 Loki。

監(jiān)控系統(tǒng)組件種類繁多，目前，最流行的大概就是上面四類。Zabbix 在主機數(shù)量不多的情況下，是非常好的選擇。

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

Influxdata 的 Influxdb 和 Telegraf 組件，都比較好用，主要是功能很全。使用 ES 存儲的 ELKB 工具鏈，也是一個較好的選擇。我所知道的很多公司，都在用。

調(diào)度

 

推薦：XXL-Job。

大家可能都用過 Cron 表達式。這個表達式，最初就是來自 Linux 的 Crontab 工具。

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

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

入口工具

推薦：LVS。

 

為了統(tǒng)一用戶的訪問路口，一般會使用一些入口工具進行支持。其中，Haproxy、LVS、Keepalived 等，使用非常廣泛。

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

OLT(A)P

 

推薦：ES。

現(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é)議，公司通過培訓(xùn)向外輸出 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ù)?Docker，我們還有其他工具。

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

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

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

Harbor，在 Docker Registry 基礎(chǔ)上擴展了權(quán)限控制，審計，鏡像同步，管理界面等治理 能力，推薦使用。

調(diào)度方面，K8s，Google 開源，社區(qū)的強力推動，有大量的落地方案。

Rancher 對 K8s 進行了功能的拓展，實現(xiàn)了和 K8s 集群交互的一些便捷工具，包括執(zhí)行命令行，管理多個 K8s 集群，查看 K8s 集群節(jié)點的運行狀態(tài)等，推薦集成。

問題排查

 

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

如果在線上實時分析，有 Arthas 和 Perf 兩款工具。當(dāng)然，有大批量的 Linux 工具進行支持。

本地工具

 

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

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

Json 方面，國內(nèi)使用 Fastjson 最多，三天兩頭冒出個漏洞;國外則使用 Jackson 多一些。

它們的 API 都類似，Jackson 特性多一些，但 Fastjson 更加容易使用。工具包方面，雖然有各種 Commons 包，Guava 首選。

總結(jié)

架構(gòu)選型，除了你本身對某項技術(shù)比較熟悉，用起來更放心。更多的是需要進行大量調(diào)研、對比，直到掌握。

技術(shù)日新月異，新瓶裝舊酒，名詞一籮筐，程序員很辛苦。唯有那背后的基礎(chǔ)原理，大道至簡的思想，經(jīng)久不衰。

作者：小姐姐味道

簡介：一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和 Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號小姐姐味道(ID：xjjdog)