基于NATS构建微服务发布/订阅机制实践

文章内容

  1. NATS & NATS Streaming 介绍
  2. 使用场景分析
  3. 实践方案介绍
  4. 总结

1. NATS & NATS Streaming 介绍

相关参考

官方文档:https://www.nats.io/documentation/
开源代码:

gnatsd(NATS):https://github.com/nats-io/gnatsd
nats-streaming-server(NATS Streaming):https://github.com/nats-io/nats-streaming-server

客户端(多语言支持):

go-nats(NATS 客户端):https://github.com/nats-io/go-nats
go-nats-streaming:https://github.com/nats-io/go-nats-streaming

参数配置:参考github介绍

其他:NATS项目近期加入了CNCF

由于相关的介绍很多而且官方介绍的十分详尽,这里只是分享自己使用过程中的一些感受和经验

1.1 NATS与NATS Streaming的区别

参考:https://github.com/nats-io/nats-streaming-server#relation-to-nats

弄清楚NATS与NATS Streaming各自的职责,区别和他们之间的交互至关重要;简单来说,NATS实现了基本的发布/订阅模型,NATS Streaming提供的则是更高级的特性,包括ACK,持久化等;

理解NATS和NATS Streaming的区别最重要的是,NATS Streaming并不是在NATS上功能的增强,它与NATS之间仍然通过Client进行交互,他们的部署是独立的,NATS Streaming以类似于sidecar的形式服务于NATS

1.2 NATS介绍

轻量,高效,高可用

详细介绍参考:https://www.nats.io/documentation/server/gnatsd-intro/

其中有以下几点值得重点关注:

1).认证授权
NATS提供基于Token和用户名/密码的两种客户端认证方式;
提供基本的针对主题订阅和发布的权限管理;

2).高可用集群
NATS部署高可用集群非常的简单,只需要在各个实例的配置文件中添加如下配置即可;其中集群可单独设置认证方式;

cluster {
  host: '0.0.0.0'
  port: 7248

  routes = [
    nats-route://192.168.59.103:7244
    nats-route://192.168.59.103:7246
  ]
}

3).自动断开不健康的客户端连接
NATS Server和Client之间会维持PING-PONG检查,发现已断开或不健康的连接会主动断开;

这是一种保证Server长时间高效运行的策略;

4).相对简单的监控界面

通过以下启动参数可以提供一个简单的web监控界面,但是功能很简陋,需要进一步改善;为了弥补不足,提供nats-top工具查看更详尽的服务器信息;

 -m your_port

5).单个推送消息大小限制

NATS单个消息的大小限制为1M,基本上是可以满足一般的数据传输的;

1.3 NATS Streaming 介绍

基于NATS构建微服务发布/订阅机制实践_第1张图片

参考地址:https://www.nats.io/documentation/streaming/nats-streaming-intro/

了解NATS Streaming主要关注它为NATS Server提供新特性;主要关注的有以下几点:

1).At-least-once-delivery & Durable subscriptions

至少一次投递和持久化,对于在分布式场景下保证数据的一致性非常有用;

2).Historical message replay by subject & 全局客户端ID唯一

可以选择任意历史节点开始订阅恢复订阅

3).多样化持久化支持

默认将消息保存在内存中,同时支持file,mysql两种持久化支持;

2. 使用场景分析

场景一 高效传输(不保证一致性)

其实在我们使用NATS的初期就是使用的这种模式,主要用于在各个模块信息同步(比如,个人信息的同步),在时效性上和一致性上要求不高;这种场景只需要创建NATS Cluster即可;

场景二 保证最终一致性

一致性的保证主要是通过NATS Streaming提供的特性来完成,在微服务架构中,跨服务的调用链经常存在,如何保证在下游服务不可用或失败的情况下业务数据的一致性要求,NATS Streaming 提供的ACK机制和至少一次传递的特性就非常重要;甚至是要避免在NATS集群宕机恢复过程中可能的数据不一致情况的发生;举例的话,典型的场景包括支付和关键业务状态的更新;

3. 实践方案介绍

场景一

在这种场景下,NATS的角色更多是高效传输层(transport),完成数据的异步传输;因此,只需要部署NATS集群即可,并不需要Streaming提供的高级特性;套用以下模板,创建多节点的NATS集群即可;

集群部署demo(以一个节点配置为例)

# Client port
port: 4222

# HTTP monitoring port
monitor_port: 4223

# 用户
authorization {
  users = [
    {user: <<用户名1>>,password: <<密码1>>}
  ]
  timeout:  1
}

# This is for clustering multiple servers together.
cluster {
  # 集群接口
  port: 4224

  # 集群链接认证
  authorization {
    user: <<用户名2>>
    password: <<密码2>>
    timeout: 0.75
  }

  # 集群信息
  routes = [
    nats-route://<<用户名2>>:<<密码2>>@nats-1:4224
    nats-route://<<用户名2>>:<<密码2>>@nats-2:4224
  ]
}
场景二

由于场景二需要Streaming相关特性支持,所以,需要部署Streaming集群;同时,根据NATS与NATS Streaming 之间独特的工作方式,我们完全可以在场景一中部署的NATS集群的基础上进行NATS Streaming 的部署;也就是说,NATS Streaming集群仍然连接此NATS集群;

这里写图片描述

集群部署demo(以一个节点配置为例)

# NATS Streaming specific configuration
streaming {
  id: stan-cluster
  store: file
  dir: store
  nats_server_url: "<>"
  # 只需要指定集群名和节点名,实现自定发现
  cluster {
    node_id: "stan-1"
    peers: ["stan-2", "stan-3"]
  }
}

Streaming的节点数建议为奇数,Streaming Server通过Raft算法选出leader节点;

4. 总结

NATS使用过程中最显著的感受是轻量,高效以及部署方便(详尽的配置介绍);同时由于它较好的分布式特性,在使用过程中从未出现意外宕机或者数据异常丢失的情况;

你可能感兴趣的:(开源解决方案)