岑文初谈移动端开放插件平台的技术难点

千牛是阿里巴巴商家的多端开放式工作平台，每天服务 500w＋的活跃商家在移动和桌面端操作业务，同时千牛本身是一个开放的端体系架构，上面承载着上百家 ISV 的服务（还在不断增加），在端设计上做到开放和体验，开放和安全的平衡。

在 2014 年 10 月 16-18 日的 QCon 上海大会上，千牛团队技术负责人岑文初（放翁）将带来演讲《高效安全的开放式移动端平台架构设计》，介绍他们开放式移动工作平台的客户端及服务端架构演进，构建移动插件平台架构的思路和经验，并针对开放模式下移动客户端存在的速度、安全、稳定性等问题和案例进行分享。会前我们对放翁进行了邮件采访，邀请他介绍他们平台的最初设计思路、迭代流程、针对弱网络的优化等思路。

InfoQ：简单介绍一下千牛平台最初的设计思路，以及每次进行迭代是怎样一个流程去做？这是一个开放插件平台架构，是否跟其他的客户端在设计方面有所不同？

放翁：千牛起源于做卖家的移动工作台，希望解决卖家离开电脑也能够管理店铺，处理日常事务的问题。当时千牛技术产品设计方面考虑两个关键点：消息驱动行为，行为标准化开放。用一个简单的案例表述一下：一个卖家出门以后可以在手机上即时的收到一个买家拍下商品的消息，看到消息以后他可以立刻点击消息，平台会呼起订单管理插件并直接定位到具体订单，然后直接修改运费后发货（消息驱动行为）；订单管理插件可能是多家 ISV 开发，但都实现了平台的标准协议，当被设置为订单管理默认插件以后，平台负责消息路由（行为标准化开放，可以类比点开超链接会打开默认浏览器，因为浏览器实现了 http 协议的解析支持）。

最早千牛是支持 Native 插件和 H5 插件两种方式，分别提供了相关的 SDK，这时候对于千牛应用来说，卖家感知的应用迭代背后其实是两部分产品的迭代：千牛平台自身产品发布（支持更多的服务和本地能力），ISV 业务插件的产品发布（新业务的产生，老业务产品改进，基于千牛新服务和能力的二次开发产品更新），整体上来说千牛平台自身迭代速度就会相对来说比较慢（一个月一个版本），业务迭代比较快（一周就可以有一个迭代），同时千牛上的业务也是随时通过后台而扩展上线的。（具体的整体架构有三版的变迁，到时候 QCon 大会分享的时候可以更详细的和大家介绍这种开放式架构的变迁设计）

开放式的平台架构和普通 App 的差别，从业务上来说：平台应用对于业务的关注更抽象（标准化业务协议，数据互通的流程设计等），从技术上来说关注的更多不定因素：安全、三方插件的性能优化和可用性、多端统一接口差异实现等等。

InfoQ：现在千牛的移动活跃度和桌面活跃度大概是怎样的比例？有什么有意思的发现吗？

放翁：千牛当前日活跃卖家数量暂时不方便透露，但 PC 和移动的活跃卖家人群当前重合度并不是很高，100w 左右，同时通过对于不同用户的在千牛多端上的行为分析结合商家本身的特性可以看到，中偏小卖家已经基本可以脱离 PC 通过移动直接处理日常经营（这个在以前是很难想像的，卖家人群操作的复杂度是非常高的），大卖家很多决策人群使用移动端来看店铺的经营状况。而中大卖家的操作员角色大部分都使用 PC 千牛做复杂的业务处理，同时多端不同角色间已经产生了互动，千牛有任务转发来驱动一些业务处理场景由决策者在移动端接收，分配给 PC 端的操作者。

InfoQ：移动端插件平台架构的设计，跟桌面 Web 端开放平台的设计，有何异同？

放翁：移动端和 PC 端对于消息驱动行为，行为标准化开放的思路和实现都是保持一致的（他们只有一个大后台），但是不同端由于界面不同，操作入口的容器也不同，在移动端操作入口局限于首页、消息中心、数字中心，而在 PC 端除了移动端所拥有的这些，IM（旺旺）本身也是一个非常强大的容器，在聊天框右面形成了一个互动化非常强的插件容器。另外移动和 PC 的 native 的能力不同，通过 SDK 给多端应用开放的基础能力也有很大差异，例如移动端的摄像头用在很多业务插件上支持扫描条形码发货等功能，PC 端的磁盘加网络能力可以用于客户端文件云化等等。

InfoQ：千牛针对弱网络环境有什么优化的经验可以分享吗？

放翁：千牛对于弱网络环境做了非常多的优化，但是都是针对千牛业务特点来定制的，千牛商家业务的特点就是数据交互重，JS 框架业务性强，图片变化量不大等，千牛针对这些点做了 Rainbow 的设计（why no spdy？），为 ISV 插件支持 Web 容器可定制化缓存策略等。具体可以在这次 QCon 上海分享中做更多详细的介绍。

InfoQ：千牛平台在双十一应该也将面临大压力挑战，这方面目前是如何应对的？

放翁：当前日常的聚划算促销和各种节日大促都已经和双十一非常类似，服务端的推送也成为了移动和 PC 千牛最重要的环节。比如买家已经和卖家说“我拍了商品”，这一瞬间如果没有商品已拍的消息，那么用户明显能够感知，这个和很多社交类软件的信息不对称推送是完全不同的，因此千牛服务端推送系统即时性的需求就凸显出来，但是对于推送的数据还有非常多的复杂操作（数据补全，去重数字通知计算等），这又和业务即时性和稳定性产生了矛盾，加上客户端网络的不稳定性，大促推送的挑战可见一斑。

另外千牛 IM 模块压力非常大，例如小米家遇到大促，一个客服可能 IM 上就有几百个等着回复消息的买家闪亮着，同时这些消息不仅仅是文本消息，还需要把这些买家的业务信息带下来（是否有订单都必须标注在 IM 的买家闪亮黄条中），同时 IM 是一个大容器，IM 每一个即时聊天客户的切换都会关联信息给到右边的插件，右边插件立刻联动的去获取用户信息，这样的内存消耗和网络消耗都是对一个客户端软件非常大的挑战。

同时双十一如何保证 ISV 软件不可用的时候快速切换到可用的其他 ISV，并且在服务恢复的时候可以再次被切换回来；客户端模块在服务端业务不可用的时候如何快速降级，最后能够保证基础的聊天可以最高效率；这些都是千牛双十一的很大的挑战。这些挑战每一个点都可以有非常多的内容可以讲，后续有机会可以让千牛团队的同学走出来给更多同行做分享。

InfoQ：说一个千牛平台做到现在，遇到的最大的挑战，以及解决的思路吧。

放翁：千牛平台的技术难点很多，就举 Rainbow 的例子吧。

当时千牛刚推出无线版本两个月（2013 年初），一群人也没有无线开发经验，但是慢网络已经遏制了很多商家用千牛的动力了，因为大部分商家出外本身手机性能较差和网络非常不稳定（卖家地域遍布全国乡镇，卖家所处地点会是很多市场内部等等），因此千牛必须去做改进。但要知道千牛大部分的数据交互都是及时性的且无法缓存（交易订单等信息随时都在变化），同时业务都是交由不同 ISV 开发，开发模式不受控制，因此如何能够在弱网络下优化千牛平台自身和 ISV 对外的数据交互成了很大的问题。

当时有一个非常有利的点是，千牛最早 SDK 封装了所有的数据交换，也就是 ISV 不论是 Native 还是 H5，都会通过千牛底层和远端做数据交换（这和业内已有的开放平台模式直接调用不同），当时是出于安全策略的需要，但这层的代理却给这种优化提供了收敛的策略保证，因此我们基于 iOS 和 Android 开发了基础层的数据交换，不改变上层的 API 调用模式，直接代理掉了 Http 协议，同时也把推送、配置更新、安全策略等都切换到了这个基础层，因此不仅提升了千牛上所有的 Http 数据交换可用性和效率，同时也实现了推送的全链路追踪，安全加密，压缩数据，数据变更通知（替代轮询）等功能。

打个广告，千牛是阿里内部的创业团队，当前负责阿里系所有的卖家（淘宝，天猫，1688，菜鸟）多端开放式工作平台。最早 6 个人从开放平台出来的服务端技术人员加上 3 个产品和一个运营，花了 3 个月时间打造了第一个移动版千牛，10 个月时间移动端自然增长到 100w DAU。当前团队包含开发、产品、运营（垂直化团队），技术涉及到移动端，PC 客户端，高性能服务端，Webkit 容器等内容，产品除了构建一站式商家工作台，还会建立商家互动服务平台，为商家生态服务圈提供更多有创新性的服务玩法。整个团队人员不多，欢迎优秀的同学加入一起来服务阿里巴巴所有的商家。联系方式：旺旺：放翁，微博： @放翁 _ 文初

嘉宾简介

岑文初（放翁），2006 年加入阿里巴巴集团，随后转入阿里软件创业团队，担任阿里软件基础平台架构师一职，负责了阿里软件基础服务平台架构设计与开发。2008 年－2012 年负责淘宝开放平台技术团队，为阿里集团构建对外的开放基础平台，开放服务数量从几十个发展到了上千个，业务类型从基础服务类扩展到阿里系新老买卖各条业务链，平台服务每日支撑 60 亿的调用量，并支持多终端多形态开发对接。2012 年至今负责商家业务部千牛产品及技术团队，从无线和 PC 两端打造阿里商家开放式工作平台，千牛当前每日支撑 500w 活跃阿里商家（淘宝，天猫，1688 等）在无线和桌面高效处理业务，同时千牛的开放式端和云设计模式为淘宝开放平台 ISV 提供了低成本高灵活性的新开发模式。