云原生(中间件)热卖产品串讲| 学习笔记

开发者学堂课程【云原生中间件产品销售红宝书：云原生(中间件)热卖产品串讲】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/629/detail/9886

云原生(中间件)热卖产品串讲

七、Kafka 产品介绍

Apache kafka 旗下的一个开源系统，被广泛使用在大数据场景中。来源于2014年13年的时候，大数据也比较早，2011年，早期的 hadoop 场景就是先把第一个数据收集起来，第二个数据进行计算。第三个数据进行存储，第四个数据分发和预测分析，所以每一个数据都是千万百万级，甚至几个 gb 的级别，用普通的消息不行，所以就研发了这款产品，因为大数据传输需要而导致的。

1、全托管服务

专注于业务开发,无需部署运维，更低成本、更弹性、更可靠

2、无继迁移

100%兼容 Apache Kafka 协议，Kafka 客户端、插件与消息队列Kafka通讯

3、数据安全

支持 SSL 加密数据传输，确保数据传输过程中不被窃取或篡改。

4、更专业

优化开源 Kafka 痛点，优化消息堆积处理、支持万级 Topic 能力。

 

八、MQ产品介绍

RocketMQ /Kafka 应用场景分析

如果是消息堆积需求特别大，一般于属于系统之间，系统内部的传输，一般用rabbit，rocket 解决问题，kafka 主要适合大数据，日志，大型数据库的数据，如果有传感器车联网app，就用消息队列，物联网消息，所以在图中统一说明。

1、与竞品的优势

竞品指的就是开源。

（1）兼容性:支持 HTTP, MQTT 以及 SDK 方式，适应多种场景接入

简单易用:提供统一的控制台，开箱即用，无需额外搭建

（2）性能+稳定:不丢消息;服务不断;在大用户量并发下保持高的写入和读取性能

（3）监控+运维:提供全链路消息轨迹跟踪、堆积消息查询、完善的（4）监控与告警机制，及时发现消息投递过程中的问题

2、消息队列为客户带来的价值

（1）业务开始发展,系统越来越多,可用性受到挑战

消息队列AMQP + RocketMQ

（2）创业初期，一到大促就扛不住

消息队列AMQP + RocketMQ

（3）物联网、车联网、Apps应用行业延伸

微消息队列MQTT

（4）大数据分析,流数据处理,实时日志

消息队列 Kafka

（5）自建消息产品需专门人员维护,需要解决开源的bug

消息队列 AMQP +kafka

3、消息队列 AMQP 开源痛点

（1）开源痛点：

部署运维成本高,缺乏成熟的运维管理工具，集群能力取决于单机上限，单队列无法扩容，抗堆积能力差,影响稳定性，Erlang语言小众,技术能力成为瓶颈，开源产品，与云产品集成能力较弱。

（2）解决方式

云托管，免运维，弹性伸缩,平滑扩容，削峰填谷，海量消息堆积能力，阿里云消息团队官方技术支持，丰富的云产品生态，云产品集成容易。

4、用了 MQ 有什么变化

（1）开箱即用,降低80%运维成本

 从前客户自行搭建消息队列，不但需要投入高额的运维成本,当遇到故障或性能问题的时候,还要花费非常多的精力进行排查。

用了MQ 购买MQ ,开箱即用 (只要四步),提供完整的数据也服务高可用能力 ，同时有完整监控机制 ,海量消息发送做到分钟级定位问题,消息的异常告警秒级推送。

（2）提高系统吞吐量,降低系统间耦合度

从前客户方端客户访问不解耦的系统,系统响应不稳定延时严重。

用了MQ 客户方端客户访问系统,系统响应可以提升到1s内。

（3）稳定可靠,降低业务不可用的风险

从前通过传统方式或开源容易丢失、重复写入等。

用了MQ消息在传输过程中不会丢失,服务本身的可用性达到金融级要求(核心交易场景使用)。十亿次百亿次只会丢一条，金融级的要求。

5、MQ for IoT 典型客户案例

（1）游戏行业客户:某在线棋牌类游戏。用户量达到一定规模后,就存在系统反应慢、客户端掉线等问题。经过诊断发现问题出现在同步链路长导致系统响应慢,同时稳定性存在较大问题。购买MQ后,通过MQ异步化处理游戏临瑞能,在3个月的时间内,用户数翻了10倍。

（2）餐饮行业客户,典型的物联网场景。通过消息队列for IoT连接手机APP、商家平台、厨房终端设备、外卖平台等,实现现代化的智能餐厅。

（3）典型客户:海X捞、XX外卖平台....

在线游戏就是天然的大并发场景，容易在两个地方出现卡顿，第一个是在登陆时候，第二个是在打副本，打boss，纯战，就在打打，打一些大怪的的时候，一起打纯战的时候比较卡。消息传递开始出现延实，没有堆积，所以这是mq消息处理的路径，可以通过消息堆积解决消息，人数多，登录不上去的问题。解决砍怪掉血的问题，或者是回血的问题，所以这是解决游戏体验比较好的案例。

6、RocketMQ 客户案例

（1）客户行业:娃娃机

（2）业务痛点:娃娃机就是投币抓娃娃，投币成功才给抓娃娃机的机会，数据每天往后台传。客户的娃娃机后台系统一直部署在阿里云上，此类业务呈现订单额度小但频次高的特点，并且与现场设备之间的联动密切，用户对于付费成功与否敏感性极强;该客户研发能力极强，多数系统及底层均由自己研发，采用MQ的契机是由于某次比较大的网络抖动(两分钟左右)导致高达3000笔小额订单丢失，意味着钱不能入账，或者账不平。财务找公司人员去解决问题，手工筛日志，时间可能一周到两周，本身最后发现的问题是它没有采取mq的传递机制。它采取的是自己写sql的方式，所以出现丢失情况，使用mq好处，如果停电了，消息会在远端存起来，收的一方收不到消息，会把消息堆着，一直试到上线网络通了，再接着发送，有消息重试过程，保证订单不丢。出现了文本日志有记录但数据库内没有数据的情况。本次故障迫使用户下决心采用消息队列。

（3）购买产品/组合:消息队列( MQ )。

（4）使用效果:通过MQ将控制流与数据流进行解耦,以提高业务的吞吐量,同时利用阿里云MQ多地部署的优势,确保用户敏感数据不会因为环境变化而导致丢失的现象。

（5）销售感言:典型的业务倒逼技术方案的升级,研发能力极强的客户,只要发现正确的痛点,也可以找到Aliware的切入场景。

7、客户案例-XX 电子 kafka

（1）背景:传统零售行业,有自己的电商和外贸平台,年销售额近300亿。

（2）销售金额:1.9万

（3）业务痛点:客户属于传统零售行业,有自己的物理机房,目前引导电商平台迁移到公有云来。之前客户用的开源的kafka ,据反馈很不稳定,出现过消息丢失等情况，每次有问题都是找第三方去排查解决,时间成本和金钱成本大大提高。

（4）之前使用的产品:开源的kafka

（5）销售方法:把阿里云的kafka和开源的kafka进行了对比,客户对于阿里云kafka提供托管服务和高稳定性很认可,这样能够减少他们运维和使用成本,更能专注于上层应用和业务发展。

（6）使用效果:电商平台目前正在测试中,使用没有遇到问题,体感很好。

（7）销售启示:聆听客户业务痛点和关注点,及时抓住并给到合理的解决方案以及对比方案,强化客户寻求变通和解决问题的决心,引导客户采购使用。电商只是客户it建设中的一个小模块,借此机会也方便去深挖客户其他应用建设情况。

场景单一，数据量极大，发消息过程中容易出现消息丢失。而且90%客户都是开远发的，在过程中随着消息越来越大，各种数据来了消息，数据越丢越多，根据墨菲定理基数越大，只要有可发生，就必然会发生，消息会越来越多的丢失，最终丢失就会影响大数据分析的结果。通过开源转商业化有效解决消息丢的问题，丢了之后重试，而且还能查消息去哪了。

8、MQ 应用行业

电商，快递物流，广告营销，im/移动应用/手游，人力资源，视频物联网，互联网门户，企业应用解决方案提供商，金融支付，电信行业。

mq是个中间部分，消息传递的部分，通用部件，很多行业都可以用，黄色部分跟钱有关系，所以它不能丢，丢了就会导致公司有损失，所以这类公司对东西体验非常敏感，它会对消息比较重视，绿色偏kafka，物联网行业。

9、行业、场景举例

（1）行业:

电商、新零售、020、游戏、直播、金融行业

（2）业务类型:

短信、邮件、即时通讯相关产品,会涉及到消息的通知,天然适合使用消息队。

（3）场景:

抢购、促销、线选房，抢学位，拍卖，比赛抽签，系统多，用户访问慢，开源自建，维护难，成本高，稳定性差

10、售卖类型

消息队列MQ (包年包月)

预付费包有两个机制，除了kafka都是收费机制，第一个写tps，第二个写topic，类似于两个好友加个好友，有个聊天框，聊天框就是topic，tps是消息条数，高度一致的收费机制。国际版有一个存储空间，普通版没有。

九、性能测试 PTS

1、如果客户要上生产系统，需要做测试，测试来自于需求，因为现在的互联网客户会应对很多不确定的因素，尤其是新浪，娱乐新闻，担心流量爆棚，系统崩掉，很多人喜欢在手机上看直播，但是如果哪天看球赛卡了，在过程中会比别人慢了几分钟，甚至解说都会卡，体验感很差，所以流量太大，扛不住的情况，所以大流量如果不准备，就会出现更多损失，客户不信任，包括会员和流失，要做一些事情，就是提前做压测，压测就是请很多人过来，不停的点击网站，点击app，看一下一个人点和十个人点100个人一万个十万个一百万个人点，网站能不能扛得住，瞬间同时发起，模拟各种段位的人来访问。原理机制是调用全国cdn的节点，全国有两千多个节点，相当于请两千个节点的人，每个节点有大几千的用户，上万的用户做动作，所以它主要是模拟点击模拟访问一个网站，所以它是流量高度压力测试，虽然是模拟，但是，是真实的，公网可以访问即可，没有技术可以压测。

2、有哪些销售场景？

（1）阿里云

上云迁移，需要检测新系统性能

（2）新业务上线

如电商系统、秒杀模块新上线新上

（3）验收项目

作为第三方测试下交付系统是否验收达标

（4）成本控制

通过压测检查到短板,把相应富裕的资源释放或者补给短板想节省机器成本

（5）扩容

扩容后需要检验下资源是否达到预期，是否浪费成本

（6）开源方案替代

JMeter或者破解版LoadRunner，解决内网瓶颈问题

（7）友商竞品

云智慧/OneAPM/腾讯压测，PTS更有价格优势，且简单易用流量更广，解决外网问题，它贵，节点不多。

3、压测之后的问题定位

出报告，告诉网站节点，从哪来的，app瞬间打开，把云监控，arms同时打开，把底层数据库四大件的存储指标，还会告诉内部系统之间应用之间这种互相调用，数据传输的性能。

4、计费及价格

PTS铂金版采用预付费购买资源包的形式收费。买多少个人，访问多长时间，收费是一个资源包，资源包买十万，但是拆不开，不可能十万人访问一秒钟，5000个人访问二十五分钟，就是十万次。

一般推荐买1000的包，有钉钉答疑群，帮客户解答问题。

5、客户案例

（1）客户行业：体育比赛

（2）业务场景/痛点:新一年度的X州马拉松比赛中签公布即将开始。 本届X马报名创历史新高,根据历史情况判断,中签结果公布的时候会有一波系统应用峰值压力,为了更好地迎接杭马中签公布历史时刻,确保系统的安全稳定运行。用户需要对系统进行压力测试,在压测中进行调整优化。

（3）购买产品/组合: PTS性能测试

（4）使用效果:通过PTS压测，找到了用户应用系统中多个瓶颈，及时进行了优化调整，优化后系统的并发处理能力提升了四倍。

（5）跟进感言:用户反应阿里云的PTS性能测试服务确实方便、好用,而且花费不高,值得点赞!

6、PTS 客户案例

优酷世界杯直播:

（1）对直播系统进行了多轮压测,确保系统能保持稳定顺畅。

（2）如果因为前期准备工作不足而导致直播卡顿,不但浪费16亿的版权费用,还会对优酷品牌造成严重后果。

7、客户案例

（1）客户行业：电子商务

（2）业务场景/痛点:客户于2017年中旬就开始着手准备线.上商城系统,但是当时不管对系统的性能还是底层资源的要求都没有一个全面的概念,且客户有商城秒杀场景,对性能要求比较高,我司推荐购买PTS进行压力测试,客户要求尽量模拟真实的电商平台压力环境,从使用者登录平台到浏览产品到加入购物车到最后支付结单退出,浏览产品环节需要的测试时间要远远大于登录、加入购物车和支付结单时间,由我司技术人员协助客户做了脚本编写工作。

（3）购买产品/组合: PTS性能测试

（4）使用效果:目前客户压力测试效果较好，对阿里云和我司的工作也表示非常认可。基本且前有新的业务场景或者更新了某个场景，都会先通过PTS，做一下压测再上生产系统。

（5）销售感言: PTS性能测试性价比高,客户表示早知道这个工具就好了,太省事了!

8、PTS 主要客户

9、适配行业

手游/页游/直播/短视频:比如点赞、留言、聊天、赠送礼物、广播等;

电商交易类( PC或者APP) :浏览、秒杀、购物车、下单;

互联网APP (社交、互金、出行、生活、知识付费、传统行业、区块链) :拉新、推广、自身核心业务场景;

网站类(几乎所有行业) :首页注册、登陆、内部系统、核心业务等;如教育、体育行业的在线报名、查询结果;

各平台上的应用:比如支付宝、微信、钉钉等开放平台上的第三方业务和页面;

客户只要有公网，app小程序，网站都可以来测一测，所以它的应用场景很广。

10、ARMS 业务实时监控服务

阿里云官方APM产品，完整覆盖应用服务端、浏览器端、业务关键指标的监控领域

（1）数据链

页面一键埋点、应用无侵入埋点、业务日志、实时流/消息

（2）场景

前端监控(商业化)

实时威知用户实际访向网站的响应时间，页面异常，和API错误率，基于地区，运营商，浏览器等多维的用户体验分析

应用监控(商业化)

针对微服务的分布式链踏分析，基于应用本身的资源使用，堆栈分析，异常捕获，以及内存快照监控和诊断。针对第三方调用监控如DB, MQ缓存等的调用分析。将业务日志和调用关联的全息排查。

自定义监控(兔费)

基于异构数据源抓取，实时计算和时序数据库的业务大盘快速定制功能业务场景覆盖:零售，交通物流等多个行业。

arms跟pts做搭配，pts只会告诉app打开的参数，但是实际上不够，还有更详细的参数，比如监控可以告诉流量是从哪个省来的，移动还是联通来的，客户是从哪个浏览器打开的，均衡度满意度怎么样，颗粒度更细一点，还有应用监控，后端的四大件五大件，网络存储sql各个方面调用，它会把整个系统网络自动识别出来，超时异常都标记出来。

 

十、ARMS产品介绍

前端监控中可以看到应用总览信息，包括JS错误率、访问速度、API请求成功率及PV情况，各个省网站速度打开如何，精细化。

能够看到应用的调用关系拓扑图，可以定位到慢SQL、慢服务、方法的调用堆栈，进而定位到代码级别的问题。如果不知道客户的系统，可以推荐arms，出现调用关系拓扑图，一张图可以清晰的表现出客户的信息，arms主要作用是看每个链条，链接之间的调用关系是否异常，帮助做定位，找问题，做定位比较快，所以用来做分析报表，就是立体监控能帮助业务人员快速理解。

 

十一、轻量级应用上云

1、初阶

如果新上云的客户，初步建议serverless比较便宜，尤其是刚上云客户，对阿里云不太信任，推荐这个，上云速度比较快，同时加pts，能做一个简单压测。

 

2、高阶

复杂一点，等客户要上读写分离的数据库，需要 oss，安全，rds，适合多场景的配置。