Mafka消息中间件系统SLA

1.背景

• 给业务承诺的SLA无法提供准确(实际)运行数据和证明，更无法打消业务对MQ服务质量的疑虑，长远看对于MQ发展不利
• MQ团队无法确定当前系统SLA数据，就无法确定服务重点优化方向
• 确定系统SLA，明确系统边界

2.目标

从系统角度查看整体系统的可用性，包括但不局限于各种异常处理，是否做到很好的容错。主要输出包括：

1.主题SLA

2.消费组SLA

3.集群SLA

4.MQ 整体SLA

3. 系统SLA

3.1可用性

3.1.1主题SLA

承诺

• 副本配置：//TODO，需要进一步梳理，申请主题的时候，如果选择的数据类型是：支付类型或者订单类型。我们给业务配置是三副本策略，意思：如果发送收到ack（不管是同步发送还是异步发送），那么消息肯定已经被三台机器都接收到了。
• 主题粒度的数据有效性配置：默认情况下，数据在服务器端保留24小时。特殊业务可以进行有效期单独设置，粒度是主题粒度。并且在mafka 2中支持消息可回溯，只要在数据有效期内，都可以重新设置offset，重新消费。
• 主题粒度的partition配置：默认情况下，主题的partition个数是6个，业务可以根据自己的实际QPS进行相应的增加，从而扩大自己的吞吐。partition扩容粒度是：主题。扩容partition的同时不会影响正常生产消费。
• 主题粒度下的生产速率以及生产客户端个数可以按照分钟维度进行监控报警。
• 主题粒度的消息内容可以在数据有效期内查看。
• 主题粒度按照多机房部署。
• 发送的性能以及延迟保证：见blog链接：
• 发送可用性：99.99%（计算的方式为：业务调用发送接口，按照成功收到的消息数/总的消息数）

指标监控报警

• 主题粒度的发送速率和发送客户端个数，可以从MQ管理平台查看监控以及设置报警，MQ管理平台使用手册(此处为链接)
• 发送的可用性，可以从MQ管理平台进行监控报警。
• 发送的延迟，可以从MQ管理平台进行监控报警。
• 进行日报，周报，月报，季度报的形式通过大象，邮件等可供业务进行订阅，并且异常数据进行特殊颜色显示（比如小于99.99%的可用性，进行标红）。//TODO：数据由MQ管理处理和展示。

消费组SLA

承诺

• 端对端的延迟（也就是生产到消费的延迟）：见blog链接：
• 消费组粒度的时间回溯/前进，消息延迟，并行消费等特性。
• 消费组粒度的积压，各个partition维度的积压，以及消费速率的监控以及报警。
• 消费可用性：99.99%（计算的方式：（总时间 - 消费组积压并且此时没有客户端消费）/总的时间）

• 业务需要进行消息去重，因为采用了至少消费一次的策略，防止数据丢失，因为网络超时等错误，所以可能导致重复消费。

  指标监控报警

• 消费组粒度的消费速率，消息积压，各个partition积压，消费者个数，以及每个partition消费现状，可以通过MQ管理平台进行监控报警，使用wiki是：MQ管理平台使用手册#消费组观察
• 消费组粒度的可用性，可以从MQ管理平台进行监控报警。需要开发完善。
• 消费组粒度的业务侧处理消息延迟，可以从MQ管理平台进行监控报警。
• 消费组粒度的端对端延迟（从生产消息到消费到消息的延迟），可以从MQ管理平台进行监控报警。，目前是有了初步方案，进一步的方案还需要明确。
• 进行日报，周报，月报，季度报的形式通过大象，邮件等方式可供业务进行订阅，并且异常数据进行特殊颜色显示（比如小于99.99%的可用性，进行标红）。：需要MQ管理平台将此功能结合到业务治理中。

集群SLA

承诺

• 集群可用性：99.99%(计算方式：（总时间 - 机器down机的时间）/总时间）
• 集群粒度的积压极限：见wiki：
• 确保集群内不能有2或以上个云主机(Broker)部署在同一台物理机上
• 确保集群内节点分布在多个机架上

指标监控报警

• falcon可以针对服务监听端口进行监控报警，利用此监控信息，算出机器 down机的时间，然后更新出集群的可用性。

MQ整体SLA

承诺

• 总体可用性：99.99%（计算方式：所有有效运行的主题和消费组的可用性平均值）

指标监控报警

• 将所有有效运行的主题和消费组的可用性进行平均值计算，然后反应出总体的可用性指标，并且进行监控。此项不报警。

故障隔离

在Mafka 2的整体架构中，已经从物理上做到了故障完全隔离。线上按照BU/BG（也就是业务部门）进行分别部署机器。
各个业务部门之间不会进行相互影响。

容量预估

• 线上服务器的配置是一致的，具体配置见wiki： 可以参考Broker的server.properties推荐配置
• 集群的容量进行性能指标测试，比如能容纳的主题个数，partition个数等。见wiki：
• 业务接入，按照冗余一倍原则来做规划处理。
• 关键数据进行监控报警，比如80%通知报警给系统管理员。：能容纳的主题个数和partition个数通过MQ管理平台进行监控报警。
• 定期进行线上容量关键数据的review。

过载保护

阈值控制

• 控制客户端连接个数：提前预估好broker集群的处理能力，限定最大同时能够处理的连接个数等，当连接数大于最大值80%进行告警。如果超过范围，则拒绝新的连接请求。控制范围为：客户端连接数量
• 客户端读写请求速率限制：提前预估单个Broker最大读写请求处理能力，限定单个Broker最大读写请求速率，当请求速率大于最大值80%进行告警，如果超过阀值拒绝客户端读请求，优先保证写可用 此策略按BG生效
• 复制限流：replica复制流量最大只为网卡30%，当replica复制流量最大值80%进行告警，同时自动触发Broker降流量。 Broker-0.9.x+，升级支持流量限制

服务降级

分钟级别响应时间

• 通过MQ管理平台，支持手工降级，支持降级粒度为：消费组、主题。具体为：主题迁移，主题暂停生产，消费组暂停消费。
• 当发生故障，集群负载短时间内急剧增高，根据业务申请主题的数据类型，优先降级日志类型，以保证支付类型和订单类型的数据高可用。
• 主题粒度的降级：1：主题粒度的迁移集群，将主题迁移到负载不高的集群上。迁移策略是：先迁移Producer，等Consumer消费完原有数据，再迁移consumer。2：主题粒度的生产暂停。具体是指通过MQ管理操作实现暂停生产，待集群负荷恢复正常状态后，通过MQ管理平台恢复生产
• 消费组粒度的降级：1：消费组粒度的暂停消费。具体是指通过MQ管理操作实现暂停消费，待集群负荷恢复正常状态后，通过MQ管理平台恢复消费
• 降级策略分级,针对降低策略进行分级，优先级设置依次为：主题粒度集群间迁移，消费组粒度暂停消费，主题粒度暂停生产。

服务扩容

• 当集群关键指标（比如cpu，内存等）达到阈值的80%进行报警，并且同时着手进行扩容，保证服务扩容过程中业务是无感知的。见扩容SOP：需要出库容SOP