消息中心实践与规划
https://mp.weixin.qq.com/s/_4tMPUkGDuQyQ2kRkE4n8w
网易严选消息中心实践与规划
从业务层面上，目前消息中心提供了即时消息，定时消息，发布订阅等应用方式；业务可以通过研发工作台提接入申请;
由于目前系统为分立系统，业务方需要根据自己的需求申请接入对应的系统，工单被审批完成后即可使用; 管理面和控制面的粒度都较粗，所以接下来的重点改造在于聚合系统，对外暴露统一的接入接口，将各个分系统作为一个统一的平台对外;
业务层面各个服务的实现
1. 即时推送异步请求服务logistics-uas实现
说明：logistics-uas系统作为统一异步请求服务，是严选的消息统一分发中心，提供了邮件、短信、app push等等消息推送能力，提供对具体消息网关的削峰限流能力；
2. 异构预约服务yanxuan-mhs实现
说明：yanxuan-mhs底层采用MongoDB作为存储组件，用来暂存预约推送的消息；系统主要有两个流程, 第一个流程，业务方将消息推送到yanxuan-mhs, 并设定推送时间, yanxuan-mhs将消息持久化到数据库，并根据推送时间向logistics-dsc分布式调度服务注册任务，等待推送时间到达；logistics-dsc回调yanxuan-mhs，yanxuan-mhs取出数据库存储的消息后使用logistics-uas即时推送服务将消息推送出去；
3. 预约后台定时调度logistics-dsc实现
说明：系统采用ZooKeeper、MySQL作为存储组件; 同时ZooKeeper还担当分布式协调器、分布式锁的角色; 定时调度框架采用了QuartZ框架;
-
系统启动：每台调度的服务器均向ZooKeeper注册自身(通过创建临时节点); 然后每台服务器, 注册一系列监听器用于监听ZooKeeper各个节点的变化; 最后每台服务器将ZooKeeper中已经存储的任务加载到QuartZ框架中，启动调度;
-
提交定时任务：系统接收到定时任务的请求后，会把任务数据写入ZooKeeper的任务节点中, 同时将任务数据写入MySQL做备份保存; 所有机器通过监听任务节点, 感知到新增任务后，将任务数据加载到本地的QuartZ框架中, 启动任务调度;
-
任务执行：当定时时间到达, 所有机器触发任务; 若任务设置为每台机器都执行, 则所有机器都会执行任务，回调远程接口; 若任务是单机执行(绝大多数任务都是这种模式), 各个机器开始抢占分布式锁调用回调接口, 任务一旦被一台机器执行成功, 则其他机器不再执行任务; 由此实现了分布式调度的可靠性;
-
系统任务分配：当前的任务类型均设置为主备模式(一主两备), 同一个任务，由主服务器优先执行，执行失败由备用服务器重新执行；主备的分配是按照权值分配的，假设100个任务, 即每台服务器会成为33个任务的主服务器，依次实现负载均衡; 当有机器不可用(服务器临时节点有变化), 都会由节点重新触发主备节点的重新分配，并且有定时任务设置每3分钟触发一次主备重新分配(防止新增任务，导致分配失衡);
4. 发布订阅服务yanxuan-mps的实现
说明：
-
首先发布消息的服务(发布方)可以通过平台申请topic，审批通过后，系统会在数据库和kafka集群中创建相应的记录，并更新到缓存；发布topic后，发布方便可以通过mps提供的接口向topic发送消息；
-
需要接收消息的服务(订阅方)提供一个接收统一参数的url通过平台订阅topic，审批通过后，系统会在数据库中创建订阅记录，并更新缓存；订阅方一旦订阅完成，mps中监测到缓存更新后，便会为订阅者创建consumer线程;
-
发布方通过mps提供的接口向其申请的topic发送消息; 然后mps会从缓存中根据topic取出kafka中实际的topic名称，将原始消息包装加入发布方信息和逻辑topic信息等元数据写入到kafka中; 消费者poll到消息后, 消费者线程将消息交给push推送器, push推送器根据消息中的逻辑topic信息，在缓存中查询所有订阅者，然后推送给订阅者提供的url, 如果推送失败，则会将原始消息以及失败的订阅者信息重新打包推送到重试队列进行重试;
严选统一消息体系未来规划
-
目前的消息中心的系统粒度还是比较粗, 一方面，分离的系统并不方便业务的接入，也不方便整个系统的维护与管理; 因此, 在接下来的改进计划中，重点的改造在于收拢整个系统的内聚性，通过生产者代理和消费者代理对外暴露统一的接口，
-
另一方面，由于消息中心开发较早，在消息中心使用两年后，严选的CMDB才开始上线，因此消息中心各个服务建立了自己的权限认证和接入方式，并且维护了自己的接入方服务的负责人，以便在接入业务出现问题时对接入业务负责人进行通知和报警;
- 目前对2020年消息中心的初步规划架构如图所示:
- 消息中心各个分散的系统将统一组成消息服务的核心，业务的接入不再直接接入核心层中的各个子服务，而是通过生产者代理层接入，代理层直接与CMDB打通，同时在生产者代理层提供对业务上游的限流，认证，消息压缩加密，以及编排推送和消息路由的逻辑;
- 消费端同样以CMDB为基础，为各个业务创建隔离的消费者线程，并提供对下游的全局流控，以及跳过消费，重试，暂停与offset重置等功能;
消息中间件的容器化与平台化
1. 现状
- 严选消息中心作为基础平台, 不仅仅通过对中间件的二次封装为业务赋能，也直接维护了严选的消息中间件(RocketMQ)，将最底层的消息中间件直接暴露给业务使用；目前，严选的RocketMQ集群均通过虚拟机或者物理机搭建，在扩展性上较为薄弱；在监控方面，尽管团队开发了统一的监控管理平台供业务方友好的接入，但仍然远远达不到平台化的需求;
- 与此同时，严选在2019年发起了庞大的以杭研轻舟为基础的上云计划，搭上“云”的顺风车，消息中间件的平台化逐步有了落地的可能，基于K8S的动态可升缩能力, 因此可以针对集群资源级别进行动态的调度，直接提供消息中间件的PAAS平台；目前杭研、云音乐和严选已经合作立项，准备于2020年三方共建基于K8S的RocketMQ中间件的PAAS平台，提供整个集团的基础平台；
2. 规划中的RocketMQ on K8S
2.1 基于K8S实现资源级别的管理
- 由于K8S的动态可升缩能力, 因此可以针对集群资源级别进行动态的调度; 云上RocketMQ可以替代传统的手动部署和运维，集群级别资源管理可通过K8S提供以下功能:
- a. 动态创建/删除Name Server集群；
- b. 动态创建/删除Broker集群；
- c. Broker集群高可用状态维护；
- d.Broker集群配置变更(通过停止Broker的写入, 修改配置, 再打开写入的方式实现)
- 构建PAAS平台后, Topic也将作为RocketMQ中的自定义资源提供给用户；Topic的生命周期管理分为:
-
a. 创建topic: 指定所属集群，队列数等
- b. 删除topic
- c. 修改topic: 修改所属集群，队列数等
3. 资源的权限隔离控制
- 在PAAS平台中，RocketMQ集群以及集群中的队列均作为资源被提供给用户使用，对于资源必须要有权限控制，轻舟云上目前具备管理员租户和普通租户两种角色，但缺乏对资源层面的权限支持，即使轻舟平台可以支持资源操作的鉴权，绕过轻舟平台仍存在权限风险，需要使用K8S RBAC的支持，RBAC是可以基于自定义资源做权限控制。
- 在对业务的资源权限控制上，平台需要支持两级权限，即管理员权限和普通租户权限，管理员可以看到平台的全部实例资源，普通用户只能看到自己租户下的实例与相关信息; 管理员可以对实例发起创建、删除和修改，普通租户只能发起创建、删除和修改的申请，由管理员进行具体的审核操作。
4. RocketMQ on K8S规划
总结
严选消息中心作为基础服务一直为严选业务系统提供支持，整个消息体系也一直在持续演进中，朝着平台化和产品化的方向迈进；同时借助“云”的东风，消息体系也在上云的路程上不断前进和努力，让我们共同期待一个更加体系化消息平台。作者简介祖翔, 网易JAVA开发工程师。2018年杭州电子科技大学硕士毕业, 2017年于网易严选实习, 毕业后正式加入网易, 先后参与网易严选企业购商城开发与基础服务平台开发; 目前主要致力于网易严选消息中间件与平台建设以及DevOps平台开发。
严选消息中心作为严选的基础服务一直在不断的演进中，本文将通过图文的方式详细介绍消息中心的实践历程与接下来的体系化和平台化规划，让我们一起来期待下吧！
背景
严选自上线以来，随着用户和业务的不断增长，很多服务从原先的包罗万象全功能的tomcat集群逐渐向分布式服务发展，到现在逐步开始以轻舟为基础的庞大的上云计划，各个服务之间通过消息队列来解除强耦合越来越普遍。
初期，部门内部没有专门的团队维护消息队列服务，所以消息队列使用方式较为混乱，各个业务若需要使用队列，往往需要开发团队自己建立和维护自己服务的消息队列，早期严选的消息队列主要以RabbitMQ为主，有一些团队也会用Kafka，甚至使用Redis的list，同时各个团队需要使用各个消息队列的客户端自行完成消息的生产、消费以及重试等等逻辑，并自行监控消息队列堆积、报警。导致的结果就是资源使用浪费，管理混乱，消息队列难以维护。另外一方面，随着业务的扩展，RabbitMQ已经无法承载严选的业务流量，以RocketMQ为核心的中间件开始逐步替代RabbitMQ，但是仍然难以改变混乱的格局;因此，团队开发维护了一套统一的消息中心服务，统一的消息中心服务一方面通过对已有的消息队列进行二次开发和进一步业务封装，满足了业务方对异步消息的不同应用需求，另一方面以RocketMQ和Kafka为中心，维护了严选统一的消息中间件服务，并提供统一的管理监控服务，以提供给业务方自行使用；在需要使用消息服务时，业务既可以使用进行封装后的消息系统，也可以申请直接接入消息中间件;
