本文根据 饿了么 CTO 张雪峰在 2017 年 ECUG 十周年盛会上演讲的整理
压力还是蛮大的, 因为技术会议越来越多, 商业味越来越重但是不写公司名字或者介绍一下业务的特点, 其实很难去讲像我们这种每天 "送盒饭" 的, 有什么技术含量? 大家抛开公司名字, 看这个行业, 业务特点比较重的, 或者偏线下的, 很多时候所谓的架构或者演进大部分时候都是被逼出来的, 也没有太多的前瞻技术什么时候还债变革或者跟上一些潮流趋势, 我们是根据业务来判断的, 分三个阶段: 第一是 冒烟 ; 第二是 小火 ; 第三是 大火 我们能够做到的是尽可能在冒烟阶段做一些技术的变革如果出小火的时候再做技术的改革, 那就有点晚了到大火的话, 相当于被逼的没有办法了 我 原来也是想纯粹搞技术, 写一 点 好玩的 东西 后来 进到一个专注具体业务的 公司 , 发现先要活下来 不同的公司会有一些差别, 我对美团 也略有了解 , 我们 在技术上 还是 略微有一些差别, 尽管是在同一个行业
我今天的演讲分为四个部分:
挑战 (challenge) 有些技术是普适的, 通用的, 比如我们一直在用的 TiDB, 再比如 office 一类的软件, 但我们的并不是将解决方案 (solution) 卖给谁有一些欧洲和美国的朋友找到我, 说我们在那边 copy 一套是不是就能 work, 这是不现实的我们现在值钱的不是代码, 而是一批对业务了解的人, 能把业务跑起来所以我们与通用技术的差异是比较大的
架构(architecture)architecture 里有一张图是家家都有的, 大同小异但为什么我们到今天折腾成这样一张图, 而不是在三年前? 因为这里面有很多现实的困难
拓扑和数据 (topology & data) 这里会有带说明的拓扑以及一些数据数据其实有很多辛酸在里面, 也出很过很多宕机, 线上业务最怕的就是宕机
正在做的以及未来计划 (doing & planning) 这里是有点精神追求的, 我们现在处于冒烟的阶段
Challenge 1
图 1 下单量随时间的变化
大家看一下, 这就是行业的特色, 绿色不要管, 是一些异常这是下单量, 其实前端流量更大, 两者有一个转化电商在国内有这样的曲线, 应该只有外卖这个行业, 我们二家 (饿了么和美团) 都差不多 业务上 要削峰填谷是很难的, 我们做那么多年的努力才培养出来这样的习惯 但是 技术上要想办法 看到这张图大家会不会想, 你们这家公司 不搞云计算, 机器浪费超级严重 我告诉大家, 就是非常严重, 但是没有办法, 我 现在做的 容量 规划就是基于 波峰来 做 我们也 想给公司节省成本, IT 部门投入蛮大, 公司也不会削减预算我们现在很在意成本 , 因此在考虑 怎么 给公司减负
Challenge 2
图 2 challenge 2
今天主要讲云后端的冲击在削峰填谷上面我们要做什么事情以及为什么要做混合云我作为程序员, 最喜欢的就是简单, 能用钱砸的就不要安排一堆人去做但是现在混合云越来越复杂, 还要做很多调度器之间的适配比如 YARN 怎么跟 ZStackMesos 适配我们是重度的 Mesos 用户, 做了大量的二次开发, 适配是非常麻烦的 高并发或者秒杀的冲击还好 , 最大的问题是 成本: 怎么提升单位运营的效率 公司拼到最后, 活下来就是拼效率, 不是拼谁钱多一切围绕着效率来走, 在这个出发点下我们做了一些架构的改造 我们原来做灾备, 相对容易 些 , 但后来灾备也做不下去了这 不光是一个排除法, 之前踩的 坑对你做下一个选项是有价值的
Architecture 1
图 3 architecture 1
5 年前我们没有这张图, 是人肉运维, 那时才叫 DevOps( a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops) )为什么呢? 因为我们的工程师就是 Ops, 没有专门的 Ops 团队三年前我进去发现很夸张, 就一个专职 DBA(Database administration)和一个 Ops 后来发现不行, 要招人, 完全超出你的想象, 招一堆人写业务逻辑业务逻辑没有办法智能, 也没有办法像刘奇他们招三个中国最顶尖的程序员就可以搞定对业务逻辑是这样的, 我们已经抽象了还是不行, 业务逻辑 AI 解决不了后来发现招人不行, 做的乱七八糟的, 系统也老挂, 我也不是吐槽 Pyhton 我们最近也做了大计划, 大概会省几亿的人民币, 就是 Python 转 Go, 因为大部分流量靠 Python 扛的, 集群压力也是蛮大的用 Go 的话 (成本) 大概除以 5 但这个写 Python 的同学很牛, 除了 DBA 没干基本上啥都干了后来拆分出了乱七八糟这些东西, 现在看起来蛮漂亮的, 花了我们很长时间
今天讲 IDC(Internet data center)+ Cloud, 因为我们自己有 IDC, 总不能报废吧? 虽然机器三年折旧, 但我们每年还会有一些增量补上去, 而且我们还有一个很大的运维团队 Cloud 又复杂了我们基本上把国内四大云都用遍了, 腾讯云我们原来是第一大用户, 百度云也是第一大用户, 阿里云不是第一估计也是前三的, 然后还有七牛云, 总之四大云把我们都裹在里面
Architecture 2
图 4 architecture 2
最早我们想做灾备, 但灾备有一个有个很大的麻烦, 就是真到灾难的时候不敢切换我们当时做的灾备不顺利, 最大的开销不在部署而在测试, 因为灾备是没有生产流量的, 验证起来很困难业务逻辑还好, 比如多了个接口, 少了个应用, 从异步变为同步, 但也很令人崩溃这一堆的事情最后让我们暂停了项目, 这个项目 (灾备) 是我发起的, 也是我叫停的这其实是个赌局, 包括 googleTiDB 是不可能保证 100% 可靠的, 总有一定的概率, 无非是几个 9
我们的(多活架构)coding & deploy & 测试加起来就三个月, 前期准备了 9 个月好多团队异地多活很容易, 三个月就可以搞定, 其实不然首先, 异地多活不是一个技术活, 要想清楚业务需不需要我们是被业务逼得没办法, 因为灾备没有搞好, 现在觉得灾备也确实不好搞 所以在偏业务的公司搞技术是一件很麻烦的事情
讲一下 global zone 我们有两种 transaction, 一个是下单, 一个是配送大部分 transaction 都可以在一个机房完成, 但还有一些东西是绕不过去的, 需要用到 global zong 百度也做了多活, 叫同城多活, 严格意义上那不是多活, 同城就类似于 global zone 要是仅仅安于北京和上海, 其实 BGP 放哪里都无所谓, 但如果要打两百个城市, 在一些三四线城市, 你根本没有办法因为我们是 IDC 不是云, 云你是无所谓在哪里的我们的异地多活是被迫的, 我很喜欢百度的同城伪多活百度外卖用的百度云在广州有两个机房, 延迟大概 2ms 只有一个地方有 master , 流量是均分的如果流量跟 master 的 DB 不在一起, 就会通过专线同城穿一下, 这就相当于我们的 global zone
Architecture 3
图 5 architecture 3
这是典型的南北线, 但其实也不是南北的线, 是根据流量切分的
Architecture 4
图 6 architecture 4
我们有 4 个调度器, 非常的头疼我们讲一下 ZStack, 在 Docker 没推之前, 基本都是在 ZStack 上, 也就是虚拟机, 物理机没有特别的调度我们大概有 20% 的节点部署了 Docker, 有多公司已经 100% Docker, 但我们现在做不到, 有一些现实的困难 Docker 也有一点麻烦, 有些集群是没法迁 Docker 的, 比如 ElasticSearch 这种有状态的服务我们现在也开始自研分布式存储系统, 从 EMC 挖人来做, 但还处于冒烟阶段
再来说说大数据的 TP( Transaction Processing )和 AP( Analytical Processing )我们的 AP 原来基本上都在 YARN 上面大家可能会诧异, 我们现在这样的一个情况, 为什么不是 Kubernetse 也是被逼的, 开始就没有打算用 Kubernetse, 而是用 Mesos 很多时候跟你的团队有关, 团队在上面已经很长时间了, 业务也比较稳定 Kubernetse 太复杂, 上手也比较重现在上 Kubernetse 也是被逼的, 因为要用 Google 的东西, 我们现在有一个机器学习平台, 除了 spark,spark 也有机器学习但还有一些同学, 特别是用惯 python 的, 用惯 tenserflow 的, 我们现在都走 elearn(自研 AI over Kubernetse)大家会感觉很诧异, 我们居然不是在 TP 上部署 Kubernetse 我们 TP 上现在主要是 Mesos 和 ZStack
Cloud 更麻烦了, 现在饿了么这边主要还是阿里云, 百度外卖那边主要是百度云百度云等会讲, 也有很头疼的, 前两天跟他们聊, 也是很痛苦的我们的团队坚持要用物理机的, 原来在腾讯云上面的时候, 我们就有自己有物理机, 并且挪到了腾讯云的机房但现在阿里云不能让我们把自己的机器给挪进去的怎么办呢, 其实在今年云栖上已经提到了, 我们算是第一批用的我们要坚持要用物理机, 否则 IO 密集的任务根本跑不起来 RDS(Relational Database Service)我们也试过, 但只是用在测试我们所有的程序员和 QA(Quality Assurance)用的环境都是在阿里云上面, 是用 RDS 当然还有重要的原因, 那就是 RDS 太贵了我们也会在 Cloud 上部署二次开发的 Mesos
Topology & Data 1
图 7 topology & data 1
大家可以看一下, 黄框基本上都是机房, 包括 IDC 和 Cloud 最麻烦的就是北京一个, 上海一个在我们上海新机房没有开之前, 大数据的 AP 和 TP 是混合部署的, 但这个混部其实是隔开的, 并不是真正意义上在一个 node 混部这边是阿里云华东和阿里云华北, 腾讯云其实快下完了另外还有一些专线, 也就是两个支付 (微信和支付宝) 原来两个支付是不走专线的, 后来发现走公网很难忍受的, 峰值的时候稍有抖动就受不了, 一秒钟可能 1 万个订单就没了在支付这个环节丢掉客人是最伤的, 一开始 APP 打不开就认了, 最后什么都走完了, 最后支付不成功, 就很麻烦我们专线非常多, 每条线都是一个环路现在广州百度那边, 百度云不是一个大的 IDC 架构, 那边是完整的体系, 到上海两个机房要做两条专线, 每一条都是环路, 也很很复杂我们内部最头疼的不是 IDC, 是各种专线, 非常复杂还有到我们的 office, 还要有 POP 点我也不想搞的那么复杂, 把北京的 IDC 废弃不就结了, 但是没这么简单前提是要搞多活, 不管是异地还是同城
Topology & Data 1
图 8 topology & data 2
我们现在北京上海两个团队加在一起大概 25k 个节点 Docker 率只有不到 20%, 我们的目标是 50%~60%, 因为有很多是做不了的, 尤其是中间件, 用 Docker 不划算大数据这块当时狠了下心, 把 TP 的应用全部干掉, 但现在发现, 虽然机房是以大数据为主了, 但是 AP 和 TP 同城能不能合在一起, 好不容易分开现在又要合在一起现在大数据的机房压力也比较大了, 我们业务的增加是 120TB, 除了大数据还有我们自己的系统日志 trace 差不多 400TB 每天要处理 3PB, 总的存量是 12PB, 数据量特别大
我们现在的系统不能让它出问题, 也不能停昨天也听刘奇讲到, 尤其是通用软件的供应商, 停一秒钟意味着什么? 不管这个客户是秒杀类的还是常规类的业务, 肯定受不了我们还只是为自己的业务提供服务, 损失要稍微小一些但是做公共设施, 比如七牛云 TiDB, 一旦停顿, 所有的用户都找你麻烦, 所以我们相对来说压力还算小我们业务没有办法, 逼着我们每天 350 次发布, 现在可能不止了, 现在有很多新业务, 每天发布好几次我们大数据非常的烧钱, 我们最贵的 3 个集群: MySQLHadoop+Spark 还有 RedisRedis 还有很大的省钱空间从经济 / 效率的角度来看, 这个东西放在那儿很浪费还有大数据的备份, 大数据是我们的命脉网站宕一天我们道歉一下就行了, 第二天该来的用户还得来, 但大数据一旦出问题, 一是数据是隐私, 二是数据丢掉或者错乱, 会更加麻烦我们每天做了很多的备份, 但后来发现这些备份太冷了, 到底划不划算, 你不能去赌它, 但是成本放那儿太痛苦了混合云架构是被逼出来的, 不是我想搞这些东西的
Doing & Future(混合云架构)
图 9 混合云架构
多活的难点主要在异地多活, 同城伪多活是比较容易的, 也就是 global zone 这种方式, 但同城做真正的多活也跟异地差不多, 主要是 latency 的问题, 你要自己做 DRC(Data Replication Center), 包括 MySQL 层面, Zookeeper 层面和 Reids 层面我们跟 PingCAP 也合作蛮久了, 我也问过东旭, 你是不是可以异地机房跨 IDC 这还是一年前, 东旭跟我说还没有考虑这个问题, 因为没有这样的用户昨天聊的时候说好像可以支持跨 IDC, 而且是北京上海这种 35ms 的延迟跨度我们用一个服务, 就希望它是跨 IDC 的, 主要就是 latency 和一致性, 这两个问题很难协调
还有 Cloud Native, 是大势所趋, 就像 Go 语言冒烟时开始做, 太超前了也不行, 毕竟要先把业务做起来但是到小火就比较危险了, 我们也曾到小火的时候再去还债, 还债还算容易, 到小火的时候真的靠人肉上去砸就比较麻烦了 Cloud 肯定会考虑的, 混合云虽然听上去很时尚, 但是我们步调比较谨慎的对运维团队也是个挑战, 比如 RDS 我们内部数据库也千奇百怪, 有 MySQLMongoDB 你让习惯了敲命令行写脚本的运维变成程序员, 我们内部反过来叫 OpsDev, 这个难度要远超过 DevOps 我们希望公司所有人都是程序员, 但是这个挑战蛮大的
我们 Serverless 是在线上做了一个系统, 但是比较简单接下来可能会考虑短信推送, 移动推送, 因为这个只要搭个 Redis, 开启就可以直接发送了对我们来说, Serverless 对复杂业务是走不通的, 除非我们全部用 Cloud infrastructure
Auto scaling 是我们在计划做的, 因为多活做了之后才能相对宽松一些, 流量想切多少切多少 95% 的 transaction 都在同一个 zone 里做完的不做这件事情就没有办法做阿里云的拓展阿里云现在可以做 auto scaling, 但是成本很高一般来说云的成本会比 IDC 要高一些, 那是不是说做 4 小时的拉起再拉出 (值应对峰值流量) 是划算的? 我们算了一笔账, 发现不一定是这样如果削峰填谷做的比较有成效的话, 就会冲淡 auto scaling 节省的成本我们和新浪微博不一样, 它是不可预知突发事件的, 所以只能做 on demand(按需)虽然我们有很大的波谷差异, 但是可以预知的前两天团队给我一个炸弹: 我们现在机器利用率很低, 我们不是上 Docker 嘛, 我们做一件事情超卖什么叫超卖? 我们原来是一核对一核, 现在一核当两核, 后来发现还不错, 用 Docker 的人感觉没有什么变化我们继续超卖, 一核当三核用, 我们按峰值来算的, 发现平时的峰值利用率也不是那么高
Doing & Future(混部尝试)
图 10 混部尝试
不管我们要不要做 auto scaling, 不管我们业务上要不要削峰填谷, 都要做 混部 混部百度走的早一些, 他们前几年做了一个系统, 目的不是要混部, 但是要产生一个好的副作用来实现这样的东西回到业务本身, 混部其实很难的, 我跟他们聊的时候, 说搜索这种业务是可以采用类似于网格计算的, 每个格子自己算, 然后汇聚他们有大量的 swap(数据交换), 但你让 spark 来做这些东西, 比如 machine learning 和 swap, 即使是万兆网卡, 也会突然把带宽占满现在机器学习跟搜索或者爬虫可以分而治之的技术不一样, 我们叫分布式, 有大量的 swap 我们也在尝试, 把能够在每一个节点单独计算, 不需要大量 swap 的任务放上去
混部是为了解决什么问题呢? 我们业务的峰值非常高, 到波谷的时候这些机器就闲置着, 那是不是可以来跑一些 job 这个 job 不是指 TPTP 也有一些 job, 但都耗不了多少 CPU 这是不划算的, 不能纯粹玩技术, 为了玩而玩, 我们要解决的是大量的场景我们能想到的是 HadoopSpark, 尤其是现在 machine learning 压力比较大但是聊下来比较难, 第一不能异地, 第二同城也很难还有很头疼的挑战: 我们大数据团队用的机型是定制的, 他们已经习惯了这种机型模板我们 TP 的模板非常多, 已经从上百种压缩到十几种, 但还是量很大的, 有 API 的, 有业务逻辑的, 有 Redis 的如何把大数据或者 machine learning 的任务适配到到杂七杂八的机型是个问题
我们这个行业经常有促销活动活动的时候即使有云, 也还是要花钱的所以活动期间可以把大数据任务冻结, 释放机器资源用于大促大部分任务拖延三四个小时都是可以接收的两边互相的部, 首先解决资源隔离的问题, 还有调度器 YARN 是很难调度 TP 的, Mesos 或者 Kubernetse 调度 AP 也是有麻烦的
我们在研究的问题是 YARNMesos 和 ZStack 怎么适配, 现在没有搞定混部的问题早就存在, 但是财务上面给我的压力没有到冒烟, 所以放最后一页讲如果饿了么哪天提供了饿了么云, 大家不要惊讶, 我们不会去做公有云, 但是曾经考虑介于 PaaS(Platform-as-a-Service)和 SaaS(Software-as-a-Service)之间的物流云我们现在有很多的配送并不来自于饿了么, 也帮双 11 配送现在也有叫闪送, 可以在很短的时间送到, 一个人送一个件, 但是收费比较高我看到闪送的人直接骑摩托车送的, 一般是电动车很多时候业务发展起来了, 正好也帮我们解决了这样的一些问题
Q&A
提问一: 刚才我听到有一个迁移 Docker 的打算, 我不知道出发点诉求是什么? 刚才说成本比较高, 这个成本是指人力成本还是时间成本?
张雪峰: 是说利用率我们这种业务如果说要扩容, 虽然有冷备的机器在, 但还是比较慢, Docker 现在很快我们这种业务扩容很正常的, 压测不可能压到所有的细节, 我们分公共和业务研发团队, 公共团队主持这个工作, 但是业务不可能了解那么细业务保证大盘不出问题, 现在公司业务小问题尽量小, 以前可能就是一个新浪微博, 现在就是小问题, 机器匀出来做一些其他的问题成本为什么比较高是吗? 不是人力成本, 是我们的机器比较差, 你先活下来, 一开始用钱, 其实创业很多时候先用钱换时间, 你上公有云, 为什么呢? 因为钱可能贵一些, 但是时间换回来了, 我们早年也是这样, 钱换时间, 因为这个时间过了就倒闭了, 倒闭还谈什么
提问二: 刚才听到, 您对一些有状态的服务迁到 Docker 里面有一些担心, 但是我看到现在 Docker 容器, 其实存储的时候有一些插件, 不把服务器切到容器上面, 细节上面还有什么问题?
张雪峰: 不是因为插件, 是因为存储, 如果我们自己可以搞定, 一旦有状态的话存储就搞不定原来最土的一种办法, 我们用所谓的企业存储方案, 后来发现不行, 量太大, 图片还容易解决, 我们内部的图片小文件还可以, 但不是块存储, 我们现在也是用钱换能力, 我们有单机的, 来做这个还可以的, 一旦进入容器里面挑战比较大不是不能玩, 说直白一点, 不能让这一块有任何的波动
提问三: 我之前在 IBM 做过存储和虚拟化适配你研究的块存储这一块给数据库这样定吗?
张雪峰: 对, 它不是对象存储, 我们的对象最主要就是图片以前没有踩过的坑里面能够看懂, 排障能力, 虽然我们不敢用我只是请某一个 EMC 的同学帮我们支持这个工作, 我不是用 EMC, 因为互联网公司很少去买软件, 我们会买一些我们搞不定的东西
提问: 没有考虑过直接买 EMC?
张雪峰: 不会我们这种一秒出来, 我给你 5 分钟先看懂故障在哪儿, 如果我们是一个平缓的业务无所谓, 大部分都是高峰期出的问题, 80% 的故障出在高峰期, 不是说 EMC 的产品不是好产品, 是我们 hold 不住
来源: http://www.tuicool.com/articles/7bAJNr2