大数据时代下的电商营销怎么玩？
当我们细细品味去年阿里取得571亿成绩的同时，不难发现，中国电子商务的市场份额正在向头部靠拢。不管承认与否，市场份额向寡头聚集说明电商行业的垄断风险越来越高。垄断是创新的杀手，如果中国的电子商务只有在天猫、京东这样超级平台上才能玩，这不得不说是一种悲哀。
为何大部分独立电商都面临生存危机？这个问题与产品、营销、营运等诸多因素关联。本文试图从大数据与电商营销层面去做一些思考。
大数据营销的核心
独立电商正在面临前所未有的营销挑战，这种挑战突出体现在三个方面。首先，营销成本越来越高，获客成本居高不下。成本高企的主要因素是媒体对定价权的掌握，以及电商巨头对资源的垄断；其次，随着媒体碎片化越来越严重，营销管理效率受到挑战，机会成本越来越高。电商在找到适合自己的媒体之前，需要一个不小的试错成本和时间积累；第三，促销竞争越来越激烈，用户忠诚度越来越低。一个同行的促销就轻易把用户给挖走，不动用特殊优惠难以触动沉睡的老用户。以往期望有高二购率的高举高打营销模式日渐式微。
电商营销的关键要素，在于营销渠道的选择、营销效率的管控和营销规模的可放大性。不断会有新的渠道出现，然而这个渠道是不是一个优质渠道，主要体现在是否可以达到效率与规模的平衡。
大数据正是这样一个工具，帮助电商进行管控与计算，平衡效率与规模。大数据在电商营销中的应用，核心是做数据资产的保值和增值。大体可分为CRM数据、访客数据和第三方数据三类，数据规模依次呈几何级数递增。所谓保值，是练内功，通过数据发现消费规律，并在此基础上对用户细分和聚类，用适合的工具与用户交流其关心的内容，最终实现用户的转化与再转化；所谓增值，是走出去，基于对自身用户的持续画像，以此在外网寻找&有缘人&，故增值的核心是数据个性绽放，业务需求匹配。不论保值还是增值，应注重积累和持续，而非短平快；注重价值规律由内向外发掘，不同层次的差异化和递进关系，而非一刀切。
大数据与网站优化
电商营销，转化率是关键，提升站内转化率是优化广告效果的基础。电商网站优化的核心KPI就是看转化率是否得到提高、转化成本是否可控。在这一块，美国的Amazon是行业的标杆。Amazon网站上，有超过35%的销售来自于站内推荐系统。推荐引擎是大数据的典型应用，其原理是追踪每一个访客的站内访问行为，并建立推荐模型，预测该用户可能感兴趣购买的商品，然后通过推荐模块在网站页面输出展示这些商品，从而吸引用户点击并购买。
大数据不仅可以洞察消费者的购买兴趣，还可以帮助网站开发者去做UI/UE的优化。通过大数据AB测试，可以了解页面布局和功能设计对于二跳率、转化率的影响，从而避免主观判断UI/UE的优劣，通过数据来持续优化UI/UE。在美国，有专门做AB测试的大数据公司，已经拿到了多轮融资，正在准备上市。在中国，目前电商的接受程度还非常有限，还处于方兴未艾的阶段。
大数据与会员营销
传统的电商CRM，通过RFM模型对已购买顾客进行分组和差异化的营销互动。而事实上，除了已购买顾客，还有大量的到访顾客、兴趣顾客、加入购物车未提交顾客等等，这些潜在购买顾客的数量级可能是已购买顾客的上万倍甚至更高。在大数据时代之前，我们对于这样一个庞大的潜在顾客群是无法管理和营销互动的。大数据使CRM的概念发生了升级，变为VRM（访客关系管理）。
大数据应用将所有网站的到访用户都管理起来，从访问到注册、加入购物车、支付、购买等环节，建立一个客户转化销售漏斗，这是进行广义会员营销的基础。同时，大数据的引入，使得传统的EDM、SMS变得更加智能化、高效率。VRM的思想，是以大数据为基础的数据库营销升级版，这种升级，体现在基础数据、营销内容、触达渠道、评价体系等多个方面。建立符合自身特点的VRM体系，是电商深入开展数据库营销的基础。
大数据与媒体广告
展示广告的程序化购买，是未来的媒体采购主流模式。程序化购买的发展，离不开大数据应用的普及。从媒体端的资源整合，到第一、第二、第三方数据的收集管理，再到智能竞价、动态创意、智能LP的应用，大数据是必要条件和催化剂。
最近一两年程序化购买的发展速度非常快，从单纯的公开市场竞价DSP，到私有化竞价市场PMP的出现，再到移动广告的程序化购买。如此快速的广告采购方式升级，是很多电商所不适应的。反过来看，这些新的媒体采购方式，虽然从理论上能够帮助到电商提升效率、降低成本，而事实上电商在程序化购买的实施过程中，实际效果与其期望值还有不小的距离。
电商要利用大数据做好媒体广告程序化购买，离不开以下几点：
1、要有自身的大数据营销规划和架构，具有大数据营销的技术储备和思想意识；
2、选择DSP供应商要慎重，不能偏听偏信，前期最好多选几家，是骡子是马，拉出来溜溜；
3、科学设定程序化购买的KPI，不能简单照搬其它渠道的KPI要求；
4、合理设定程序化购买项目的启动和评价周期，注重结果，更注重过程；
5、培养自己的大数据营销人才，深入进行大数据洞察，而不是简单外包，浅尝辄止。
大数据与电商营销生态圈
电商营销生态圈，可以看做是媒体、流量、用户、顾客、回头客这几个要素之间的闭环。每个要素，都涉及到一系列的产品和工具。大数据时代之前，我们也有报表，也能看到这些要素之间的递进关系。而大数据时代的来临，仿佛让我们配备了高倍显微镜，能够对这几个要素的结构和流动看的更加清晰，同时大数据又构建的新的游戏规则，使得电商能够用全新的视角和方法来开展新电商营销工作。
大数据让电商营销生态圈变得更加绚丽，对电商营销人的学习能力和执行能力提出了挑战。面对这种挑战，迎头而上是唯一的选择。
作者简介：周凯&& 上海智子信息科技有限公司（） 营销副总裁 复旦大学MBA。前梦芭莎高级副总裁，2008艾瑞新营销专家奖获得者。
看过本文的人还看过
最新图文推荐
最新专栏文章
大家感兴趣的内容
网友热评的文章　　您是否在为经销的酒类产品库存而发愁？　　您是否因京东、淘宝商城的高额保证金及店铺装修费而犹豫？　　您是否在因没有专业的策划营销团队而伤透脑筋？　　刚开始做电子商务推广可能会丈二和尚摸不着头脑，现在笔者有了一点经验和大家分享一下吧，在这也向更有经验的人请教请教：　　1、任何营销的核心都是产品，产品包装的专业、丰富有深度就能获得更多消费者的信赖，同时也能体现该企业的用心和专业，能给消费者留下良好的印象。　　简单来说现在的广告就是需要投入少却能感觉高大上，如果只是有着单纯满天飞的广告，却不能有打动消费者心理的包装，那么投入再多的心血也无济于事，所以产品的包装很重要，要能让消费者有冲动去购买我们的产品，能让消费者回头购买并且帮我们宣传那当然是最好的推广方式了。　　2、店铺的装饰可以不求奢华，但求简洁、主题统一，切忌花里胡哨、图文胡乱堆砌。首页体验一定要好，不仅仅是为了好看，而是给消费者细致、专业的感觉，而且能让消费者有明确的整体认知。　　3、详情页比较长可以留住消费者，图文并茂能有更好的感官体验，更多的对比和解释，也能显示专业和细致。如果有准确的历史由来当然更好，食品类电商可以在详情页加上美食介绍。　　4、产品的营销包装是进入消费者视线的第一印象，那么当消费者收到在网上购买的产品后，打开包裹后的印象也很重要，试想如果我们只是卖大米，但是有着贴心、好看的打包方式和专门的品牌胶带、盒子，那样的体验是不是更好呢？
楼主发言：1次 发图：0张 | 更多
　　离职后开始随大流，进入电商行业，把我这段时间的经历做做总结：　　看了很多派代的文章，发现最多的就是刷单，其实刷单只是锦上贴花的事情，绝对不是电商的本质，真正要做好电商，首先你要分析分析你自己的产品，选择永远大于努力.　　1:产品的需求在哪里，你能满足哪些客户的需求，你相比竞争对手而言你的竞争力在哪里。有哪些优势，做做分析，看看主要竞争对手的弱点在哪里，一步一步的去打。　　2：服务怎么样，如何做好售后服务，要知道老客户的维护带来的利益远远大于新客户，平均开发一个新客户的成本需要20元左右，而维护好一个老客户的成本低于10元，如何促进老客户的二次销售就显得而外重要。　　3：团队怎么样，美工团队，运营团队，客服团队，数据分析团队能不能各施其职，电商是辛苦活，电商电商就是电殇，能不能持续努力工作，团队有没有拼劲，团队对产品知识的专业度非常关键。　　4：产品的优化做的如何，标题有没有按照买家的搜索习惯设置，详情页有没有把买家担心的问题解决，有没有突出产品的优势，解决问题的最好办法就是在问题发生之前解决问题。　　5：产品的定价：标品低价，非标品高价，按照客户的购买习惯，结合数据魔方，合理制定价格，如何是标品，考察的是供应链，标品的低价将会带来巨大的流量，托起一家店铺，非标品讲究的是高大上，只有价格足够高，才能够撑起广告的投入，让流量持续不断的进来，淘宝上并不是价格低的产品就好销售。　　6：良好的人脉关系，有没有良好的电商交流圈，圈内有没有很多顶级的类目第一的高手，能够第一时间了解电商发展的趋势，了解天猫，淘宝，京东，唯品会，1号店最新情况。　　7：工厂供应链的配合，工厂是否足够支持网络销售，在选品，售后上是不是确保客户100%满意，能否说到做到。是不是能够在销售上面做到不断货。　　8：产品品牌知名度如何：是不是行业领导品牌，淘宝，天猫消费群体越来越接近实体，搜索权重品牌占比会越来越大，小品类生存空间在减少，顺势而为比逆水行舟容易的多，不要想改变世界。　　如果在以上几点你都能做到中国最优秀之一，那就放心的去冲，只要有位置有流量，自然会有转化，销量自然会节节高升，如果单纯靠刷单，即使能够到第一去，转化低的话，很快位置会下来。目前淘宝已经过了靠运营就能做好淘宝的阶段，现在比拼的是综合能力，而核心是产品，有了好的产品，加上适当的运营，必然会脱颖而出的。
　　电子商务平台在建设上如果能做的好也是电商未来营销运营有一个很好的规划和基础奠定。在平台开发上蒙特可以给大家分享一些好建议。　　一、从电商网站浏览中了解你的客户　　1.不要急于实现网站搜索　　小微初创企业不用急于实现搜索功能，如果你的产品类目一开始就很窄，用户没什么可搜索的，所以你能做的就是优化网站浏览性能。最好不要过早推出跳转外部链接这样的搜索功能。当浏览的作用发挥到极致，你的网站最终会有成千上万的产品，这时你就需要搜索功能来弄明白消费者怎样找到他们想要的商品。　　2.完善产品分类系统　　在建立电商网站的最初阶段应该集中建设网站的分类系统，以便将不断增加的产品归类。这最终有益于提供良好的用户体验，而且也无需陷入建立外部搜索的复杂过程中。电商网站在建立了综合分类系统后，不仅更容易找到商品清单，还能知道消费者是如何找到他们想买的东西的，这需要多次数据迭代和重复分类产品。蒙特做网站会发现导流的最好办法是立足于消费者画像。　　3.精确定位目标用户　　你的用户定位常常不是顾客自己认为的那样。给产品分类的方法绝非按照高级用户和初级用户那么简单，因为它们的界限很模糊，有太多产品同时符合两者的需求。　　4.重视用户反馈　　非常重视用户反馈，尤其是人们如何使用或评论网站的导航系统。如果你给消费者很多互动选项，就能根据他们对网站社区的参与情况将用户分层——对比，如：给某个商品点赞的是低门槛用户，写评论的是中级门槛，给你发私信或提出新的产品分类建议的则是忠诚用户。最重要的是让用户有参与感。给你的用户提议改善网站导航系统的权利，但是对你真正听从建议的用户设置高门槛。　　二、有效利用电商平台搜索就是为了提升效率　　1.在网站加入搜索功能的两种方式　　一种快而“下流”，即直接在网站上添加搜索服务，用第三方应用程序接口来处理产品索引，省钱省时间，适合没有足够的马力、员工或带宽来从零开始建设后端、分析部门和数据关联的初创企业;另一种是建立自己的搜索工具。　　2.拯救SEO　　最重要的是你要知道你的搜索系统是如何影响SEO(搜索引擎优化)的，尤其是当你正打算怒刷品牌存在感的时候。蒙特网站建设公司最好的办法是跟踪记录网站上的每个网址。也就是说，如果你变动了网站上的某个网址，要保证所有相关参数也同时改动，还要记得更改路径以尽量避免出现404错误页面。　　3.精确搜索结果　　最关键的是知道人们在搜索后点击了什么，首先要保证搜索结果是相关的。“面搜索”(Faceted search)是一种检索根据分类体统组织的信息的搜索技术，使用户可以依据多个特征来搜索一连串结果，就像订票网站和零售网那样，根据性别、年龄、价格区间等进行查找。当然，虽然“面搜索”很好用，但也不能添加太多。　　4.用好过滤器　　弄好搜索系统之后，你还要注意消费者用的过滤器。如果你经营的是Etsy(美国手工艺成品电商)这样的网站，人们可以在上面看到很多相似的产品，这样他们可能更在意产品的价格。但如果你的网站卖的是垂直类产品，消费者可能就对价格不太敏感，他们只是要找自己需要的产品，而不太关心需要付多少钱。　　三、电商平台如何引导用户　　每个电商人都想把用户留在自己的网站上，哪怕他们没找到自己想要的产品或产品缺货，这听起来很花时间，尤其是像亚马逊网站上那样的精确产品推荐机制。其实要留住用户，有一个不需要特别具体的用户数据的方法：如果你不能给消费者展示断货产品的替代品，那么就给他们推荐互补产品。　　你还可以用数据来完善用户体验，按照需求和兴趣细分用户非常重要，这样你首页上的产品才会正中消费者下怀。在引导用户方面，这里有一些建议：　　1.不要在用户购买之前强制他们注册账户　　对大多数电商公司来说，在消费者没下单之前让他们注册账户是没意义的。亚马逊和Etsy那样的大电商有足够多的影响力才有资本这么做。　　2.避免用花招来骗套消费者信息　　当你想了解消费者时，应该先确保他们信任你。除非你的网站是关于批量交易和特价产品的，否则要谨慎使用优惠券和折扣。如果你的差异性在于提供硬件产品，那么不仅消费者不太在意价格，你的品牌也会更集中于产品本身的差异性(而非折扣)。　　3.极简的“傻瓜级”支付体验 。 如果你允许消费者在不注册账户的情况下购买产品，那么你无法捕捉他们的信息和偏好，他们也无法回来查看自己的消费记录。　　4.把网站上“关于”部分最小化　　人们是去电商网站购物的，不是了解电商公司的。消费者需要简洁清晰的体验，找到自己需要的东西，买了以后就离开，要尊重这一点。许多初创企业都会倾向于说很多关于公司的信息，但没法让消费者记住，所以还是集中精力做好购买体验吧。但是如果你正处于积极招聘人才的成长期，加入一个描述你们团队背景和文化的页面还是非常必要的。　　5.想出“打动”消费者的地方　　你的一些消费者也许对价格很敏感，但另一些可能更关注质量，这当然取决于你卖的是什么，但无论如何，你需要在这些特质的基础上给消费者分组。举个例子，如果某个产品卖爆了，你就应该更关注如何提供更好的、更有参与感的同类产品。　　6.知道你的消费者私下的容忍限度　　虽然一些消费者在消费过程中可能接受过量身定制的推送产品，这仍可能让别人感到被监控和不舒服。这时应该非常坦率地告诉消费者你正在匿名地跟踪记录他们的消费行为以改善网站和服务，而不会侵犯他们的隐私。要理解用户的核心目的，然后与他们沟通反馈，这样他们就会开始认为你的品牌符合他们的需求了。　　四、电子商务平台创造最好的购物车　　虽然购物车已经在很大程度上过时了，但这并不意味着你可以停止创新。大多数人在亚马逊和其他大电商网站出现后就不再塑造自己的购物车了，因为他们认为人们已经习惯了大电商网站的那种结构。但你应该明白的是那些公司有他们的竞争优势，可以凭自己足够大的规模引导消费者做任何事情，而不用将用户的最大利益时时刻刻记在脑中。但是初创企业没有这种优势，所以大电商做的事情对你来说不是最好的选择。　　　　五、不要错过获得电商平台付款的机会　　1.选好支付系统　　明智的做法是在网站上整合3种支付方式，然后再根据网站用户数据选择最优。最重要的是要保证你没有过早加入少数人要求的或在硅谷比较流行但无法融入外界的支付方式。　　支付系统的好坏关乎初创企业生死。如果你建立的是全球配送的国际业务平台，你需要谨防诈骗，消费者很容易成为受害者。这就是为什么用PayPal或Stripe这样的支付系统比较好，他们很善于处理诈骗问题。　　2.简单最好　　在购物车和支付系统方面，最大的挑战是防止过度优化，让一切保持简单。如果加入太多有创新的但不必要的东西，你会误入歧途，并且作为初创企业你也耗不起那些时间和资源。　　对于，电商网站建设蒙特技术和实力被万家客户推荐，没有更好的，只有更适合你的---蒙特!
请遵守言论规则，不得违反国家法律法规回复(Ctrl+Enter)电子商务促销优惠组件设计 - ITeye问答
现在各大电商都有自己的促销优惠方式，满减，立减，折扣，现金券，返现，积分抵现，赠送积分，使用范围也可能是单种商品，大类商品，单笔订单等，优惠环节涉及购买时，订单时和支付时，可谓非常纷繁复杂。
现在我正在开发的电子商务平台有商品Goods和货品Product，有订单Order和订单项OrderItem，我希望能尽量减少与现有功能的耦合，而设计一个尽可能全面覆盖上述优惠促销的组件，并可在以后进行扩展，现在初步有一个设计雏形，但是实际过程中发现还是太复杂，并且不得不开始耦合了，所以决定停工重新整理思路。
希望有能人给点思路和建议
问题补充：多谢各位的帮助，感觉还是规则引擎最靠谱，我决定使用规则引擎试试看。
问题补充：最佳答案给了第一个回复我的chinaagan，在评论中提醒了我规则引擎，原本我自己写，其实也就是写一个类似的东西，但是肯定没有主流开源的功能强大和专业
采纳的答案
如果统一来处理是很麻烦的，跨多个应用边界了，购买、订单、支付多个环节，并涉及不同范围及相应的不同的促销优惠方式。。。根据应用边界拆分成购买、订单、支付环节吧。。。个人意见，如有雷同，纯属巧合
去年我们也做过一个类似的促销系统，目的跟你们一样，也是想把促销的内容从现有的平台中解耦出来，可以跟你一起探讨一下，先说下我们的思路吧：
1.提供一个促销管理程序，自己人用，可以在上面添加订单满金额、产品满金额或满数量的一些促销，种类包括立减、打折、买赠、送积分、换购、送券等等，可以设促销地区时间，到时间自动启用停用，也可以设各种促销的档位，满100怎么着满200怎么着，以及是否可以累计。
2.再提供一个促销计算接口，客户进入购物车的时候，调用一下促销接口，把购买的产品ID传过来，计算接口实时算出促销并回传信息。
大体思路就是这样，缺点是促销是实时算出来的，可以应付一下中小型的电商系统，访问量大了肯定会成为瓶颈，如果楼主有更好的思路，我们可以一起改进！
这个问题其实是非常麻烦的，因为涉及到业务太多了。想完全解耦完全是不可能的。说说我的思路吧。
1 首先可以定义出各种促销方式，金额，数量，附赠品等
2 对于某种类型的促销方式，使用的规则是什么。可以自定义一套规则来定义其形式，拿金额来说，可以通过读取数据库拿去指定货品的金额打折方法，然后计算金额，最终得出一个折后的金额。
3 对规则的定义。考虑到不同产品的规则不一样，规则的指定肯定是针对单品来算的。
其实对于我们来讲最终关注的是最终优惠后的金额，所以我们只需要记录处每一项单品的原始价格以，最终价格以及优惠方式即可。这样就可以完全了解整个订单的所处优惠方式以及计算策略了。你所说的订单和订单项，无非是总订单信息和详细订单信息，对应关系应该为1:n，这个完全是不需要做处理的。数据库方面应该添加些字段即可。
关键就是规则的定义，建议你在这方面做一个详细的分析，比如影响规则的纬度，规则定义的范围等等。另外，象携程网的话好像就是出了你这样的类似的一个规则引擎，用于机票和酒店的打折优惠的。这个不好做，但是还是祝你成功。
优惠改变订单的不外有三种
1.改变数量。
2.改变金额。
3.增加物品——积分，点数，金券或实物等。
我的考虑，订单估计要做两份。
- 原始订单
- 优惠处理过的订单。数量，金额或物品（其他Item）的变化。
优惠引擎，接受原始订单，生成最终订单。
不知道你说的耦合发生在什么地方，优惠引擎依赖订单是必然的，订单部分就不用依赖优惠引擎。
这种单向依赖还可以接受吧？
至于单件商品和整体的计算逻辑在优惠的设计范围内，这里又不会有什么耦合发生的，对吧？
倒是支付，能否使用积分，点数或金券等这些支付逻辑，恐怕要做为订单属性和订单绑在一起的。
举例来说：特价商品不能用金券。
- 优惠——特价商品。
- 原始订单。
- 优惠处理过的最终订单——总金额减少了，并且被添加了不能用金券的属性。
- 支付时金券被无效。客户需要按最终订单的金额付款。
大致如此，随便聊聊。
祝好运。
你们商品和货品有什么区别
新手路过，感觉要用到策略模式
已解决问题
未解决问题从0到1构建一个电商平台 – 开发篇(转)-爱编程
从0到1构建一个电商平台 – 开发篇(转)
文章来自 在外企和互联网碰撞的猴子 的微信公共账号。是我们跨境电商项目的架构师写的。我们项目的每个点读提到了，方便记录查找，我转载一下。
针对如火如荼的跨境电商行业，催生了提供一个SaaS电商平台为一些传统企业和机构开展跨境电商业务的市场机会，所以我们有机会来做这件事情。今天重点讨论销售和运营系统，不涉及跨境贸易价值链中的采购、通关、购汇结汇以及支撑电商业务的CRM，OMS，ERP等系统。
团队成员-最初由3名具有比较丰富企业级电商平台开发经验（&6年）的资深工程师组成，经过1年发展，团队规模成长到30+工程师。
1.&领域驱动&– 基于自己对企业级电商平台设计和开发的丰富经验，进行领域建模，并将领域映射到业务子系统，划分高阶系统边界
2.&分布式、服务化&- 吸取企业级电商平台的经验教训，各业务子系统独立开发、测试和部署，子系统以服务暴露自己的能力，子系统与子系统之间以服务进行通信和交互。这一点可能会有些争议，在业务发展初期，整个系统的容量不需要那么大，分布式是不是设计过度，特别是在部署上对一个小团队来讲也很难驾驭。在项目中途我也曾经深深的质疑过这一点，但是慢慢也体会到它带来的好处，放开分布式架构带来的未来系统更容易更灵活的优势暂且不谈，至少每个业务子系统能比较独立高效的开发，测试和部署，在一个高速发展的团队，不可避免的沟通会成为一个巨大的挑战，这种独立性可以很大程度减少一些艰难和低效的沟通。
3.&持续集成&– 从第一天开始建立持续集成的体系和流程，保持开发、测试、部署的高效性
第一阶段（2个月）
在人员有限的情况下，以一个业务领域切入，构建业务子系统，确定基础技术选型，提供业务子系统的样本项目工程和框架供后续业务子系统开发参考。因为交易是电商平台最重要的一个业务领域，并且涉及到跟几乎所有其他业务领域的交互，我们选择交易子系统为切入点。
基础技术选型：Java+Spring作为服务开发的基础框架，MySQL存储交易数据，RestEasy作为REST服务框架，子系统间的服务调用使用Hessian。因为团队成员曾经在淘宝交易平台的工作经历，整个服务框架基础技术栈的的选型深受阿里的影响。
1. 一个业务子系统由-app, -client, -server三个项目组成。其中app是controller层，通过RestEasy把服务以REST接口发布出去；client暴露了业务服务接口及Domain对象；server提供业务服务的实现。这里app不会直接调用server，app需要调用业务服务也是以client为入口。这里主要的考虑是基础服务和应用服务这两级服务的概念。这个概念相信了解淘系系统的人不会陌生，基础服务只提供对核心领域对象的基本操作（典型的增删改查及基于此的一些基本操作），应用服务一般对应一个业务场景，需要调用一个或多个基础服务，进行串联、聚合或其它计算处理。例如：购物车的增删改查是典型的基础服务，而计算购物车时一个典型的应用服务。这样设计，随着业务量的增长，系统未来更容易向微服务架构演进。
2. 业务子系统打包成WAR部署到Tomcat需要一个web项目，-web，Web项目里，包含datasource，hessian服务发布，声明包含哪些业务子系统，以及配置文件。因为在项目初期我们需要支撑的业务量还没达到一定的规模，出于成本控制的考虑我们需要将多个业务子系统打包发布到一个WAR中，所以这里出现了需要在Web项目中声明包含哪些业务子系统。未来如果需要从一个WAR中将一些业务子系统拆出来单独发布，也比较灵活。
3. 服务调用框架，说到这里，大家第一反应肯定是Dubbo，在项目初期，我们并未使用Dubbo的方案，主要是考虑到团队成员并没有Dubbo使用的经验，而且在我们并未产生大规模分布式服务和服务治理的需求时，Dubbo的使用在项目初期反而可能成为我们的不可承受之重，把Dubbo用起来并不难，难的是如何驾驭它。所以我们选择使用DNS+Load Balance来做服务发现，基于动态代理实现了Hessian/Local/Mock的服务调用机制（Local主要用于不同业务子系统部署到一个WAR中，Mock主要用于UT），每个Web项目提供一个服务调用的配置文件，配置这个Web项目要调用的服务的调用机制和服务endpoint，因为我们使用DNS+Load Balance来做服务发现，所以服务endpoint都是Load Balance的地址。
4. 分布式日志，分布式服务调用如何跟踪一个请求的整个服务调用链条，是我们必须要解决的问题，基于Google的Dapper论文，淘宝实现了EagleEye。其实Dapper的原理并不难理解，我们选择自己实现请求的global ID并在分布式服务调用间进行透传，与ELK（ElasticSearch+Logstash+Kibana）相结合，可以比较清晰的呈现一个外部API请求跨系统服务调用的所有日志。
5. 缓存的使用，对于内容型数据（例如：价格，商品税率），使用Redis缓存，这里特别要注意防缓存穿透（当数据库记录本身不存在每次都穿透缓存去读数据库）；对于配置型数据，使用Local JVM缓存（未使用EhCahce,自己实现MRU和缓存空间设定，主要原因是以前项目有相应的积累，可重用）；对于操作型数据（例如：购物车，库存），使用Redis缓存，操作型数据里，特别是购物车读写同样频繁，在高并发环境下容易因为缓存更新失败而导致缓存和数据库数据不一致，需要使用MQ记录不一致情形并通过Listener应用执行缓存失效。
6. 图片服务器的使用，团队小伙伴以前有大规模应用TFS的经验，给我反馈是TFS算是淘宝开源作品里为数不多的精品，刹那间我是有点心动的。现实马上打醒我，小伙伴需要去做其它更重要的事情，TFS这玩意，等我们图片规模大到一定程度必须自己来做图片服务器和存储系统再考虑吧。于是我们选择了七牛，很完整的图片管理和CDN服务，算下来一年的价格也不贵。当然第三方服务始终是不可靠的，我们也专门引入了assets的业务子系统管理图片及图片在服务器上的元信息，这样在将来比较容易的迁移到其它图片云服务或者自己使用Nginx+TFS。
第二个阶段（4个月）
随着人员的逐步到位，各个业务领域的业务子系统开始铺开进行开发，这个时候如何协调开发人员以统一的风格来实现各个业务子系统就显得格外重要了。而且，在基础框架和工具层面，也要尽量统一，减少维护的成本，所以，我们在开发团队里一直有一个由精兵强将组成的小组负责这一部分。
1. 数据库规范：包括每个业务对象对应的数据库表如何设定主键，唯一ID，唯一性索引，每张数据库的预留字段（创建时间，更新时间，创建人，更新人，乐观锁计数等）。
2. REST API规范：增删改查的URI pattern，特殊POST操作的URI pattern，API版本。
3.&通用参数规范：对语言，货币，请求ID，调用者等的统一命名和处理。
4.&领域边界划分：在划分基础领域边界的基础上，为了提高性能，减少不必要的远程服务调用，在业务允许的情况下，进行一定的冗余。例如：在购物车中不仅仅存储商品SKU ID，还包括商品的名称，商品缩略图链接，店铺名称等信息，避免在查询购物车时再去调用商品API获取这些信息。
5.&异常处理：提供异常基础类，基于异常基础类提供异常处理框架在业务服务层和REST服务层对异常进行统一处理。各业务子系统仅需扩展异常基础类，在业务代码中抛出这些异常即可。异常处理框架帮助处理剩下的事情。这样对于API调用者来说也是极其友好的。
6.&配置管理：在系统还没有发展到一定规模时，可能还不需要一个集中的配置中心。但是，每个业务子系统切忌分散管理配置信息，因为开发，测试，预发布，线上各种环境需要的配置很可能是不相同的，分散管理的配置信息在每次部署一个新的环境简直是噩梦。目前，因为我们已经的系统规模已经发展到10+个业务子系统，即使每个子系统都集中管理配置信息，如何高效的管理各个不同环境的配置信息已经成为一个非常突出的问题，我们基于disconf已经做了POC，计划在下一个阶段把disconf用起来。我本人是Netflix OSS的粉丝，本来Netflix Archiaus是我的首选，但是考虑最近接触的国内开源的工具越来越好，社区也越来越活跃，我们果断的选择了disconf。
7. Session：在这个方面我们是走了一些弯路的，已开始我们有规划专门的session service，并且与shiro做整合，后面的session信息存到Redis中，这个已经基本开发完毕。但是在项目实际演进的过程中，这个阶段我们的前端应用里PC端和移动端商城都是基于PHP开发（基于Yii Framework），在PHP里已经有比较完整的session处理，我们后端的业务服务完全是无状态的，在这里再去使用这个统一的session service反到在项目时间特别紧张的情况下给PHP开发造成很多困扰，所以，我们决定短期内放弃session service，全权交由PHP来处理。在未来系统演进到前段多应用，甚至不同技术栈时在重新把它找回来。
8.&Scheduler和任务处理：对淘宝了解的同学一定听说过他们早期开源的TBScheduler和现在正在使用的TTD，还有最近当当开源的Elastic-Job，可是，对于一个刚刚起步的业务系统，对于这种任务处理还没到需要分布式的地步，所以，我们选择了从Quartz和Spring Batch切入，但是Quartz本身只负责调度本身，我们还是需要存储一些任务的详细信息和状态，要支持异步任务的回调通知状态，排他性任务，已经简单的任务流程编排，我们按照自己的需求，基于Quartz做了扩展支持这些功能。未来如果业务发展需要我们引入分布式任务处理的机制，我想Elastic-Job会是我的第一选择。
9.&统一登录服务：今天我相信在Java的世界里大家要实现统一登录服务大部分人会第一选择会是CAS。CAS对各种认证协议的支持未尝完备，后面也很容易挂自己实现的credential数据库。不过比较讨厌的是，CAS自带前台登录页面，这部分是基于JSP的，而我们的前端工程师全是PHP的，改造起来那叫一个费劲。虽然我们可以放弃它自带的JSP页面直接调用CAS的API，但是处理起来过于复杂，对于我们这个规模有限的初创团队有点不可承受之重。另外，目前我们团队在注册这个环节是直接绕过了CAS调用用户子系统的注册API，对于PHP同学们来讲也是很高兴的。
10. 非Java业务子系统：在电商平台中，从业务需求来讲，促销是非常复杂的一个业务子系统，各种不同的促销条件，促销次数限制，促销之间的互斥和组合，促销金额计算，和优惠券或优惠码结合使用，其实这需要一个高效的规则引擎，一方面能够比较清晰的定义这些规则，另一方面在执行期也能够在毫秒级能够完成对一个订单的促销计算，传统的Java+关系数据库建模是很难搞定的。已开始我们想基于一个开源的规则引擎来做，所以我们队Drools做了一定的研究，作为一个通用的规则引擎，Drools功能比较强大，但是也比较复杂，在我们只有1个开发工程师能铺到这个领域的情况下，也很难搞定；另外，Drools在实时规则计算的效率上也是一个很大的问号，而且促销管理业务工具对我们是非常重要的，基于Drools的规则定义语言来开发这个工具难度太高。我们最终选择了DSL，定义一套促销这个领域的专有语言，用JRuby来实现促销DSL的语义模型和语法解析器，一来Ruby的一些声明式语法特性是非常适合来定义DSL的语义模型和进行语法解析，另一方面JRuby运行在JVM中可以和各种Java库无缝整合。促销引擎分为4个子系统：DSL引擎-负责管理促销DSL定义，解析DSL转化为语义模式；预计算引擎-负责对促销规则进行预计算，将商品和其可能应用的促销进行关联（提高runtime计算的效率）；runtime计算引擎-在线为一个订单计算促销结果。优惠券引擎 – 处理优惠券和优惠码的生成，管理和使用。目前，我们的促销规则DSL定义，预计算结果和优惠券信息均使用MongoDB进行存储。其实即使这样，业务管理工具来管理DSL来表达的促销规则还是一个挑战，我们在两者直接加入了一层meta data层来做映射缓解这个问题，这就意味着业务管理工具只是DSL表达能力的一个子集，对于一些高级的促销，我们直接在工具上开放了DSL编辑器直接对DSL进行编辑。另外，促销引擎的4个子系统都已经利用Docker进行部署，也为我们系统向容器化部署演进打下了基础。
11. 前台商城系统和CMS：本身我自己在CMS上有一些研究，对WordPress, Joomla和Drupal都有一定的了解，加上电商运营的特点，对CMS的要求特别强，我一开始是打算在Drupal上往前走的。而且我们在Drupal上也做了投资，研究学习，POC，前前后后也有小三个月，但是慢慢我也发现一个问题：Drupal本身也是很完整的一个系统，加上生态系统，和电商的领域已经有很多交集，这给我的小伙伴造成了很多困扰，他一直在质疑为什么产品目录树，购物车这些Drupal都有现成的插件我们还要再去实现一套后端服务。虽然从架构上很容易解释，但是现实是当你每天面对这样一个系统时是难免会很纠结的。后来，我们找到了一个既有丰富的Drupal经验，也经历了去Drupal，自主开发CMS的小伙伴，一番沟通和探讨，我们决定放弃Druple，自己干。
我这里贴一下我的小伙伴给我的建议吧：drupal善于做cms，模块固然成熟，但是牺牲了性能为代价。我们的业务场景更加灵活丰富，结合了传统pc，线下收银，以及移动，o2o等各种场景。单纯的依靠定制模块开发将会是事情变得更加复杂且不可控。 采用一个流行且易用的开源框架，使得我们在迅速迭代与稳定架构之间获得了更好的平衡，同时也能更好的结合中国特色的市场需求。通过框架的crud功能，我们迅速完成了传统的cms模块。而通过mvc最流行的业务分层模式，我们更好的通过m层同后台进行了松耦合式的开发体验。使得整个系统既可以脱离应用层纵向拓展，也可以通过其他各种应用层架构（node.js agular.js）实现横向的拓展。drupal的缺点还有一些，比如社区陈旧，模块数量虽多但是优质模块很少。性能上因为其自身机制，当系统复杂之后容易产生性能瓶颈，且不利于开发人员trace。 如果采用drupal，我们将被迫用5-10年的senior phper去学习一个在中国并不流行的技术架构。基本是很难找到人的。换开源php框架之后，那么，只需要有几个senior的开发人员进行组织整体架构并review，就能利用中国大量的码农(coder)。
12. 业务管理工具：AngularJS+Bootstrap，这个应该没有太多争议，虽然现如今React.js如火如荼，可是在我们那个时候Angular还是更靠谱的选择，另外我们的工具应用选用了Spring的AppFuse框架，让他们能够更快速的开发前台工具应用，并方便的处理访问控制，多语言，前后台交互等问题。
单独的话题
1. 单元测试 – 节奏再快，资源再短缺，我还是坚守底线，大家做好UT，而且是基于mock的UT，前期在UT的投资虽然对于快速迭代的节奏来讲往往都会有冲突，可是它带来的后期维护的便捷和高效往往是值得我们付出的。
2. 持续集成 – 从第一天，我们就投入一个专职工程师进行来负责持续集成，Jenkins, Maven repostiory, Git的搭建，持续集成脚本的开发，持续集成流程的建立。这些在很多小团队看来不必要的投资其实随着项目的执行其带来的好处是会不断被放大的。我们采用chef来生成操作系统和中间件级别的标准image（例如：Tomcat, Nginx, MySQL, Redis, MQ, ElasticSearch等等的标准image），但是我们的持续发布脚本并未使用chef来编写，而是直接用ruby来实现的，这个主要原因是直接用ruby提供了更大的灵活性，我们在以前的项目中也有一定的积累。
3. 测试 – 很遗憾，我们的测试资源是在有限，在保系统功能的基本准则下，我们牺牲了API级别的功能测试，前期只能靠UT来保障了。这也有很多无奈，如果有一天测试资源跟上，需要第一时间把API自动化测试，和基于场景的自动化测试不上。
1. 配置中心，目前很痛的一个环节，前文已经提到，我们已完成disconf的POC，接下来就会使用。
2. 服务发现和调用框架：用不用dubbo?其实有其它更轻量的选择（例如：consul做服务注册和发现，hystrix/turbine做故障隔离和服务metris），我们现在的实现已经很小清新。另一个角度dubbo在国内的生态的确不错，基本上主流电商公司都在使用。这个留着慢慢纠结吧。
3. 错误数据校正平台：在高并发的场景总是不可避免出现一些异常情况造成错误数据，建立一套错误数据校正平台是很重要的，要知道客户投诉起来，运营抱怨起来，往往技术团队是最惨的。
4. 全docker化：目前除了促销引擎的4个业务子系统，其他还是使用的青云上的linux虚机，考虑到初期业务不大要节省服务器成本，我们不得不将一些业务子系统合并到一个WAR里面发布，如果每个业务子系统都能够docker化，就不需要这么费劲了。
5. API网关：目前我们的业务服务已经有需求要被外部系统调用（例如：联盟营销系统），如何将内部的业务服务暴露出去变成一个课题，我们需要引入API网关来解决这个问题，目前我们已经开始调研zuul。
6. 多租户模式下不同客户的个性化定制：目前我们只能做到前端商城的个性化定制和外部系统集成的个性化定制，核心业务层如何做个性化定制是需要解决的，我们以前有做传统企业级电商平台的定制框架的经验，但是在SaaS多租户的场景下这个将会是个巨大的挑战。
7. 压测体系：SaaS和传统企业电商平台的压测是很不一样的，如果评估线上环境的容量，如何持续的对线上环境做压测，如何模拟真实流量，现在这些一二线互联网电商平台已经积累了足够的经验，我们要做的，就是一步一步，吸取人家的精华，结合自身的情况，执行起来。
8. 运维体系：这是一个比较大的话题，我们可以单独再讨论。
版权所有 爱编程 (C) Copyright 2012. . All Rights Reserved.
闽ICP备号-3
微信扫一扫关注爱编程，每天为您推送一篇经典技术文章。