UDN-企业互联网技术人气社区

板块导航

浏览  : 1215
回复  : 0

[技术交流] 新浪公有云Docker编排实践(上)

[复制链接]
htmlman的头像 楼主
发表于 2016-7-14 10:57:56 | 显示全部楼层 |阅读模式
  本次分享主要是分为四个部分:

  • 微博的业务与混合云;
  • 业界趋势与DCP技术架构;
  • 弹性调度;
  • 混合云三节实战;

  下图展示的微博业务规模:
2.png

  从图中可以看出,微博用户日活跃1亿,接口访问量百亿级,设备数量W+,所以每一次的技术升级对于我们都是很大的一个挑战。

  目前微博的用户访问特点基本上分两种:

  春节峰值流量会是平时的两到三倍。如果为春晚花掉上千万来采购设备,将是一笔很大的开销。

  娱乐事件。突发事件是我们无法来预料,也是我们无法预先准备的。
2.png

  如上图右上角所示,10分钟之内数据流量呈现出3到4倍的增长,假如我们技术平台内部是2000台的服务器,对于Web服务器来说,就需要10分钟之内扩容4倍,才能承受住流量激增的冲击。2014年微博已经做了容器化,当时只是一个私有云的建设。但是如果流量增加到3到4倍的时候,之前的技术是解决不了现在这种状况的,可无可扩。所以我们面临的一个问题就是,如何在10分钟之内完成1000个节点的扩增。

  上图下方显示的是我们公司内部项目评审及设备申请的流程,此流程耗时可能长达两个月,无法及时应对刚才所提到的峰值问题。

  目前主要的痛点基本上就是极端峰值、成本、扩展性以及业务加速迭代,这些给我们提出了更高的技术要求。今年开始我们参考了业界的混合云趋势,比如安全、可扩展性、成本等方面。此外,国外的Zynga、Airbnb、Yelb以及国内的阿里云、12306、高德等公司都在用容器技术来解决问题。Docker、Mesos等容器新技术使大规模调度成为可能。

  下面简单介绍下12306的案例。基于与阿里云的深度合作,我们了解到12306主要查询流量余票查询业务都放在阿里云上,但是其数据是会经过大约几分钟后才会更新,所以大家在12036上看到的余票数量可能是不准确的。火车购票用户可以容忍这种情况,但是对于微博的用户,用户发一条微博出来,不可能几分钟后才让大家才能看到,所以这对实时性提出了更高的要求。
2.png

  微博混合云涉及到公有云和私有云,2014年微博平台实现平台容器化,建立一个共享、安全,资源整合的私有云,2015年利用公有云的高效和低成本,开始混合云方案。我们之所以选用公有云,可以通过算一笔帐来探究一下,如果我们在10分钟之内需要1000台机器,阿里云支持按量来付费。假如说一台机器每小时4块钱,我们需要1000台机器,一个小时需花费4000块钱。如果我们采购1000台机器,成本可想而知。使用公有云, 在一定范围内可以认为是无限扩容的。基于网络方面,阿里云内部是VPC网络,会为每个业务方创建一个内部的私有网络,微博与阿里云之间实现两个专线的连通,实现了网络互通。整个混合云分两个部分,一个是快速弹性调度,另一个是基础设施跨云。
2.png

 上图是微博DCP系统技术架构的演进历程。第一阶段是容器化,2014年我们做了单机容器化、在线Docker集群。第二阶段是私有云,我们用的是弹性调度,然后是基于弹性调度的服务发现以及私有云的建设。第三阶段是混合云,我们把公司离线资源接入,和公司资源进行整合,多种资源管理调度框架整合,实现了跨云端的调度。
2.png

  上图是一个基本的混合云DCP技术架构图,它来源于Docker的三架马车,分别是编排、调度以及主机。编排系统Jpool发起,比如上线发布、回滚等各种命令。比如现在想要获取1000个节点的容器信息,向调度层进行申请,调度层向Docker进行下发命令,然后获取容器信息。基础环境在底层Pluto系统偏主机层,它的主要作用是和阿里云主机进行打通、计算成本,最重要的是进行初始化,初始化之后首先会安装Docker环境,包括Swarm、Mesos,之后这些机器进入一个可调度的状态,底层通过一个专线,保证阿里的机房和我们的机房进行互通。当然除了Docker这三架马车体系之外,还离不开一些服务发现、镜像中心、监控中心、容量评估等。
2.png

  上图是我们的技术栈,主机或VM主要是私有云裸主机,公有云VM,在上面进行Docker的具体化;OS方面,线上90%的业务已经升级到CentOS 7.0;Docker版本是1.6.2,之所以还在选用Host模式,微博访问流量量非常大,选用其他模式导致我们的系统性能有所下降,所以我们选择Host模式。Iptables我们也是关闭的,因为打开它之后会影响性能。Docker Registry方面,我们构建了自己的仓库,有V1、V2的版本,实现分布式跨IDC动态同步。Swarm版本是1.0.0。部分小规模的服务用Marathon是进行调度。所有的服务发现基于Consul的,Consul的版本是0.6.0。
2.png

  上图显示的是混合云DCP功能模块,基本上分为PaaS、IaaS和基础框架。容器技术虽然解决了我们快速发布问题,但是如果要真正解决峰值流量的问题,还需要建设完整生态体系。
2.png

  下面简单介绍一下DCP的核心思想,2014年的时候只有微博平台内部进行了Docker化,微博的业务是这样的,用户用电脑刷微博的时间集中在中午,晚上用户大都用手机刷微博,而且在凌晨的时候,我们的离线机又开始忙了。每个部门每个时段,它的机器会有空闲的状态,如何把这些空闲的机器利用起来,设计共享池机制,评估它的容量压测,比如根据一些系统指标还有一些SLA的情况判断,如果机器空闲自动进入这个共享池状态,进入共享池就代表是可供调度的状态,共享池的机器可供动态调度。DCP整体的模式是基于银行的运作机制。
2.png

  上图是容器的一个生命周期。以私有云为例,当某一部门的机器空闲的时候,它进入共享池,代表这个机器可以用,这个机器进入共享池之后进行初始化,初始化之后按照上图下方所示,Docker环境或者是机器环境启动,代表容器可以进行动态调度,直到容器上线。中午不繁忙的时候,容器进行下线再返回共享池。
2.png

  简单举个例子来说,比如此时需要机器,原来共享池里面ABCDE各个业务方空闲都共享给共享池,根据容量评估这时容器可以下线,然后利用资源进行动态扩容。当不需要机器的时候,归还共享池。
2.png

  整个流程其实可以模拟成这样:首先是主机申请,包含内网申请和云端申请。内网申请相当于在共享池里面申请,但是内网会出现一种情况,假如平台有2000台机器,当出现5倍或者10倍流量增长的时候,扩无可扩的时候,则进行云端申请。拿到主机之后进行初始化,初始化的时候主要安装两个环境,一个是系统环境,一个是Docker环境,Docker环境大家都理解,肯定要把Docker装上,容器才能运行,成为可动态调度的模式。为什么还要装系统环境?任何一个公司的产品、任何一条业务线,业务跑到一个真正全新的主机上,肯定有自己的系统环境或者各种各样的配制、脚本等。我们系统初始化的时候,其实是按照业务方进行选择,业务方用各自的模板来初始化。基于初始化之后,可以进入动态调度的阶段,然后使用算法实现动态调度。比如申请了1000台机器,容器上线之后,再调度上面的服务发现策略(Nginx、Motan、SLB),然后进行反初始化,归还Buffer池、结算中心。刚才提到按小时算的成本,按小时每小时4块钱,还是赶快归还比较好。
2.png

  上图为主机申请的流程。阿里云在北京有三个机房,每个机房据介绍有万+台机器,用户可以选择可用区域,然后选择交换机确定IP端,选择VPC网络,VPC网络可认为自己独立的私有网络。选择操作系统VM镜像,刚才提到初始化的时候,有Docker环境,在整个环境动态扩容的过程中,动态调度的要求几十秒内完成。比如我有2G的镜像,还有70M的JDK,千台节点拉这么大镜像镜像仓库、网络带宽都是很大调整,这时候要怎么办?所有的云产品每隔6小时,把所有的系统VM镜像进行备份,比如我所有的镜像拉下来之后,包括Docker都放在云盘上,相当于一个备份,比如说下次创建主机申请的时候,选择已经做过的镜像,在这个操作系统上的镜像创建机器,这样基础镜像就在VM镜像上面,这样大大缩短了拉镜像时间。最后选择机器配制,选了主机配制之后初始化进行动态调度。初始化是其实基于Ansible,因为阿里云提供的是SSH访问,Ansible会有性能问题,在Ansible使用过程中我们做了优化,提高其性能。下图系统环境装了dnsmasq、ntp、cron等,软件环境安装了Docker、Swarm、Consul。

原文作者:付稳 来源:Docker


  新浪公有云Docker编排实践(下)

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部