新闻动态

完善的7*24小时服务,携手共赢,共同成长

首页 新闻动态云计算文摘 正文

微信 vs QQ,腾讯的左右互搏

2016-01-23 18:31:37   
 
本期推荐的第一篇文章,讲述了微信后台系统的思维和架构演进。在原文页面上,有读者评论说:微信团队与 QQ 团队之间技术是不是基本不怎么沟通?也许看过本期文摘推荐的前两篇文章后,你会有一个自己的结论。毕竟双方都提到了一些类似的问题。不管怎么样,双方都解决了一些技术债务,而在腾讯这么大体量的公司眼中,技术债务可能带来很多麻烦。创业公司则完全不同,技术债务不一定是坏事,这也是本期第三篇文章要分享的思考。第四篇中介绍了Schemaless——Uber 自行开发的高容错性、高可用的数据存储项目。
 

从无到有:微信后台系统的演进之路

五年前的1月21日,微信正式发布,到现在刚满五年,它的发展恐怕超出了很多人的预计。五年时间,微信的后台系统是怎么演进的?恐怕没有比张文瑞更了解的人了。他是微信高级工程师,微信接入系统负责人, 一直从事后台系统设计开发,早期涉足传统行业软件,后投身互联网。作为微信最早的后台开发之一,见证了微信从零开始到逐渐发展壮大的过程。

在微信正式发布前的两个月里,张文瑞提出,微信后台做了三件最重要的事情:
  1. 确定了消息模型
  2. 制定了数据同步协议
  3. 定型了后台架构
发布之后,面临的就是起步和成长阶段。微信先是小步慢跑,然后就进入了飞速成长阶段,10个月时间,注册用户从100万突破1亿。

张文瑞认为,帮助微信度过这个阶段的,是以下几个举措:
  1. 经过详尽讨论出来的极简设计
  2. 拆分服务模块,大系统小做
  3. 从 QQ 后台取经,学习全面的业务监控
  4. 自行开发的 KVSvr 存储,解决无单点故障的容灾能力。
稳定发展后,微信开始“精耕细作”。这期间的工作包括:
  1. 三园区容灾
  2. 性能优化
  3. 防雪崩
  4. 安全加固
当然,系统在不断发展变化,微信后台也在面临新的挑战,比如:
  • 资源调度系统
  • 高可用存储
金句:  

有个广为流传的关于朋友圈开发的传奇——朋友圈历经4个月,前后做了30多个版本迭代才最终成型。其实还有一个鲜为人知的故事——那时候因为人员比较短缺,朋友圈后台长时间只有1位开发人员。

实现需求最大的困难不是设计出一个方案并实现出来,而是需要在若干个可能的方案中,甄选出最简单实用的那个。这中间往往需要经过几轮思考——讨论——推翻的迭代过程,谋定而后动有不少好处,一方面可以避免做出华而不实的过度设计,提升效率;另一方面,通过详尽的讨论出来的看似简单的方案,细节考究,往往是可靠性最好的方案。

标签:高可用、后台、架构
 
阅读原文
 
【精彩声音】:

当今世界中,物理机器和服务之间的1:1对应关系已经不那么长江了。我们不再有专门用于 web 服务的服务器,而是有一台服务器,上面托管着 web 服务的一部分。(来自Brian Brazil
 

24个小时,2亿 QQ 用户全网应急大调度

2015年8月12日的天津港大爆炸,你一定还记忆犹新。腾讯在亚洲最大的数据中心,就在天津,而且距离爆炸点仅仅1.5公里。

天津数据中心内含腾讯社交核心业务,包括QQ、空间、相册及音乐等业务,社交核心业务主要按深圳、天津和上海三地来分布部署,各支撑中国三大区域的用户访问。为了保证QQ用户正常使用服务,运营团队马上展开了2亿QQ 用户的全网应急调度。在24小时内,QQ用户服务最终无感知地在线迁移到深圳和上海,完成中国互联网史上最大规模的用户调度,而且继续保持全年4个9的可持续服务能力。

本文来自腾讯高级运维工程师周小军,分上下两篇,讲述了整个调度的过程。

上篇分析了调度面对的7大挑战:
  1. 用户如何在体验无损的情况下调度到异地
  2. 用户的状态数据、消息如何保证不丢失?
  3. 用户的数据如何做到几地的全量一致性同步?
  4. 异地的服务容量(包括服务器容量、模块容量、业务容量和IDC容量等)能否支撑大量用户请求的涌入,异地容量不能支撑时如何处理用户请求?
  5. 容量峰值后如何快速缩容?
  6. 调度能做到多快,分钟级、小时级还是天级?
  7. 运营是否具备自动化的调度能力?
下篇介绍了大调度背后的技术架构以及以下几种能力别后的技术细节:
  1. 多地分布和异地容灾能力
  2. 快速的调度能力
  3. 数据多地同步能力
在运营上,下篇还介绍了如下几点:
  1. 织云自动化运维平台
  2. 柔性服务和过载保护
  3. 快速伸缩能力
  4. 立体监控
  5. 技术保障
如果你对这次“8·13大调度”感兴趣,不妨一读。

金句:  

腾讯社交业务以SET的方式部署服务,每个SET集合了一个或一组服务模块,通过接口对外提供调用服务。SET间是无状态的,通过SET可以实现横向扩容能力。也就是说这些业务都支持部署最小化,当有需要时,可以不断增加SET数量来支持业务的流量,且SET之间无差异。

标签:运维、调度、可扩展、容灾
阅读上篇
阅读下篇
 
【精彩声音】:

把地球的寿命缩短到46年,工业革命刚刚在一分钟前开始,就在这段时间里,我们已经摧毁了世界上一半的森林。(来自@WhatTheFFacts
 

如何利用技术债务,以及为什么要这么做

本文作者是技术创业者,之前的经历让他觉得技术债务令人头疼。自己创业之后,他开始有了不一样的思考:  

在创业公司中,技术债务无好坏之分;只是你必须学会利用的一个风险。

他还认为:技术债务可以帮助早期的创业公司增长更快。这基于以下两个原则:
  1. 有些特性会测试你风险最高的业务前提,不要浪费时间过度开发这样的特性。
  2. 加速你的“开发-度量-学习”迭代过程,越快越好。
利用技术债务,不等于不对它做规划。作者认为:
  • 尽可能控制技术债务的影响范围。
  • 让技术债务可以翻转。
  • 让技术债务可以跟踪。
文章最后,作者指出:
  1. 每个人都要有“打破砂锅问到底”的精神。
  2. 即便没有多年经验,黑客式的思维方式也要比不能“黑”(Hack)的专家思维来得好。
  3. 营造一个黑客和专家可以共生的空间。
金句:  

大公司花很多钱来节省时间,以便挣更多钱;早期创业公司花钱来黑出时间,以找到深入的思维成果。

究其本质而言,聪明的黑法是管理技术债务更好的办法,可以让你加快迭代周期。

标签:创业、技术债务、管理
阅读原文
 
【精彩声音】:

我喜欢云计算提供者之间的价格战,更便宜的计算资源让技术世界里的其他一切都成为可能。(来自@jaykreps
 

Schemaless:Uber使用MySQL设计的键值存储

2014年初,出行热引发Uber的存储担忧,其基础设施无法承载日益增加的数据量。现在,Uber已将核心出行数据从Postgres迁移至Schemaless,这是他们自己开发的容错性强和高可用的数据存储。本文进一步描述了Schemaless的架构体系、在Uber基础设施中的作用及它的发展过程。

首先,根据业务需求,Uber对于新方案提出了5个关键需求:
  1. 要可以实现增加服务器时线性增加处理能力
  2. 在写操作上达到高可用性
  3. 二级索引
  4. 向下流动的通知依赖机制
  5. 满足运维对系统的信任
由于市场存在的商业或开源数据存储项目无法满足以上5个关键需求,Uber决定自主开发尽可能简单的系统,开发设计灵感源自FriendFeed,开发重点放在运维层面的理念则是受Pinterest启发。本文有3部分,后文2部分进一步描述了Schemaless的架构及如何使用触发器,其中对Schemaless形成存储方式进行了介绍。

金句:  

其它方案或许在理论上运行起来可靠性很好,但我们是否能够在运维中将其他方案的优势马上发挥出来,这有赖于我们是否能开发出符合Uber自身实际情况的解决方法。而这不仅仅依赖于我们使用的技术,也要看我们团队对于这些方案的使用经验。

标签:数据库、高可用、Uber、MySQL、NoSQL
阅读原文
 
【精彩声音】:

我主持着一个基础设施创业团队,我们有一条原则:如果每个月在 AWS 上的开销介入两万到九万九美元之间,你就一定可以在某个地方把账单数据减少一半。这个阶段的网站,一般来说是只用了 AWS 提供性能的20%。(来自@jaykreps
 
点击回顾
 
关注SpeedyCloud官方微博
掌握最新动态和优惠
扫描SpeedyCloud官方微信
获取价值50元免费云主机
欢迎发送邮件到social@speedycloud.cn,聊聊你对于“SpeedyCloud云计算技术文摘”的想法和建议,也欢迎你说出对于SpeedyCloud迅达云成公司的意见和看法。

*|FORWARD|*