阿里云消息服务的相关技术架构

SegmentFault都非常困，所以借这个活动把大家的精神气提起来。就前面那个问题，阿里云其实也会有很多用户收集的需求，而且这个规模量会比这个更大，我们用的程序就是用P写的，P（音）是解释型语言，它的那些解释器效率非常低，但是它有一种新的解释器PNPN，这个解释器效率非常高，然后我们优化完以后，我们性能能够跟C++是一样的，甚至能够比JAVA的效率还要高。下面我开始我的，我今天的题目是阿里云消息服务的技术架构，我在做分享之前想跟大家做一个小小的，有多少人知道阿里云，知道的举手，看来阿里云的做的很好，有多少人知道阿里云的飞天，就是知道的比较少。说明今天我出来讲是非常有必要的，阿里云是09年的博士带着一帮有理想的同学到去做飞天的梦想，包括我们今天的消息服务其实也是在飞天这个平台上演化出来的一个云服务产品。自我介绍一下，我是阿里云飞天事业部服务团队的，我现在在负责这款产品的研发，我在负责另外一块产品。我在11年加入阿里云，从阿里云飞天平台研发测试一直做到现在，其实比较自豪的事情，我们飞天平台现在已经能做到10K的规模，10KHadoop进入，我们其实今天讲了一个叫消息服务，其实广义的消息，大家觉得我们日 。、邮件、IM信息，比如说 其实我们计算机世界也是一样的，而且计算机世界对消息处理的要求更高。到我们上面来，我们争取们变成土豪公司。这是广义的消息，处理这种消息的软件有哪些？传统的消息软件，开源的RabbitMO，然后是Kafka。而且技术门槛蛮高的，你要配一个专门的人去看着不要出问题，然后你机器投入比较多，Kafka刚才前面讲到你在，你在杭州要部署的时候又要一套，然后发展很快到海外去了，统，我们今天想把它封装服务，然后解决传统软件的一些痛点。它有哪些特点我们可以来看一下，第一门槛低，你只要到阿里云点击开通，你甚至不需要知道Kafka24用HTTP的时候，你原来的小概率会出现，可能每两天要挂一次，这个时候你不得不证数据十个9可靠性，基本上不丢。还有服务高可用，我们假设任何物理机或者虚拟得到的可用性是三个9。然后是安全，Docker的安全性怎么样，今天Docker没有给成一个解决方案，们提供一个RAM控制功能，还有多用户。最后还有弹性，今天我们消息服务上的的的消息至少被你的程序成功处理一次。然后是一对多的，一个 群，你里面发的消息所有人都能看到，队列是说你单独沟通，只有跟你聊天的人看到。这边，今天比如说你想做一个消息系统，有发生，然后你想去接各个服务的API，你绑定哪几个，你就可以顺利去发邮件。这在我们的官网上也有，这是阿里云消息服务MNS架构，基本上是四层，最外飞天集群希望我们有两个Server，一个是MetaServer，一个是DataServer。务切片，每个用户的切片都会在不同的服务器上，然后当有物理机fail片可以快速迁移，这样的话任何时候物理机fail都不影响你往里面写数据。据写进来都是写到飞天的分布式系统，里面一个系统，每条消息的数据有replication的能力，自动能力，当我发现我消息对应的三份只有两份的时候它会去补全，从而实现我们数据十个9的可靠性。消息服务商业化到现在我们从来没有们还有防Ddos，我们还有支持RAM，主子帐号，还有临时AK。用我们的产品往角色，运维你给他一个运限的帐号，开发给他一个开发权限的子帐号，这样的话你可以去控制你的队列哪些该给谁。临时AK是解决这个问题，今天我们移动APP非常流行，大家都会移动端往我这边发数据，但是有一个问题，会有AK，AK就是你的用户名、，你在用户的设备上放一些你的帐号其实是很不安全的，临时AK的作用APPAK，然后AK比如说15分钟有效，这样的话你不用担心你今天发出去的APP家，反向从里面找出你企业的AK信息，这是适用于这种场景。另外我们今天所有消息服务都是支持https，你去截人家某些官网可能可以从包里面截到用户名、。第四点，每个用户数据都会打上用户，实现独立命名空间，也就是说用户A根本看不到用户B的存在和他的数据。最后，我们做了一个特别包，我们有有效期，如果你的消息句柄在网上家截获了，也不用担心，因为这个然后是弹性的实现，我们元数据分片具备自动能力，然后数据节点可以水平扩展，前端http服务节点也是可以水平扩展。无论是消息队列的个数，还有的个数，ServerA机器上去调一个服务B，这是一个比较紧的耦合系统，因为当你服务B挂的时候，它会马上影响你服务A。一个公司可能有两个开发在做两个不同的服务，服务A往往会被服务B坑掉。我们可以用这样一个方式来解耦它，就是松耦合系统，我服务A要向服务B请求，我先把数据放在队列里面，然后B再从队列里面处理。这样的一个好处是说当你B挂的时候，其实A还是可以继续工作的。包括你有些运维活动，比如说我的B要升级，这个服务A都是不会被影响的，这是系统解耦。还有一个我们的典型场景叫削峰填谷，正常比如说我用户直接你的服务，尤其是像秒杀这种产品，你会非常痛苦，你为了用户可能几天的大量就得扩一堆服务供http的，经常会出现这种情况，我跟你两个企业之间需要做数据交换，这个时候两家都有，怎么办？可以通过阿里云消息服务做一些中转。下面是异步通知这个产品，正常的时候会发现用户提了任务，这个任务需要一段时间计算，我又不知道你什么时候算完，然后我不停的发送请求。其实12306就是后去处理，处理完了以后你再通过另外一个我们的这个方式通知用户说处理人家买不了了，30分钟以后你检查一下这个用户到底有没有把钱付了，没有付钱，我下面给大家两个用户案例，一个是捞月狗，这个公司现在国内最大的第游rabbitmqrabbitmq10所以现在他们是我们一个忠实的客户，基本上他从用了我们以后需要去运维Q这个事第二个案例是FmRadio8公司，他服务的客户里面有比较牛B的，比如说人民12我们以后他在大概两个多，就把这套系统搭完了，而且在春节千万级用户的活动发次，应该有这种解决方案。消费的时候，你怎么办？有可能两个人都在消费，你一条消息挂了，完了以后它再发的时候发到B上面去了，然后你那边还没有处理完。我们生产者往服务里面发消息，队列里面，然后假设A拿到了这条消息，今天A拿NNBAB你A挂的时候过一段时间我B还可以消费。还有一个问题，那是因为我程序挂了，还有一种情况，今天个任务处理的时长30fail，它还在努能被消费者B去处理。这里面我们提供另外一个接口，今天我30秒超时，我在25秒能保证消费者A虽然这个任务超时，它还是能处理完。这是从我们消息处理上的两种另外还有一个问题，刚刚好象也有人提到了，日志处理顺序的问题，日志处理Spark是今天一个最佳实践的方案，然后我们的方案也有下面的，大家可以去看。接收64K的消息，为什么不做更大的，我们每个系统都有时间空间，系统也是一样，当你系统如果要追求QPS的时候，你可能会牺牲你的Throughput，当你追求Throughput的时候可能会牺牲QPS，比如说我的QPS很高，但是我可能Throughput很低。Throughput就是吞吐量，其实受限于网络，QPS受限于你的处理能力。今天极度优化了我的QPS，我强调的是秒钟处理消息的数量，不是说秒钟的网络吞钟只能处理十。所以我们今天消息服务限制了64K，这是不是意味着我要发大数据就实的消息变成了M和D，的消息M放到消息队列里面需，然后的D放到OSSMNS以后再从OSS上去拿消息和数据，这样就完成了大数据的传输，而且这个基本上是无最后提到OSS，我今天把阿里云服务的产品体系做服务这么一个产品系列，它里面不光是说消息服务，它最大一块是对象，就是我们OSS，另外还有块，还有日志服务，刚才月Spark，其实阿也提供类似的功行了。还有你的数据，刚刚提到那些音数据放在上面时间久了，你后面可能不需用买。还有一个就是表格，以前叫OTS，这个性能上更好。这基本上就是阿的服务产品的系列，然后大家如果之前讲说写代码什么的，你可以先想想这个产品是不是可以先用起来，我们是按量，你不用是不的。 ，大家有可以扫描看一看：谢谢老师，现在阿扩招，大家有的话可以找他提问：你好，但是这么火，秒杀、团购、特卖的，流量压力比较大，你：你的问题我基本上听明白了，这也是阿，现在双十一大部分在大量阿然，都会分开的，可能前面插一个，量控制住，还让你输入 库，还是我们传统的MQ那种，它是一个分布式的数据库，然后里面可以查你这个下单有没有下，没下我就秒杀，经常会发现我秒的时候，过一会儿又回来了，有时还有你数据也会出现这个问题，当你系统规模很大以后，任何小概率都会发生，不是完成，然后它事后有有一次检查，当我再拿到一条过去的不一致的消息的时我碰到过，余额宝转帐的时候，我从一个比较偏僻的地方，又从感觉IT不是很强的了。它有日志在那边，数据库状态在那边，会帮你补回来，去看看，如果你发生这种状态，等待24小时后会回来的，或者你打。提问：老师你好，请问一下你之前说的削峰填谷来解决大数据高并发的时候能一种是要改变我服务器状态，还有一种是读，你的缓存只能对读有用，比如说我，我有很多同时来，读你的缓存是有用的，但是如果你大量请求，比如我来改某个：你还有一种情况，缓存写到中间状态，做一致性的处理。程，但是你用队列先把任务放进去，然后后面做操作。这样的话你前面进来的速提问：问一下，如果我们作为一个发送者是没有问题的，但是作为一个消费者该怎么办，因为我们服务有一个静态服务器地址，但是APP没有办法实现？：阿有另外一个服务叫移动推送，就是我们会跟它对接，今天我去读你的服务地址是可以的，但是我服务去你的，你没有给我回，没有关系，今天我们有一个移动推送服务，这个移动推送服务类似于第，你甚至于不用第三方，你可以用、Android这种网关去做你这个推送的事情，本质上那是一个移一个你移动推送的帐号和群，就是APP那个模板，然后我们这边一条消息过来，可以提问：之前我做过淘宝卖家工具，用的是阿的接口，其中有做服务推送的，开发商订阅一些信息、支付信息，这些信息应该一直是传输到你那种成功处理之后才会删掉，对吧？我的场景是这样，我们第应用上去之后，他就要拿到他近：我们这个产品是类似免费的，就是一点钱没有收，我们后面可能会。订阅以后我有一个可以是一对多推消息，本来只有两个人订阅，突