改造前的架构
4.PNG
请求的处理路径：
请求-> lb_svr(负载均衡) -> access_svr(网关) -> device_svr/family_svr (具体的服务) -> mdp_svr -> access_svr
mdp_svr 用来将回包路由到具体的access_svr
当前的问题：
1.耦合严重。新增一个服务，网关就要更改代码，添加连接池业务代码和消息路由代码。业务扩展不方便
2.突发流量，扩容不及时，容易把服务打挂。
利用mq改造后：
5.PNG
改造后的处理路径：
请求-> lb_svr(负载均衡) -> access_svr(网关) -> 推动到mq中对应的topic。比如device_svr服务，access_svr就推动这类消息到topic_device。
具体的服务订阅自己感兴趣的topic，然后消费，处理完消息后，将回包推送到一个指定的回复topic。mdp_svr从这个回复topic中消息消息，然后推送给access_svr(网关)。
为什么还要保留mdp_svr?
所有的网关服务access_svr上线后，会把自己的服务id上报到mdp svr。mdp svr收到回包后，会先从redis中找出当前的客户端连接在哪个access_svr上，然后再将该回包转发给对应的access_svr。
假如去掉mdp_svr，那么所有的access_svr都要订阅这个回复topic，然后查找这个包对应的客户端是否挂在自己这边。
mdp_svr则是把这个查找工作抽离出来单独处理，减轻各个access_svr的压力。
当然，mdp_svr不是必须的。假如要求架构上更加简单，可以去掉mdp_svr。
