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

[[342127]]

圖片來自 Pexels

 

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

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

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

消息隊(duì)列

推薦：

 

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

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

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

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

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

緩存

 

推薦：

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

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

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

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

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

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

分庫分表

 

推薦：ShardingSphere 中的 Sharding-JDBC。

分庫分表，幾乎每一個(gè)上點(diǎn)規(guī)模的公司，都會(huì)有自己的方案。目前，推薦使用驅(qū)動(dòng)層的 Sharding-JDBC(已經(jīng)進(jìn)入 Apache)，或者代理層的 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ù)同步

 

推薦：Canal。

國內(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)行同步。

對 MySQL 來說，Canal 是國內(nèi)用的最多的方案;類似的 Databus 也是比較好用的工具。

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

對于 ETL(抽取、清洗、轉(zhuǎn)換)來說，基本上都是 Source、Task、Sink 路線，與前面的功能對應(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è)整體。

通訊

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

 

Java 中，Netty 已經(jīng)成為當(dāng)之無愧的網(wǎng)絡(luò)開發(fā)框架，包括其上的 socketio(不要再和我提 mina 了)。

對于 HTTP 協(xié)議，有 common-httpclient，以及更加輕量級(jí)的工具 Okhttp 來支持。

對于一個(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)用框架。

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

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

微服務(wù)

推薦：

 

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

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

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

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

對于調(diào)用鏈來說，由于 OpenTracing 的興起，有了很多新的面孔。推薦使用 Jaeger 或者 Skywalking。Spring Cloud 集成的 Sleuth+Zipkin 功能稍弱，甚至不如傳統(tǒng)侵入式的 Cat。

配置中心是管理多環(huán)境配置文件的利器，尤其在你不想重啟服務(wù)器的情況下進(jìn)行配置更新。

目前，開源中做的最好的要數(shù) Apollo，并提供了對 Spring Boot 的支持。

Disconf 使用也較為廣泛。相對來說，Spring Cloud Config 功能就局限了些，用的很少。

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

對于 Spring Cloud 來說，Zuul 系列推薦使用 Zuul2，Zuul1 是多線程阻塞的，有硬傷。

Spring-Cloud-Gateway 是 Spring Cloud 親生的，Spring Cloud 大力支持，基于 Spring 5.0 的新特性 WebFlux 進(jìn)行開發(fā)。底層網(wǎng)絡(luò)通信框架采用的是 Netty，吞吐量高。

分布式工具

 

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

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

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

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

 

推薦：

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

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

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

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

調(diào)度

 

推薦：XXL-Job。

大家可能都用過 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í)成本較高。相對來說，XXL-Job 就更加輕量級(jí)一些。中國人開發(fā)的系統(tǒng)，后臺(tái)都比較漂亮。

入口工具

推薦：LVS。

 

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

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

OLT(A)P

 

推薦：ES。

現(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ù)?Docker，我們還有其他工具。

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

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

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

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

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

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

問題排查

 

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

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

本地工具

 

本地使用的 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 首選。

總結(jié)

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

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

作者：小姐姐味道

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

編輯：陶家龍

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