写点什么

创新项目从来都是在负债之下做架构取舍

  • 2020-05-29
  • 本文字数:5206 字

    阅读完需:约 17 分钟

创新项目从来都是在负债之下做架构取舍


大家好,我今天的分享主题是“ 从 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 还是其他的),还有比如你使用什么样的手机、登录进来之后你先点了什么,这些都是可以记录的。最常见的,如果你前面的页面做得不那么友好,可能用户找不到他想要的东西,因为手机屏幕很小,需要翻页,那么怎么翻是合理的?一定是按照货架上的顺序吗?不见得。一开始大家都在乎货架上的顺序,从上到下第一层、第二层、第三层、第四层,但是我可能上来就想拿最底层的。或者说如果有促销,那把促销的东西放在最上面,让人看到,给他引导。这些东西可以通过你的布局操作,但前提是有数据,你才能进行设计,不然你不知道他是不是按照你预想的来做。


作者介绍


史海峰  贝壳金服 2B2C CTO。曾在神州数码、亚信联创长期从事电信行业业务支撑系统集成工作,参与中国移动、中国联通多个项目,具有丰富的大型业务系统研发实施经验。曾在当当负责总体架构规划、技术规范制定和技术预研推广,善于把握复杂业务需求,提出创新性解决方案,参与多个重点项目的方案设计,在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作,发掘最佳实践、推动技术革新,组织内外部技术交流。曾担任饿了么技术创新部高级总监。多次参加业界技术大会,任讲师及出品人,不定期更新微信公众号“IT 民工闲话”。


2020-05-29 15:29817

评论

发布
暂无评论
发现更多内容

【Vue2.x 源码学习】第三十九篇 - 组件部分 - 创建组件虚拟节点

Brave

源码 vue2 8月日更

抖音快手短视频营销获客系统软件开发简介

Apache HBase MTTR 优化实践:减少恢复时长

华为云开发者联盟

Apache hadoop zookeeper HBase MapReduce服务

Compose 中的文字

Changing Lin

8月日更

面试官:你说说一条更新SQL的执行过程?

艾小仙

MySQL 系列教程之(七)DQL:从 select 开始

若尘

MySQL 数据库 8月日更

Spring数据库事务典型错误用法剖析

博文视点Broadview

摄影利器一加9 Pro,让你轻松成为手机摄影师

Geek_8a195c

如何请求一个需要登陆才能访问的接口(基于cookie)——apipost

Proud lion

大前端 后端 Postman Cookie 接口工

业内首发!腾讯位置服务推出移动端3D数据可视化图层

波场链DAPP开发|波场链TRONCHAIN介绍

Geek_23f0c3

DAPP智能合约交易系统开发 波场链DAPP开发 tronchainDAPP

接口测试--apipost如何自定义变量

与风逐梦

软件测试 接口测试

前端,测试如何修改后端接口返回的响应数据

CodeNongXiaoW

项目管理 大前端 测试 后端 接口管理工具

MySQL 不完全入门指南

Java 编程 架构 面试 架构师

抖音快手AI智能获客询盘软件系统开发内容

抖音快手短视频询盘获客系统开发搭建

2分钟玩转中文接口测试工具-ApiPost

CodeNongXiaoW

项目管理 大前端 测试 后端

抖音快手短视频智能询盘获客系统软件开发介绍

抖音快手智能获客黑科技软件系统开发费用

JS对象拷贝:深拷贝和浅拷贝

华为云开发者联盟

js 对象 对象拷贝 深拷贝 浅拷贝

AI 场景的存储优化之路

焱融科技

人工智能 云计算 AI 分布式 高性能

抖音快手短视频获客系统软件开发

阿里p9的Java面试心路历程笔记,轻松拿到了90w年薪的Offer

Java~~~

Java spring 架构 面试 JVM

LT浏览器——响应式网站测试利器

FunTester

性能测试 自动化测试 web测试 兼容性测试 测试报告

Regan Yue带你一起学习微软AZ-900认证的有关知识「 第IV章」

Regan Yue

云计算 微软 8月日更 微软认证

搜房记

escray

生活记录 8月日更

LeetCode题解:219. 存在重复元素 II,哈希表,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

评DeepMind神经网络求解MIP论文:并非无所不能

杉数科技

神经网络 机器学习 算法 Deep learning 智能优化算法

netty系列之:自定义编码和解码器要注意的问题

程序那些事

Java Netty 程序那些事

Go 语言,一文彻底搞懂 slice 实现原理

微客鸟窝

Go 语言 8月日更

抖音快手获客软件系统开发价格

创新项目从来都是在负债之下做架构取舍_文化 & 方法_技术琐话_InfoQ精选文章