前面已经把用于功能开发的 整体技术架构 基本搭建好了，感觉已经可以落地使用了。
但是，仍然会有很多没有考虑全面的地方，比如缓存和异步消息的架构， 这两个基本上是 目前 做实际应用的标配了，因此在高层架构设计阶段， 同样要对这样通用的、或者是公共的架构进行架构设计。
我们接下来聊一聊如何确定异步消息系统MQ架构的话题。
一：为何需要异步消息系统
1：系统各应用间解耦
MQ的消息生产者和消费者互相不关心对方是否存在，通过MQ这个中间件的存在，使整个系统达到解耦的作用。
如果服务之间用RPC通信，当一个服务跟几百个服务通信时，如果那个服务的通信接口改变，那么几百个服务的通信接口都的跟着变动，这是非常头疼的一件事。
但是采用MQ之后，不管是生产者或者消费者都可以单独改变自己。他们的改变不会影响到别的服务。从而达到解耦的目的。
2：集群处理提高响应速度
MQ有生产者集群和消费者集群，他们都是并行的。从而大大提升响应速度。
3：削峰应对高并发
因为MQ能存储的消息量很大，所以他可以把大量的消息请求先存下了，然后再慢慢处理，比如：秒杀处理、实时抓单系统等。
如果采用RPC通信，每一次请求用调用RPC接口，当请求量巨大的时候，因为RPC的请求是很耗资源的，所以巨大的请求一定会压垮服务器。
削峰的目的是用户体验变好，并且使整个系统稳定，能承受大量请求消息。
二：确定基本的异步消息技术方案
1：确定使用哪一种MQ中间件
这里假定使用Kafka来作为MQ中间件。
一个是在高并发场景下，Kafka的性能非常好；另外，kafka除了支持传统的消息方式：队列、发布订阅模式，它还支持流式处理，同时，跟大数据系统也能很好地结合。
2：确定是否需要MQ集群
这里假定需要做kafka集群
3：确定使用哪一种消息形式，队列 还是 发布订阅？
假定在应用中，队列或发布订阅模式都会存在，具体的可以在结合具体功能实现的时候再确定
三：需思考的点
1：消息发送失败
要保证发送成功，如果不成功，需要重发，或者在业务系统里面记录日志，用定时任务来补发，相当于做业务补偿
2：消息重复消费
这个在消息消费端，处理业务的时候，可以在业务处理前，进行业务数据和业务状态的校验，以判断是否需要继续；另外也可以做幂等处理的设计。
3：另外一个要注意的就是要提高消息消费的速度
至于：消息推送、消息接收、消息处理提交等机制，都有框架帮助我们做好了，我们也就不用去过多思考了。
4：如何做消息驱动应用的可插拔
比如下订单过后，会有一系列的后续处理，像锁定库存、分配积分、赠送优惠券等等，那么，我们怎么能够很方便的去做这些业务的解耦，实现业务可插拔呢？
毕竟刚开始的时候，业务比较少，也简单，但是随着业务发展，会有更多的需求要加进来，最好后面实现的业务就相当于是一个业务插件，加入进来，而不会影响已有的业务。
对于这种场景，一个简单的方式就是：下了订单后，发出一个消息给到MQ，每一个后续的业务动作，都单独实现成为一个插件，自己去监听相应的动作消息，如果有自己该处理的消息，就接收下来处理，思路很简单。
对于这种实现，我们最初实践过统一的事件中心，也就是所有发出的消息，由事件中心统一去接收，然后按照业务规则，再进行分发，业务规则就定义在事件中心。但实践中发现，这种方案在高并发下会有问题，事件中心会成为处理的瓶颈。
后来改成了一个简洁的方案：通过配置来动态的开关消息的业务处理，业务是直接打通，而不需要事件中心再行分发，从而轻松应对高并发。这也说明，好的设计通常就是最简洁的设计。
5：另外：关于消息机制的使用方面，比如：
消息数据的设计
消息统一ID
消息驱动的具体业务处理
等等的内容，就放到概要和详细设计的时候再说
作者：CTO说
链接：https://www.toutiao.com/a7011805056831930919/?log_from=729bd7ea29185_1634022779391
网友评论