amqp

MQ概述 MQ是Message Queue的简称，意为消息队列，从字面意思上可以理解MQ的是一个存放消息的容器，并且它的 数据结构为队列（FIFO先进先出） 。MQ一般应用于 应用解耦，异步处理提速，流量削峰 ，实现高性能，高可用，可伸缩和最终一致性架构。 在MQ中一般存在三种角色 Broker、生产者、消费者 ，在不同的MQ产品中，也会存在不同的其他角色，这里只简单介绍一下主要的三种角色的作用：Broker也就是MQ服务，用于将生产者发送过来的消息按照类型分类存放在不同的队列中；生产者（自己实现）用于将数据发送到Broker；消费者（自己实现）用于从消息队列中获取数据进行消费。 MQ的优势 1、应用解耦：解耦各个应用，提高系统的扩展性、容错性和可维护性；比如在电商系统中订单系统需要调用库存系统、支付系统、物流系统进行业务操作，假如库存系统宕机，那么整个系统将不可用。使用了MQ之后，订单系统与库存系统的耦合度降低，库存系统挂掉不会影响订单主业务流程。 原始架构 MQ架构 2、异步提速：提高接口响应速度和系统吞吐量，提升用户体验；在分布式架构中，我们经常使用http、rpc等方式进行服务间的接口调用，那么假如订单系统调用库存系统修改库存需要300ms，成功修改库存后再调用支付系统进行支付需要300ms，最后支付完成调用物流系统进行发货需要300ms，再加上订单入库需要50ms

Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS/PaaS/SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年， Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施，是微服务架构应用的核心依赖，也是实践云原生的核心设计理念的关键技术，通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS/PaaS/SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年， Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施，是微服务架构应用的核心依赖，也是实践云原生的核心设计理念的关键技术，通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

简介： 本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》，主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 作者 | 周礼（不铭） 阿里巴巴集团消息中间件架构师 导读 ：本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》，主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS / PaaS / SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年，Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 1. 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取 DevOps 领域的最佳实践来管理研发和运维流程； 通过 CICD

一、介绍 消息队列（Message Queue）是一种应用程序对应用程序的通信方式，应用程序通过读写出入队列的消息来通信。 消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 通俗理解消息队列： 生活中的消息队列，如同邮局的邮箱，如果没有邮箱的话，邮递员必须要"找到"接收邮件的人，递给他这封邮件，才算完成任务，可以想象这个过程是很麻烦、很慢、效率低下的；但是如果有了邮箱，邮件直接放进邮箱中，用户只需要去邮箱中找，看看有没有自己的邮件，有就拿走，没有就下次再来，这样就极大的提升了邮件的收发效率。 官方介绍： RabbitMQ是一个消息代理：它接受和转发消息。您可以将其视为邮局：当您将要发布的邮件放在邮箱中时，您可以确定，邮递员最终会将邮件发送给您的收件人。在这个类比中，RabbitMQ是一个邮箱，邮局和邮递员。 二、在什么情况下会用消息队列? （异步） 2.1 电商订单 比如点外卖，点击下单后的业务逻辑可能包括：检查库存、生成单据、发红包、短信通知等，如果这些业务同步执行，完成下单率会非常低；如发红包，短信通知等不必要的流程，异步执行即可。此时使用MQ，可以在核心流程（扣减库存、生成订单记录）等完成后发送消息到MQ，快速结束本次流程

kafka ：Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。 RabbitMQ:是使用Erlang语言开发的开源消息队列系统，基于AMQP协议实现，主要特征是面向消息 队列 路由（点对点 和发布订阅）可靠性 安全性，对数据一致性 稳定性 高可靠行要求很高，对性能和 高吞吐量的要求次之 RocketMQ阿里的开源中间件，是纯Java开发，具有高吞吐量高可用性适合大规模分布式系统的应用特点，思路起源于kafka单并非完全copy kafka，在我看来是对消息的靠靠性以及事务性做了优化 测试目的 对比Kafka、RabbitMQ、RocketMQ发送小消息(124字节)的性能。这次压测我们只关注服务端的性能指标,所以压测的标准是: 不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时服务端已出现性能瓶颈,可以获得相应的系统最佳吞吐量。 测试场景 在同步发送场景中，三个消息中间件的表现区分明显： Kafka的吞吐量高达17.3w/s，不愧是高吞吐量消息中间件的行业老大