解密阿里云七武器之高性能消息服务ONS

7月22日,首届阿里云分享日上,阿里云正式对外发布了企业级互联网架构解决方案,该服务由EDAS应用框架、ONS消息队列、DRDS分布式数据库组成,能有效解决企业上云后网站过载、性能瓶颈、重复开发等问题。

而由阿里巴巴集团经过6年的自主研发,基于高可用分布式集群技术的ONS云消息服务,是企业级互联网架构解决方案的典型代表。目前,ONS云消息服务每天可处理上千亿条消息,服务于阿里内部上千个应用,轻松通过天猫双十一等大促考验。外界对ONS的描述是“成熟、稳定、可靠,性能突出”,那么ONS究竟有多神?一起来探究一下。

ONS配图1

此前,一张流出的ONS产品视图证实了阿里将把自己6年来的看家武器提供给开发者。

多维度接入、轻松回溯、线性扩容

接入方面,阿里云ONS支持JAVA、C++、.NET、PHP四种语言的SDK接入,同时提供RESTful风格HTTP协议完成收发消息,另外还支持MQTT协议接入可以满足设备与设备、设备与应用间的可靠高效的通信。除了常规的延时消息,实现消息延迟投递,满足应用需要定时、延迟发送消息的需求外,依靠类XA的分布式事务架构,阿里云ONS还支持事务消息,能实现事务最终一致性。

订阅方可能常常会遇到这样的难题:当你下午2点半的时候发现12点的消息出现了错误,传统的模式下消息可能出现丢失,而人工回溯又特别费时费力,估计今晚跟女朋友的约会又要泡汤了。在阿里云ONS多维度的消息管理下,你大可放心赴约,ONS支持消息回溯消费,可以最多回溯到3天前的消息,并重新消费。此外,阿里云ONS还提供了图形化的基于WEB的管理控制台,能直观管理消息路径,随时进行回溯纠错和失败重试,精确实时反馈投递情况。最高可精确到topic维度,可以监控各topic消息堆积情况,提供报警机制。

在性能方面,阿里云ONS采用了多线程设计,提供亿级消息堆积能力,完美支持业务削峰场景。在高并发场景下能弹性扩容,1天内就能部署并验证上千个节点的大型企业专有云架构,保证消息投递的低延迟和及时性。

承诺可靠性99.99% 阿里云ONS与同类产品对比

其实对阿里云来说,再高的性能需求都不叫事,拥有6年来淘宝、天猫、双11交易链路大规模真实场景应用经验,阿里云ONS一天内完成上千亿条消息传递都成了家常便饭。虽然亚马逊AWS也有消息服务SNS,但SNS架设在国外,国内没有接入点,对国内的用户来说需要跨国网络,这就带来了稳定性和网络延迟的多重考验。商业化之后,阿里云ONS还将推出相应的机制来保证99.99%的可靠性和99.9%的可用性。

与目前流行的开源消息中间件Kafka相比,基于云服务的阿里云ONS的优势很明显,用户无需花高额的价钱购买服务器并维护,还能按量付费,适合多个场景。目前,阿里云ONS已经全方位覆盖了物联网、金融支付、电信、快递物流、广告营销、社交、手游、人力资源、视频以及互联网门户等十大领域,尤其是物联网的应用场景,每个传感器都是系统中的节点,节点之间依靠消息异步通信,天然形成了基于消息的分布式应用。

ONS配图2

财报显示,2015年第二季度,阿里云成为阿里巴巴增长最快的业务,加上阿里巴巴CEO张勇宣布对阿里云增资10亿元,显然云计算已经成为阿里最为重视的业务之一,资源也会向其倾斜。此次阿里云推出的中间件产品ONS,也是在经过6年的优化和检验之后才向用户开放,稳定性和可靠性更有保证。

随着云计算在全球范围内的普及,各方面的需求越来越强烈,未来中国市场将为全球云计算市场贡献43%的增长,IDC预计到2018年中国云计算市场将达到20亿美元。。强劲的市场增长也将吸引越来越多的互联网公司投入云计算市场,据研究机构IDC数据显示,2014年阿里云在中国公有云市场份额排名第一,市场占有率达29.7%,超过亚马逊、微软和IBM在中国市场的份额总和。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1、MQ场景     1)订单异步解耦     2)解决分布式事务问题     3)应用于聊天平台     4)大规模机器的Cache同步     5)MySQL BinLog订阅数据分发 2、ONS应用场景     异步、解耦、最终一致、并行 3、设计假定     1)每台PC机器都可能down机不可服务     2)任意集群都可能处理能力不足     3)最坏情况一定会发生     4)内网环境需要低延迟来提供你最佳用户体验 4、关键设计     1)分布式集群化         a、理论上无限处理能力         b、集群级别高可用     2)强数据安全         a、单机磁盘级别冗余         b、单组多队列级别冗余         c、多组消息队列冗余     3)海量数据堆积         a、推模式:订阅者逻辑简单         b、拉模式:关注吞吐量,快         c、推拉结合:队列通知消费者,消费者去拉取(两次交互)         d、阿里采用长连接和轮询:轮询去拉,有则拉取,无则保持长连接等待,直到有消息     4)毫秒级投递延迟 5、关键概念     1)Topic:第一级消息类型,主标题     2)Tug:第二级消息类型,分标题     3)发送组:生产者所在集群     4)订阅组:消费者所在集群     5)RocketMQ不是一对一,也不是一对多,是随机一对一     6)网络三种状态:成功、失败、没响应 6、消息乱序问题:Message服务器不处理,恰好不需要解决     1)发送时对消息进行编号     2)一组消息只有唯一一个订阅者处理(sharding)     3)一组消息的数量(即“锁的颗粒度”)越小越好 7、消息重复问题     1)重复原因:网络不可达     2)幂等:某个操作无论重复多少次,结果都一样(不需要解决,性能极高)     3)非幂等,去重         a、保证有个唯一ID标记每一条消息;         b、保证消息处理成功与去重表日志同时出现     4)去重代价:额外的tps和qps 8、事务的分布式优化     1)事务1-->MQ Server-->事务2     2)同时成功,同时失败:         a、发消息;         b、执行事务1;         c、确认消息发送;         d、投递消息到消费者     3)处理超时问题(重复):事务2增加消息确认表(去重表)     4)消息失败(事务2失败):记录后人工处理(小概率事件)

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值