VIP不同阶段发展历程的商业模式演进
唯品会在2008年12月创立，一直到2012年，唯品会在做的主要事件就是尾货的抛售，做线上的outlets商家。这种商业模式就是帮别人消化库存，但是这个库存消化完了，现在特卖，公司的重点在发生变化。目前电商被分为了分成了两类，一是平台级公司，包括：1、电商大平台：淘宝、天猫；2、通用B2C：京东商城；3、线上折扣：唯品会；二是垂直类电商，包括：3C类的苏宁易购、鞋包类的好乐买和麦包包、化妆品类的乐蜂网和聚美优品、百货类的1号店、服装类的凡客和梦芭莎等。品牌合作商会倾向于选择最大的网站进行合作，而消费者会考虑可以提供商品种类更全的打折网站，在品牌供应商和消费者之间的中间打折渠道商存在雪球效应，赢家通吃。因此，更多的品牌供应商提供更多的产品→更实惠的价格和产品选择→吸引更多的消费者→生成更多的订单→为品牌供应商增加销量→吸引更多的品牌商到唯品会→吸引更多的品牌供应商……
所以，从2013年公司上市到现在，唯品会一直在做多品牌特卖，依托特卖作为核心竞争力，逐步引入更多的业务领域运营。针对一个确定的供应商，VIP整个“货品”业务运营生命周期中包含四个重要的内容：物品体系，产品体系，商品体系和财务体系。
VIP的商业模式相对其他电商形态，一个非常大的特点就是需要针对供应商的每次合作都要进行全程的运作，确保每个环节都得到有效的控制，以及保证较高的运作质量。同时，由于VIP花费大量的精力对全过程进行管控，尤其是对货品的选择，具有VIP的要求和品味，这个也是VIP区隔其他电商最大的地方。目前VIP的核心运作体系是围绕货品展开，这也是VIP的核心商业模式，同时也在局部尝试把自己的整体运作体系开放给第三方的尝试，核心目的还是为自己的主业服务。
唯品会系统架构演变历程
单一应用架构
架构特点：单个应用；所有功能部署在一起；采用LAMP架构，PHP+MySQL
架构缺陷：所有应用部署在一起；任何一个模块出现故障将会影响其它应用模块；系统内部耦合度高，无法扩展；开发效率低下，发布困难。
竖井式垂直应用架构
a. 架构特点：
- 应用拆成独立的应用模块
- 各个应用模块独立部署
- 数据库拆分成不同数据库，由对应应用访问
- 采用LAMP架构，PHP+MySQL+Memcache
- 域名拆分
- 动静分离
b. 架构缺陷：
- 应用之间耦合度高，相互依赖严重
- 应用模块之间交互复杂，有时直接访问对方模块数据库
- 数据库单点访问严重，出现故障无法恢复
- 数据复制问题严重，造成大量数据不一致
- 系统扩展困难
- 各个开发团队各自为战，开发效率低下
- 测试工作量巨大，发布困难
分布式应用架构
a. 架构特点：
- 核心业务抽取出来，作为独立的服务对外服务
- 服务模块独立部署
- 数据库读写分离、分库分表
- 大量使用缓存，提高访问
- 系统间异步交互
b. 目前现状
- 服务化不够彻底，服务颗粒度过大，局部扩容难
- 应用间数据复制严重，数据不一致性严重
- 基础组件薄弱，日志，监控系统不完善
- 服务定义混乱，包含大量接口，接口定义重复
- 大容量访问下无法提供可靠性服务
c. 亟待解决
- 核心系统全面服务化：商品，促销，库存，用户等基础服务中心
- 基础组件：服务化框架，DAL层分库分表，缓存组件
- 加强监控，日志系统
- 异步化，限流，分流，降级，压力测试，异地灾备
电商运营平台关键设计
关键需求分析
业务架构的核心，在于通过一个完整的业务场景运营体系（orchestration）组装各种企业的业务能力，形成符合企业商业模式和运营特点的场景，用最有效的方式达成销售的目的；并在这个过程中，有序管理和运营好企业的各种能力资源，用最小代价达成最大的业务目的。
电子商务成功实施，应该至少具备这些基础能力：多终端支撑能力、统一支付能力、统一订单能力、统一商品管理能力、统一多渠道管理能力、快速营销落地能力、统一信息分析能力、系统功能扩展能力、最大化客户体验能力、系统高可用和安全能力、高性能能力、团队建设和发展。下面就一些重点方向进行说明。
平台和业务功能设计
遵从三个维度定义架构设计的原则
a. 内容可扩展性
- 针对电子商务平台上销售的各种商品提供动态支持
- 针对各种营销活动提供动态可支持性
b. 功能可扩展性
- 针对各种扩展功能需求，系统支持统一的方式扩展新的能力，并提供统一的管理
c. 系统可扩展性
- 支持对大量用户访问能力的平滑支持
- 支持高可用，高安全，并具有高的系统恢复能力
以基于“云”模式的服务端IT架构框架为整体策略，采用基础架构和功能实现分离的原则
a. 服务端：构建统一的云模式IT基础设施
- 基于标准化的设施，分别构建统一的IAAS层和PAAS层，实现资源的共享，提高未来业务应用开发的效率和可维护性，并提高整体设备的利用
b. 大架构模式：实现基础架构和app功能实现分离原则
- 功能开发团队
- 采用简单工具
- 关注流程
- 关注功能实现
- 关注数据处理
- 关注用户体验
- 系统开发团队
- 关注系统稳定性
- 关注系统性能
- 关注系统扩展性
- 关注系统可维护性
- 关注系统可靠性
核心模型设计
a. 核心商品offering销售场景规划
通过分析模型的定义，可以精确实现对每一个营销活动的分拆
b. 销售场景实例中的核心业务对象规划
完整的销售交易场景需要以下各种对象实例的互相配合
c. 促销活动结构规划
作用对象（target object ）+条件因子（Condition） + 优惠方式（Promote）+ 规则/约束（Rule） + 例外（Exception ） = 促销活动 （Active）
架构设计和治理
企业IT架构重构
构建一套全新的柔性的，适变的体系架构，能够持续演进满足未来业务和运营发展的变化需求，即从应变模式改造为适变模式。所谓应变模式，是指被动的等待业务的需求，不能提前预计各个层面的变化，系统架构，发放等都是被迫改进；而适变模式，则要求我们通过理解变化来管理变化，使新架构体系有足够的柔性和容忍的应对业务需求的变化。
基于企业架构模式，建立基于规范结构+互联网模式的高效体系，通过企业架构设计，对企业的各个运营内容进行清晰的定义和界定各自的职责和协同模式。
整个企业架构体系包含三个大的部分。
a. 企业架构：里面有多个组成部分，共同构成企业的基本结构和形态。
- 企业战略：企业的核心发展规划，业务形态，发展目标，社会责任等
- 商业模式：为了实现这个战略目标，企业采取的各种用于获取利润的商业形态
- 运营架构：运营架构实现对商业模式的落地，这个体系内包含企业核心能力，IT形态，企业数据等基础形态，不同的商业场景基于这些能力构成并实现运营
b. 运营治理管控架构：针对运营架构的实现和运作，规范和管理其实现，确保整体的规范性，效率和质量；
c. 演进转型架构：针对我们期望构建的企业架构体系，我们采取什么策略，路线等来逐步实现这个目标。
- 未来企业的IT应用包含两种关键模式，我们需要同时支持
- Head系统通过建模来实现支持业务变化
- Long Tail通过快速迭代和标准业务协议参与整体业务场景
- 未来的IT形态是“平台+应用”的模式，应用实现业务多态，平台实现企业业务应用开发使用运营一体的支撑
应用架构重构
总体架构如下图所示。
在逻辑架构层面采用大应用架构模式。如下图所示。
平台技术服务
技术服务是PaaS平台提供的、基于各应用组件的共通性的技术要求抽象的、为上层的业务服务和应用提供支撑的标准化技术组件的集合，并可以根据应用系统的建设进行而扩展，为业务组件和应用组件提供支撑，实现标准化要求，解决易用性问题；根据技术服务的实现方式，可以分为技术服务平台和技术服务组件；技术服务的消费者包含了业务服务和前端应用。具体如下。
服务总线架构采用软件服务管理和业务功能实现分离的原则。具体如下。
服务总线协议如下。
- Client端应用模块直接通过总线调用需要的服务
- 服务总线对服务调用做鉴权，并根据结果访问具体的实例
- 服务实例处理完需求后返回结果给总线，总线把结果返回给client
- Client端与服务总线之间的协议为REST
- 总线与服务实例之间的传输协议也为REST
总结：采用平台+应用架构模式构建SAAS模式的企业内部运营支撑平台。
- 实现对各种用户的统一接入，集中管理各种应用的接入和访问，实现一体化管理体系
- 提供统一的IT环境，为新的销售应用开发运行提供承载基础，通过标准化的基础设施保障最终应用的实现质量
- 对第三方提供统一的营销数据和功能服务；标准化营销功能和数据口径
业务服务重构
按照业务运营体系重构业务能力中心模式，能力中心以运营为中心，兼顾现状和发展；每个业务能力需要按照如下逻辑结构进行重构。
业务能力中心模式重构，核心重点在于三个部分：
a. 对外统一接口协议服务域：对外提供稳定，标准，符合公司整体业务和技术规范的访问接口；
b. 能力提供域：
- 核心能力域：是业务的核心对象，所有的业务处理通过核心能力域进行交互
- Legacy能力处理域：针对业务的不同状态进行处理
- New能力处理域：针对业务的不同状态进行处理
c. 业务运营支撑域：实现所有对外服务提供的一致管理，对多种不同的用户访问提供多租模式支撑。
