新闻动态

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

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

阿里和新浪的异地多活

2015-12-25 17:56:14   
当你看到这期文摘的时候,应该是圣诞节了。“双十一”和“双十二”都已告一段落,不知道你们剁了几只手?看到这篇文章,新浪微博的高级技术经理也分享了微博在多机房部署方面的一些心得和踩过的坑。接下来的文章,探讨了Docker 对于延迟的影响。
当你看到这期文摘的时候,应该是圣诞节了。“双十一”和“双十二”都已告一段落,不知道你们剁了几只手?当然,阿里巴巴的运维人员现在应该也松了一口气,可以出来讲讲他们的技术了。阿里巴巴技术保障部研究员毕玄,就跳出来分享了阿里巴巴高可用架构的演进史。看到这篇文章,新浪微博的高级技术经理也分享了微博在多机房部署方面的一些心得和踩过的坑。接下来的文章,探讨了Docker 对于延迟的影响。

最后,我们还提供了一本经典的数据库书籍下载:Readings in Database Systems ,希望大家喜欢。

最后的最后,祝大家圣诞快乐!
 

阿里巴巴实现高可用的三个步骤

本文来自阿里巴巴技术保障部研究员、互联网业界技术大牛毕玄,他探讨了阿里巴巴高可用架构的演进史。

开门见山,毕玄指出:

对于阿里的交易以及支付来讲,我们做异地多活最重要的目的除了灾备之外,更重要的点是追求持续可用,整个支付交易的体量对于用户来讲是持续可用。

接下来,他提到了常用的“两地三中心”做法,并指出阿里使用这种方法有三个问题:  

1、这个模式不一定Work。

2、异地备份中心因为不对外提供服务,所以整个资源会处于浪费状态,成本比较高。

3、对于阿里的规模来讲有一个很大的问题,在两地三中心中,数据一定是单点去写。

然后,他提到了阿里在高可用上经历的三个步骤。  

第一个是做了同城的双活,第二个做了异地只读及冷备,第三个是做了异地多活,经历了三代体系的演进才走到了今天。

在毕玄看来,阿里的“异地多活”的目标是:

1、需要多个跨地域的数据中心。

2、每个数据中心都要承担用户的读写流量。

3、多点写。

4、任意一个数据中心出问题的时候,其他中心都可以分钟级去接管用户的流量。

最后,毕玄列出了“异地多活”对于阿里的价值。  

第一、有极强的水平伸缩能力。

第二、异地多活怎么去应对故障。

金句:

某些地方用了两地三中心之后,当一地的数据中心出问题的时候,是不敢把流量切往异地的备份数据中心,原因是异地的备份数据中心是冷的,平时是没有用户流量进去的。如果要把流量切到那边起来之后,其实没有人有多强的信心能够保障起用以后是可以正常服务的,毕竟平时都是冷的。因为是冷的,就意味着整个起用的过程需要时间,不可能说起用就起用,一定会有时间周期。这是两地三中心的最大问题,看起来模式是很安全的,也是可用的,但是事实上不一定是这样。

标签:高可用、灾备、阿里巴巴
阅读原文
 

新浪微博的“异地多活”

新浪微博和阿里巴巴电商是两种完全不一样的应用场景,对比两篇文章,有异有同,还是蛮有意思的。

本文是新浪微博的研发中心高级技术经理刘道儒的分享,也是他看到上面阿里的文章后引发的感悟,主要提到微博在多机房部署方面的一些心得和踩过的坑。

刘道儒首先分享了微博异地多活从2010年以来的建设历程,然后,列出了这个过程中遇到的挑战:

  • 机房之间的延时
  • 专线问题
  • 数据同步问题
  • 依赖服务部署问题
  • 配套体系问题


下图,就是新浪微博的解决方案:

在考虑该解决方案时,新浪的考量有:

  • 能否整业务迁移
  • 服务关联是否复杂
  • 是否方便对用户分区
  • 谨慎挑选第二机房
  • 在数据层自身支持
  • 控制部署规模
  • 消息同步服务化

最后,刘道儒列出了新浪异地多活的新方向:

  • 升级跨机房消息同步组件为跨机房消息同步服务
  • 推进 Web 层的异地部署
  • 借助微服务解决中小服务依赖问题
  • 利用Docker提升前端快速扩容能力


金句:

由于几十毫秒的延时,跨机房服务调用性能很差,异地多活部署的主体服务必须要做数据的冗余存储,并辅以缓存等构成一套独立而相对完整的服务。数据同步有很多层面,包括消息层面、缓存层面、数据库层面,每一个层面都可以做数据同步。

配套体系的问题,技术上不是很复杂,但是操作的时候缺很容易出问题。比如,微博刚开始做异地多活部署时,测试同学没有在上线时对广州机房做预览测试,曾经导致过一些线上问题。配套体系需要覆盖整个业务研发周期,包括方案设计阶段的是否要做多机房部署、部署阶段的数据同步、发布预览、发布工具支持、监控覆盖支持、降级工具支持、流量迁移工具支持等方方面面,并需开发、测试、运维都参与进来,将关键点纳入到流程当中。


标签:高可用、灾备、新浪

阅读原文
 

使用 Docker 对延迟有哪些影响?

Azul System 是专门开发 JVM 运行时解决方案的公司,他们的CTO Gil Tene是 Docker 社区的

把口味和风格放在一边,重点谈谈对延迟的影响,从纯“机械”角度分析,是很简单的:Docker 使用 Linux 容器作为执行环境,没有 CPU 和内存在 OS 层面的虚拟化,会有一些 i/o 层面的虚拟化。

在CPU 和内存层面:Docker 的 CPU 和内存延迟特性跟 Linux 的分不开,但是影响 Linux 延迟行为的因素同样会影响 Docker。

在磁盘 I/O 层面:配置是影响延迟的最主要因素。任何跟存储的吞吐和延迟相关的问题,都会跳过虚拟化和磁盘虚拟卷,直接访问磁盘设备和加载点。

网络 I/O 层面:如果你需要某种有普适性,而且 NAT和桥接都有某些自动生成的网络部署,那就要注意网络延迟和吞吐方面的问题了。

金句:

Docker 的目的,不是要往一个机器里面打包进去太多东西。以客户OS 为单元的虚拟化也不是这样。当然,它们都可以这么用,但它们所能提供的最大优势,在于交付一种不变的、保存良好的配置,而且能在完全相同的配置上开发、测试、部署应用。这在后面会带来易于管理的部署和版本控制(包括回滚),还可以做一些有趣的事情,比如动态控制容量等等。当然,有些配置管理工具也可以在物理服务器上达成类似效果,但是可以把你完美运行的东西打包成一堆比特,而且可以“马上开机”,这是非常吸引人的。

标签:Docker、I/O、延迟

阅读原文
 

电子书下载:经典数据库“红书”最新第五版Reading in Database Systems 

在数据库领域, 主流数据库的奠基人 Michael Stonebraker 可以说是大师级的人物了。如果没有他在1992 年提出对象关系数据库模型,如今的数据库领域不知道会是什么样子。Michael Stonebraker教授在现代数据库系统的概念和实践方面做出的基础性贡献,跨越学术界和产业界,促成了数据库系统向产品的转变。“发明了几乎所有现代数据库系统所用的概念,创办了无数成功的数据库技术公司”可以说是他几十年研究生涯最好的总结。Stonebraker教授也曾担任过Informix的CEO,目前他是MIT麻省理工学院客席教授。2014年,他因为自己在现代数据库系统的概念和实践方面做出的基础性贡献,获得了图灵奖。

Reading in Database Systems 是 Stonebraker 教授和其他人合作完成的数据库论著,第一版诞生十年前,其宗旨是要为读者提供数据管理领域的经典文献,以及最新研究成果。第五版中就涵盖了自1988年来的12篇经典文献,如果你想纵深了解数据库的发展,又希望知道这个领域在未来的方向,这本书是不二之选。

来看看本书目录:

背景介绍

  1. 传统的关系型数据库管理系统
  2. 每个人都应该知道的技术
  3. 全新的数据库管理系统架构
  4. 大规模数据流引擎
  5. 弱隔离和分布
  6. 查询优化
  7. 交互分析
  8. 开发语言
  9. Web 数据
  10. 谈谈不断变化的复杂分析(Complex Analytics)
  11. 谈谈不断变化的数据整合(Data Integration)

金句:

阅读基础文献可以提供历史的大背景,让读者了解影响数据库解决方案的思考过程,确保我们的读者打下该领域的基础认识。

标签:数据库、分布式、经典

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

*|FORWARD|*