图书电商业务系统化之路

这是一篇写给业务部门的稿子,主要是阐述了业务发展下系统支撑的思路，并没有展开去具体分析，电商平台在商品、交易以及涉及到供应链部分的复杂度整体还是较高的。具体内容:
一、业务背景

信息系统作为电商业务的基石，在业务发展过程中，有力的支撑了多个业务环节的顺利开展。

我司通过多年的拓展和经营，逐步构建了涵盖线上线下的多渠道业务模式，不仅有大众类的图书电商零售业务，也有对电商大客户的供货协同业务，同时还有中盘 馆配、跨境电商、数字阅读等领域的业务同步开展，这些大的业务方向下，又包含了几家甚至几十家不等的店铺或者客户，各个方向不同的业务要求交织在一起，如何解决和满足这些差异点，变化了怎么办，就是电商平台要去关注的主题。

作为行业首家应用ERP的企业，依托SAP成熟强大的供应链管理能力，支撑了商品、物流组织所涉及的系统问题，电商平台更多的精力集中在解决销售组织、交易、物流、结算环节的问题，这些环节主要有以下特点:

• 以依托各类电商平台完成销售业务为主，线上线下并行
• 业务方式多样，包含了B2C、B2B、COD、EDI、JIT、协同仓等等
• 店铺、客户需求的品类多、折扣、商品信息差异化、多样化
• 各业务共享电商仓库存，SKU更新的准确性、及时性要求极高
• 主要经营纸质书，同时也存在电子书、百货、卡券等业务
• 全国多点仓储，交易订单需要合理拆分、巡仓、作业
• 通过组织型物流覆盖全国，灵活的配送方式选择
• 各业务销售波动大，大促期间业务量突增50倍及以上

这些业务主要的特点都对电商平台的架构以及功能产生着方方面面的影响，也对系统提出了自身的需求:

• 能够快速响应业务变化
• 能够适应业务快速增长
• 能够保持业务过程中的风险可控

这里可以举一个实际的例子来说明一下：

 

我司积极响应国家“互联网+税务”行动计划，决定从9月7日启动实施电子发票，当业务部门正在方案调研阶段，接到通知无锡仓于11月1日，必须切换到电子发票，当地税务不再提供卷式发票。

       当时项目组收到这个消息，距离正式切换时间只有30天，接着就是双十一大促，时间紧、任务重，最后通过多方配合，确认业务需求，加班加点进行系统调整以及功能开发，顺利在10月31日，开出了第一张电子发票。

       由于电子发票需要和第三方平台打通，获取用户领取电子发票的链接地址再发送短信给客户，我们还将网页地址通过短链接编码技术，把每张电子发票所需的2~3条短信，成功的压缩到1条短信，这样一个小小的优化点每月便为公司节约费用1万元。

这样的情况，在电商平台建设过程中是司空见惯的，如果不能按照外部约定的时间完成系统调整，带来的是业务风险以及业务损失，更不用谈支撑业务的快速增长了。

二、系统支撑

上面提到了的业务特点以及对系统的需求，那在线的电商平台又是怎样去建设的？

 

       随着互联网的发展，信息技术广泛的应用在了互联网以及传统的企业级领域，除了大家所熟知的大数据、云计算外，SOA、微服务也是其中的一项，它是我们应用到电商系统建设的一种基本思想理念，根据业务发展舍弃传统的单体应用开发模式，通过共享服务的方式进行系统建设，最大化的减少了业务功能重复开发，从而能最大化的复用原有的业务流程以及功能，达到快速支持业务开展的目的。

技术团队从2015年开始对原有系统进行了服务化拆分，开始了从单体化系统向分布式系统的过渡阶段，先后进行了库存服务、价格服务、商品信息服务的调整，预计到2018年能完成整体的系统服务化架构调整，届时，在服务化架构下，电商平台将为业务提供更大的灵活性，并且可以随着业务的变化而迭代演进，这也是目前主流电商企业所采用的一套架构思路。

通过服务化建设，电商平台会形成前台应用+平台系统+中台系统+后台ERP的整体架构。

        前台应用主要承担各业务线的经营组织和管理，例如直销官网、新西兰网、网店运营平台、客服工作台、基础管理平台等。

平台系统主要包括对接平台、开放平台、抓取平台，这些平台主要保障电商平台与第三方平台之间的数据通路。

例如开放平台:

将自有的商品，供应链服务能力开放出来，方便有开发能力，运营能力的商家对接，

通过系统对接，可以打通合作伙伴和电商的交易中心、商品中心、配送中心等服务进行无缝对接。

通过开放平台，第三方独立软件开发商可以为卖家或者店铺开发独立的商用软件系统，并共享电商的交易，商品，物流，客户资源。

中台系统包含了主要的共享服务，它们为各个业务线提供共享的流程以及处理逻辑，例如交易处理、库存处理、用户信息等等，

它们包括:渠道中心、商品中心、交易中心、配送中心、用户中心、营销中心、结算中心

通过这些业务中心，系统会把各类业务数据进行不断的沉淀，再通过大数据技术进行清洗分析，进入BI系统为业务提供经营决策分析。

 

三、系统保障

       说完系统建设，再跟大家聊聊系统的保障，我司的多数业务都是在线上开展的，这就要求我们的系统7×24小时的能够提供稳定服务，如果系统出现问题，带来的是直接的业务销售损失，如何来保障这样的要求、出了问题又怎么处理?我们认为需要从以下两个方面进行保障：

1. 在人员组织上进行保障

在2017年，技术中心增加了业务运维组，这个小组的职责便是监控系统的运营情况、收集跟进业务部门反馈的问题。在监控岗位的同事，会对问题进行信息收集、信息定位、信息通知、总结沉淀。

2. 通过技术能力进行保障

• 全局基础设施稳定性风险

高可用风险：数据库故障、中间件故障、硬件网络故障

• 外部链路稳定性风险

服务能力风险：容量不足、性能不足、上下游依赖系统故障等

• 内部稳定性风险

代码Bug、配置错误、业务数据异常等等

对于梳理出的潜在风险点，需要进行事前的监控、定期的检查，定期对出现的问题进行沉淀总结，形成预案。

关于系统保障，关键还是在于查漏补缺，总结经验!

四、团队

业务不断地突破，离不开每一个人的努力，在技术团队里，需求流程、研发流程、测试流程、运维流程、监控流程等环节，都需要每一个人来高质量的完成。技术团队也是一只以80/90为主的团体,我们热爱技术，热爱阅读，也将用技术服务于同样热爱阅读和知识的客户,我们也永远在路上。