阿里巴巴所提倡的 “大中台,小前台”战略是非常先进的业务打法,这个策略对技术的挑战其实更大!
文章作者是全程网络CTO焦英俊,前阿里巴巴资深技术专家,1688总架构&垂直开放平台负责人&云电商平台创始人。
阿里店铺到10年经历了4个大的主版本。
店铺系统的挑战
挑战划分为三大维度的问题:全平台、垂直化、个性化。
全平台:PC端、App端、Wap端,三端统一。我来举个实际例子,某一天业务人员找到技术说下个月要搞促销,我们希望在指定一批商家的店铺上投放特定优惠券,希望每个端都能同步投放,怎么破?
垂直化:电商领域其实非常广泛,你不可能要求做原材料的行业和做快消品的行业是一样的体验。那会出问题,举个例子,原材料就是需要大量的规格展示,越专业越好;快消品主打营销,希望更多的营销主题;甚至某些企业还想提供独立的官网来提供企业的知名度。面对不同行业,不同诉求,这势必要求系统具备垂直化的能力来应对。
个性化:这个更容易理解了,每个商家都希望自己的店铺和其他人是不一样的,都有自己的特色!千人千面。
店铺的中台架构策略
模块化策略
首先,我们一起看下这张图片,大家应该都非常熟悉。商品陈列信息,阿里内部称为offer橱窗。
逛过电商网站的同学应该知道,这么个看似简单的内容,会有非常多的呈现方式,常规的都能数上很多,更不用说个性化的方式。
粗略的分析一下:
页面元素:图片、价格、订购
数据元素:大图(需要筛选出来合适的尺寸,阿里为了图片的美观做了多次的优化,目前可以做到按需加载不同尺寸的图片)、价格(是否有活动、折扣、会员价)、订购按钮(有没有权限,有没有库存)
显示要求:平铺
从这三点要求上来看,可以看出,这个小板块背后的逻辑还是比较复杂的。以前我们怎么做?
第一个版本:硬编码,开发写了一个web control里面调用各种service,模板也单独写了一个(那个恐怖的时代,我印象中,页面超级复杂,大量的页面、JavaScript逻辑是copy出来的,轻易不敢维护),这个版本应该持续了有5、6年,相当痛苦。
第二个版本:control层widget,当时的架构师花了大量的时间构建了基于widget模式的系统。后端的逻辑看起来优雅了下一些,但是前端依然是全部写在一个页面当中的。当时web的同学最大的担忧就是发布,一个小小的VM都能引发一个p1故障。这个状态大概持续了3年左右。
第三个版本:组件化,页面层的种种问题积累了太多的血淋淋的教训!当时团队实在忍受不了了,决定全面实施组件化,加强了前端层面分组件开发的模式。这个是个巨大的进步,但是没有持续到半年就发现新问题了!整个系统设计的复杂度非常庞大(学院模式的过度设计),加上阿里惯性的拥抱变化,最后无人可维护。同时没有办法支持多个站点的需求,只能解决单一店铺。这个版本最后持续了一年多的时间。
第四个版本:模块化!简单的来描述就是前端组件化+后端组件化,当然这里需要遵循同一个组件协议!开发人员也无需关心是在前端渲染还是后端渲染,这里最重要的点是让前后一致了,下面我们再具体介绍一下。
“前后端一致”的组件化
除了布局,当然还有一些其他技术的细节,比如校验、session管理、异步通信等,这里不再描述。最后看一个页面的案例。
统一数据中心
整个子系统由数据容器以插件的形式运行于客户端,它管理着数据资源,每个dataProvider对应一种数据源,它通过两种方式来获得外部数据。
一种是通过查找serviceInfo资源,然后基于其配置,以Dubbo协议(泛化调用方式)或HTTP协议的方式获取。
另一种通过本地服务调用的方式获取,接着根据dataStore中的业务代码(source.groovy)来聚合及处理这些数据服务的返回结果,并最终将获取的数据提供给app使用,完成app的取数与渲染,呈现在所有基于店铺平台客户端的应用页面之中。
开放的设计平台
在核心技术日趋完善的情况下,我们发现生产力依然低下,因为我们要开发的业务需求还是非常多,虽然大家的开发效率已经得到大幅度的提升!
但是还是会出现乱拳打死老师傅的情况,面对日益增长的个性化需求,我们选择了开放,将店铺核心体系开放出去,接入设计师来帮助我们完成个性化部分!
这其实也是典型的云服务开放的案例,通过设计平台,我们既解决了自身的资源问题,又养活了40多个设计师!
最后店铺业务只需要1-2个人日常维护就可以满足不断增长的业务需求!
店铺生态建设
围绕着平台核心技术的打造过程,我们自然逐步完成连接开发者、设计师、第三发开发者、运营人员,他们都可以很好的工作在店铺平台中完成各自的需求。整个店铺业务形成闭环,自然高效的工作在一起!