基因:善•感恩•爱•奉献

本文由高磊在高可用架构群所做的分享整理而来。转载请注明高可用架构公众号ArchNotes。

使命:帮助每一位后MBA/EMBA成长

愿景:成为最有价值的学习分享和资源整合的平台

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图1)
高磊 雪球运维架构师。2012年主持研发和运维 Redis 集群等分布式系统,专注于中小型公司运维架构和运维体系建设,目前在雪球负责技术保障工作,在Docker容器及其周边生态系统积累了大量一线经验。

宗旨:同修共赢和谐快乐

本次分享主要聊聊创业公司在实践Docker方面的一些经验,内容分为以下六个部分:
一、背景介绍
二、容器选型
三、应用迁移
四、弹性扩容
五、未来规划

六、Q&A

2016年3月25日,由北大纵横后MBA学院五期金融班的班长项峻峰担任合伙人的创业项目——中国诚信经营AAA级示范企业安润金融正式成为中国互联网金融协会创始会员;

一、背景介绍

雪球(http://xueqiu.com) 是一家涉足证券行业的互联网金融公司,成立于2010年,去年获得C轮融资。雪球的产品形态包括社区、行情、组合、交易等,覆盖沪深港美市场的各个品种。

与传统社交网络的单一好友关系不同,雪球在用户、股票基金及衍生品、组合三个维度上都进行深度的相互连接。同时雪球的用户活跃度和在线时长极高,以致我们在进行技术方案选型和评估的时候必须提出更高的要求。

目前雪球的 DAU 为1M,带宽为1.5G,物理机数量为200+,云虚拟机数量约50个。雪球采用了 Docker 容器作为线上服务的一个基本运行单元,雪球的容器数量近1k。

二、容器选型

我们的服务面临的操作系统环境大致有五种:物理机、自建虚拟机、云虚拟机、LXC 容器、Docker 容器。

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图2)

(安润金融首席风险官郭建彩在会议现场)

中国互联网金融协会是在2014年4月3日正式获得国务院批复,由中国人民银行、银监会、支付清算协会、证监会等牵头组建,由央行条法司、银监会惠普金融部牵头筹建,被公认为是首个国家级别的金融管理协会。协会旨在制定行业规则,强化互联网金融监管,同时积极促进行业自律,引导和支持互联网金融从业机构完善管理、守法经营。

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图3)
(图1)

我们主要的考虑的选型指标包括“成本”、“性能”、“稳定性”三个硬性基础指标,以及“资源隔离能力”、“标准化能力”、“伸缩能力”这几个附加指标。

中国互联网金融协会对网贷平台的审核十分严格,细化的要求是,申请入会的P2P平台必须近三年未发生重大违法违规事件;经营互联网金融业务的网络平台在电信主管部门备案;在经营期间未出现过重大经营事故或重大违约事件;股东和管理层无不良记录且具备一定的金融知识和从业经验。

这五类操作系统环境在雪球的实践如下:

安润金融成立于2014年2月,公司总部位于北京,已在全国十余省份设立分公司及办事处。此次安润金融能够成为中国互联网金融协会创始会员,和安润金融拥有优秀的核心团队、领先的风控体系、先进的科技水平、顶尖的合作伙伴以及卓越的企业文化有很大的关系网络科技;区别于多数同业平台,安润把风险管理作为企业的发展基石,在优秀风险管理能力的保障下深入金融模式创新,最终以向广大客户提供最专业、最安全、最便捷的金融服务为自身终极目标。

        值得注意的是,在2015年1月24日,首届北大纵横后MBA论坛在冰城哈尔滨开幕并成功举办中国好项目PK赛,在现场比赛环节,安润金融CEO对安润金融进行了路演,对公司愿景、商业模式、核心竞争力、企业文化等做了精彩阐述,获得了全场一致好评。在现场PK赛的第一轮便以综合评分前四的成绩进入六强,之后经过六进三等几轮残酷的角逐选拔,最终荣获北大纵横后MBA第一届创业大赛的冠军。

荣誉既是鞭策,未来,安润金融将一如既往地发挥自身的价值,与中国互联网金融协会其他会员互相学习、共同进步,为整个网贷行业健康发展最大化地贡献自己的力量;同时安润金融愿意为北大纵横后MBA的校友们提供多方面的金融支持和服务,安润金融的大门也永远向每一位希望在互联网金融领域做出成就的北大纵横后MBA的校友们敞开。

文:项峻峰

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图4)(图2)

后MBA班级:5期班

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图5)

如果喜欢本文不要忽视您的”点赞“功能哦三、应用迁移

我们 SRE 团队借助 Docker 对整个公司的服务进行了统一的标准化工作,在上半年已经把开发测试、预发布、灰度、生产环境的所有无状态服务都迁移到了 Docker 容器中。

雪球借助 Docker 对服务进行的标准化和迁移工作,主要是顺着 Docker 的 Build -> Ship -> Run 这三个流程进行的。同时在迁移过程中填了许多坑,算是摸着石头过河的阶段。

我们首先设计了自己的 Docker Image 层级体系。在 Base 这一层,我们从 ubuntu-upstart 镜像开始制作 base 镜像。

这里做了动静分离,静态的部分(static.sh 和对应的 static 文件)和动态的部分 ( runtime.sh ) 都会被添加进 base 镜像,静态部分会在构建 base 镜像过程中被执行,而动态部分会在启动 project 镜像的过程中被执行。详情如下图所示:

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图6)
(图3)

其中静态部分我们更推荐灵活的使用 shell 脚本来完成多个基础配置,而不是写冗长的 Dockerfile。下图是一个很好的对比,左面是gitlab官方的dockerfile,右面是我们的动静分离实践。

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图7)
(图4)

然后基于 base 镜像,我们又添加进入了 JDK、NodeJS 等运行环境,并在JDK的基础上进一步构建了 Resin 镜像。

在上述镜像中再添加一层业务执行代码,则构成了业务镜像。不同的业务镜像是每个业务运行的最小单元。

在雪球我们大力的推进了服务化,去状态。这样的一个业务镜像就具备了迁移部署、动态伸缩的能力。

需要提醒的是 docker build 镜像的过程中会遇到临时容器的一些问题,主要涉及访问外网和dameon能力。

Docker 构建这块就跟大家分享这么多。接下来咱们聊聊分发这一步。

分发的过程痛点不多,主要是 Registry 的一些与删除相关的 Bug、Push 镜像的性能,以及高可用问题。

而本质上高可用依赖于存储的高可用。在雪球我们使用了硬件存储,接下来计划借助 Ceph 等分布式文件系统去解决。

说完分发,我们谈谈运行这个环节,Docker 运行的部分可以探讨的内容较多,这里分为网络模型、使用方式、运维生态圈三部分来介绍。

绝大多数对 Docker 的网络使用模型可以汇总为三类:bridge(NAT)、bridge(去NAT)、host。

Docker 默认的桥接是用的第一种 NAT 方式,也即是把命名空间中的 veth 网卡绑定到自己的网桥 docker0。然后主机使用iptables来配置 NAT,并使用 DHCP 服务器 dnsmasq 来分配 IP 地址。

在雪球我们对 Bridge 模式去掉了 NAT,也即把宿主机的 IP 从物理网卡上移除,直接配置到网桥上去,并且使用静态的 IP 分配策略。

据了解,有好多其他公司在自己的IDC机房中也是采用了去NAT的桥接模式,这样的好处是 Docker 的 IP 可以直接暴露到交换机上,性能最高。

而端口映射方案不容易做服务发现,雪球并没有使用。

其中去 NAT 的 Bridge 模式需要在宿主机上禁用 iptables 和 ip_forward,以及禁用相关的内核模块,以避免网络流量毛刺风暴问题。

说完网络,我们看下一些使用场景。

我们在 docker run 的时候通过 —mac-address 传入了静态 MAC 地址,并通过前述 runtime.sh 在运行时修改了 docker 的 eth0 IP。其中计算 MAC 地址的算法是:

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图8)
(图5)
同时我们按照雪球统一的运维规范在运行时修改了容器 Hostname、Hosts、DNS 配置。

在交互上,我们在容器中提供了 sshd,以方便业务同学直接 ssh 方式进入容器进行交互。

Docker 原生不提供 /sbin/init 来启动 sshd 这类后台进程的,一个变通的办法是使用带 upstart 的根操作系统镜像,并将 /sbin/init 以 entrypoint 参数启动,作为 PID=1 的进程,并且严禁各种其他 CMD 参数。这样其他进程就可以成为 /sbin/init 的子进程并作为后台服务跑起来。

然后跟大家介绍下我们在 docker 周边做的一些运维生态圈。

首先我们对容器做了资源限制。一个容器默认分配的是 4core 8G 标准。

CPU 上,我们对 share 这种相对配额方式和 cpuset 这种静态绑定方式都不满意,而使用了 period + quota 两个参数做动态绝对配额。

在内存上我们禁用了 swap,原因是当一个服务 OOM 的时候,我们希望服务会 Fast Fail 并被监控系统捕捉到,而不是使用 swap 硬撑。死了比慢要好,这也是我们大力推进服务化和去状态的原因。

对了,顺便提一下 docker daemon 挂掉,或者升级,我们也是靠应用层的分布式高可用方案去解决。只要去掉状态,什么都好说。

在日志方面,我们以 rw 方式映射了物理机上的一个与 Docker IP 对应的目录到容器的 /persist 目录,并把 /persist/logs 目录软连接为业务的相对 logs 目录。这样对业务同学而言,直接输出日志到相对路径即可,并不需要考虑持久化的事宜。这样做也有助于去掉 docker 的状态,让数据和服务分离。

日志收集我们在 java 中使用 logback appender 方式直接输出。对于少数需要 tail -F 收集的,则在物理机上实现。

在监控方面,分成两部分,对于 CPU、Mem、Network、BlkIO 以及进程存活和TCP连接,我们把宿主机的 cgroup 目录以及一个统一管理的监控脚本映射到容器内部,这个脚本定期采集所需数据,主动上报到监控服务器端。

对于业务自身的 QPS、Latency 等数据,我们在业务中内嵌相关的 metrics 库来推送。不在宿主机上使用 docker exec API 采集的原因是性能太差。据说 docker 1.8 修过了这个 docker exec 的 bug,我们还没有跟进细看。

以上是我们在上半年的一些工作,主要方向是把业务迁移入 docker 中,并做好生态系统。

四、弹性扩容

大家知道上半年时,股市异常火爆,我们急需对业务进行扩容。

而通过采购硬件实现弹性扩容的,都是耍流氓。雪球活跃度与证券市场的热度大体成正相关关系,当行情好的时候,业务部门对硬件资源的需求增长是极其陡峭的。

在无法容忍硬件采购的长周期后,我们开始探索私有云+公有云混合部署的架构。我们对本地机房和远端云机房的流量请求模型做了一些抽象,如下:

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图9)
(图6)
我们把服务栈分为接入层、服务层、数据层三层。

第一个阶段,只针对接入层做代理回源,目的可以是借助公有云全球部署的能力实现全球就近接入。

第二个阶段,我们开始给远端的接入层铺设当地的服务层。演进到第三个阶段,远端的服务层开始希望直接请求本地数据。

这里比较有趣的一点是,如果远端服务是只读逻辑,那么我们只需要把数据做单向同步即可。

如果要考虑双向同步,也即演进到第四个阶段,也即我们所说的双活。

其中不同机房之间的流量切换可以使用 DNS 做负载均衡,在雪球我们开发了一套 HTTP DNS 较完美的解决此问题。

目前雪球的混合云架构演进到第三个阶段,也即在公有云上部署了一定量的只读服务,获得一定程度的弹性能力。

在公有云上部署 Docker 最大的难题是不同虚拟机上的 Docker 之间的网络互通问题。我们与合作厂商进行了一些探索,采用了如下的 Bridge (NAT) 方案。

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图10)
(图7)

这本质上是一个路由方案。首先虚拟机要部署在同一个 VPC 子网中,然后在虚拟机上开启 iptables 和 ip_forward 转发,并给每个虚拟机创建独立的网桥。网桥的网段是独立的 C 段。最后在 VPC 的虚拟路由器上设置对应的目标路由。

这个方案的缺点是数据包经过内核转发有一定的性能损失,同时在网络配置和网段管理上都有不小的成本。

庆幸的是越来越多的云服务商都在将 Docker 的网络模型进行产品化,例如据我们了解,阿里云就在向 docker 提交 docker machine 的 driver。

除了路由方案外,另一个方案是隧道方案。也即铺设 ovs 之类的 overlay。

但是,在公有云上本来底层网络就是一层 overlay,再铺设一层软件 overlay,性能必然会大打折扣。

我们最希望的,还是公有云自身的 SDN 能够直接支持去 NAT 的 bridge。

当使用 Docker 对服务进行标准化后,我们认为有必要充分发挥 Docker 装箱模型的优势来实现对业务的快速发布能力,同时希望有一个平台能够屏蔽掉本地机房与远端公有云机房的部署差异,进而获得跨混合云调度的能力。

于是我们开发了一套发布系统平台,命名为 Rolling,意喻业务系统如滚雪球般不断向前。

在此之前,雪球有一套使用开源软件 Capistrano 构建的基于 ssh 分发的部署工具,Rolling 平台与其对比如下:

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图11)
(图8)
大家可以点开图细看下,Rolling 帮助我们解决了非常多的痛点。像编译时机、环境干净程度、代码验证、版本控制,等等。

Rolling 的上下游系统如下图所示:

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图12)
(图9)

下面截取了几张 Rolling 平台在部署过程中的几个关键步骤截图

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图13)
(图10)

上图显示了 Rolling 在部署时的第三个步骤:资源选择。目前雪球仍然是靠人力进行调度配置,接下来会使用自动化的调度工具进行资源配置,而 Rolling 已经赋予我们这种可能性。在真正开始部署之后,还有一键暂停、强制回滚、灰度发布的功能。

【后MBA创业项目】 安润金融成为中国互联网金融协会创始会员互联网金融创业公司Docker实践(图14)
(图11)

上图显示了某业务在使用 Rolling 部署后的运行状态。

Rolling 平台的带来的质变意义有两方面:

其一从运维同学的角度,Rolling 使得我们对服务的调度能力从静态跃迁为动态。而配合以大力推进的服务去状态化,Rolling 完全可以发展成为公司内部私有 PaaS 云平台的一款基石产品。

其二从业务同学的角度,其上线时不再是申请几台机器,而是申请多少计算和存储资源。

理想情况下业务同学甚至可以评估出自己每个 QPS 耗费多少 CPU 和内存,然后 Rolling 平台能够借助调度层计算出匹配的 Docker 容器的数量,进而进行调度和部署。也即从物理机(或虚拟机)的概念回归到计算和存储资源本身。

五、未来规划

一方面,我们非常看好公有云弹性的能力,雪球会和合作厂商把公有云部署 Docker 的网络模型做到更好的产品化,更大程度的屏蔽底层异构差别。

另一方面,我们考虑在资源层引入相对成熟的开源基础设施,进而为调度层提供自动化的决策依据。

六、Q&A

Q1:同时维护五类操作系统环境,是不是太多了?
多套环境,是确实有多种需求,很难砍掉。
物理机,不用说了,上面要部署nginx/redis等等。
KVM,因为雪球要装一些windows,来对接券商等传统行业(必须要求windows)。
LXC,确实是历史遗留,不排除切换到物理机,但是目前没有动力。
Docker,无状态服务。
PS. 我们实践中,只把无状态的服务放到 Docker 中,有状态的不会放。

Q2:跨机房的事情如何处理的?
跨机房这块我们在本地机房与公有云之间铺设了专线。目前使用情况如我跨机房图的第三图所示,也即云端有只读服务。

Q3.公有云和私有云拉专线么,雪球处于哪个阶段?
跨机房这块我们在本地机房与公有云之间铺设了专线。目前使用情况如我跨机房图的第三图所示,也即云端有只读服务。

Q4.发布系统中有无考虑ansible还是基于ssh直接上的?
发布系统早期Capistrano,本质上就是ssh,与ansible/saltstack没有质的区别。现在写了一套 Rolling,是基于 docker registry 和docker api的,与 ssh 没有任何关系。

Q5:为啥是4核8g?
主要大多数业务,其的每个节点,大概会用略低于这个配置的资源,我们就拍了这套 Default 值。

Q6. 调度参考监控系统的哪些指标?
我们调度目前还没真正做起来,参考的值必然会包括操作系统层面的指标(CPU/Mem/Network/BlkIO),同时应该会参考业务的指标(QPS、Latency)等等。

Q7:能详细说一下用shell脚本配置如何做,雪球是不是已经自研一套shell脚本组件来管理配置,代替dockerfile?
shell 脚本(也即capistrano这套基于ssh的发布系统),逻辑上就是git拉取代码,然后执行编译,然后打包,然后基于不同项目的配置,scp到不同的目标机上,启动起来。我们并没有替代 dockerfile,而是简化dockerfile,而且这一步是在构建base镜像时做的。跟业务部署并没有关系。

Q8.有没有评估过lxd?
刚搜了下,LXD 好像是 LXC 的管理 hypervisor,我们没有评估过,没有去看他的优缺点。我觉得技术选型的时候,除了技术本身,一定也会着重考察生态。Docker 生态系统非常好,也是我们选型的主要考虑因素。

Q9.目前雪球有多少个业务(核心的)跑在docker上?
我们的 docker 总体数量大概是1000个左右,其中大约有1/5是测试、预发布环境的,剩下的800个左右线上。我们总共有40个左右的业务,有的大,有的小。

Q10.如何管理docker集群?
对docker集群的管理,或者说对资源层的管理,是我们下一个milestone的目标。有可能会去考虑mesos,目前还在试验环节。

Q11.容器和业务有做为一个整体做弹性和自愈吗?还是分开的?
我们是把容器和业务是绑死在一起的。一个容器里,就是一个业务进程。所以要弹的就是容器。

Q12.使用docker之前,每个业务也是用很多台主机么?
没有,之前是在物理机上裸着混部署的状态。我们在去年下半年和今年上半年经历的大扩张以及微服务化。

Q13. rolling打算开源吗?
最初考虑过这个问题,可能拆除业务逻辑后有机会吧。我个人理解,在座的许多公司一定有能力自行研发一套自己的 Rolling,重要的是去想清楚它的思想,从代码生产,到上线提供服务,中间到底需要什么,如何进行标准化,这是我们最受益的。

打赏
  • 打赏支付宝扫一扫
  • 打赏微信扫一扫