客户端代理架构图分享

Posted 2023-02-27 小弟季义钦

转载请注明出处： jiq•钦's technical Blog - 季义钦

下面是我设计的一个客户端代理的架构图，主要完成以下功能：

1、异步消息通知；

2、耗时任务处理；

3、缓存维护；

注：缓存维护这个功能图上面没有体现出来，主要是提供缓存描述结构和缓存获取接口，特定的缓存业务实现这个接口，客户端代理服务通过.NET的EMF的方式动态加载实现缓存获取接口的类，调用缓存获取接口，将各类缓存维护在自己的内存中。

同时提供一个通过缓存名称获取对应缓存的接口出来，这个接口内部通过命名管道的通信方式向客户端代理服务拿对应的缓存内容。

后端服务化是当前的趋势@！，所以在这个架构中包括一个注册中心，用于服务的动态注册和发现、以及配置信息的管理。

特别注意，在设计使用消息中间件的架构的时候需要利用好其优势：

（1）消息发送者和消息接收者不需要同时在线。

消息发送者发出消息的时候、允许消息接收者关闭甚至crash，当消息接收者重新启动的时候仍然可以接受消息并进行处理。

（2）消息发送者的发送速度和消息接收者的接收并处理的速度不需要一致。

比如前台可以拼命发送订单，发送量可以达到几万甚至几十万的并发量，但是订单处理系统可以慢慢的从消息队列中取出订单进行处理，也可以无缝地增加多几个订单处理系统来进行订单的处理。

（3）消息的发送者和消息的接收者可以使异构的系统。

很多消息中间件都具备多种语言的客户端，如RabbitMQ、ZeroMQ、ActiveMQ等都是。

至于消息队列的选择，需要跟你你的场景的不同选择不同的消息中间件。

比如如果是大量的日志收集，可以使用Kafka。

如果纯粹追求速度，而不担心消息偶尔丢失，以及消息代理down机时消息的丢失，可以选择ZeroMQ，这个号称史上最快的消息队列。

至于ActiveMQ和RabbitMQ，总体来说RabbitMQ更加优秀，因为：

（1）RabbitMQ遵循通用的AMQP协议，而ActiveMQ遵循的是JMS规范，前者的AMQP 在“语意层面的定义”，这就意味着，它并不仅仅是象 JMS 或者其他的 MQ 一样，仅能按照预定义的方式工作，而是“可编程”的消息中间件。而“语言中立”则意味着只要遵循 AMQP 的协议，任何一种语言都可以开发消息组件乃至中间件本身。

（2）RabbitMQ比ActiveMQ速度快，而且HA（High Avalibility）方面是优势，适合企业级开发。

（3）据我所知RabbitMQ在业界使用最为广泛。（除了Kafka很多人用于日志收集，然后再收集的日志数据上进行数据挖掘，挖掘用户习惯等作为广告精准投放依据）。

更重要的是大家可以看看这个网站：http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

明显RabbitMQ胜出@@^_^~!

In any case, given that we expect that we'd have to develop our own queue scaling solution that involves partitioning, which may or may not be a task we are interested in taking on, the strongest candidates are RabbitMQ and Apache QPID. Both are mature products that support AMQP (though they support different versions). Both have strong vendor support, and both have good single-host performance numbers. 

下面是一些消息队列对比的文章，随便看看：

http://blog.csdn.net/sunxinhere/article/details/7968886

http://www.cnblogs.com/liping13599168/articles/1915245.html

http://blog.csdn.net/chenweitongzju/article/details/8172979

http://www.searchsoa.com.cn/showcontent_48449.htm