简介
满世界的后台都在向微服务架构发展，我对微服务的理解是将一个复杂的业务分拆为多个服务，由多个服务协作完成一个服务；在后台微服务架构时需要考虑高可用、一致性等问题，也要考虑在实现上、编码上的复杂程度，大多同行采用消息服务中间件对服务进行解耦，微服务多个服务间通过消息中间件进行通信。当然有不少做法是采用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:参考