饿了么混合云架构探索

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