微博平台混合云实践 - Docker全架构
27
微博混合云实践 Docker全架构演进
Transcript of 微博平台混合云实践 - Docker全架构
微博混合云实践Docker全架构演进
服务弹性伸缩能⼒力⾯面临挑战
挑战： • 短时⼤大量设备扩容需求，⺫⽬目前技术体系不能很好满⾜足 • 闲置设备资源在现有的技术框架下未能被充分利⽤用 • 成本因素，采购周期⻓长，机房机架位不⾜足
业界发展趋势 容器化
发挥规模优势，“让夏利开出奔驰的感觉”
Google File System in 2003, MapReduce in 2004, Bigtable in 2006, The Datacenter as a Computer in 2009, Percolator (real-time updates) in 2010, Pregel (graph processing) in 2010, Dremel (interactive analysis) in 2010, Spanner (globally distributed database) in 2012, Omega (cluster scheduling) in 2013, Kubernetes (Open Source of Borg) in 2014, Borg (cluster manager) in 2015, and Jupiter Rising (advanced networking) in 2015.
Facebook Tupperware
Tupperware: Containerized Deployment at FB
• No Isolation • Not secure
• Matured • Namespace
Isolation
⺫⽬目标： • ⼯工程师不在关⼼心具体服务器在哪 • ⾃自动化处理设备故障 • 有效利⽤用设备资源 • 300,000+个进程，15,000+个服务
开源解决⽅方案
我们的痛点及需求
• 设备采购周期⻓长
服务A池
服务B池
服务动态池
离线池
XXX池
• 环境差异，有机器⽤用不上 • 共保不⾜足，从哪来机器
利⽤用公有云解决 短时⼤大量设备需求
整合服务池 解决内部弹性需求
待解决的三个问题： • 跨云的容器环境初始化 • 容器混合部署调度 • 容器业务编排问题
混合云评审流程A
评审流程B
评审流程...
采购
上架
微博平台混合云整体架构
基础资源（Pluto）
调度中⼼心（Roam）
容器编排（JPool）
业务容器
通⽤用⼯工具
私有机房 公有云
Pluto解决 “从0到1的问题”如何在5分钟内扩容1000个设备节点？Kubernetes和Mesos并未提供解决⽅方案
Docker Machine？Docker之外的基础环境怎么办？
设备初始化技术选型machine puppet ansible vagrant slatstack
Docker⽀支持 官⽅方原⽣生 配置模块 ansible/centos7-ansible:stable Docker Provision 配置模块
语⾔言 golang ruby python ruby python
管理能⼒力 Null master存在瓶颈，masterless模式 理论千级别 Null 好于puppet
配置管理 Null ruby’ yaml ruby’ PyAMl
成熟度 发展期 成熟 相对成熟 成熟 成熟部署结构 ssh ⽀支持masterless ssh ssh M-S
版本管理 Null Git Git Null ⾃自⾏行集成维护成本 低 可控 较⼩小 低 可控执⾏行状态 回显 Null 回显 回显 Null
灰度发布 Null ⽀支持 ⽀支持 Null ⽀支持可移植 ⽆无需 CentOS 7不⽀支持⽼老
版本 ⽆无需 ⽆无需 有⻛风险
Docker Machine⼆二次开发 + Puppet Masterless
Pluto服务架构
公有云
Pluto服务 - 基础环境管理
Pluto系统的⼏几个关键点 ⼀一、⺴⽹网络性能
VPC+VPN⺴⽹网络带宽
Pluto系统的⼏几个关键点 ⼀一、⺴⽹网络性能
VPC+VPN⺴⽹网络延迟
Pluto系统的⼏几个关键点 ⼆二、费⽤用核算
公/私有云Provider 成本中⼼心
Pluto系统的⼏几个关键点 三、资源管理
开发/运维
QA PM
puppet masterless
crontab dnsmasq docker init_env java jpool_agent ntp profiles scribe sudo sysctl
repo
rt
Pluto系统的⼏几个关键点 四、服务发现管理能⼒力
压⼒力机 client server 每节点service数量 响应时间 平均每台QPS
1 1 3 1000 15-35ms 55
2 2 3 1000 15-35ms 50
6 6 3 1000 20-40ms 40
client数量固定时,增加每个client的并发量,响应时间明显上升,因此猜测在consul client和server 间可能存在连接限制,需要跟进研究
基于Consul的服务发现系统压测报告结论： 可⽀支撑单500节点规模，可⽔水平扩展
Pluto系统的⼏几个关键点 四、服务发现管理能⼒力
Leader负载
Pluto系统的⼏几个关键点 五、混合云负载均衡⽅方案
⼏几种⽅方案可⾏行⽅方案： • 公有云LB服务 • VIP in VM
Pluto系统的⼏几个关键点 六、OS稳定性
坑： • Docker 1.6+ Crash on CentOS 6.5 • CentOS 7不兼容⽼老Puppet 版本 • “Usage of loopback devices is strongly
discouraged for production use. Either use
`--storage-opt dm.thinpooldev` or use `--
storage-opt
dm.no_warn_on_loop_devices=true` to
suppress this warning.” — 虽然能够work，需要关注性能
Pluto下⼀一步：提升单机利⽤用率
• Proposal: Add api to modify docker
daemon labels，例如可以在夜⾥里低峰期在设备上打允许批处理任务的Label，供上层调度系统分配任务
• 智能分配策略，解决超买超卖问题
Roam解决 “1+1>2的问题”⼩小业务享受⼤大池⼦子，⼤大业务间相互共享
K8s和Mesos的核⼼心竞争⼒力，Swarm的pluggable整合优势 有坑吗？
调度中⼼心架构选型Borg Kubernates Mesos Swarm
关系 演进⾃自Borg 借鉴Borg理念 Docker官⽅方
开发者 google google twitter docker
开源 No Yes Yes Yes
API kubectl http/dcos Docker API
⽀支撑规模 ⼗十万以上 理论万级 有万级别应⽤用案例 No
容器技术 LXC Docker LXC Docker
架构特点 集中管理 集中管理 集中管理 Pluggable
HA Chubby etcd zk zk, etcd, consul
资源分配 predicate + priority fair sharing/strict priorities
binpack, spread, random
⽣生态圈 CoreOS Aurora/Marathon/Bamboo Docker Ecosystem
Fail Over Replication Control
业务策略 Pod，Service Framework Compose
应⽤用案例 Yelp, Apple, eBey
落地成本 ⾼高 ⾼高 低
基于swarm⼆二次开发，下⼀一步整合Mesos
Roam系统架构
调度性能
分组
Stra
tegy
HA Swarm Master
业务动态扩容缩容
JPoo
l
Nginx/ConfigService变更upstream
缩容资源池
扩容资源池
roam delete container
roam add container
Nginx/ConfigServicereload
Roam下⼀一步： Swarm + Mesos
Thank You
