May 9

琥珀离线系统(基于Docker设计思路) 不指定

djangowang , 16:00 , 工作相关 » Docker , 评论(0) , 引用(0) , 阅读(923) , Via 本站原创 | |
开篇
     “古巴比伦王颁布了汉摩拉比法典,刻在黑色的玄武岩,距今已经三千七百多年,你在橱窗前,凝视碑文的字眼,我却在旁静静欣赏你那张我深爱的脸……”,想必大家都听过这首周杰伦演唱的《爱在西元前》,由方文山填词,歌词生动美妙不落俗套。作为周杰伦的御用作词人,方文山其实只有高中学历,但他才华横溢,创作了不少经典之作,有些作品甚至被收录进了学校的课本中。那么他是如何写出这么美妙的歌词呢?直到看了他的访谈笔者才了解到其实他的歌词大多来源于生活中的灵感,这首《爱在西元前》就是他在某日逛完博物馆后有感而发,他从现实的场景获得灵感再进行文字加工,从而文思泉涌,妙笔生花。其实运维工作也亦然,需要我们时时从工作中寻找灵感。笔者从事运维工作接近8年,多年的工作经验总结出一个道理:我们要善于从运维工作中发现问题,并根据问题及过往经验发明创造改进工具,接着再从发明创造中提炼技术,最后根据技术提炼原理。近来以Docker为代表的容器很火,很多互联网公司都在使用。那么Docker是如何获得互联网公司的青睐的,我们又应该如何来应用Docker,本章将从以下几个方面逐一介绍:
 我们为什么使用Docker
 离线系统业务架构
 Clip名字服务
 Clip名字服务与Docker应用场景



我们为什么使用Docker
     首先来看一下我们在运维中发现了哪些问题。以笔者就职的腾讯公司案例为例,腾讯产品战线很长,笔者所在的团队负责运维腾讯的QQ、Qzone等核心产品,而这些产品也算是中国互联网骨灰级的业务了,整体架构都有着复杂的历史背景。不仅团队的老员工发现架构逐渐产生的问题,团队新入职的同事也会指出与原任职公司比较架构存在的一些问题等等。如何将很多好的技术融入到我们的业务架构中,以解决产品的问题是摆在每一个运维架构师面前的难题。架构的复杂性与历史沉重的包袱决定着牵一发而动全身,并且架构支持的业务为近半数的中国互联网网民所使用,还有着不少的优点,在对其进行改进优化之前,我们主要先分析了它的优缺点:
  优点:目前还是单机或单集群对应一个业务模块的形式,彼此间没有交集与复用(见图1),其架构优势应对爆发式增长扩容方便,成本结算简单,架构形成的历史原因更多的是前者流量的爆发增长。
点击在新窗口中浏览此图片
图1
  缺点:随着网民的饱和,相同业务模块下移动流量上涨,PC流量直线下降,很多业务出现了低负载情况。海量服务器的运维场景中即使只有1%的低负载规模也是惊人的,在实际运营中低负载+长尾业务下的机器数量可能达到了25%-30%甚至更高。当然这里不排除业务对流量做了冗余与灾备,但是多个业务模块的灾备就会出现浪费资源的情况。除低负载与长尾业务外,为了应对业务的流量徒增团队为产品留出了足够富裕的Buffer资源以应对某业务徒增,而导致这些资源的实际利用率不高。

分析了优缺点后以及运营中发现的这问题后,从2014年中我们就开始着手离线业务混合部署项目。项目的思路是通过高负载业务譬如音频转码、视频转码、图片人脸计算和图片特征提取业务(注:后统称“离线业务”)与低负载、长尾业务和部门buffer业务进行混合部署,来提升机器利用率并同时为部门节约机器成本。不过经过半年多的运营,我们也发现了很多问题:
  在低负载与长尾业务上部署离线业务,如果离线业务抖动出现大的CPU毛刺(特别在晚高峰时段)就会影响用户的使用体验,从而导致部分投诉产生的情况。
  部署在buffer池上的离线业务,由于在线业务申请机器导致机器上的离线环境没有及时清理,继续运营影响在线业务的正常使用。
这两个问题比较有代表性的问题也是我们最不希望看到的,所以总结经验教训后在2015年上半年我们又重新打磨项目开发了新版离线系统,新项目与老项目相比通过Docker技术将离线业务与在线业务的低负载、长尾业务和Buffer池进行了部署,从而顺利解决了上述的问题。这里主要利用了Docker的三个优势:
  Cgroup对资源的隔离让离线与在线业务彼此间对资源使用有了保障;
  命名空间,让相同框架多业务跑在相同物理机上成为可能;
  容器的快速回收上线下线,使用Buffer资源时不再为回收离线资源而头痛。



离线系统业务架构
上文中笔者提到QQ、Qzone的整体架构着很复杂的历史背景,而希望仅仅通过Docker或一两种工具来解决现实存在的所有问题是不现实的,所以我们在保持现有架构与内部用户习惯的基础上另辟蹊径逐渐解决我们产品运营上的一些问题,具体部署见图2。
点击在新窗口中浏览此图片
离线系统业务架构(图2)

从图2中可以看到在部门Cmdb基础之上,我们建立了数据分析系统,通过它可以分析出哪些是低负载业务,哪些是时段低负载业务。在此基础之上我们使用Clip名字服务系统在Cmdb基础之上重新建立了业务之前的IP关系,并根据重新划定关系的IP进行了业务流量与资源快速的调度。其中Etcd为服务发现工具,根据Clip名字服务系统传入的信息通过Confd重新生成HAproxy的配置文件并热重启它,离线业务流量通过HAproxy的虚拟IP屏蔽底层资源信息,建立离线与资源的生态供应链,同时上层监控与调度均为Clip名字服务系统。这里读者有可能会有疑问,尽管HAproxy的虚拟IP屏蔽底层资源信息(其为动态的),但如果程序有问题,如果能快速到机器上去debug自己的程序呢? 这里我们使用的是Clip名字服务。




Clip名字服务
Clip(http://blog.puppeter.com/read.php?7)是一个名字服务C/S架构,它将传统的IP管理维度替换为名字服务即有意义可记忆的String。Clip将IP对应的String关系保存在Server端。Client端可以下载SDK,通过SDK遍历Server端的String对应IP的关系,并在本地对获取的IP模块关系进行重新的组织与编排。传统服务器IP方式与String方式相比,String方式有3点优势:
  传统IP管理方式,IP由4组无意义的数字组成,比较难记忆。String更方便记忆;
  管理海量服务时,IP相似经常会导致运营故障,譬如A模块(10.131.24.37 )和B模块(10.117.24.37),后两组数字一致,系统惯性的认为B模块就是A模块,发送配置导致线上故障。通过string管理方式可以规避此问题;
  String 可以解析1个IP,也可以解析一组IP ,根据IP也可以反解析String对应关系,使得管理一组服务更加方便。
    Clip中的String由四段(字段含义idc-product-modules-group)组成,读者会发现String与Cmdb的结构很像:四级模块定位一个服务。但是为了充分利用资源我们的业务要求一个IP可能要对应多个服务,不同的服务有自己的波峰与波谷,在相同的IP上只要保证各业务的波峰不重叠就满足了业务的需求,也充分了利用资源。而在一台服务器上混合部署不同的业务模块,四级模块就只能定位到服务的IP级别,而无法精确定位到真正的服务,所以Clip名字服务在Cmdb的基础上增加了port端口,即五段(字段含义idc-product-modules-group-port)定位一个服务。我们可以将动态的IP通过Clip接口注册到指定含义的String上,通过Clip自带工具来解析实时的String对应IP关系,譬如:

# clip cstring -q idc-product-modules-group-port
192.168.0.1
192.168.0.2
192.168.0.3
192.168.0.4
192.168.0.5

Clip数据存储结构分为两层:
关系层保存了String对应IP或内部系统Cmdb的模块关系(见图3)。
点击在新窗口中浏览此图片
Clip名字服务关系表(图3)
关系层数据含义见表1
点击在新窗口中浏览此图片
关系层数据含义表1
数据层保存了String与IP的具体关系(见图4)。
点击在新窗口中浏览此图片
Clip名字服务数据表(图4)
点击在新窗口中浏览此图片
Clip名字服务在存储String对应IP关系基础上,在SDK上还提供了远程端口扫描、远程ssh、远程文件拷贝和查找String关系结构的工具子命令等,更多可以见http://blog.puppeter.com/read.php?7。




Clip名字服务与Docker应用
如笔者上文所提,离线系统的建设思路就是将离线业务通过Docker快速的部署在资源空闲的机器上,而空闲的机器是通过数据分析系统长期分析沉淀的结果,Clip名字服务就是这两种资源建立联系的桥梁,但只有Clip绑定关系还是不够的,还需要建立绑定关系String对应Docker环境的关系,所以在Clip名字服务的基础上我们又扩充了Docker的资源关系表。
点击在新窗口中浏览此图片
Docker资源关系表图5
其中Docker资源使用的关系表的字段含义见表3:
点击在新窗口中浏览此图片
我们来看一个需求案例:某视频转码业务在上海需要使用资源约1000核心,对应的关系表为表4
点击在新窗口中浏览此图片
由于buffer资源不时在变动,我们需监控String (sh-buffer-qq-video-2877)整体核数是否低于mcount值,如果低于则出发自动扩容策略。同时也需针对Docker资源使用关系中的app_port字段来监控整体String (sh-buffer-qq-video-2877)业务是否处于健康状态。在这里我们沉淀了String (sh-buffer-qq-video-2877)的一些基础数据如负载、内存、网络和磁盘IO等为资源的调度奠定的基石(见图6)。
点击在新窗口中浏览此图片
离线运营系统图6
Tags: , ,
发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]