使用NATS替换NSQ为后台服务解耦

简介

满世界的后台都在向微服务架构发展，我对微服务的理解是将一个复杂的业务分拆为多个服务，由多个服务协作完成一个服务；在后台微服务架构时需要考虑高可用、一致性等问题，也要考虑在实现上、编码上的复杂程度，大多同行采用消息服务中间件对服务进行解耦，微服务多个服务间通过消息中间件进行通信。当然有不少做法是采用RPC方式，当服务多、出现网状RPC调用就会很复杂，管理上也不太方便。
之前我们采用NSQ进行通信（开发语言JAVA&Golang）,NSQ的离线消息存储功能也蛮好用，如果程序挂了，重启后不会丢消息。

为什么用NAT替换NSQ，各有什么优缺点

特性	NSQ	NAT
离线	支持	不支持
实时性	准实时	准实时
请求-应答	需自行封装	自带

NSQ的离线功能与消息顺序

• 当程序挂掉重启后可以继续接收处理消息，保证消息不丢失，这项功能对实时性要求不高的业务是非常好用的，可以异步模式，PUB端发送到NSQ就ok，无需关心SUB端处理成功与否以及处理及时性；
• 消息是可能乱序的，这种情况出现在既有离线消息又有内存实时消息的时候，NSQ是不保证绝对的消息顺序的；

NSQ的请求-应答模式

• NSQ本身只提供PUB-SUB，没有请求-应答模式，需要自己进行封装，当然也很简单；在某些业务场景使用纯异步模式不太合适，需要类似RPC的请求-应答模式；

使用NSQ消息中间件，部署应用服务（主备、双主）

以下例子以单个微服务部署两个应用为例子

• 两个应用订阅相同主题，使用相同的CHANNEL，同一条消息只有一个应用接收到，比如鉴权接口，只要一个鉴权通过即可；
• 两个应用订阅相同主题，使用不同的CHANNEL，同一条消息两个应用接收到，比如处理临时内存数据，两个应用都需要更新自身内部内存数据；

NAT的优势（什么性能之类的就不说，基本上都满足需求的）

参考 http://blog.csdn.net/chszs/article/details/50996679

• PUB/SUB模型 针对同一个主题只有订阅了都可以接收到，掉线了就接收不到（不存储离线消息）
• Request/Reply模型 当有多个订阅者收到请求后，只需要其中一个处理成功并Reply即算成功
• 队列模型 在PUB/SUB和Request/Reply上增加队列模型，同一条消息只有一个订阅者接收到
• 使用队列模型，当有多个订阅者时是随机选择订阅者发送消息，不保证负载均衡（切记）

以上，NAT支持异步调用、同步调用，双主、主备模式，假负载模式；做内部消息通信、为微服务架构解耦是非常合适的。

PS:参考

• http://wiki.jikexueyuan.com/project/nsq-guide/
• http://nsq.io/
• https://github.com/nats-io/go-nats