您现在的位置是：首页 > 文章详情

「玩物得志 App」：一家典型的云原生企业，如何在创业早期数次“弯道超车”？ | 云原生Talk...

日期：2020-09-09点击：609收藏

造梦者：张淼，玩物得志 App CTO

引言

前几天，阿里云研究员毕玄分享了自己作为阿里云技术人的一个感受：

做基础技术的同学，当越来越好地满足了业务发展的诉求后，会发现业务方对基础技术的唯一诉求就是最好什么都别变，什么都别动，那么做基础技术的同学，未来的发展空间就会非常受限。

但自从很多基础技术变成了阿里云对外售卖的商品的时候，就完全不一样了，以前只是解决好自己所支撑的业务面临的基础技术的问题，而现在，当我们把这些技术变成一个商品，为社会各行业所使用以后，面临的最关键的问题是商品竞争力。作为技术型的商品，技术竞争力尽管不是全部，但绝对是最主要的……

当开始做这些对外提供的技术商品后，面临的一个巨大挑战就是视野需要有巨大的改变，不能再像以前一样，管它什么方法，反正支撑好了自己的业务就行。到了做商品这个阶段，就必须非常清楚的知道在这个商品中的技术方案在业界处于什么位置，后面的策略是什么，这对做基础技术的同学而言，也就意味着没有天花板了，因为就算是世界第一，也仍然面对着不断被追赶的挑战，就得不断的创新。

玩物得志 CTO 张淼在接受我们采访时，特别提到了上面这段话，他深有感触。2012 年张淼毕业于浙江大学，毕业后做了 2 年 WinZip 桌面软件开发，2014 年加入到蘑菇街，从 0 开始构建蘑菇街商品体系，经历了蘑菇街完整的服务化、平台化过程以及多个核心中间件的开发。2018 年底，张淼投身创业玩物得志，这是一家国风文化电商平台。今年4月，玩物得志完成了数千万美元的B轮融资，而此前，玩物得志在一年内完成了三轮融资。

对于一家创业公司而言，玩物得志的成绩非常亮眼。业务的高速发展与玩物得志对技术的布局策略有很大关系。张淼说：“这次创业我是从 0 开始组建技术团队，不到2年的时间就发展到 170 人。2014 年 - 2018 年我在蘑菇街经历的技术演进，和当下我在玩物得志所经历的技术演进，完全不一样。我们就是得益于云原生技术与产品的非常典型的快速迭代的创业公司。”

本期「云原生Talk」我们一起聊聊玩物得志背后的云原生故事。

从0—>1搭建研发系统

一家创业公司，面对近年来国内外环境的快速变化，要想活下去甚至是实现高速增长，对于研发团队来讲，效率是第⼀位的。过去这两年，关于创业团队如何完成从 0 到 1 快速搭建研发基础设施，中早期研发团队如何助力业务快速奔跑，张淼总结了三个核心经验：效率优先、见路不走、最多比业务往前迈半步。

张淼解释：“在基础设施、基础架构的设计选型上，我们没有洁癖，⼀切效率为王。项目第⼀版上线时只有⼀个单体应用，“当时我们采用了阿里云提供的⼀些基础工具，就把整个研发流程快速撑起来了。现在回想起来仍然觉得非常庆幸，如果我们选择自己去搭建整个链路和基础设施，玩物得志很难有现在这么快的发展速度。创业公司最开始技术人员很少，通过阿里云云效提供的基础和规范的研发工具，我们不会花费大量的人力做维护（至今我们也只有2个运维同学），这是第一次弯道超车。”

玩物得志比较幸运，很早就吸引了一批拥有丰富的行业经验和架构能力的研发工程师加入，大家见过很多大厂走过的路，并且知道那些路的优点和缺点，因此不需要再去趟坑。张淼提到，“我们会在基建选型上更加理性，创业公司没有那么多资源去消耗，相对来说会倾向选择⼀些稳定且通用的技术方案。2019 年玩物得志整体业务发展速度是每月翻一番，在这样高速发展的业务背景下，我们也出现了技术架构跟不上业务的问题。我总结的经验是技术最多比业务往前迈半步，这样的节奏可以保证不会出现技术溢出的情况。早期在业务支持和架构升级之间做妥协，也只能倾向于业务支持，毕竟活下来还能保持高速增长是创业公司的第⼀要务。”

玩物得志系统架构图

玩物得志没有大型电商平台的历史包袱，核心技术人员基本见过甚至参与过⼤型电商平台的架构设计，所以整体架构设计上会比较清爽简洁，基本⼀步能达到同等规模电商平台好几年架构调整后的结果。

为了支撑业务的快速发展，玩物得志极少自己造轮子，会大量采用云平台提供的SaaS、PaaS服务。比如大数据体系是在阿里云 Dataworks 框架体系上建设起来，使用了其核心存储、计算等组件，上层的可视化以及业务查询部分，由于业务方在使用过程中有大量的定制化需求，所以玩物得志在开源方案的基础上进行了一些二次开发。

玩物得志大数据概览

在核心链路设计上，玩物得志基本都做了多平台的备线⽅案，以保证链路稳定性。张淼提到，创新来源于业务，业务系统主要面向用户、运营同学，因此大量底层的实现都会交给云平台。这种架构设计使得玩物得志在运维、中间件等方面的人力成本前期投入很少，研发团队大部分精力都放在怎么让业务跑得更快上。

当然，由于行业的⼀些特色，部分基础服务玩物得志会在云平台的基础上做联合共建，比如风控相关的系统，会基于阿里云积累的数据和模型，再结合文玩相关类目的⼀些特色数据和模型来搭建成⼀个完整的垂直电商风控系统。“再比如最早的推荐引擎是我们和阿里云共建的，只不过阿里云的推荐引擎的核心模型是标品的模型，与玩物得志采用拍卖的形式所需要的非标品模型相差比较大，因此后期改成了我们自己实现。”

玩物得志反垃圾概览

技术选型思路

玩物得志自创立起就选择了阿里云，并且基于阿里云原生构建了所有应用。

张淼说：“最早是觉得快，如果所有基础设施都要自己来建⼀遍，实在是太慢了，早期业务量不大，不用过分考虑成本，用钱换时间、换稳定性是值得的（而且现在云的成本说实话也不高）。还有很现实的一点，对于创业公司而言，想要在短期内招到特别厉害是技术牛人，成本是很高的，如果一些云产品可以帮助我们解决难题，免去了高额的人力成本，综合评估下来成本是更加划算的。”

首先，在整个研发流程上，玩物得志最早借助云效等产品，将⼀整套完整高效的研发流程固定下来了。很多创业公司会基于 Jenkins 之类的做定制， Jenkins 的问题：⼀个是维护成本相对较⾼，⼆是流程规范上相对比较随意，对快速迭代的初创型企业来说，⼀忙很容易出问题（比如代码版本管理、线上问题回滚、多环境部署等）。

其次，在资源管理上，我们最早采用 ECS、RDS、Redis，后期拓展到整个大数据、ES、安全等几十个细分的点，大多数服务都是可以按量按需弹性购买，很大程度上降低了我们的成本。

在中间件领域，我们采用了阿里云消息队列 MQ 系列产品；线下我们也尝试了容器服务 ACK 、全链路压测 PTS 等。

为什么一开始就比较坚定地选择阿里云原生的技术和产品，张淼提到，“前期我更关注用钱来换时间，尤其对于快速奔跑的创业公司而言，多花一点钱，把时间节省下来，相对来说投入产出比会更高一些。”

选择云厂商的产品，优势主要有三点：

1、成本低。这里是指总体成本（人以及其他资源成本），以我们的实践经验来看，综合成本是更低的。

2、稳定性高。相较于小型创业团队自己花费精力、人力来维护而言，稳定性会更好。

3、节省业务团队接⼊成本。

张淼说：“我们在跟阿里云技术专家交流的时候，他们会分享很多最佳实践的经验，相较于自己搭建平台，业务团队接入成本更低，并且他们在售后服务支持上也做得非常到位。”

当然，并不是所有服务都要用云厂商提供的产品，这就需要 CTO、技术 leader 明确，哪些服务自己搭建，哪些可以使用云平台，时机和选型很重要。张淼说：“要选好的云平台，不靠谱的云平台可能让你的业务挂半天都恢复不过来，我们之前用过另外一家云平台提供的某个中间件服务，挂了半天都没有去解决，也没有人员响应，这对我们的影响就很大。还有就是明确分工和责任，双方合作才会比较愉快。”

对于做技术选型的经验，张淼分享了几点：

（1）核心业务尽量选稳定的、社区生态好的产品和方案，创业公司尤其业务驱动的创业公司少做小白鼠。

（2）结合团队同学的相关知识背景来做选型，类似的技术方案我会优先选择团队内同学曾经hold过的方案，除非有特殊的点能说服我。比如团队里很多同学对于阿里系的产品如 RocketMQ 很熟悉，使用姿势很了解，也阅读过核心源码，我们就倾向于采用 RocketMQ 来做消息队列。技术团队做选择一定要结合人的因素。

（3）重要且相对前沿的技术方案和趋势，我们会跟踪和观望，当这个领域角逐出明确的一二三名之后，我们再动⼿，比如跨端⽅案，我们差不多观察了半年，最近才真正开始行动。

（4）在⼀些边缘业务上，我们愿意尝试⼀些较新的技术，可以为团队成长买单。

（5）核心技术选型成本上面，⼀定要把⼈的成本考虑进去。比如自己搭⼀些基础服务，为了保障后期系统稳定性，往往需要招相应的专家，对于创业公司早期而言，招到专家型人才的难度较大，即使招到了人，成本也很高。⼀旦出现棘⼿问题解决不了，对业务影响非常大。所以，如果算上人的成本的话，采用云产品的总体成本相比自己搭建成本要低很多。

（6）选择云平台的技术/产品时，可以从几个维度来评估：稳定性，价格，售后服务，云厂商背后的集团资源、技术实力。玩物得志自成立起就与阿里云建立了深度的合作关系，不仅因为他们提供了稳定的产品和服务，也因为在这些产品背后，有专业的技术专家团队做支撑。

服务化——>平台化

2014 年张淼加⼊蘑菇街，谈及这段经历和现在玩物得志直接上云的对比，张淼坦言：“完全不一样。当时服务器等基础设施是通过租赁运营商机柜，然后自己采买服务器，代理商负责机房驻点运维，我们的运维⼯程师负责应用基础运维。那时候云相关的技术还不成熟，和现在的整体环境不⼀样，基础运维成本还是比较⾼的。现在云原⽣等相关的技术已经⽐较成熟了，所以玩物得志⼀开始就上云了，没有经历蘑菇街当初上云的⼀些复杂经历。最早蘑菇街是⼀个大的 PHP 单体应⽤，我记得我们是一边做服务化拆分，一边把全栈技术体系从 PHP 往 Java 迁移，⼤概花了近百名⼯程师1年左右的时间。当时也开发了⼀些中间件，也是无奈之举，那时候开源的项目与蘑菇街的使用场景并不匹配，不得已我们只能自研。”

“蘑菇街对于我了解电商行业及其技术架构设计是一段非常宝贵的经历。玩物得志⼀开始选择的核心开发语⾔是 Java ，不评价 Java 语⾔本⾝的好坏，仅从生态丰富、⼯业化程度高、容易招人这几点，就足以成为⼀些有志于做大的创业公司的首选（如果⼀开始就没想开发⼤规模应用或者偏功能型的应⽤，Python 会是我的最爱）。”

其次，玩物得志最早只有 3~4 个后端开发⼯程师，⽤ Spring Boot 写了个单体应用，它的开发效率也已经很高了，因为知道后期会做服务化拆分，所以在单体应用阶段，在代码结构设计上就有了⼀定的考虑。服务化说到底还是领域的设计和拆分问题，不⼀定要拆分应用了才开始做。因为我们早期就有相关的意识，所以整个服务化进程很快，差不多2个季度时间就基本完成了，期间没有停服，业务迭代速度仍然飞快。

因为业务增长飞快，尤其在非标品领域，由于商品生命周期短，并且每天新增加的商品量巨大，导致玩物得志差不多在应用上线半年之后，就要面临分库分表以及数据冷热分离的需求，这些需求在蘑菇街差不多是 2016-2017 年才开始做的（蘑菇街创立于 2011 年）。“必须得说，云原生是开发者最好的时代，云厂商提供的⼀些不错的解决⽅案，使得我们不⽤像之前在蘑菇街⼀样必须自研，用最短的时间就可以让业务无障碍地快速奔跑。”

服务化主要解决的是底层基础的问题，如领域的拆分、数据库拆分、接口调用逻辑的拆分等，玩物得志在 2019 年经历了3期的服务化之后，基本服务化已经完成的比较彻底了。总的来看，服务化的核心在于“拆”，让架构逻辑清晰、让风险分摊、进而让组织架构升级，但并不能很好地解决业务效率提升的问题，在效率上很可能是“1+1<2”。所以在服务化完成之后，玩物得志开始了平台化进程，希望能做到“1+1 > 2”。

张淼说，“ 2018 年我在蘑菇街经历了完整的平台化历程。但那时候很多事情的意义不太懂，比如当时技术负责人让我们做SPI、流程引擎、规则引擎，我们就做了，做完还挺开心，的确也解决了⼀些效率问题，但理解得不深⼊。现在当我自己开始主导技术团队来做平台化时，我花了大半年时间来思考平台化乃至中台的意义。最近中台也被很多人诟病，也有传⾔有些大厂开始拆中台。我得出的结论是，做平台化或者中台化，不是一个简简单单的技术上的事情，因为技术很多解决的是“术”的问题，但架构、平台化乃至中台，其实解决的是“道”的问题。所以，在平台化的第⼀期，我给团队定的目标就是把核心系统的架构图和业务流程图都画出来，梳理流程里业务经常变更的点。过去一年，团队里一些同学只是被leader带着狂奔，并没有真正想明白手头的这些系统业务为什么这么实现，他们必须自己想清楚，才知道要怎么做抽象、怎么总结、怎么提效。”

蘑菇街当时做平台化的时候，大约有 1000 名研发工程师，而玩物得志相对而言研发资源有限，张淼说，他更珍惜或者说需要更极致地去运用研发资源来做一些真正对业务提效的事情。在他看来，平台化 40% 的点在技术上面，60%的点在管理上面，也就是说，只是技术做好，管理做不好的话，平台化或者说中台化还是很难实现。

举个简单的例子，张淼说，比如最近我们有一个新项目，涉及到商品交易支付等链路，我们安排了 3~4 个小团队去打仗，但是他们做着做着就感觉自己的职责更像是一个 PM ，因为大部分工作其实在平台基础团队内，他们唯一可做的就是稍微修改下详情页，甚至详情页有可能都是底层商品团队来负责，这样的话对于这些业务团队同学而言就会没有抓手，只能干等着。他们也会有自己的痛点，感觉没有负责具体的业务，但是业务需求来的时候都会降临到他们身上，但是这个业务做得好与坏，最终承担结果的又是业务团队，对于他们而言只是做一个支持的团队，就会比较难受。

这个问题的核心在于分清楚业务团队和平台团队的抓手分别是什么，对于他们的KPI或者说OKR的制定会有一些新的考虑。平台化的难点在于管理层面，如果团队非常积极，那就会出现互相争抢的状态，如果大家都不积极，就会尽量把手头的工作往平台团队去推，那业务团队就真的是在做类似 PM 做的事了。

组建一支战队

在2019年初，张淼刚开始创业的时候，研发团队不到 10 个⼈，大家挤在一间十几平米小办公室里，听张淼天马行空地分享关于未来研发团队的发展阶段构想。“我当时说了四个阶段，海盗战队——>舰艇战队——>航母作战群——>星际战队。那个时候没人信，现在信的人稍微多点了。我跟大家说，只要我们努力，就一定会经历所有的阶段。现在回头想想，还是很有感触。”

海盗团队（50人以内）

海盗团队最明显的一个特点就是快速灵活。打个比方，我们就好像在余杭塘河上的一艘小船，因为河水不深，一眼就能看清河底有没有礁石会不会触岸，所以小船上基本由1~2个经验丰富的舵手把控即可，也不需要依赖先进的雷达装置（数据团队等）。碰到特殊情况或者业务方向需要调整，调头很快。海盗团队的特点是怎么快速怎么来，但是也会面临一些问题，比如说管理或者随着业务规模的变大，技术架构上也会面临一些挑战。

舰艇编队

舰艇编队比较核心的指标是做完了服务化的拆分，整个业务架构不再是一个大的单体，而是根据领域、部门做了拆分，同时我们所处的环境也不再是余杭塘河了，而是进入了钱塘江。钱塘江的水深有几十米，不能一眼看清水面以下的情况，一不小心可能会触礁，所以就需要雷达等装置。玩物得志也是在舰艇编队期间组建了大数据、算法团队。整个团队无论从武器装备还是人员配置层面，都更加立体、现代化。

航母作战群

这个阶段的核心特点就是完成了平台化乃至中台的建设，所处的环境也不是大江大河，而是太平洋。航母作战群是一支以航空母舰（中台或者简化为平台）为首的作战编队，着眼于快速机动部署的能力，每次作战业务编队都不需要依赖其他国家的机场或者自建基础设施，架构抽象完成度较高，团队的协作效率也非常高，进而可以使作战半径更大，打击速度更快，整个系统都是海陆空协同作战。

星际战队

最后一个阶段称为星际战队，只有少数的巨头可以实现。星际战队的核心就是脱离了水面，这里的水面就是云平台（至少完全脱离了其SaaS、PaaS服务），星际战队的规模已经大到现有的云平台并不能很好解决他们的业务问题或者云平台的成本要远高于自己团队维护的成本了，那么研发团队会选择自建一个云平台，脱离水面，驶向真正的星辰大海。

“我们现在处于航母作战群的最早期。”张淼说。在他看来，完成这四个阶段的核心在于公司体量能不能支撑那么大，“这就不只是技术的事情了，更多还在于业务发展与团队成长。”

关于未来

谈及玩物得志正在攻坚的技术难题，张淼提到几点：

（1）算法的问题。兴趣类非标品，商品生命周期短且海量，怎么有效地做推荐、做流量分发，这是个难题。

（2）研发效率的问题。怎么提升团队的研发效率，我的思路还是从⼯具化着⼿，用工具提升效率，所以我们内部有个⼯具小组，来提炼优化各个研发工作环节。

（3）规模增大后，有些基建慢慢开始需要我们自研，原来⽤了很多云平台的SaaS服务，但不是所有的SaaS服务在公司业务规模扩大之后还能适⽤，会暴露出很多问题。

（4）平台化的实践过程中会遇到的部分技术问题和管理问题。

张淼提到，未来玩物得志还是会立足文玩领域，这个市场已经相当庞大，玩物得志有8个⼀级类⽬，近 80 个⼆级类⽬，有些类目单个就已经是⼏万亿的市场了，但是大家对文玩品类的认知和品类实际的经营状况是有差异的，很多类⽬的线上化程度不够⾼，运作方式偏传统，还没有被普罗大众所关注到。正如玩物得志 CEO 唐金尚所⾔，“我们要把行业做大，让更多的用户能接触到文玩国风领域的东西，感受到国潮的美”。

当然，玩物得志也在考虑引入一些新技术，比如5G浪潮下能提升直播体验的AI/VR的相关技术，比如基于知识图谱的推荐算法的尝试。“我对于新技术是非常开放的态度，也希望把玩物得志带领成一个开放的技术团队，线上核心业务的技术选型上保守一些，但创新型、探索性业务上会不断尝试应用新的、前沿的技术。同时也希望研发同学能不断拓宽业务视野，真正做一个‘正确、高效解决问题的攻城狮’。最近我还计划在公司内部做《玩物夜话》，邀请不同行业的大咖过来做异业交流，这样大家才能破圈，去了解自己专业领域以外的事情。”