简介： 手机淘宝作为整个互联网领域旗舰 APP 之一，装机量和用户访问量都是名列前茅的。

阿里妹导读：手机淘宝作为整个互联网领域旗舰 APP 之一，装机量和用户访问量都是名列前茅的。而首页作为打开手机淘宝的门面，是淘宝电商领域的主要流量入口和服务消费者的核心阵地，其业务的复杂性之高、系统的稳定性之重都有着极高的要求。首页承载着非常重要的业务使命，负责整个阿里生态的业务分发和商业策略输出。随着淘宝无线化战略的升级，首页也从 PC 时代类目导航的导购模式升级为无线时代个性化推荐的导购产品，从传统的千人一面走向未来的一人千面，决定了首页多样性、创新性、多变性业务特点。

背景

和猫客、飞猪、盒马、闲鱼等APP一样，首页无论在哪个体系下都是主要的流量入口，分发效率一直是我们追求和解决的核心问题。

如何让最优的商品和内容高效的触达消费者侧，提升流量价值，一直是我们追求的目标之一，截止当前我们进行了不同方式的探索，实现和积累了一些策略来解决这个问题。

当前首页根据不同的地域、人群划分出“大陆版”、“亲情版”、“村淘版”、“海外版”的业务版本，这些版本即传承手淘首页的通用能力，同时通过自身运营的自由度和独立体系，展示自己的垂直区域特色内容，更加高效的触达自身服务范围的用户。

比如“海外版”是针对大陆版以外地区的页面投放，“村淘版”则是围绕乡村地区，实现村淘的业务目标的重要的流量分发渠道。“亲情版”则是针对家庭关系用户进行业务模块的精准分发。

图：首页大陆、亲情、海外、村淘版本

新的挑战

随着首页整体业务策略的不断调整以及技术栈的不断升级，我们尝试基于人群、地域等属性进行的细粒度的人货匹配的运营策略。

一方面通过为不同人群定制差异化的视觉样式、用户路径、货品供给培养特定的用户产品心智，另一方面通过平台能力快速灵活的进行页面布局调整，能让需求爆炸式增长的同时也能快速的响应。

同时在面对提升分发效率上面不断演进的运营策略升级，需要我们技术侧提供一套高效稳定的常态化的运营体系对其进行支撑，对我们技术系统的建设也提出了极高的挑战，这里的挑战既有业务的也有技术的。

多版本隔离运营

这里面有两个关键字“多版本”和“隔离”，其中“多版本”是基于业务诉求的考量和抽象，面向用户的基本实体就是页面，这些页面主要由页面布局、货品供给、素材渲染几个因素构成，而针对不同目标群体需要有所差异化的透出，所以就需要在页面级别、模块级别和坑位级别针对不同人群、地域进行多版本的搭建运营。

在完成“多版本”运营的业务诉求的一个大前提是基于稳定性的考虑，“隔离”很好的诠释了在多版本下首要去关注的稳定性要素，一方面要保证不同版本的变更所带来的跨域影响问题，另一方面是按业务租户的方式为不同的业务开辟独立的运营体系，基于以上两方面考虑我们整体采取容器化的隔离机制实现业务运营之间的操作带来的风险规避。

所以在打造运营平台体系首要考虑的就是如何支持多版本下的隔离运营能力，大陆版、海外版、村淘版、亲情版这些独立的业务版本下如何自由的、稳定的衍生自己的方案投放是我们首要考虑的问题。如下图所示，是我们经历一场大促不同时期首页需要备战的方案矩阵。

图：首页多版本运营

快速灵活布局搭建

说起搭建，阿里集团生态体系下不乏有一些优秀的产品，比如天猫 Zebra 系统、淘宝 TMS 系统等，都是在页面搭建领域具有极高的产品口碑，基于灵活的模块化机制，致力于让运营同学能快速地搭建出符合业务需求的页面。

手淘首页的页面搭建作为我们日常工作中一类高频率的运营操作行为，需要高效、灵活的平台化解决方案，才能提升我们整体的研发模式和产出效率。所以我们以提升效率为目标，提升协同效率为诉求，一方面可以拉动运营角色参与到手淘首页体系的日常建设中，另一方面可以更加高效的产出不同业务场景的页面布局。

如下图就是三套页面方案的模块差异。

图：首页搭建方案差异

流量运营闭环建设

在首页大流量的场景下，任何业务决策的调整就像一把双刃剑，一方面可以让业务在这样的体量下快速孵化快速迭代，另一方任何调整在这样大流量的冲击下问题都会被成倍放大，风险和收益共存。

所以首页缺少一套从运营策略、数据收集、业务决策的闭环体系来使业务快而稳的奔驰。在过去的时间里我们沉淀了很多能力孤岛，单看每个岛屿都是一个完整的生态，但是岛屿间横跨了无尽的大海，这样不构成流程化体系化的平台，无论运营、开发、测试都是相互割裂的实体。

从运营路径来看，这些单点能力只会让他们只有输入没有输出，走了一步不知道下一步该怎么办，所以我们要基于科学的运营体系构建流量运营闭环。

图：流量运营闭环

组件抽象和复用

何为组件？

组件（Component）是对数据和方法的简单封装，组件可以将 UI 切分成一些的独立的、可复用的区域，这样你只需要专注于这些单体的逻辑开发。

所以我们基于组件化协议将整个首页 layout 进一步拆分成多个组件，其中每个组件构成页面的基本单位，用于渲染单一业务的基本区块。

首页的组件渲染是典型的 MVVM 的模式，端侧( View )和服务数据( Model )通过组件化协议( ViewModel )进行双向通信，一方面通过抽象组件协议解耦两端的耦合性问题，另一方面通过实例化组件实体完成了页面间的复用问题。

那组件协议本身的抽象和定义是我们首先需要去面对的问题，设计过于复杂、抽象过于碎片会使协议难于维护前后端联调沟通成本放大，设计的过于精简、抽象过于大支又起不到解耦的效果，这些都是需要我们长期思考和解决的问题。

图：组件化协议

动态化和实时性

前面几项总结其实都是基于业务上的挑战，而技术层面真实要面对的主要可以分为动态化和实时性的问题，动态化是实现实时性的主要手段，实时性又是动态化的方案考虑首要因素。

首先从业务诉求上面讲，首页是一个典型的中心化业务场景，快速响应是我们首要面对的问题，日常需要频繁根据业务策略调整布局，以重新分配流量，特别是大促态下，调整尤为频繁，对动态化和实时性的要求极高。

现如今需求量与日俱增，变更迭代速度从过去天级别到现在小时级别，就是在动态化和实时性上面做了很多体系化的建设，其中一方面我们在端侧协议引入了新奥创和 dinamicX 的动态化解决方案，另一方面服务端上面做了很多诸如 FAAS 化的动态化数据编排的能力，使我们在实时性上面有着不俗的成绩，无论是业务上线、功能迭代还是异常回滚都是在秒级生效。