浅谈NATS消息系统

老王 2021-05-21 19:07

我用过很多消息系统,比如:简单的Redis Streams;高效的Kafaka等等,不过自从我把编程语言切换到 Golang 以后,总觉得必须找个用 Golang 开发的消息系统才配得上门当户对,原本我已经和小家碧玉的NSQ厮守终生,不过当我认识了上流社会 CNCF 钦定的大家闺秀NATS后,刹那间就仿佛徐志摩遇到了林徽因,扭头就给结发妻子写了休书。

INSTALLATION

服务端 nats-server,客户端nats,监控工具nats-top,性能测试工具nats-bench

shell> go get github.com/nats-io/nats-server/v2

shell> git clone https://github.com/nats-io/natscli.git
shell> cd natscli/nats
shell> go get .

shell> go get github.com/nats-io/nats-top

shell> git clone https://github.com/nats-io/nats.go.git
shell> cd nats.go/examples/nats-bench
shell> go get .

需要说明的是,关于 stream 有新旧两种架构的服务端实现,其中旧的 NATS Streaming Server 架构已经过时,如果你是初学者,直接使用新的 NATS JetStream 架构即可。

BENCH

开多个命令行窗口,分别启动 nats-server,nats-top,nats-bench:

shell> nats-server -js -m 8222
shell> nats-top
shell> nats-bench -n 100000000 -np 10 -ms 1 a
nats-top

nats-top

如上所示,高达一千万的 MPS,我就问你 OK 不 OK!Beautiful 不 Beautiful!

MODE

PUBLISH SUBSCRIBE

NATS 实现了一对多发布订阅消息模型。当 publisher 往 subject 上发布一条消息后,此 subject 上所有 subscriber 都能收到 此消息,属于一种广播。

Publish-Subscribe

Publish Subscribe

shell> nats sub source.subject
Subscribing on source.subject
[#1] Received on "source.subject"
ZNQz8dCWc5
[#2] Received on "source.subject"
d1EggZJYVT

shell> nats sub source.subject
Subscribing on source.subject
[#1] Received on "source.subject"
ZNQz8dCWc5
[#2] Received on "source.subject"
d1EggZJYVT

shell> nats pub source.subject "{{Random 10 10}}" --count 2
Published 10 bytes to "source.subject"
Published 10 bytes to "source.subject"

QUEUE GROUPS

如果我们把 subscriber 分组,那么当 publisher 往 subject 上发布一条消息后,同一组里只有一个 subscriber 会收到此消息,从而实现了负载均衡。

Queue Groups

Queue Groups

shell> nats sub source.subject --queue foo
Subscribing on source.subject
[#1] Received on "source.subject"
LFuJZBjnxV

shell> nats sub source.subject --queue foo
Subscribing on source.subject
[#1] Received on "source.subject"
76kAIoUYCI

shell> nats pub source.subject "{{Random 10 10}}" --count 2
Published 10 bytes to "source.subject"
Published 10 bytes to "source.subject"

REQUEST REPLY

一般来说,消息系统是以异步的形式工作,也就是说,publisher 往 subject 上发布一条消息后,并不在意 subscriber 的 reply 是什么。如果 publisher 在意 subscriber 的 reply 是什么的话,那么消息系统就应该以同步的形式工作,在具体实现中,是通过两次发布订阅来完成的:当 publisher 发布消息后,它会订阅一个特定的 subject,当 subscriber 处理完消息后,它会把 reply 发布到这个特定的 subject。当然,整个过程对使用者是透明的。

Request-Reply

Request Reply

shell> nats reply 'weather.>' --command "curl -s wttr.in/{{1}}?format=1"
Listening on "weather.>" in group "NATS-RPLY-22"
[#0] Received on subject "weather.beijing":

shell> nats request weather.beijing ''
Sending request on "weather.beijing"
Received on "_INBOX.7mc3ox00ma7WYWyNjuBSsw.NBtCmYbp"
☀ +30°C

通过 weather 例子,我们可以发现 request reply 模式已经有了 RPC 的味道。

MICROSERVICE

正是因为 NATS 具备了 RPC 的能力,所以在微服务中采用 NATS 后,系统会更清晰。

传统微服务架构

传统微服务架构

采用 NATS 的微服务架构

采用 NATS 的微服务架构

说明:以上图片来自于「The Zen of High Performance Messaging with NATS」。

MONITOR

说到监控,除了前面提到的 nats-top 之外,还有诸如 natsboard之类的 UI 可供选择:

natsboard

natsboard

现实中,大家都知道,徐志摩和林徽因的结局,终究还是错付了,不过我对 NATS 的爱不会变,她是我的不二之选,至少在更好的消息系统出现前如此。

[返回] [原文链接]