起源于20世纪70年代的电子商务，如今在全世界的发展可以说如火如荼，不断推陈出新;当下国内家居、零售、餐饮等传统行业也相继搭建自己的电商平台，凭借着多年积累的扎实的资金与地面部队、线下运营推广的实力，结合O2O模式，逐步在电商领域发力!

随着越来越多的实力派企业向电商领域进军，技术上如何快速搭建符合行业特点，有利于企业快速试水，同时便于后续可持续发展的电商平台，成为了关键的技术支撑需求。

如何在两个月时间内，迅速搭建类似京东、亚马逊、淘宝、卓越、当当的电商平台?需要从繁杂的电商业务系统中找到主流，需要借助开放的力量快速丰富和完善功能;而且，我们不能陷入为每家企业单独打造独立平台的泥潭，这就需要多租户与定制化。

要实现B2C电商平台必须具备的所有功能，包括卖场、商品、用户、社区、基础设施、促销价格、交易、订单、支付、虚拟资产、供应链、仓储、配送、财务、客服售后以及移动App等系统，还要满足一定的性能要求，使系统具备一定量级的用户服务能力，防攻击能力和内容分发效率，同时还要具备一定的可扩展性，为将来的升级扩容做准备。

从寻找产品、各种信息比较、订购、付款、送货到消费者服务和支持，构成电子商务的基本流程，我们需要根据必须的信息流、资金流和物流，对必须实现的模块进行筛选，以满足基本可用的电商平台需求。以卖场、移动、商品和用户系统为例，电商平台基本的业务架构见图1;抓主“流”，无招胜有招，不受常规完整性限制，就大胆迈出了快速搭建电商云平台的第一步。

图1 电商平台业务架构

即便如此，要做到这些基本的功能模块，不仅需要对电商业务非常熟悉，包括订单管道、拆分、暂停、转移、锁定、下传等正向流程，订单取消、重拆分、病单拉回、退款等逆向流程，以及开票业务、供应链业务、销售、支付处理、出入库等流程，还需要在技术上设计出一套综合考虑各种因素的，非常合理的技术架构，使得整个电商平台具备良好的技术指标，满足高性能、高可用、高并发、低成本的要求，还具备良好的可扩展性，这一点很重要，否则就是不计后果的野蛮开发。

首先，综合业务与技术方面的考虑，这个平台必须是开放的。

业务上，开放，可以借力ISV和有开发能力的租户。每个企业都有自己的ERP系统，要实现最后一公里的无缝对接，完全依靠平台的技术力量是不够的。这个时候如果把平台的业务能力开放出来，提供足够细粒度的API，ISV或有开发能力的租户就可以自行实现业务对接，并持续更新。随着业务的复杂，越来越多的需求会使平台开发者难以应对，而ISV和租户本身对自己的需求的理解是最贴切的，可以利用他们的力量，同时并行开发多个服务，只有这样才能快速丰富电商平台的服务，并确保这些服务的实用性。

技术上，完全依靠平台开发者的力量，初期维护几十上百个接口还可以，随着服务的增加，就只有依赖一套自动化的工具和平台，实现服务的轻量化。

众多服务的稳定性问题必然在服务轻量化以后对整个平台的稳定性问题带来明显的影响，这就需要从服务入手解决平台的稳定性问题。包括将Http服务异步化，使用事件驱动减少线程等待，通过虚拟隔离线程池将过度占用资源的业务排队，从而限定不同的业务所占用的资源等。

与此同时，还需要解决质量保障的问题。众多的ISV开发能力参差不齐，项目管理能力和开发风格也不尽相同，我们不仅需要制定一批规范，约定服务展现方式，包括窗口大小、ICON大小，颜色风格等;还需要制定完善的评审与上线流程，对于不同的服务，要求提交不同级别的测试报告。我们鼓励所有ISV服务都布署到云鼎或云擎平台，以便更好的管理并保障服务的稳定性和可用性。

以上这些都是根据用户需求和技术的需要，顺理成章。在解决了API的开放可用，以及基于开放API开发的服务的正确性和稳定性之后，我们需要一个服务市场供用户挑选和定制。随着服务的日益增多，我们的平台用户可能不知道自己已经购买的服务放到哪里去了，对于同一类服务，比如卖场、购物车、商品管理或交易管理，有多家ISV开发的多个服务，用户不知道该选用哪一个。这个时候就需要把这些服务在用户的桌面上聚合起来，便于用户查找和使用服务，引导用户使用更优秀的服务。尤其对于租户，可以提供Mobile Phone、Pad、WebBrowser、PC，包括Windows、Linux、MacOS、Android、iOS全平台跨OS的开放系统(架构见图2)。

图2 开放系统架构图

对于商家，可以通过Web、PC和移动端访问开放系统和其中由ISV开发的商品、交易、数据分析类应用;对于ISV可以通过Web访问管理站点;对于开放系统运营商则可以通过Web访问运营后台，进行ISV注册用户的维护、服务的审核等。

在Web、PC与移动端，开放系统通过一个壳将ISV开发的各类插件性质的服务聚合到一起实行统一管理和消息传递;这个壳和各个服务将调用服务器API，通过官方SDK、第三方SDK或直接调用开放系统API、第三方API，并在规范的开发框架下完成服务功能的实现。

所有API依赖于平台运营商和第三方提供的数据，建立在云平台基础之上。

接着，多租户模型的设计是必须面临的技术问题。不是说如何实现多租户，多租户模型已经是非常成熟的技术，已经有类似Salesforce这类的成熟应用将其实践到极致;这里面临的是如何在短时间内，快速搭建的电商平台中设计多租户模型，兼顾系统功能与开发效率，同时具备良好的系统可扩展性。

通常，多租户模型，一个实例服务一个租户(企业用户)，通过创建不同的实例来实现服务的虚拟和自动扩展。与虚拟化技术最大的不同在于，虚拟化主要是指虚拟主机、内存等资源。

按照多租户模型，如图3所示，我们应该在AppLayer动态创建多个实例，分别服务于不同的租户;如果是单实例同时服务于多个企业用户，可以称之为多用户模式，在这种模式下，用户登录时通常需要选择企业名称或ID;在DataLayer通常采用共享数据库实例、共享表的方式存储多租户的数据。

图3 多租户网络架构

应用层如图4所示，通常在一个应用集群运行着多个应用实例，应用的实例将根据租户注册情况动态创建，根据用户使用情况动态调整和管理资源使用。

图4 多租户应用层架构

多租户模型所创建的多个实例是需要自动部署的，这就对系统的自服务能力提出了要求，在短期内有两种方案可以考虑。

一种是依赖云鼎、云擎平台，先实现多用户的方案，利用云鼎、云擎平台自动生成数据库实例。在企业用户少的情况下，是有利于快速搭建电商平台的。结合开放的需求，需要实现并开放基础的API、定制功能的API以及由定制功能生成的API(可分步骤实施)。

一种是暂时多租户共用实例。

如图5到图8所示，数据层通常有A、B、C、D四种架构，实现难度逐步增加，对开发团队的技术要求越来越高，租户定制功能的灵活度也由低到高。

图5 多租户数据层架构A

在私有库模式下，为每个租户单独创建一个数据库实例(或在一个数据库实例中创建多个数据库，这里将这种折中的模式归入此类)，每个实例中运行着一套完整的业务表，在数据库内部，跟单租户系统没有任何区别。

图6 多租户数据层架构B

在私有表的模式下，每个租户将共享一个数据库实例，但在数据库实例内部，为每个租户创建一套完整的业务数据表。

图7 多租户数据层架构C

在扩展表模式下，基本表将负责每个租户独立数据的独享存储，扩展表将使用租户ID共享存储所有租户的定制数据，扩展表的字段类型通常是固定的。这种模式通常也采用私有元数据表、共享扩展表的方式来存放数据。

图8 多租户数据层架构D

在共享表(通用表或公有表)模式下，大量的表中存放着多个租户的数据，通过租户ID来区分和隔离，对于定制化的信息通常采用统一类型(如varchar)的稀疏列;由于存放了所有租户的数据，数据表和数据库的数据量都会很大，通常需要使用散列分区技术的大数据库系统。

从实现角度，实现最快的模式是应用层多用户+数据层A架构，次快的模式是应用层多租户+数据层A架构，效果最理想的是应用层多租户+数据层D架构。

数据库表的设计时，租户ID的设定，要有全局唯一的ID，每个租户的数据ID(如订单ID)要能够独立从1开始展现。

如果为了避免联合主键(联合查询，SQL语句会非常麻烦)，可以考虑“7位租户ID+11位数据ID”(数字或字符)，展现时取出后面11位的展现，同时存放租户ID方便应用使用。

如果更多的照顾到使用方便，可以使用租户ID与数据ID分开设计，以SKU-Price为例，如图9所示。

图9 租户ID的设计实例

定制可以先支持Logo、首页商品推荐区名称的设置、推荐商品的设置等，后期逐步结合模板实现复杂的UI(颜色、字体、布局等)、表格、业务流程和权限定制。

不同租户的定制功能涉及到开发量，不可能做到极致，解决的办法，一方面是依赖租户自身的开发力量，一方面是依赖ISV的力量，结合开放的需求，需要开放元数据表、数据表、透视表组合逻辑等(可分步骤实施)。

解决了基础数据问题，在UI和流程定制方面，需要制定一套完善的依赖模板的定制方案，如图10所示，是以Android系统为例的定制流程。

图10 模板定制流程

不妨自定义一套URI格式协议，包括协议头、host和activity名称和参数等信息，比如：“ecc://com.jd.eCloud/index=activityName?p1=v1&p2=v2”，在URIRequest中，与ISV约定根据协议写死地址，客户端只保留一套模板html页，从而实现不同的租户看到不同的展现。

另外，在开发组织与项目团队的管理方式上也需要辅助使用一定的方法和技巧。传统的走正步形式的瀑布开发模型一定不适合快速搭建的需要。

看板方式，把工作细分成任务，写在卡纸上，贴在墙上，把栏命名好，来显示任务在工作流程中的状况。

XP敏捷开发的Scrum模型兼具了多重优点，是比较常用的方法。

把来自各个职能部门的产品、开发和测试人员聚到一起，分成不同的开发小组，把工作细分成细小、实在的交付成果，安排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。

把整个开发时间分成固定时长的短迭代(通常一至四周)，在每个迭代后演示新增可发布功能。

每个迭代中，ScrumMaster负责召开PlanMeeting，按照PO提出的优先级制定Sprint目标，创建SprintBacklog，以UserStory的方式分解成MVP功能点，估算工作量，承诺，生成故事卡、任务卡并上墙，开始维护BurndownChart，并定期召开SOS。

每个迭代发布后，经过评审，优化发布以及跟产品一起更新优先级别。

每个迭代发布后，进行回顾，优化过程。选用vagrant开发环境，可选ci/svn版本控制，通过cctray持续集成，通过代码赌场等活动提高代码质量。

如此快速搭建的电商平台，这里就关键几个架构问题和项目问题以及业务问题进行了讨论，具体在实施中如何在基础设施到网络架构方面做到高性能、高并发、高可用、高扩展、低成本，可以在单独的主题中进一步详细讨论。

http://www.csdn.net/article/a/2014-01-02/15817757