唯品会“简易”DCOS实践探讨【zoues.com】

声明:本文来自「又拍云主办的Open Talk——Docker与微服务架构实践」的演讲内容整理。PPT、速记和现场演讲视频等参见“ UPYUN Open Talk ”官网。

嘉宾:邱戈川,唯品会基础架构技术产品经理。

责编:钱曙光,关注架构和算法领域,[email protected],另有「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguangarch申请入群,备注姓名+公司+职位。

为什么需要容器化平台

目前唯品会做的是 容器化平台 ,为什么需要这么做?主要跟唯品会目前面临的问题有关。


唯品会经典的服务运行图

大家对唯品会的特卖模式,即早上10点和晚上20点的上新,应该并不陌生。从上面这张监控图中很容易看出,8点到12点这个时间段,客户的请求量非常大,之后请求量一直下降,一直持续到20点再次上新,流量才又开始增长。这里面出现两个问题:一个就是我们经常搞大促,这个量是平常8点到10点的几倍甚至几十倍,我们要支撑大量的资源来支持这个量。但是这个量没有了之后,剩下的资源我们该怎么办?大家可能会想,唯品会为什么不用公有云,这也是一个比较特别的原因就是数据安全,所以只能依赖于私有云。所以我们希望容器化能解决这个很容易出现的问题,即 支撑高峰和善用低谷

除此之外,唯品会目前还面临很多其他的问题:

  1. 整个运维思路比较简单,在部署方面基本上是单物理机,单进程模式——毕竟是要保持业务的稳定性,这是目前最大的约束。但是公司所有的物理机从机房上架、上电,网络开通等,整个流程消耗非常大;
  2. 资源利用率很低,整个体系的物理机CPU利用率平均还不到10%,在四个数据中心却有超过2万台物理机,这个量浪费非常大;
  3. 灵活性差,响应慢,我们要换一个硬盘很困难,效率很低、成本很高,这也是我们考虑容器化的一个原因。

所以现在我们需要打造下一代的管理平台,主要考虑以下几个因素:

  1. 能够分时段和分资源的方式使用,这样能够高效地利用资源;
  2. 唯品会现在是多数据中心,后面可能要考虑混合的数据中心,我们希望私有云或公有云的接入能做到快速部署、自动部署和严格隔离;
  3. 整个电商平台业务模式会因为支持多数据中心、混合数据中心变得非常复杂,不是纯粹的一个单体网站,后面涉及很多的流程和很多的模块,我们希望把它们有效地混合在一起。

当然大家很容易想到本文的主题,单就纯粹加一个Docker是否能完全解决这个问题?最大的问题不是Docker加进来就OK了,除了要用Docker引擎之外,还要考虑怎么做编排。我们需要做到把所有资源有机地编排在一起,做到弹性伸缩和灵活资源调度。

Docker容器、容器编排

现在的容器化平台是个很大的概念,那么我们要从概念模型上去看,我们到底选择什么样的平台,毕竟现在很多企业有很多不同的选择。

简言之,公有云可能是从虚拟机开始,私有云从物理机开始。如果你从物理机开始,一个物理主机拥有多个容器在跑,每个容器会含有单个应用(单进程),每台物理机会运行一组容器,每个容器管理一段IP。容器IP管理是个复杂的问题,后面会说到。

从选型上来看,我们的容器方案用的是Mesos+Marathon,如上图,这个选型的原因是什么?很多情况下大家可能会去选择Kubernetes,可以看下二者之间的对比。

因为我们是多数据中心,所以Kubernetes能不能支持还是一个疑问。另外,虽然Google做的东西比较好,但是有一个毛病,就是做到一定的程度就扔掉不管了。我们这么做选择,里面有很多特性的问题,但是现在包括Kubernetes自己在做很多类似的功能性拓展。Docker自己也在做,Swarm也是选择之一。至于选哪一种,就是萝卜青菜,各有所好了,大家自己要做好自己的业务分析。

把这几套体系做好选择是不是就够了?实际上你需要考虑的问题不单是这个,容器本身还要考虑的是数据中心的运营,如下图,要考虑的东西包括:

  1. 镜像管理和发布流程管理 :要不要做权限控制和分组,整个发布流程怎么管,应用上线怎么发放,发布流程很重要;
  2. 弹性管理和监控体系 :监控最大的问题是整个框架需要自己去搭建,这个是做容器化最大的一个能力考量,不像原来做物理机直接找个开源方案就搞定了;
  3. 网络管理和网络模型 :网络模型是搭建方案时最大的一个问题,而不只是简单地搭一个容器使用默认的NAT模式,这样整个方案的效率和延迟性是没法接受的。后面我会讲一下唯品会的容器网络模型。

再强调一遍,整个容器化平台是一个体系,不要单纯地选择一个Docker引擎,希望大家做方案的时候一定要考虑清楚体系怎么搭建。

上图是我们目前整个体系的架构,里面我就不细讲了,从下面开始看,首先是整个物理机集群的调度,然后是容器的调度。除此外我们还要有相应的管理体系,包括我们自身还有运维等,每个模块都需要考虑到,可以做简单,也可以做复杂。

关键技术点

首先我们看下资源层的模型,也是从物理机器开始,把所有的物理资源后者云主机认为是一个池子,如下图:

在搭建整个物理资源时,每个物理资源每一台服务器会有一个IP段,作为容器的管理,我们要做好相应的网段管理,要把所有的网络规划做好。

对于物理资源,我们用PC的服务器方式做,从管理上讲,会有自己的CMDB的管理体系,根据不同的方式分不同的业务,业务分不同的主机,主机管不同的容器,这个模型比较简单,实际上我们也是这么做的。

对于整个网络,目前还是以最简单VLAN的方式做,当然也可以用很多开源的方式做,但是稳定性和可靠性是一个比较大的麻烦。

从管理上讲,大二层的网络方案有一定的风险,毕竟整个交换机管VLAN的总数是有限的,包括网络ARP包的量也比较大,但在没有达到大规模的时侯可以先不去考虑,所以我们基本上不需要任何管理系统,直接用交换机给每台主机分一个段,这里面有另外一个问题,就是整个IP的分配都是由Docker引擎去做。这种方式最大的问题是怎么去分配这个IP,你的IP段分给了Docker引擎之后,如果现在一台主机上有16个IP,但是只有5个容器,那有11个IP是浪费的,但好处是管理上会非常简单。

容器调动机制有利于Mesos+Marathon,用自己的发布系统来管理,会把所有容器的发布通过发布系统触发方式去做,剩下的就是利用Marathon把整个的容器集群调度起来。

容器的执行,基本上是依赖于整个Docker容器的方式去做,但这个Mesos最新版可以把Docker引擎去掉,我们目前还不想这样去做,我们还得用Docker引擎去帮助我们管理IP分配。

镜象机制大家都比较清楚了,我就不讲这个原理了。唯一做的不太一样的地方是我们倾向于单个镜象,单进程;我们不倾向于一个容器里有多进程,如果你有多进程,而你的主进程并不是在启动进程,那很可能在管理上会很复杂,因为其他进程死掉的时候,Marathon实际上根本不知道。这是我们当时遇到的一个坑,所以我们想了很多办法,应用全部拆成单进程的方式去做管理。

这是我们的一个物理主机的情况,实际上是说一个容器会做纯粹的单IP,单进程,因为IP走的是二层的网络,所以IP的互通在交换机里做好了,不需要做很多的网络转换。为了监控我们自己的应用,我们会在物理主机上部属很多辅助的容器。

容器存储,目前我们存储的方式还是选择本地存储,现在只是跑应用,还没有很好地跑数据或跑大数据的应用,目前只是用到本地存储,通过卷挂载的方式去使用物理机的本地存储。

资源的隔离,很多的业务体系希望不同的业务体系只跑那一类的业务,希望它们不要有冲突,你在网站上看到购物车是一个体系,物流是一个体系,另外我们希望可以支持多数据中心。这个都是通过Mesos的分组方式支持。

之前提到的监控实际上是很大的一块,所以整个容器要为整个公司去考虑你的监控体系,去监控容器的CPU、NET、IO。目前唯品会的整个网络层体系是这样的:应用层有自己的监控体系,我们把它叫作Mercury,这是我们自己做的业务层监控,Mercury是调用链的监控,业务层主要是Telescope。大家需要自己去考虑自己的方案。目前也有不少开源的选择。

唯品会的容器化管理,基本上涵盖几个大块,一个是刚才说的监控,另外就是整个弹性的伸缩,弹性伸缩这一块,我们目前用比较简单的做法,实际上是通过Jenkins的方式,固定时间把某些应用的容器的实例给缩下来或扩展上去。

  • 版权声明: 本文源自互联网, 于3个月前,由整理发表,共 3389字。
  • 原文链接:点此查看原文