很多时候，所谓的架构演进并没有太多的前瞻性，多半是被逼出来的。什么时候偿还技术债务，什么时候做出改变，什么时候跟上一些趋势，很多公司都是根据业务来判断的，但是我们把它分为三个阶段：烟小，火大。我们能做的就是尽量在smoke阶段做。有的技术变革，小火着手技术改造就晚了；虽然是同一个行业，但不同的公司会有一些差异，加上我对美团略有了解，所以我们在技术上还是有一些细微的差别。我今天的分享分为以下四个部分：Challenge（挑战）。有些技术是通用的、通用的，比如我们一直在用的TiDB，还有像Office这样的软件，但是我们不把解决方案卖给任何人。有欧美的朋友来找我说，我们那边抄一套就可以了。这是不现实的。我们现在看重的不是代码，而是一群懂业务，能跑业务的人，所以我们和一般技术的区别比较大。建筑学。每个家庭都有一张建筑图，大同小异。但是，为什么我们今天而不是三年前就在这样的画面中折腾呢？因为这里面有很多实际困难。拓扑和数据（topology&data）。将有一个图示的拓扑结构和一些数据。事实上，数据中有很多辛酸，停机的次数也不少。在线业务中最可怕的事情就是停机。正在做什么和未来的计划（doing&planning）。这里有一点精神上的追求，我们现在正处于吸烟阶段。饿了么的技术挑战如上图所示，这是一张显示订单量随时间变化的图表。这是外卖行业的特点，绿色部分表示有些异常。前端的流量会更大，因为两者之间有一个转换。电商在中国就有这样的曲线。应该只是外卖行业。我们两家公司（饿了么和美团）很相似。商业上很难“削峰填谷”，因为我们经过这么多年的努力养成了这样的习惯，但我们必须在技术上找到出路。看到这张图，你是不是觉得如果你的公司不搞云计算，机器会造成巨大的浪费。我想告诉你，这是一种非常严重的浪费，但是没有办法。我现在做的容量规划是基于波峰的。我们也想为公司节省成本。IT部门投入很大，公司不会削减预算。我们现在很关心成本，所以我们在考虑如何减轻公司的负担。今天我们主要讲一下云，后端的影响，我们在“削峰填谷”中要做的事情，为什么要做混合云。作为程序员，我最喜欢的就是简单。能花钱就不要安排一堆人来做。但是现在混合云越来越复杂，需要做很多调度器之间的适配。比如YARN如何适配ZStack和Mesos？我们是Mesos重度用户，做过很多二次开发，适配很麻烦。高并发或闪杀的影响还好，但最大的问题是成本：如何提高单元运行效率？公司拼到底，生存就是拼效率，而不是拼谁钱多。一切以效率为中心。基于这个出发点，我们做了一些结构上的改变。以前我们做灾备还是比较容易的，后来就没法继续做灾备了。这不仅仅是一种淘汰的方法，你之前踩过的坑对你做出下一步的选择很有价值。饿了么的架构演进5年前我们还没有这张图，还处于人肉运维阶段。当时称为DevOps（一种旨在统一软件开发（Dev）和软件运维（Ops）的软件工程文化和实践）。为什么？因为我们的工程师是Ops，所以没有专门的Ops团队。三年前进去的时候，才发现有点夸张。该团队只有一名全职DBA（数据库管理）和一名Ops。后来，我发现这是不可能的。招人，我招的人完全超乎你的想象。我招了一堆人来写业务逻辑。业务逻辑没办法聪明，也没办法像刘奇他们那样招三个中国顶级程序员搞定。业务逻辑是这样的，我们已经抽象出来了，但是还是不行，业务逻辑AI解决不了，后来发现招人不行，我们做的项目很乱，而且系统也很旧。我不是在抱怨Pyhton，我们最近也做了一个大计划，大概能省几个亿人民币，就是从Python转Go，因为大部分流量都是Python承载的，压力大集群很高。用Go术语大致除以5。今天我们要说的是IDC（互联网数据中心）+Cloud，因为我们有自己的IDC，总不能报废吧？虽然机器是三年折旧，但我们每年还是会补一些增量，我们也有庞大的运维团队。这时候，克劳德又复杂了。国内四大云我们基本都用过了。我们曾经是腾讯云和百度云的最大用户。阿里云不是第一，但也是前三，然后是七牛云。简而言之，我们使用所有四大云。包裹在里面。一开始我们想做容灾，但是容灾有一个很大的毛病，就是当灾难真的来的时候我们不敢切换。我们做的容灾并不顺利，最大的开销不是部署而是测试，因为容灾没有生产流量，验证起来非常困难。业务逻辑还行，比如接口多了，应用少了，从异步到同步的变化，但是也很郁闷。这一堆事情最终让我们暂停了这个项目。这个项目（容灾）是我发起的，我也停止了。这是一场赌博，包括Google和TiDB，不可能保证100%的可靠，总有一定的概率，无非就是几个9的问题。我们的（多活架构）coding&deployment&test一共花了三个月的时间，我们花了九个月的时间准备。很多团队异地多干很容易，三个月就可以搞定，但事实并非如此。首先，多住异地不是技术活，要弄清楚业务需要还是不需要。我们被业务逼得没法做了，因为灾备没做好，现在觉得灾备真的不好做。所以在业务型的公司里搞技术是很麻烦的。这里先说一下globalzone。我们有两种交易，一种是订单，一种是发货。大部分交易都可以在一个机房完成，但是还是有一些事情是绕不过去的，需要全局zong。百度也做了更多的工作，叫做“同城多活”，严格来说并不是多活，“同城”类似于globalzone。如果你只满足于北京和上海，你把BGP放在哪里无所谓，但如果你想打200个城市，在一些三四线城市，你就无计可施了。因为我们是IDC，不是云，你不关心云在哪里。我们被迫在不同的地方生活得更多。很喜欢百度的“同城伪多货”。百度外卖使用的百度云在广州有两个机房，延迟在2ms左右。master只有一个，流量分布均匀。如果流量不跟master的db，会通过专线经过同城，相当于我们的globalzone。如上图，这是一条典型的南北线，但不是南北线，是按流量划分的。如上图，我们有4个调度器，很头疼。让我们谈谈ZStack。在Docker没有推出之前，基本上都是在ZStack上，也就是一个虚拟机。物理机没有特殊的调度。我们大概有20%的节点部署了Docker，很多公司已经100%使用了Docker，但是我们现在做不到，确实有一些困难。Docker化也有点麻烦。有些集群无法迁移到Docker，例如ElasticSearch等有状态服务。我们现在也开始做自己的分布式存储系统，从EMC挖人来做，但是还在冒烟的阶段。再说说大数据的TP（TransactionProcessing）和AP（AnalyticalProcessing）。我们的AP基本上都在YARN上。您可能会感到惊讶，在我们目前的情况下，为什么不使用Kubernetes？这也是被迫的。一开始没打算用Kubernetes，而是用Mesos。大多数时候它与您的团队有关。团队长期在Mesos上，业务比较稳定，而Kubernetes太复杂，学习量大。现在我用Kubernetes因为我想用Google的产品。我们现在有一个机器学习平台。除了Spark，还有机器学习。但是还是有一部分同学，特别是用惯了Python和Tenserflow的同学，我们现在都去elearn（自研AIoverKubernetes）。大家会觉得很奇怪我们不是在TP上部署Kubernetes。我们的TP现在主要是Mesos和ZStack。这时候，克劳德就更麻烦了。现在饿了么主要是阿里云，百度外卖主要是百度云。百度云也有很多让人头疼的地方。前两天跟他们说话也是很痛苦的。我们团队坚持使用物理机。我们在腾讯云的时候，有自己的物理机，搬到了腾讯云的机房。但是现在阿里云不能让我们把自己的机器搬进去。怎么做？今年在云栖上已经提到了，我们是最先使用的。一定要坚持使用物理机，否则IO密集型任务根本跑不起来。我们也尝试过RDS（RelationalDatabaseService），但只是用于测试。我们所有的程序员和QA（质量保证）都使用阿里云上的环境，使用RDS。当然还有一个重要的原因，就是RDS太贵了。我们还将部署二次开发的MesosonCloud。饿了么的架构拓扑和大数据如上图所示。黄色方框基本就是机房，包括IDC和Cloud。最麻烦的是北京和上海。我们上海的新机房启用之前，大数据的AP和TP是混合部署的，但是这个混合部门是分开的，并不是真正的节点混合部门。这里是阿里云华东区和阿里云华北区，腾讯云也快下载完了。还有一些专线，就是两种支付（微信和支付宝）。原来两次支付都没有走专线，后来发现走公网受不了，高峰期的轻微抖动受不了，1万单可能一秒就没了。在支付过程中失去客户是最痛苦的。如果一开始APP打不开，是可以识别的，但是所有的流程都走完了，最后还是支付失败，那就很麻烦了。我们有很多专线，每条线都是一个循环。现在在广州的百度，百度云不是一个大的IDC架构，而是一个完整的系统。需要两条专线去上海的两个机房，每个都是一个环路，也很复杂。最让我们头疼的不是IDC，而是各种专线，因为很复杂。我们办公室还有一个POP点。我不想让它变得如此复杂。可能大家会说，北京的IDC要不要了，其实并没有那么简单。因为前提是要多做活动，不管是异地还是同城。我们现在在北京和上海的两个团队之间有大约25k个节点。Docker率不到20%，我们的目标是50%~60%，因为有很多东西做不到，尤其是中间件，用Docker不划算。当时大数据区被加固，把所有TP应用都“干掉”了，现在发现虽然机房以大数据为主，但AP和TP能不能同城结合？一起。现在大数据的机房压力也比较大。我们的业务增加了120TB。除了大数据，我们还有自己的系统日志和痕迹，将近400TB。每天处理3PB，总存储12PB，数据量特别大。我们现在的系统不能出错，不能停，尤其是通用软件的供应商。不管这个客户是闪购还是正规商家，他都绝对受不了。我们仍然只是为自己的业务提供服务，损失略小。但是对于公共设施，比如七牛云、TiDB，一旦停了，所有的用户都会找你麻烦，所以我们的压力相对小一些。我们业务没办法逼着我们一天发布350次，现在可能不止，因为现在新业务很多，我们一天发布几次。我们的大数据很贵，最贵的3个集群：MySQL、Hadoop+Spark和Redis。Redis还有很大的省钱空间。从经济/效率的角度来看，把这个东西放在那里是一种浪费。还有就是大数据的备份，这是我们的命脉。如果网站宕机了一天，我们只是道歉，第二天该来的用户还得来。但是大数据一旦出现问题，一是数据是隐私的，二是数据丢失或者乱序，会比较麻烦。我们每天都会做很多备份，但事实证明，这些备份太冷了，不值得。你不能赌它，但成本太痛苦了，不能放在那里。混合云架构是被逼出来的，我不想做这些事情。饿了么在做和未来规划的是，多活混合云架构的难点主要是异地多活。同城多活比较容易伪造，也就是globalzone的方法，但是真正的同城多活和异地多活差不多，主要是延迟的问题。你得自己做DRC（数据复制中心），包括MySQL级别，Zookeeper级别，Reids级别。当我们使用一个服务时，我们希望它是跨IDC的，主要是因为延迟和一致性。这两个问题很难协调。还有CloudNative，这是大势所趋，就像Go语言一样。抽烟的时候开始做也没关系。毕竟，您必须先开展业务。但火势较小时更危险。火小的时候，我们也还过债。还清债务相对容易。云一定会考虑的。混合云虽然听起来很时髦，但我们的步伐却比较谨慎。对运维团队也是一个挑战，比如RDS。我们内部的数据库也是五花八门，有MySQL、MongoDB。你习惯了在命令行打字，写脚本的运维就成了程序员。我们内部称它为OpsDev，难度远高于DevOps。我们希望公司里的每个人都是程序员，但是这个挑战还是挺大的。我们的Serverless是一个在线系统，但是比较简单。接下来可能会考虑短信推送和手机推送，因为这个只要设置好Redis并开启就可以直接发送。对我们来说，除非我们为所有这些业务使用云基础设施，否则无服务器将不适用于复杂的业务。Autoscaling是我们打算做的，因为做多了可以相对轻松一些，流量想砍多少就砍多少。95%的交易都在同一个区域完成。不这样做，阿里云就没有办法做大。阿里云现在可以做弹性伸缩，但是成本很高。一般来说，云的成本会比IDC高。做4小时拉拉拉拉划算吗（这个值应该应对高峰流量）？我们计算了一下，发现情况不一定如此。如果削峰填谷更有效，将稀释自动缩放节省的成本。我们和新浪微博不同，它是不可预知的、出乎意料的，所以我们只能按需（ondemand）去做。虽然我们有很大的波谷方差，但它是可以预测的。前两天团队给了我一个“炸弹”：我们现在的机器利用率很低。我们没有使用Docker吗？我们只做一件事——超卖。什么是超卖？我们以前是一核对一核，现在一核当二核，后来发现还不错，用Docker的人感觉没什么变化。我们继续超卖，一核当三核，我们按照峰值计算，发现平时的峰值利用率并没有那么高。不管我们要不要做AutoScaling，不管我们的业务要不要削峰填谷，我们都要做混合部门。在部门混编方面，百度走得更早。他们几年前建立了一个系统。目的不是为了混部门，而是为了实现这样的功能产生好的副作用。回到业务本身，部门之间其实很难混。跟他们聊天的时候说搜索业务可以像网格一样计算，每个网格自己计算，然后聚合。他们有很多swap（数据交换），但是如果你让Spark来做这些功能，比如机器学习和swap，即使是10G的网卡也会突然把带宽占满。现在机器学习不同于可以分而治之的搜索或爬虫技术。我们称之为分布式，里面有很多swap。我们也在尝试将可以独立计算的任务放在每个节点上，并且不需要大量交换。混合部门要解决什么问题？我们业务的峰值很高，到低谷的时候这些机器就会闲着，所以跑一些作业是可能的。这份工作不涉及TP。TP也有一些作业，但它们不会消耗太多CPU。这不划算，我们不能纯靠技术来玩，但是为了玩，我们要解决大量的场景。我们能想到的就是Hadoop，Spark，尤其是现在MachineLearning压力很大。但是聊天比较困难。一来不能异地，二来同城也难。还有一个很头疼的挑战：我们大数据团队用的模型是定制的，他们已经习惯了这个模型模板。我们TP有很多模板，从几百个压缩到十几个，但是还是很大，包括API，业务逻辑，Redis。如何使大数据或机器学习任务适应杂项模型是一个问题。我们行业经常有促销活动。即使活动期间有云，也仍然要花钱。因此，活动期间可以冻结大数据任务，释放机器资源进行大促。对于大多数任务来说，延迟三四个小时是可以接受的。双方互助部门首先解决资源隔离的问题，还有调度器。YARN很难调度TP，Mesos或者Kubernetes调度AP也很麻烦。我们正在研究的问题是如何适配YARN、Mesos和ZStack，目前还没有解决。混科问题由来已久，但我的经济压力还没有到冒烟的地步。如果有一天饿了么提供饿了么云，请不要感到惊讶。我们不会做公有云，但是我们考虑过PaaS（Platform-as-a-Service）和SaaS（Software-as-a-Service）之间的物流云。我们现在有很多不是饿了么的外卖，双11我们也帮忙外卖，现在也有叫闪送，可以在很短的时间内送达，一个人一件，但是收费比较高。我见过闪送的人直接骑摩托车送货，一般是电动车。很多时候业务发展的时候，恰好帮我们解决了其中的一些问题。
