如何快速搭建开放、多租户的电商云平台

起源于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