小雨伞已上线的触达系统 https://mp.weixin.qq.com/s/wItL0k8oHOqF0_LlEctrRw 在过去一年里，经过多次迭代，已经基本达到当时系统设计的目标。随着业务接入的增多，也引来了我的一些思考。
当前触达系统工作模式
触达系统将要面临的挑战
1.随着大量业务的接入，对于触达的消费速度会面临一定挑战，当然可以通过简单的扩展 消费进程或者直接加机器横向扩展可以解决。
2.触达系统作为基础业务，对于增加触达类型多等操作，存在更大的风险，事故的影响范围会越来越大，解耦服务及如何在不影响现有服务的情况下新增功能或消息类型会变得更重要。
3.如何更有效的利用系统资源，现有的进程模式相对线程、协程而言,占用更多系统资源(内存，cpu)，且随进程增加会越来越明显(花在上下文切换时间越来越多)，系统资源利用率不高。
4.无法做到对某种消息的单独扩展。比如客服消息的使用量大，而邮件的使用量相比客服消息小很多，如果要扩展，在现有模式下，只能整体扩展，无法单独扩展客服消息的消费者，以提高某种消息类型的消费速度。同时各种消息类型单位时间内处理消息的条数存在差异。
5.redis作为消息队列实现，无法实现消费确认机制，会存在消息丢失的可能，且在并发速度上，无法和专业的MQ软件到达相同的并发数量级。
触达系统改进的想法
1.在不改变现有触达系统的功能和协议的情况下，改进消费者的实现方式。
2.公司现有的基础支撑
ETCD 支撑实现服务注册和服务发现
RabbitMQ 代替 redis 实现更高量级的消费速度和消息可靠性
go 语言的推广，go协程模式可实现更少的资源占有和更高的并发速度
3.系统业务架构图：
系统主要分以下角色
- Receiver 服务接收由于接口发送的消息协议，并解析发送到对应消息服务的队列中。
- Consumer 负责消费消息，将消息发送到客户端。
- Alarm System 告警系统(需要更多业务思考)
优化目的
- 解耦每种消息消费者并实现新消息类型服务注册与服务发现。做到在不影响现有系统的情况下扩展功能。
- 实现不同消息的并行消费和水平扩展。
- 更换消息队列模式，实现消息可靠传递与消费
- 减少资源使用提高消费速度。
- 建立触达监控机制
初版触达系统方案地址：https://mp.weixin.qq.com/s/wItL0k8oHOqF0_LlEctrRw