回顾Docker如何助力微博迎接春晚峰值挑战

云计算
羊年的春晚与往年的春晚一样,却又不太一样。一样的是服务器君仍要应对全民“DDOS攻击”,不一样的是今年无法通过简单的扩容抵御峰值。今年不但主信息流日常用户活跃度已经达到了去年春晚的峰值,同时渣浪的产品拿出了多个杀手级产品,像红包飞,明星粉丝群,这些产品带来的QPS压力同样惨绝人寰。所以今年仍然按业务峰值扩容部署,信息流、红包飞、通讯、对象库、RPC等多个服务需要的扩容成本显然已经到了无法接受程度。

羊年的春晚与往年的春晚一样,却又不太一样。一样的是服务器君仍要应对全民“DDOS攻击”,不一样的是今年无法通过简单的扩容抵御峰值。今年不但主信息流日常用户活跃度已经达到了去年春晚的峰值,同时渣浪的产品拿出了多个杀手级产品,像红包飞,明星粉丝群,这些产品带来的QPS压力同样惨绝人寰。所以今年仍然按业务峰值扩容部署,信息流、红包飞、通讯、对象库、RPC等多个服务需要的扩容成本显然已经到了无法接受程度。

[[128769]]

怎么办?利用各服务的错峰特点,通过容器化弹性调度,解决抗峰值容量问题。平台通过对线上业务进行容器化改造,整体集群完成50%规模的容器化部署,容器节点数达到上千个以上。借助服务发现、弹性调度等基础设施,5分钟内可以完成上百规模节点调度,可即刻提供10W QPS的承载能力,应对任一服务的峰值。

达成这一目标的挑战可以概括为三个方面:时间紧,风险大,范围广。要在一个月的时间内,部署基本属于国内最大的容器化集群,并且提供一样甚至更好的服务SLA,核心接口成功率达到 99.99%,平均耗时小于40ms,同时需要覆盖全业务,5分钟内完成服务间资源调配。下面与大家分享一下平台的一些实践经验和踩过的坑。

为什么选择Docker?

首先分享平台为什么选择Docker。程序猿都知道在代码运行的世界里,拆东墙补西墙是一件不靠谱的事情,弄不好会塌方的。Docker能够完美解决环境差异化问题,通过Image定义依赖的环境因素,宿主机仅提供操作系统内核功能,所以任何一个镜像可以部署到任一Docker化的宿主机上。

当然很多人会有疑问,为什么不采用传统VM?这就是第二个关键问题,就是要快!Docker容器相比传统VM最大优势是可以实现秒级启动,更关键的是可以秒级停止。平台采用“瘦容器”的使用方式,容器与服务同生命周期。服务一旦摘除,容器就会立刻释放资源,新容器可以立刻就地启动,这样能够极大的缩短扩容所需时间。

部署一个大规模容器集群,Docker仅提供核心的容器化技术,为了确保集群的可控性需要一套完整的解决方案。平台的解决方案总体上可概括为:部署架构、服务监控、研发流程、扩容预案等几个方面。

部署

部署架构平台采用的是简化的结构,有几个建议很大家分享一下,a) 一个容器仅有一个进程;b) 采用host网络模式,除非你知道NAT,Bridge有什么坑;c) 最小化镜像大小,规划好层次结构,并且尽量复用;d) 日志采用volumn挂载方式;e) 一切皆容器,例如镜像构建环境也要容器化。

容器化部署最重要也是最复杂的,就是服务发现问题。平台参考Kubernates,Mesos,etcd等开源项目的经验,结合自身的业务特点以及现有基础设施,实现了一套基于ConfigService中心和调度系统服务发现机制。服务调度粒度从原来仅能针对整个服务池,细化到任一一节点,实现了7层nginx,服务节点,RPC节点三者之间的动态联动。这里运维的开发工作量是最大的,必须为运维的小伙伴们点个赞。

Docker 部署被诟病最多就是网络,平台目前采用的是host模式,为什么没有采用NAT或者Bridge呢?由于涉及的技术细节比较繁冗,这里仅分享一些踩过的坑。例如NAT使用iptables底层流量转发依靠内核netfilter模块,其默认仅保持65536个链接,在服务有大量链接的场景下,会出现大量拒绝链接的现象。再如Bridge的MAC地址默认是选择其子接口中最先的一个,这样就会导致一个宿主机下多个容器启停时出现网络瞬断。还有很多问题不一一列举,平台未来计划采用vlanif的方案来解决容器网络部署难题,请关注后续微博平台的分享。

服务监控平台

服务监控平台采用的是cadvisor开源方案,但由于cadvisor本身仅提供性能数据不完整,并且仅支持influxdb,所以平台在其基础上进行了二次开发,支持CPU使用率、存活个数、内存占用、Swap占用、磁盘占用等性能指标,并且提供了对ElasticSearch的支持,争取能够回馈给社区。

研发流程要尽量透明,容器应该融入到现有的流程,而不是改变现有流程。例如不要侵入代码,如请使用XXX环境变量等。不要影响原有的测试、发布、降级等流程,如测试预览环境应该容器化,而不应该增加针对容器环境的测试。

扩容预案要确定好规则,避免流量增长时乱扩容,平台通过核心接口QPS,总体QPS,平均耗时三个指标来定义扩容触发条件;扩容比例按流量增长计算,建议以 10%规模递增;扩容来源于整体QPS低、冗余Buffer大于50%的服务池。另外有很多细节需要注意,例如机房流量均衡问题、流量突增问题。

回顾

回顾这个过程,时间紧任务急,小伙伴们也是蛮拼的,在小黑屋不知度过了多少日夜。特别要感谢各位领导的支持和信任,让我们在困难面前没有畏首畏尾。当然这才是刚刚起步,希望更多牛人能够加入到平台大家庭,共同打造容器化平台。

责任编辑:Ophira 来源: 互联网转载
相关推荐

2019-03-11 08:10:59

微博K8S流量

2017-07-20 15:05:55

新浪微博极端峰值

2013-09-13 13:35:41

微淘微信微博

2011-07-21 16:05:39

CEO信息化

2021-12-24 10:47:49

Kubernetes容器化微服务

2014-02-18 14:29:41

Windows Azu微软CNTV

2015-04-16 10:35:08

微博微博如何实现

2012-01-11 09:50:18

英特尔至强处理器AMD

2015-04-10 15:02:57

阿里云CDN微博

2011-10-19 09:20:17

AndroidAndroid4.0

2021-12-30 07:42:13

Kubernetes集群架构

2020-10-30 10:26:21

CIO首席信息官数字化

2015-07-06 13:36:14

Redis微博关注关系

2016-10-28 11:36:07

IBM

2012-04-24 16:51:29

人大金仓

2024-01-12 09:14:34

人工智能CTOLLM

2015-11-24 09:43:37

微博Docker混合云

2016-01-04 11:47:07

微博混合云Docker

2018-03-13 06:58:09

数据中心运维管理基础设施

2009-04-13 10:21:45

网管春晚摩卡软件
点赞
收藏

51CTO技术栈公众号