你的分布式应用真的须要那么多同步调用么？

时间 2019-11-10

原文原文链接

摘要： 在5月17日举办的2016云栖大会·武汉峰会上阿里中间件产品专家马雷（阿仁）就阿里中间件MQ作了精彩的演讲，告诉你们：阿里中间件团队的目标是让消息“传”无边界。本文也就为何使用消息中间件，消息中间件的核心场景进行了分享。相信阿仁的分享会让你们对分布式应用的异步调用有更加深入的了解。精彩不要错过！git

对整个分布式应用系统而言，一共分为两种调用，一种是同步调用，一种是异步调用。同步调用就是基于RPC，基于链路监控等等的一套东西，而今天分享的主题是则基于异步调用的。

你们仔细思考一下，咱们所作的整个分布式系统中有多少链路是同步调用的，又有多少链路又应该是异步调用的呢？好比在一个下单流程中，有多少核心链路是使用同步调用的，有多少须要异步调用？

消息中间件的使命是让消息传递无边界,传递无边界有两个概念，第一个就是你能够把包括应用之间的通讯等各类字节流这样的消息传到各个端，包括手机端，物联网，智能电灯，汽车以及云上应用服务等。第二个就是消息能够传递任何东西，从最小的几个字节到最大的几百兆的文件。github

1、为何使用消息中间件

1.云是地基

先问一个问题：为何要使用消息中间件？如今开发分布式应用系统，不多有人从头开始写代码，由于如今已经不是一我的憋在酒店里写一个软件就能够成功的年代了，如今每每须要团队做战，并且还有可能从更大的角度来说，是一个生态在做战，而且你所在的生态有可能和其余的生态存在竞争的关系。那什么是中间件呢？

用现实生活类比来说，如今房价卖的很高，之前卖房子该怎么去卖？开发商须要先买块地基，而后在地基上搭建个框架，最终将其装修完了之后卖给客户。如今卖房子怎么卖呢？能够直接用现成的框架，不管最终客户想要装修成写字间也好，别墅也好，公寓也好，均可以快速地卖给客户，快速实现资金回笼。因此这里有一个理念是：云实际上就是一个地基，用户不须要去搞本身的IDC。数据库

二、中间件是框架

而中间件至关于框架，有了云的地基，有了中间件的框架，就能够在上面快速地搭建业务，实现将业务的快速变现，这才是业务的基石。中间件是应用快速落地的加速器，它可让团队拥有快速试错的技术能力。apache

2、消息场景核心问题-解耦

在整个的分布式应用中，须要将应用拆分红不少个WAR包，那么有多少链路须要同步调用，多少能使用异步调用？以经验来讲约70%~80%的链路均可以使用异步调用。阿里消息中间件的延迟是在1ms~5ms之间的这样的一个粒度，实际上相似于准实时的概念，甚至在秒杀的某类场景当中减库存也能够是异步的，通知以及实时监控这些链路所有均可以异步实现。设想若是所有都使用同步调用进行设计，如今淘宝的一个下单流程须要几百个调用，若是全是同步的话，实现这样的下单须要大概几十s量级的时间，那么淘宝为何能作到下单以后当即就能成交，实际上是由于其后面所有链路都使用的是异步调用，而且只有在核心链路中某些最核心的交易环节中的几个环节才会使用同步调用。

在这里分享一个可能给你们一些启示的泰国电影，这个电影一共有三个主人公，父亲，女儿和女儿的男友，当时女儿不顾家族和父亲的反对必定要和男友交往，父亲实在是拗不过女儿就赞成了，可是这个父亲却采起了一个很是残酷的措施，把女儿和她的男友用手铐拴在一块儿，因而天天不管吃饭仍是睡觉，天天任何行动女儿和男友都在一块儿。最后的结果相信你们都猜到了，开始很是快乐，最后女孩的男友疯了，在疯以前将女孩杀死了，而父亲也由于这个事情今后一蹶不振。这是一个真正的悲剧，人生是这样，若是两个事物太过于耦合在一块儿的话就将是个悲剧。

设计程序架构也相似，若是你将全部程序都紧耦合的设计在一块儿，对于这样高度耦合的架构，相信在不久的将来随着业务的发展，你所设计的系统也会成为一个悲剧。真正的场景是在分布式应用中，好比说应用中A和B两个功能模块，既但愿他们解耦开，可是又但愿他们互联达到目标状态。咱们不但愿B不可用时候，A也不可用，这是目标。那么为了这个目标能采起什么策略呢？编程

第一步，须要增长不少A和B的实例，可是这样带来的问题是链路也会增长，调用也会增长。由于A的配置或者B的配置要更改，那么第二步就须要在A和B中间加一个负载均衡器，这是最传统的作法，你增长多少，我就增长多少，你们互不关心对方的配置。缓存

第三点，当有一天作大促销的时候，或者当你的客户大量增多的时候，大量的流量到来，A的流量须要直接传导到B。因此阿里在整个消息领域引出了一个很是重要的概念，叫作Topic或者Queue（队列）。Topic其实也是基于队列的，这个东西的做用是：第一负载均衡，第二点它能够充当一个大的缓冲，这样能够把全部的流量缓存到Topic里面。安全

举个例子说明Topic的概念：这张图有三部分，生产者，Topic和消费者。生产者生产的消息放到对应的Topic里面，谁取了这个消息或者谁订阅了这个消息就把消息拿走。实际上Topic的概念就像是变压器，变压器是220V的出来的也是这个流量，接入其余的也是这个流量。这给最终设计系统带来一个好处就是首先对于后面的这些应用而言，它们不会由于前面像洪水同样的流量而被压垮。第二个更为重要的就是在设计整个系统的时候就不会有更多的成本浪费在这些旁枝末节的服务上。

再举个例子，作秒杀业务时下单应用很是重要，对这个应用扩展了100台机器，下面的通知好比发邮件的应用，需不须要也扩展100台机器呢？实际上是不须要的，虽然仍是须要发邮件，可是能够保证邮件以平稳的流量发送，只须要扩展5台或者10台来知足基本需求就能够。这是两个最大的好处，中间的这个Topic，也就是消息中间件就像一个万能的变压器同样，即使大洪流来了通过它也变成比较顺畅的流量。

接下来举几个现实中的例子探讨一下到底哪些链路须要异步。

流程推动：就是作工做流或者审批流，再有就是订单的流转，下订单，减库存，使用优惠券结算，最终通知用户或者订单超时等等。这是第一点，流程推动是以前用的最多的。

定时消息：消息中间件MQ支持一个定时或者延时的消息，在电商里面主要有两种应用场景，一个是客户下单30分钟以后，订单可能会断定为超时，因此在客户下单以后须要异步发一条消息；而且在30分钟以后，若是订单尚未支付，就被断定为超时并将其关掉。另一个就是支付提醒，用户下单以后10分钟尚未支付，那么会对其发送一个支付的提醒。这样带来的最大好处就是也能够本身写轮询条件或定时程序，首先对订单或这张表或者其余的多个表进行轮询，可是这些东西其实不须要去作，只须要发一个定时的消息就能够了，触发条件就会发送那个消息。

日志监控：若是系统足够大而且对实时性要求比较高，日志所有要异步地放到实时计算的引擎里面。

社交互动：如今Facebook用MQTT协议作社交，对于其余相似微信的社交以及如今比较火的视频直播聊天室，点赞送花买礼物等这种对于消息来讲的巨大挑战：首先要求实时性，好比在聊天室直播的过程当中送花的等待时间不能过长；其次是并发，芒果TV在超女100强比赛的时候也是用了视频直播，包括熊猫TV在选熊猫女郎的时候也是，当聊天室里忽然冲进去几百万人的时候，订阅的关系就变得很是复杂，就是说我和你是好友，我发的东西，你应该能看见，可是我跟她不是好友，没有订阅关系，我又和某一个兴趣组有订阅关系，这样就造成了多级的订阅关系，这时候再发消息谁可见谁不可见就取决于订阅关系是什么样的。若是我发的消息以后，一百万人要同时都能接受到这个消息，这是对消息领域一个很是大的挑战。微信

3、什么是阿里云MQ

阿里云是如何解决这个问题的MQ这个产品已经有7年的历史，而且MQ是通过双十一几千亿条消息流量检验的。第二个就是这个产品在开源社区进行了部分的开源，由于第二阶段须要扩展影响力，因此就将产品一部分进行开源，而开源版本的MQ也有不少电商在用。这就是MQ产品的历史。

从商用的结果来看，阿里的消息队列MQ应该是全球性价比最高的，由于它的计费很简单，就只有API和Topic调用这两块费用。客户建一个Topic就有一个资源占用费，并且计费是阶梯的，其余的消息产品包括亚马逊，微软以，因为收的消息有多种形成很难计算费用，好比要经过调用次数收费，网络流量也须要收费，出口的费用，存储的费用甚至积压的费用都会收取，而阿里云的MQ只收取API的调用费用和Topic的资源占用费用，因此很清楚。

下图是MQ的入口，整个产品都是在这个叫作阿里云互联网中间件里面。互联网中间件包括了企业级分布式应用服务EDAS，消息队列MQ和分布式关系型数据库服务DRDS。咱们的团队是服务于整个阿里巴巴集团的，阿里系中大多数应用都在用咱们的中间件。网络

再一张图是主要控制台界面，在这里能够进行Topic管理，发布管理以及订阅管理。查询方面能够进行Topic查询，Message Key查询和按照Message ID查询，而且还有后面的报表，从这里能得到好比10分钟内TPS是多少，生产了多少消息，失败了多少这样的数据。还有监控报警，整个消息领域内有两个数据最为关键，一个是RT的时间，也就是发送消息的延迟，咱们能将其控制在1ms~5ms，这个数据是很是准实时的；第二个是堆积，当大流量到来时会堆积不少消息，堆积对不少消息是很重要的，有的消息中间件堆积了一亿条消息，再将其从新拉取的时候将会使性能降低很是多。若是订单的业务堆积了1000条就须要报警了，须要看看应用是否是已经报错了，因此监控是一个很是重要的功能。多线程

阿里云消息中间件的特色：

双11验证：MQ是通过了双十一验证的，MQ不是阿里看到了将来云计算领域消息是很重要的部分而去开发的，这个彻底是阿里的业务需求加上七八年的技术沉淀下来的结果。
体系完善：阿里云MQ的体系比较完善，首先咱们在内部产品名叫作MetaQ和Notify，同时有一部分是开源的，叫作RocketMQ，企业今天能够去IOE，将来真的强大到能够专门研究中间件，能够转移到开源的产品上去，这里没有技术绑定的风险。
高可靠和高性能：MQ对消息是多份存储的，可靠性很是高。而且是高性能的，对于单机TPS，在此领域不少人说Kafka性能很高，可是实际上阿里云MQ比Kafka的性能还要高，如今单机性能已经达到10万TPS以上，也就是一秒钟发十万条以上信息，而且这仅是对于单机不是集群。
多协议：MQ还支持多协议，不只支持TCP还支持HTTP以及MQTT，另外MQ还能够像之前的传统软件同样独立部署，若是想不在云上使用，而在本身的IDC环境中使用MQ也可行。

TCP VS HTTP VS MQTT：专业 VS 简单 VS 物联

在整个消息领域里面，大概有这三个协议，对于支持TCP协议的消息，TCP的协议定义长链接是最稳定的，玩法也是最多的。在TCP上能够作到“推拉结合”的方式，在消息里面也有两种基本传递的方式，一种是“拉”一种是“推”，淘宝以前使用“推”的方式，这样比较快，可是你们后来发现这种方式就像是喂金鱼，若是下游消费能力很差很容易被撑宕机，因此后来改成了“拉”的方式，而且将其作成相似“推”的方式，这时候“拉”的方式已经和“推”的方式效率上差很少了。“拉”的方式最大优势就是下游消费端能够按照本身消费能力控制消费进度，即便下游处理能力没有那么强，消息依然会循序渐进处理，可是毫不会崩溃。“推”的方式则是所有推给下游，很容易形成崩溃。

在物联网和移动端就彻底不同了，由于终端不一样，它的消息很小，因此采用真正“推”的方式，其次这样的消息不会存很长时间，不少消息会被丢弃，不少场景应用“推”的方式。

HTTP相比TCP要慢不少，可是HTTP有好处，不少小众语言包括GOLang，Python和PHP等都支持，你们对HTTP的接受程度很高，因此也会提供HTTP接入。

另外在整个消息领域有不少商业的也有不少开源的，有不少成熟的也有不少不成熟的，甚至几我的用数月时间也能写出一个消息中间件，可是这个就像学日语同样，入门很简单可是要想真正把消息中间件作到透没那么简单，须要研究CPU,磁盘等等很深的东西。

MQ VS Kafka VS ActiveMQ

对比一下，MQ与以前提到的 Kafka，Kafka 基于日志的场景，可是若是须要传输订单的消息，好比金融报文，甚至对汽车遥控的消息，如要使用 Kafka 有效性就会低一些。另一个就是ActiveMQ，若是用ActiveMQ就会很简单，但流量出现洪峰的时候，性能就会降低很是多。另外MQ在支持事务方面是其余消息中间件所不具有的。MQ提供事务消息，应用与应用之间有服务的分布式事务，数据库之间也有多个分布式事务，好比同时查50个库，这种叫分布式数据库的事务。在消息领域也有分布式消息，也叫做事务消息。就是在作本地事务和提交消息之间，把这两阶段联动成一个事务，以前若是本身写的话，须要判断它的提交状态，全部事物的回滚都须要本身作。MQ使用事务消息能保证操做的原子性，要么全成功，要么全失败。

Kafka存储局限性：连接

MQ和Kafka 18项差别对比：连接

另外在阿里云上面有两个消息服务，MQ消息队列和MNS消息服务，MQ是阿里云专业的消息中间件，是阿里双11使用的消息中间件，支持TCP、HTTP、MQTT三种协议。产品首页：连接

应用场景解析：物联网通用消息协议MQTT

消息队列Message Queue可应用在多个领域，包括异步通讯解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通讯、移动应用、手游、视频、物联网、车联网等。

而基于物联网的应用是自然的基于消息的分布式应用。消息是构建物联网应用的基础，每一个传感器将成为系统中的节点，节点之间依靠消息异步通讯。

物联网消息解决方案=MQ+MQTT

物联网消息解决方案的大体过程是这样的，物联网消息从终端上传到云上来，首先通过云盾安全监测和SLB负载均衡，再到MQTT的网关进而进入核心服务，最终短信以及E-mail网关将这些数据发出去。

其中最重要的一点就是链路监控的功能。MQ消息中间件使用了鹰眼监控，能够监控消息从哪一台机器发出来，其RT时间为多少秒，发到哪一个Topic，以后被那个订阅组消费了，以后订阅组下面有挂载了多少台机器，哪一台机器接入成功了，哪一台接入失败了，实现真正地监控消息轨迹，而不是让用户去查看日志。

最后想说一点关于创业方面的，创业公司最重要的是试错的能力和商业模式的验证，使用中间件，使用异步解耦的消息可让创业团队，拥有快速试错、快速创新的技术能力，可让技术团队专一业务应用开发，从而实现整个团队的业务快速发展。

文章做者：马雷（花名：阿仁）

编辑：贾子甲 (漫步~云端) 、 Sheeta

用云栖社区APP，舒服~

【云栖快讯】红轴机械键盘、无线鼠标等753个大奖，先到先得，云栖社区首届博主招募大赛9月21日-11月20日限时开启，为你再添一个高端技术交流场所详情请点击

评论文章 (2) (5) (5)

分享到:

网友评论

戈风2016-05-27 14:17:10

有个问题：异步化以后怎么确保操做成功？若是失败了如何处理？
例如我有一条指令消息（给用户发邮件）推送到MQ中，结果不知道为啥消息不见了仍是消费失败了之类的，没有成功给用户发到邮件，这类问题通常怎么处理？

0 1

rayray2016-05-30 11:02:12

@戈风消息处处流转，并且可能一份变多份，排查起来的确不方便，因此MQ有相似消息轨迹功能。一条消息能够从发送到TOPIC到订阅组到最终消费机器的整个链路进行查看。里面描述具体发邮件的CASE，若是消息已经发到邮件应用程序中，那么须要再具体排查邮件处理程序。

lxepoo2016-07-01 11:02:30

要拆分为异步，最大的阻碍，要有一堆持久进程来实时消费各类消息。这对不少小公司来讲，是一个最大的问题。可能MQ不是为小公司准备的，大公司也存在本身的问题，使用MQ须要重构整个业务架构。因此，还须要时间。