Kafka的应用——环信业务优化

业务背景：

         目前项目应用中采用第三方工具【环信】来作为我们客户端的聊天工具。针对第三方业务稳定性无法把控的特点，我们设计

过多种方案来避免自身业务受制于第三方业务：

         一、环信预注册

                   避免了环信注册账号时，环信业务崩溃而影响自身业务无法正常使用的风险

         二、环信容错

                   避免了环信业务不稳定时，造成自身业务数据不一致的风险

          但是目前，环信业务仍然直接耦合在自身业务中，虽然通过以上措施保证了自身业务的可用性与数据一致性，却无法保证在

环信业务崩溃时，自身业务的流畅与快捷。（由于环信业务的阻塞，业务处理时间将大大延长，业务并发性能与用户体验将大大

降低）

解决策略：

         通过消息队列的特性，将自身业务与第三方业务（环信）解耦合：

         1、自身业务中涉及环信数据不做处理，直接通过 Producer 以 JSON 格式发送到 kafka （屏蔽了环信操作造成阻塞、超时

而影响自身业务的执行）；

         2、推送 系统作为 kafka 的 Consumer 角色，处理环信操作业务；         

实现步骤：

一、环信业务迁移

         1、开发 HttpClient 接口，便于推送 项目访问 主项目中的数据

                   1>.获取环信 token 数据、重置环信 token 数据

                   2>.同步生产者的消息与消费者的状态，便于监控消息的发送状态（开始发送、开始处理、处理完毕）

         2、将环信业务方法迁移一份至 推送项目中，使推送系统中可以处理环信加群、环信退群、群组改名等操作。

                   （主项目中的环信业务方法继续保留，用于主项目的环信预注册功能）

         3、定义环信的统一消息格式（JSON格式）

         4、用 kafka 队列调用方式来替换主项目中原有的环信调用方式

二、生产者改造

         1、自定义生产者分区规则

                   每条环信消息以 schoolId 为 key 进行 hash 分区，使同一所学校的环信操作必定按顺序存储到一个分区内

                   （备注：如果生产者发送时已经造成的顺序错乱，概率较小，而且对环信业务影响不大。暂时不予考虑）

三、消费者改造

         1、手动控制 offset 提交时机，避免多次重复消费消息