新闻动态

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

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

微信和 Google 的高可用

2015-12-18 11:45:08   
 

微信和 Google 的高可用

使用云服务,最大的好处,就是可以多快好省地提升系统的可用性。系统的可用性,也是这一期云计算文摘的核心内容。前两篇文章分别介绍了微信朋友圈和 Google 在可用性上的考量,后两篇,一篇讲到如何将 MySQL 用作 NoSQL 引擎,以提升可用性;另一篇分析了如何基于可用性的角度考虑,将后台服务器的反应数据转换成用户角度的延迟,以提升负载均衡的效率。
 

微信朋友圈技术之道:三个人的后台团队与每日十亿的发布量

 

陈明,微信高级工程师、朋友圈负责人,2012年加入微信后台团队,负责微信后台核心服务的研发,包括朋友圈、即时通信、基础设施等。本文来自他在2015年ArchSummit深圳大会的演讲“微信朋友圈技术之道”,介绍了微信后台团队的开发模式、微信朋友圈的架构以及在性能上的一些工作。

开篇提到:微信的后台研发团队只有三名工程师!!由此可见:中国技术人的实力还是很强的。

接下来介绍了微信朋友圈的架构,包括使用了哪些核心表等等;此外还提到朋友圈的后台处理流程和容灾。
 

金句:  

整个微信是微服务的架构,每一个请求后面可能会涉及到几百个服务,每一个服务都有一个QoS,目的是对一些重要的服务进行保证。比如除夕晚上流量达到平时的5倍,这时整个系统的性能肯定不够,所以要优先保证什么呢?优先保证支付,优先保证红包的体验。红包体验保证了,再保证消息,比如点对点两人之间的消息。这两个保证的前提下,再保证群聊。如果群聊也能保证,再保证朋友圈。性能不够时将优先级低的服务暂时停掉,这个过程是不需要人工干预的。

微信现在每天的发布有10亿多,浏览量超过100亿,对性能的要求很高,所以上面的存储都是做成可以水平扩展的。

标签:微信、架构、基础设施、开发流程
 
阅读原文
 

来自 Google 的高可用架构理念与实践

 

Google 设计系统时,在可用性、可靠性上面,有哪些理念和思考?本文来自Coding.net 的 CTO 孙宇聪,他曾在 Google 总部担任SRE(全称是 Site Reliability Engineering ,基本相当于国内的运维,但是更偏开发)。他参与过 YouTube 的运维管理,以及 Google 的云平台团队,并担任多个项目负责人。
 

孙宇聪首先介绍了决定可用性的两个概念:MTBF 和 MTTR。  

MTBF: Mean time between Failures。 用通俗的话讲,就是一个东西有多不可靠,多长时间坏一次。

MTTR: Mean time to recover。意思就是一旦坏了,恢复服务的时间需要多长。

一个服务的可用度,取决于 MTBF 和 MTTR 这两个因子。从这个公式出发,结合实际情况,就很好理清高可用架构的基本路数了。那就是: 要么提高 MTBF, 要么降低 MTTR。除此之外别无他法。

接下来,孙宇聪介绍了实现高可用的两个方案,每个方案各有三个必须要注意到细节:

方案一:提高冗余度,多实例运行,用资源换可用性。
  1. N + 2 应该是标配。 
  2. 实例之间必须对等、独立。
  3. 流量控制能力非常重要。

方案二:变更管理(Change Management)

  1. 线下测试(Offline Test)
  2. 灰度发布
  3. 服务必须对回滚提供支持

最后,孙宇聪提供了可用性的7级图表,供读者检查自己服务的可用性级别:

  1. Crash with data corruption, destruction.
  2. Crash with new data loss.
  3. Crash without data loss.
  4. No crash, but with no or very limited service, low service quality.
  5. Partial or limited service, with good to medium service quality.
  6. Failover with significant user visible delay, near full quality of service
  7. Failover with minimal to none user visible delay, near full quality of service.  

金句:  

一般一个服务只要你不去碰他一年都不会坏一次。更新越频繁,坏的可能性就越大。凡是 Software 都有 BUG,修 BUG 的更新也会引入新的 BUG。发布新版本,新功能是 MTBF 最大的敌人。

想要提高可用性,必须要和开发团队找到一个共同目标。这里再给大家一个秘籍,那就是 error budget。跟开发团队确定一个可用度,比如说 99% 。 如果业务团队搞出来的东西很烂,各种状况,最后达不到这个标准。那么对不起,暂时别发新功能,只修 BUG。

标签:Google、可用性、架构、发布
阅读原文
 

为什么说MySQL 是更好的 NoSQL

 

互联网公司的技术人员,你要是说不会用 NoSQL,都不好意思跟人打招呼,而且对 MySQL 也越来越鄙视。但是,很多公司在技术选型时,其实对 MySQL 并不了解,错误以为它的性能必然不如 NoSQL。这篇文章来自WiX 的工程团队,就是要破除这样的迷思。

WiX.com 是一个基于云的 web 开发平台,全球有千万用户。在这篇文章中,他们的工程团队负责人Yoav Abrahami分享了WiX 如何将 MySQL 用作 NoSQL 引擎。他提供了相关的数据和解决方案,同时给出这么做的具体建议:

把 MySQL 当 NoSQL 用时,要避免数据库锁或是复杂的查询:

  • 不要使用事务,这会带来锁。使用应用级的事务。
  • 不要使用顺序主键。 
  • 使用客户端生成的主键

设计数据库架构时,要为读操作专门优化:

  • 不要范式化
  • 不要使用外键
  • 允许查询时读取单行数据
  • 不要执行修改表结构的命令。

查询数据时:

  • 根据主键或索引查询
  • 不要使用连接。
  • 不要使用聚合(aggregation)
  • 数据仓库和 BI 等相关操作要在复制库上进行,不要在主数据库上操作。

金句:

MySQL 是一个强大的数据库引擎,网上有齐备的大量资料,从运维到错误案例分析,从复制到不同使用模式,一应俱全。

将 MySQL 作为 NoSQL 引擎使用很合适,虽然这不是它本来的用途。在 WiX,MySQL 是我们进行键值对操作时的选择,因为很容易使用,而且它有很好的生态系统。不光如此,它还提供延迟、吞吐和并行性方面的度量指标,足以匹敌大部分的 NoSQL 引擎,甚至超过它们。

标签:MySQL、NoSQL、数据库
阅读原文
 

Spotify 如何设计基于延迟的负载均衡系统

 

负载均衡系统,是提升可用性的重要手段。

Spotify 是全球最大的在线音乐服务之一,当 Rd.io 离我们远去之后,能与 Spotify 抗衡的,恐怕只有 Pandora 和 Apple Music 了。他们分享了Spotify 设计基于延迟的负载均衡系统( latency based load balancer)的经验。

预计延迟选择器(Expected Latency Selector,ELS)是Spotify 为他们的负载均衡系统的命名。他们会让ELS 度量以下数据:

  • 每台服务器成功的延迟和成功率。
  • 在负载均衡器和每台服务器之间的特定请求数,这些请求已经发出,但尚未收到回应。
  • 快速失败比慢速失败好,因此还要度量每台服务器的失败延迟。

然后,他们用一个公式,计算如何为各个服务器分配权重,让更慢的机器得到的流量更低,

接下来,他们还分享了自己的数据,探讨不同算法下,ELS 的性能表现。半年下来,ELS 的表现非常可靠而出色。

这个系列共有两篇,链接中为第一篇,文末有第二篇的链接,其中详细介绍了他们的公式。

金句:

用户非常关心延迟,我们也想让反应更快的服务器回应更多流量。ELS 可以将所有度量到的数据转换成客户角度的预计延迟。

标签:负载均衡、延迟、算法
阅读原文
 

SpeedyCloud网络总监暴永峰分享全球云平台网络架构


2015年,ArchSummit大会(北京站)将于12月18日-19日在北京国际会议中心举行。SpeedyCloud网络总监暴永峰届时将出现在“云平台应用选型与建设实践”主题专场,结合近10年的实践经验,分享云平台全球网络节点部署与架构的演进实录。

下层基础决定上层建筑。一部全球云平台网络架构演进实录,也是一部信息技术革命的进化实录。从北京至全球,如何部署云平台全球网络节点?如何设计OTN组网架构?如何设计未来的架构模式?

全球资深技术大咖云集的风云际会,探讨技术与实践的最佳结合,感受技术的人文魅力,我们在现场等你!


 
阅读原文
 
关注SpeedyCloud官方微博
掌握最新动态和优惠
扫描SpeedyCloud官方微信
获取价值50元免费云主机
欢迎发送邮件到social@speedycloud.cn,聊聊你对于“SpeedyCloud云计算技术文摘”的想法和建议,也欢迎你说出对于SpeedyCloud迅达云成公司的意见和看法。

*|FORWARD|*