内容介绍：
一、云消息队列RabbitMQ的产品优势
二、架构实现原理
三、高弹性低成本的Serveless系列
四、Serveless系列适用场景
五、疑问解答
本次课程主题是高弹性、低成本的云消息队列RabbitMQ 版。由阿里云消息队列产品专家杨文婷分享。
本次课程从4个方面展开，第一个是RabbitMQ云消息队列有什么样的一些优势。第二个是针对优势描述它的架构实现原理，第三个是在架构实现原理基础上，用架构实现Serveless系列能带来什么样的好处。第四个是Serveless系列适用场景分别是什么样。
一、云消息队列RabbitMQ的产品优势
云消息队列RabbitMQ不是开源的托管版本，它是基于自研的高可用分布式存储架构实现的AMQP 0-9-1协议给客户使用的一款消息队列产品。
1. 云消息队列产品的三大优势
（1）兼容开源的客户端
兼容开源的客户端因支持AMQP 0-9-1协议，所以开源的所有语言、所有版本的客户端都支持。不需要修改任何代码，只需要修改服务接入点即可使用。
（2）解决开源稳定性痛点
在兼容的前提下，在架构上解决了开源很多稳定性的痛点，例如开源消息堆积能力，导致服务宕机不可用。集群的容量受机器规格的上限，如果要支持多可用区的高可用，很容易出现脑裂的问题。开源的一些运维，因为基于A类语言，没办法去解决。这些问题在云消息队列RabbitMQ都是由架构从根上解决开源稳定性的痛点。且云消息队列RabbitMQ是非常稳定可靠的。
（3）高弹性，低成本
在基于架构基础上还会给用户带来非常高的弹性能力，因为是分布式架构，所以它的弹性能力非常高。而且是按量付费，所以用户可以低成本使用。弹性能力是秒级弹性，支持5万Qps的弹性能力。
2.商业增强能力
作为商业化产品，为用户提供了非常强大的可观测能力。来提效用户排查线上的业务问题，例如在Metrics方面，给用户提供非常完善的Metrics指标，这些指标不仅种类多，而且label的粒度非常细，可以精确到Exchange和Queue粒度，提供了非常直观的大盘。在两个截图里可以一眼看到实例资源里面所有的Exchange和Queue的各个指标的排序情况，并且一些问题的资源的趋势变化，对比开源非常有优势的是消息轨迹的查询能力。在图里可以看到非常详细的生产者信息，路由入队的信息。包括消息投递的信息和消息的ACK的完整的信息。根据这个消息可以快速的定位，原因是什么？问题出现在哪一环节上。
二、架构实现原理
实现高弹性的无序扩容的优势需要什么架构去实现。有两个重点，一个是分布式的架构，还有一个是基于强大的弹性调度系统，分布式架构比较经典的是计算层，首先计算层和存储层是存储分离的，计算层主要负责AMQP 0-9-1协议的适配，商业化的一些权限，负载均衡等一些计算层的逻辑。存储层主要存储队列上的Queue的消息，队列Queue的删除，ACK提交、存入等一些能力。计算层和存储层都可以分别扩容，并且部署在多个可用区，图中画两个可用区，其实部署在不同的可用区里面。
当一个可用区，整个机房出现网络或者电力上的一些问题，Rabbit客户端可以无缝重连到另外一个可用区，并让消息平滑切过去。在这个基础上，它可以快速的扩容，因为它是分布式架构，它的存储的节点都可以通过横向扩容的方式拉起节点，让容量通过扩容的方式去扩容。
服务的高可用其实是基于多可用区部署的方式，两个可用区的节点是平等的，没有主从。开源有主节点、副节点这样的方式。在异常的情况下，可以通过前端的负载均衡，快速的将服务切换到另一个可用区。所有的节点都是对等的，所以根本不存在脑裂。在这个情况下，弹性怎么能快速弹起来。基于弹性调度系统，首先会有监控的模块去快速分析整个集群里的流量、服务指标，集群水位，资源池的余量指标，然后通过计算规则，通过ACK的容器服务快速拉起每个集群的pod节点。很快就能扩容机器，包括实例的迁移、流量的迁移、容灾的切换，都是通过调度拉起容器的Pod节点做处理，所以在监控调度下，才能达到系统的快速弹性能力和多用可用区的高可用能力。
底层通过容器下调用阿里整个ECS 的资源池、云盘、OSS、盘古的各种存储资源，还有网络的负载均衡等各种各样的资源，在资源池下面，通过容器的快速的拉起和计算以及集群的水位计算，来快速调起弹性。
三、高弹性低成本的Serveless系列
高弹性、低成本的Serveless系列给用户带来两大好处。首先是它的付费模式是按量的付费方式，按照累计收发消息次数收费，用户是低成本，零门槛的付费方式，开通实例不需要钱，真正去消息收发，去创建Queue的资源时才收费，不像其他云厂商开始就要预估最高峰值是多少。根据最高峰去部署最大规格的集群，大部分时候都是浪费的，可以按照实际的业务流量去收取收费，解决成本问题，资源池非常庞大的，所以突发流量，大流量，不需要担心集群水位不够，也不需去担心将来最大的流量要多少。无需容量评估的一个解决运维成本的问题。
四、Serveless系列适用场景
Serveless系列试用的场景非常多，首先它是开箱即用，只要点击购买就可以创建好实例，创建好实例后，在普通的流量场景下，可以节约成本。因为不需要根据峰值预部署流量，可以按照实际流量去付费，大部分闲置的资源不需要付费。还有极端的情况下，例如开发测试环境，开发测试环境消息量非常少，很多开发测试环境用Serveless只需要付可能不到十块钱，非常便宜就能将开发测试环境给用下，在开发测试环境上，可能做一个项目，就要拉出一个环境，做一个业务线就要拉出一个环境。
在这个情况下，可以大量的节约机器资源。比如峰谷和流量的业务，例如充电桩的业务，或者学校打水的业务，或者ktv娱乐场所，有非常明显的峰值，一天中大部分时间都是不使用的，比如学校打水业务，可能每天晚饭后是高峰期。其它22个小时或者20个小时几乎没有流量，Serveless非常节约成本、非常适合这些业务的使用，还有非预期流量，例如有一个突发的流量，包括自建的或其他按照机器规格购买的实例，很难保障突发流量的稳定性，例如游戏活动，当人数突然多时，流量峰值非常高的，这个时候是非预期的。
包括一些平台的软件，它会让各种三方传一些数据。数据提交时是人随机提交的，这时候突然会有一个非常大的数据提交，要缓慢的分派给下游的消费者，这时也是突然的流量高峰，这时5万的QPS弹性能满足这些突发流量的业务。在这些场景下，节约大量的成本，比如图中场景。可以节约成本50%到80%左右。
五、疑问解答
问题1：针对充电桩业务的顺序消费如何解决？
回答1：RabbitMQ协议里面没有特定的顺序的语义定义，开源能够实现顺序是因为开源是单机架构，它的顺序依赖于所有的消息存在一台机器上，按照先存先消费的情况保证顺序，RabbitMQ是分布式的架构，消息会分布在集群所有的节点上，存储不是顺序的。目前暂时不支持顺序消费。这个功能因为很多开源迁移上游用户需要，目前正在开发中。能保障大致技术的实现是将所有节点的消息拉过来做归并排序，然后投递给消费者。
问题2：和普通的MQ比，RabbitMQ有什么优点？
回答2：开源MQ有稳定性痛点和弹性容量，是单机架构，4核16G，容量上限确定。除非拆集群或者把机器分配，但不是一个平滑的过程。RabbitMQ主要是两大点，一是解决开源稳定性痛点，开源的RabbitMQ是强依赖于内存的实现架构。例如消息堆积会影响内存。指标或Queue原数据多也会影响内存，连接键多也会影响内存，任何影响内存都会导致机器宕机，而且是重启不可恢复的。重启还需要加载数据。这就是开源稳定性的痛点，在开源和其他云体、云厂上都使用开源代码和部署代码。所以痛点没有解决。
无论在开源的官网上，还是其他云厂最佳实践上，都会监控内存的水位，推荐监控的阈值是40%，相当于内存接近40%时，可能有机器宕机的风险。在云上，本身代码都是自研的，使用时堆积不会影响稳定性，而且无论堆积多少消息，都不影响消息的发送请求，rt都是稳定可使用的。
还有是容量问题，单机的集群容量是部署的，例如4核8G或者8核16G，它能支持上限只有这么多，而且是一次性，没办法扩容，要么拆集群或换机器规则。
问题3：用户按照业务的最高峰去部署机器流量超过之后弹性如何？部署最高规格成本很高怎么解决？
回答3：RabbitMQ有高弹性、低成本的两个特点。云厂商会将用户的可观测能力作为非常高的要求来实现。所以Metrics和Tracing的两大能力比开源要强，能够帮助快速的提效排查任务效率的时间。
问题4：RabbitMQ会自动扩容吗？消息堆积怎么处理？速度上传可靠吗？RabbitMQ是RocketMQ改造的吗？
回答4：消息堆积对于本身服务稳定性的影响和对业务处理的影响。消息堆积不会影响本身业务的稳定性，也不影响任何接口的rt的稳定性，不会影响性能。作为业务使用方，消息堆积的最佳时间是先监控告警发现问题，然后再看大盘排查定位。
首先在云监控上配消息堆积的监控告警，收到告警之后打开大盘，然后看堆积相关的指标变化趋势，比如消息量多还是处理耗时变长，消费处理耗时变长。看是哪个指标的变化引起消息堆积。因为它的曲线在Queue 表盘上，可以同时看到好几个指标的展示，可以看哪个指标变化突然跟堆积量一起变化，可能就是因为这个指标变化引起。
继续排查，可以看哪些机器上出现问题，可以抽查消息轨迹看消息的消费，比如投递的成功还是ACK的失败，还是投递下来很久之后才ACK导致消息堆积，这就是整个的最佳实践。
问题5：速度上传可靠吗？QPS秒级五万，但实际过程中可以自定义，照秒级的是否会出现峰值？
回答5：弹性的能力有两大指标，每次能弹多大的容量上去，容量大概要多少时间？相当于弹性的速度和弹性的幅度，QPS秒级五万就是可能在几秒钟之内就能弹到五万的能力。例如热弹和冷弹，热弹时是热备的容量，这个时候对业务更无感。冷弹时能在几秒之内快速弹上去，例如从五万弹到十万。大部分用户很难有高的流量。五万的能力99.99%的用户都能热弹的范围内满足需求。
问题6：RabbitMQ主要是在vbc局域网中使用，还是由云外的用户客户端直接连接？
回答6：接入点都会提供，公网接入点有，vpc的接入点也有。看自己的需求，两个接入点，要哪个就用哪个。
问题7：除了SDK，有提供对外的API吗？，
回答7：首先开源SDK上面的API都能直接调云上，除了开源的RabbitMQ的SDK，还可以对数据SDK上创建Queue，删除Queue的接口支持，开源SDK是无缝使用的，控制台的API是根据阿里云的pop的网关标准，API也会给客户提供。
