2019-04-15 18:41

引用来自“OSC首席混子”的评论

NS_DISPATCHER , NS_CONTORLLER 严重依赖了 MQ 这样真的好么?一旦 MQ 无法正常工作了,整个系统不就是处于瘫痪的状态了么?这个系统里 MQ 是被作为了一种常规的通信机制使用么?

引用来自“宜信技术学院”的评论

MQ采用双主部署,通过LVS进行自动切换,当MQ单台出现故障,会自动故障转移。启动另一台MQ确保通讯没有问题。

引用来自“OSC首席混子”的评论

我是觉得采用MQ方式得通信机制不够轻量级。用一个轻量级的通信机制不是很好么?否则就要把太多的关注点集中在通信的层面。
主要依据业务考量mq的实现,目前采用redis实现,相对轻量,对于对一致性要求高的项目会换成传统mq实现。
2019-04-15 18:40

引用来自“OSC首席混子”的评论

NS_DISPATCHER , NS_CONTORLLER 严重依赖了 MQ 这样真的好么?一旦 MQ 无法正常工作了,整个系统不就是处于瘫痪的状态了么?这个系统里 MQ 是被作为了一种常规的通信机制使用么?

引用来自“宜信技术学院”的评论

MQ采用双主部署,通过LVS进行自动切换,当MQ单台出现故障,会自动故障转移。启动另一台MQ确保通讯没有问题。

引用来自“OSC首席混子”的评论

我是觉得采用MQ方式得通信机制不够轻量级。用一个轻量级的通信机制不是很好么?否则就要把太多的关注点集中在通信的层面。

引用来自“OSC首席混子”的评论

系统中的服务如果开始做横向扩展的时候,MQ 也就需要做横向的扩展,否则这个通信机制可能成为整个系统的瓶颈。
需要依据具体负载高的点进行扩充节点。所以在mq是瓶颈的时候才需要扩展mq。
2019-04-15 17:09

引用来自“OSC首席混子”的评论

NS_DISPATCHER , NS_CONTORLLER 严重依赖了 MQ 这样真的好么?一旦 MQ 无法正常工作了,整个系统不就是处于瘫痪的状态了么?这个系统里 MQ 是被作为了一种常规的通信机制使用么?

引用来自“宜信技术学院”的评论

MQ采用双主部署,通过LVS进行自动切换,当MQ单台出现故障,会自动故障转移。启动另一台MQ确保通讯没有问题。

引用来自“OSC首席混子”的评论

我是觉得采用MQ方式得通信机制不够轻量级。用一个轻量级的通信机制不是很好么?否则就要把太多的关注点集中在通信的层面。
系统中的服务如果开始做横向扩展的时候,MQ 也就需要做横向的扩展,否则这个通信机制可能成为整个系统的瓶颈。
2019-04-15 17:05

引用来自“OSC首席混子”的评论

NS_DISPATCHER , NS_CONTORLLER 严重依赖了 MQ 这样真的好么?一旦 MQ 无法正常工作了,整个系统不就是处于瘫痪的状态了么?这个系统里 MQ 是被作为了一种常规的通信机制使用么?

引用来自“宜信技术学院”的评论

MQ采用双主部署,通过LVS进行自动切换,当MQ单台出现故障,会自动故障转移。启动另一台MQ确保通讯没有问题。
我是觉得采用MQ方式得通信机制不够轻量级。用一个轻量级的通信机制不是很好么?否则就要把太多的关注点集中在通信的层面。
2019-04-15 14:00

引用来自“OSC首席混子”的评论

NS_DISPATCHER , NS_CONTORLLER 严重依赖了 MQ 这样真的好么?一旦 MQ 无法正常工作了,整个系统不就是处于瘫痪的状态了么?这个系统里 MQ 是被作为了一种常规的通信机制使用么?
MQ采用双主部署,通过LVS进行自动切换,当MQ单台出现故障,会自动故障转移。启动另一台MQ确保通讯没有问题。
2019-04-15 11:37
NS_DISPATCHER , NS_CONTORLLER 严重依赖了 MQ 这样真的好么?一旦 MQ 无法正常工作了,整个系统不就是处于瘫痪的状态了么?这个系统里 MQ 是被作为了一种常规的通信机制使用么?
2019-04-15 09:48

引用来自“hotsmile”的评论

还不错的样子!!!
感谢支持~欢迎一起更新升级开源软件~记得点star哦😄
2019-04-15 09:48

引用来自“白云v城主”的评论

需要的就是这种完整的解决方案
感谢支持~欢迎一起更新升级开源软件~记得点star哦😄
2019-04-15 09:20
需要的就是这种完整的解决方案
2019-04-15 09:11
还不错的样子!!!
回复 @
{{emojiItem.symbol}}
返回顶部
顶部