从 0 到 1，创新项目架构取舍之道

大家好，我今天的分享主题是“从 0 到 1：创新项目架构取舍之道”。大概一两年前，饿了么的 CTO 在会上问大家，你们觉得像饿了么这样级别的互联网公司，最重要的资产是什么？作为一个技术领导者，有没有考虑过这个问题？到底是数据、代码、客户、人才、系统？其实到最后会发现每一种资产都很重要，还有创新能力也非常重要。

我今天也会提到一些这方面的考虑，主要内容是以下四点：

创新项目从 0 到 1 架构演进策略：一个项目从 0 到 1，你要上来就搭个大的架构还是慢慢来？顾虑是对手可能比你还敏捷，中间有很多环节顾不上，别人上的我也要上，那怎么办？

成熟技术体系中如何快速创新：饿了么这么大一个公司，已经拥有成熟的体系，如果想做一些创新，怎么才能实现？

敏捷迭代中的技术债如何偿还？

技术怎么与创新业务齐头并进？这两点都围绕技术问题展开，情况是开始可能技术不够成熟，后面功能越来越丰富，数据越来越多，是不是可以做技术驱动业务的事情？

一、案例引入

我们用一个案例来分析：去年饿了么做了无人货架这个业务，无人货架是 2017 年新零售行业的一个风口，很多公司的办公室里面都有。去年的 9 月份开始，到现在不足一年，所以还有很大的发展空间。它的作用是放在办公室里面，如果你饿了，想吃点什么喝点什么，走过去扫码就可以。

为什么它是新零售的风口？跟你在路边买水果直接扫码有什么区别？我们展开来讲:

• 无人货架模式定位在办公室里，这是一个封闭的公共空间。如果想吃饭可以叫饿了么，但是想吃点零食或者喝点水，无人货架三十秒之内就可以拿到手，而且不用考虑我什么时候去买去囤，因为随时都可以。

• 货架面对空间里这么多的人，核心问题是怎样最大程度地满足需求，以及在此基础上是否能给一些新的口味。甚至再进一步，在这些流量上能不能做一些拓展，架子上没有的东西是不是也可以卖，比如新鲜水果。很多公司可以看到有冷柜和热柜，热柜负责保温的，标准化的场景是可以热乎着吃，放个豆浆、包子等。所以无人货架是一个很好的零售业务场景。

• 我们可以对接企业的需求，比如老板看大家挺累，我们来喝个下午茶，买光架子上的零食水果，大家随便吃也没多少钱。所以这个模式有很多展开空间，未来行业里，会有更多的玩法。

二、创新项目从 0 到 1 架构演进策略

去年 8 月 6 日业务团队提出要试水项目的时候，我们知道一些创业公司做的风生水起，甚至一些大公司比如京东、顺丰、苏宁都已经开始进入这个领域，包括后来的猎豹。这个业务上我们是后来者，后发优势就是你知道别人是怎么做的，但面临的压力也很大。试水期间（8 月 6 日~23 日），我们做了商品调研、业务场景调研，也提了一些解决方案，跨部门协作开发，还做了 Demo 在公司里试用。

9 月 6 日无人货架项目立项；9 月 20 日 V1.0.0 产品正式上线。整个过程看起来还比较顺利，业务总体反馈也都比较好。但是当时这个项目没有任何后端体系，比如营销后台、运营后台、供应链等，就是业务团队去买一堆货，自己往上面放，这种模式完全不可控，不具备扩展性。

11 月 20 日，我们打通了饿了么当时原有的供应链系统。到今年 3 月 5 日，对接饿了么新零售地网供应链系统，采购仓储物流这些都打通了。CRM、预售、拼团、鲜食等都是今年上半年我们做的一些拓展尝试，下一步也会做智能货柜。

三、成熟技术体系中如何快速创新？

我们说一下成熟体系和创业公司的区别是什么。

饿了么拥有一个大型、成熟、弹性、多活的技术体系。日订单量千万级别，整个技术团队上千人，系统指标要求很高，所以基础设施必须完善，不可能靠人力天天操作；架构设计有严格的评审机制和一套规范的操作流程。2017 年饿了么做了一个行业比较牛的“异地多活”，在两个机房之间可以调度流量，并做日常演练。最后就是容器化、混合云、计算力外卖等，这些关键词大家可以网搜一些文章了解一下。面对这样的体系，我们刚才说的无人货架这种短平快小项目如何应对？

分析一下其中优劣：

• 首先要求一定是快，而且需求可能变。今天这么玩，明天一拍脑袋那么玩，即敏捷迭代，快速试错，灵活响应。你不能跟他说你能不能有点谱，因为大家都不知道该怎么玩。那优势在于饿了么有非常完善的机制，高水平人才充足，比如我们想成立一个团队，拉起来很容易。业务立项会分到某一个技术团队，前后端测试、项目管理等的磨合过程中，团队配合度已经很好。不必从 0 到 1 建设一个新的产品技术团队。

• 但是劣势就是我们有太多条条框框，由于饿了么体系很大，架构规范严格，不可能自己再做一套用户体系，不可能自己做支付，一定得对接公司的。那就得跨团队沟通。做这样一个试水的创新项目，跟公司整体项目的级别一定是不匹配的。有时就是需要去刷脸，才能把这些提上去。

• 最后，如果我们今天数据出了一个 bug，想把数据修一下，不行。按照严格的操作流程，这个事情不能你去操作；而且要进行评估：风险有多大，一次要多少条，会不会对性能有影响。这个时候可能业务团队已经忍不了，所以其实是优势劣势并存的。

我们要把这个事情做成的话应该怎么办？首先得有一支能打的团队：召之即来、来之能战、战之必胜。我们搞的是一个独立的项目，全新的系统，但是所有参与项目的人，都是从各个团队拉过来的。团队都坐在一起，在“小黑屋”里，环境相对来说封闭，能更专心，更高效，更团结一心。以创业的状态进行，把所有的任务都排好然后开始开发，最后所有的任务都是完成状态。

上帝用七天创造了世界，我们最终用六天把这个项目做好了。期间有什么事情？除了刚才讲的攒人，还有对架构的取舍。

• 微服务：虽说一开始没有那么多要拆分的微服务，但是毕竟是互联网主流架构，要把系统做得特别灵活，为了能拓展。但也不需要考虑那么远，所以有考虑，以后再说；

• 技术栈：饿了么现成的拿过来用，大家都熟，再选择其他技术栈是不太可能的；

• 自有的 IDC：很多创业公司都是在阿里云上做起来的，我们当时也考虑说是不是干脆找个阿里云。阿里云都在自己手里头，想怎么玩怎么玩，不用关心公司的条条框框。但是最后想了一下，还是要用自己的系统。因为比如你要跟公司的用户系统、公司的用户系统、支付系统打通，你不能说我外挂一下，除非自己做。不能自己再做一套基础的体系，成本太高了。跟很多创业公司不同，他们往往数据库只有一个，反正用户数据少，能活着就行，但我们在一个体系里面，这些技术是现成的，我们要用；

• 异地多活：有没有必要呢？有必要，但是暂时可以绕过。因为我们一般切换服务的时候是在晚上，是有人在办公室甚至熬夜到两三点钟会用无人货架，但是毕竟不是常态。我们先不考虑多活，因为实现多活更复杂；

• 中间件：一定是公司现成的，包括数据库的中间件，数据的备份等；

• 测试环境：也是公司现成的，同上；

• 持续部署：需要知道谁发了什么版本，而且要有工具想回滚就能回滚；

• 容器化：暂不考虑，我们直接来台虚拟机当成裸机来用也 OK，容器化有更高的技术复杂度，我们现在只要做一个简单的业务跑起来；

• 日志监控：日志监控这个体系是公司现成的，对当前的业务有很大帮助。当时我办公室的电视上接了个监控视图，有天早上一看，业务量爆增，我说这一定有问题，查了一下发现有人在爬我们的数据，这种情况如果没有监控，你根本就不知道。

四、敏捷迭代中的技术债如何偿还？

同样的我们欠了很多债，下面分析一下：

• 业务层：包括一开始只是设置价格就进行销售，没有做营销、促销，运营的策略等。比如说在不同架子的相同的位置上摆不同的货，这些都是后来做的，一开始没有考虑，都是放上去就 OK。供应链，业务级的监控，权限（运营、业务操作等这些权限），一开始也没有做那么多，是后来补上的；

• 应用层：反爬、埋点、缓存、搜索、多活等这些也是这样。多活，刚才说了，影响不大但是是有影响的；

• 数据层：我们一开始对用户的行为数据没有埋点收集（比如，他进来浏览了多少东西然后跳出了，或者他点了什么是不是失败的），当时没有考虑那么多。但毕竟有个基础的东西在，比如最后一个爬虫，我们做好了也可以爬别人，看看其他公司的怎么样；

• 系统层：容器化暂时不用。

对于现在这个架构，我们做的取舍其实是一种选择，以最快满足业务上线，具备基本功能为目标，而不是一拍板就定了。

五、技术怎么与创新业务齐头并进？

再往下延伸，要考虑几个问题：

• 调整策略，从突击队到正规军：现在我们已经有上万的点位，已经有稳定的业务，那后面如果想怎么着就怎么着，想怎么变就怎么变，想怎么玩就怎么玩，想怎么抓数据就抓数据，这个一定是有风险的。一开始，从 0 到 1 搞起来，这个阶段有点损失没关系。但是一旦业务、技术、运营都是稳定团队的话，就需要转换你的战略。不再用突击，要用正规军的方法；

• 控制节奏，提高协同效率：我们会调整我们项目的结构，提高协同的效率，大家提前做沟通，做一些规划；

• 合理分配资源，偿还技术债；

• 架构规划，模块拆分；

• 沉淀数据，智能运营：把这些数据收集起来，一个业务没准两三年以后能有更大的市场，那这些数据沉下来就是有价值的。比如前两天饿了么就在准备重启一个去年被停掉的项目，那个项目之前运行了大概两年，一旦老板决定重启，我们所有的代码、数据都还在，可以随时使用。不过要想重启，可能最大的问题是人，就是原来那些人去做其他项目了，有多少人还留在这个团队都不好说。但数据代码的资产都还在，很快就能拉起来；

• 做减法，保持架构健康度：之前做这么多需求，业务团队有这么多想法，现在都还有用吗？不见得。很可能一个东西上来之后发现用户不买账，但它还是系统的一部分，依然天天运行着，还要考虑他的运维等，这时候做减法更能保持架构的健康度。

六、总结

所以总结一下：在风口创新里面，快一定是第一位，天下武功唯快不破。既然技术要去支持业务，那绝对不能拖后腿；但从 0 到 1 并不需要想那么多，以 MVP 为第一目标，不追求技术先进、架构完美。

还有，既然我们是一个比较成熟的体系，而且相对来说更有经验，那么我们要适度地前瞻一些。把产品、把架构设计得稍微好一点、灵活一点，将来拓展就不用改太多，不用推翻了就要重来，然后针对不同阶段、不同策略，适时做一些调整。

最后，技术上，先支持业务，深入理解业务，再驱动业务。一开始业务人员让你干什么你就干什么。接下来你还要深入理解，然后才能和业务的同学平等对话。如果业务是比较轻量级，2C 的，这种情况下大家要互相沟通。如果你已经做的量级非常大，可能从业务、从运营的角度来讲，难以了解全国情况，比如我们做的 O2O，基于地理位置不同，各地都不太一样。全国各地业务什么特点这都不好说，需要有一个强大的体系把数据收集起来，去做数据分析，去做策略指导业务，而不是靠一个人即兴的想法。所以我们要做到更好，就需要更多的数据，根据这些数据来分析用户，可以去看我们业务的趋势，能做一些更好的指导，接下来可能成为用技术驱动业务。不是说用人员驱动业务，而是一套比较大的系统，这个系统能够驱动业务，把公司业务能力固化在体系里。

最近一个在政府单位工作的同学和我聊起创新，创新很重要，但更重要的是有没有一个合理的体系，换句话说就是不能指望某个人力挽狂澜，不是一个有志之士想激发创新，就能创新。要靠一个公司或者一个组织，要有活力，要能保证多样性，要能够实时变化，这需要一套体系。所以在座的各位手里都有那么多数据，希望我们可以给后面的人留存更多的资产，能给我们后面的业务给予指导和帮助。

Q & A

Q1：快速迭代的时候，你的时间有限，像这种时间控制里面有什么东西？

A1：没有更多的选择，但是一旦你迭代的节奏调整过来，每个迭代多少大家都是有数的，而且一个比较好的团队有这个优势，开发一定要自测。

Q2：货架的数据是从哪些维度进行收集？

A2：比如登录网站，或者打开一个 APP，你是在什么样的环境下（4G、3G、WiFi 还是其他的），还有比如你使用什么样的手机、登录进来之后你先点了什么，这些都是可以记录的。最常见的，如果你前面的页面做得不那么友好，可能用户找不到他想要的东西，因为手机屏幕很小，需要翻页，那么怎么翻是合理的？一定是按照货架上的顺序吗？不见得。一开始大家都在乎货架上的顺序，从上到下第一层、第二层、第三层、第四层，但是我可能上来就想拿最底层的。或者说如果有促销，那把促销的东西放在最上面，让人看到，给他引导。这些东西可以通过你的布局操作，但前提是有数据，你才能进行设计，不然你不知道他是不是按照你预想的来做。

本文转载自 IT 民工闲话 公众号。

原文链接：https://mp.weixin.qq.com/s/w_bnKYmg5_8KZx3H9Xp6RQ