内容回顾 | 不写代码，分享两个解决方案……

最近，确实有点太忙了，昨天回到家都已经十点了，所以一直也没有时间搞事情。

然后这两天在写新需求的时候，发现公司系统架构方面有一些比较好的解决思路，今天我们把思路梳理下分享出来，主要是针对消息中心的一套解决方案；同时空闲时间，也看了一些限流方面的解决方案，今天我们就利用中午时间和大家分享下这两个技术方案。

先看第一个技术方案，消息中心。

消息中心

消息中心一般就是用来给各个平台发送消息的，应用规模小的时候，平台单一的时候（比如只有钉钉或者企业微信一个平台），我们可以直接在应用中嵌入Jms组件，实现消息发送、异步业务处理等业务需求。

但是随着系统规模的扩展，以及平台的扩张，我们可能需要同时给多个平台发送各类消息（需要同时支持钉钉、企业微信、飞书等），处理各类业务需求，这时候单一的Jms组件已经无法满足我们的需求，而且从架构上来说，所有服务都封装在一个系统中，耦合性高，不利于扩展。

这时候，把消息发送处理单独封装成一个独立应用就显得特别重要，而且后期独立的消息系统可以对接各种各样的系统和平台。

我们需要做的仅仅是定义一个主消息队列，封装一个通用的消息体，然后定义一个主消息队列的业务处理类，在这个类中我们做统一的消息保存、消息分发等操作。

看起来有点复杂，但是实际系统架构应该要比这个复杂的多。

简单介绍下，上面这张架构图中，消息中心收到主消息队列的消息后，会保存消息内容，同时会根据不同的消息类型，把它转发到对应的子队列中，然后由对应的子队列的消费者处理相关消息或交易。以上就是消息中心的构建思路，具体实现，我们今天就不展示了，改天我抽时间做一个demo分享下。

限流组件

关于限流组件，我查了一些资料，其中的解决思路大致是这样的：先构建一个token池，池子的大小就是我们限流大小，每收到一个请求，将一个token发给这个请求，知道token全部发送完。这种解决方案，主要应用在秒杀、抢购等应用场景中，可以有效防止超库存下单等情况。

感觉这种场景在我们日常生活中也是很常见的，比如博物馆发送免费门票，然后游客凭票参观，这就是典型的限流。

如果访问请求没有token或者token无效，则相关请求不予以处理。一般我们用redis来创建token池。

这里我们同样只分享思路，具体实现后面再分享。

好了，今天这两种解决方案的分享就到这里吧！另外最近我刚刚好在做钉钉、企业微信创建个人日程的需求，等忙过这一阵，我想把这一块的内容也分享下，供大家参考，让大家少走弯路。好了，今天的内容就到这里吧。