店铺系统的挑战

挑战划分为三大维度的问题：全平台、垂直化、个性化。

全平台：PC端、App端、Wap端，三端统一。我来举个实际例子，某一天业务人员找到技术说下个月要搞促销，我们希望在指定一批商家的店铺上投放特定优惠券，希望每个端都能同步投放，怎么破？
垂直化：电商领域其实非常广泛，你不可能要求做原材料的行业和做快消品的行业是一样的体验。那会出问题，举个例子，原材料就是需要大量的规格展示，越专业越好；快消品主打营销，希望更多的营销主题；甚至某些企业还想提供独立的官网来提供企业的知名度。面对不同行业，不同诉求，这势必要求系统具备垂直化的能力来应对。
个性化：这个更容易理解了，每个商家都希望自己的店铺和其他人是不一样的，都有自己的特色！千人千面。

店铺的中台架构策略

模块化策略
首先，我们一起看下这张图片，大家应该都非常熟悉。商品陈列信息，阿里内部称为offer橱窗。

offer橱窗

逛过电商网站的同学应该知道，这么个看似简单的内容，会有非常多的呈现方式，常规的都能数上很多，更不用说个性化的方式。

粗略的分析一下：

页面元素：图片、价格、订购
数据元素：大图（需要筛选出来合适的尺寸，阿里为了图片的美观做了多次的优化，目前可以做到按需加载不同尺寸的图片）、价格（是否有活动、折扣、会员价）、订购按钮（有没有权限，有没有库存）
显示要求：平铺

从这三点要求上来看，可以看出，这个小板块背后的逻辑还是比较复杂的。以前我们怎么做？

第一个版本：硬编码，开发写了一个web control里面调用各种service，模板也单独写了一个（那个恐怖的时代，我印象中，页面超级复杂，大量的页面、JavaScript逻辑是copy出来的，轻易不敢维护），这个版本应该持续了有5、6年，相当痛苦。

第二个版本：control层widget，当时的架构师花了大量的时间构建了基于widget模式的系统。后端的逻辑看起来优雅了下一些，但是前端依然是全部写在一个页面当中的。当时web的同学最大的担忧就是发布，一个小小的VM都能引发一个p1故障。这个状态大概持续了3年左右。

第三个版本：组件化，页面层的种种问题积累了太多的血淋淋的教训！当时团队实在忍受不了了，决定全面实施组件化，加强了前端层面分组件开发的模式。这个是个巨大的进步，但是没有持续到半年就发现新问题了！整个系统设计的复杂度非常庞大（学院模式的过度设计），加上阿里惯性的拥抱变化，最后无人可维护。同时没有办法支持多个站点的需求，只能解决单一店铺。这个版本最后持续了一年多的时间。

第四个版本：模块化！简单的来描述就是前端组件化＋后端组件化，当然这里需要遵循同一个组件协议！开发人员也无需关心是在前端渲染还是后端渲染，这里最重要的点是让前后一致了，下面我们再具体介绍一下。

“前后端一致”的组件化

App全新概念

页面结构

除了布局，当然还有一些其他技术的细节，比如校验、session管理、异步通信等，这里不再描述。最后看一个页面的案例。

页面案例

统一数据中心

整个子系统由数据容器以插件的形式运行于客户端，它管理着数据资源，每个dataProvider对应一种数据源，它通过两种方式来获得外部数据。

一种是通过查找serviceInfo资源，然后基于其配置，以Dubbo协议（泛化调用方式）或HTTP协议的方式获取。
另一种通过本地服务调用的方式获取，接着根据dataStore中的业务代码（source.groovy）来聚合及处理这些数据服务的返回结果，并最终将获取的数据提供给app使用，完成app的取数与渲染，呈现在所有基于店铺平台客户端的应用页面之中。