告诉你到底什么才是符合中国国情的「全渠道中台」？

【导语】：新零售时代已经到来，传统大型零售商家们也在追逐技术潮流，希望通过中台建设来支撑业务发展。然而中台建设非一夕之功，大多数的探索都折戟沉沙，踩过的坑更是不计其数。前事不忘，后事之师，本文就将以技术更迭为主线，通过传统零售行业的码农们一次次血与泪的教训，告诉你到底什么才是符合中国国情的「全渠道中台」？

楔子

零售战鼓隆，各家齐斗法

云溪论剑后，江湖出宝典

古有葵花经，现有“大中台”

没有“两个亿”，别想做中台

技术道业务道，自求条正道

各家纷説自己好

谁曾想，旧日零售江湖间现己变成了血海滔滔

你也说中台，我也说中台，到底什么是中台？

现如今随着“新零售”这三个字一再被提及，整个零售界都在提一个“神密的东西”，那就是中台。甚至中台被上升到了“推进企业数字化变形”的乃至直接促成企业数字化转型能否成功的地位了。

那么中台它到底是个什么样的东西呢？在人们眼中中台似乎犹如月球的背面一般神密。

在人们眼中的中台无外乎于上述类似的组件图，类似的图一再被各大零售商或者是不少知名软件商一再的提及。

它似乎有着“华丽的外表，沉渔落雁的面容，婀娜多姿的身段”？它只是利用了2009年TOGAF设计规范从顶向下的设计方法论把业务模块进行了LEVEL 3级别的一个分解的功能图而己，它只要业务架构师手绘一些功能甚至公司的一个BA用Excel做一个功能列表然后让稍微资深点的UI做一下布局在一天内即可以得出的一个picture而己。

多少甲方为了这么一张外面报价800-1,000块钱制作费的首图化了近千万、甚至上亿的代价了？甚至笔者在几个展会听到不少的开发商豪言“你要做中台？你公司干什么的？每年至少2个亿销售额有吧？没有？那您也别做中台了”。

中台的诞生

中台这个东西我明确告诉大家：它一点不神密，它也不是近3年的什么高科技的产物，早在2012年这个东西就已经有了。同时我本人在13年也已经用“中台”的理念制作了一套类似的东西我们在当时把它称为“SMART PLATFORM”，这套东西的代码我会在后面的章节涉及到设计和实现的时候公开它的核心源码、数据库表结构与设计思路，这个是属于我个人的也是没有问题的，各位也可以放心使用。

这种一体化全渠道平台的出现最早是在银行、金融界，在那个时候银行、金融、保险界的一些大公司面对着繁杂的legacy systems需要开始迈入“手机端、无线办公”端的时代，于是当时的人们想到把这么多的legacy systems是不是可以做成一个“大后台”。

在这个大后台中，把所有的业务功能进行整合，所有的数据使用一个或者是一套数据库以此来打通各个业务，解决掉数据孤岛问题，提高性能，降低不同系统间交互、接口转换，以及支持不同系统间数据交互的事务一致性时带来的昂贵的开发、网络延时与开销以及不必要的开发工作量。

但是，业界在根据这个指导思想进行开发时发觉问题来了！

如果仅仅是把所有的东西打包在一个“大后台”并不能真正解决IT的痛点，因为必竟它是一个IT系统。IT系统要考虑的东西除了业务功能，更重要和更有价值的地方在于：

性能

安全

可以快速响应业务的创新或者説甚至可以“加速业务创新”并以此来为业务赋能

以上説的神乎几神，我们中国人现在讲究的是“效率、实干”，要“落地”，要“接地气”，因此下面我们就用接地气的话来把上面这一段中台出现的背景、历史上经历的痛点来着重的讲一下吧。

直接使用零售场景来描述中台的诞生与过程

一个顾客在传统的零售场所的消费体验可以用下图描述出主要的“零售体验核心环节”

以上这个图，它出现在20-25年前的零售大卖场内，支持它的系统也是20甚至25年前的“作品”。这边需要着重説一句的是：截止作者写此稿时，现有大部分的大型商超竟然用的还是20-25年前的IT系统。这也正是近来各大厂商、业界宣了沸沸扬扬的“新零售”，“数字化转型”的原动力与由来（改造需要money, money，没有money没有利益何来原动力）。

因为，这么土的东西，直到现在终于有机会推翻它了。

言归正传，解读上图！

当一个顾客来到了大超市内，我们知道传统的大超市还会分不同的品牌，把化妆品还放到不同的位置甚至独立的橱柜，这就导致了客户要买什么东西，他会记得去问各个“导购”或者去服务台询问。

“哎呀，请问会员怎么办？”，导购人员会告诉他！

“哎呀，请问会员积分哪里积怎么积？”，导购人员会告诉他！

“哎呀，请问印花是怎么得到？”，导购人员还是会告诉他！

客户问错了人，比如説他去问“收银员”这把刀不是説买一把送一块肥皂吗？收银员通过话务机于是叫来了导购，但是导购也不知道，就又通过商场广播叫来了“促销人员”，促销人员当然知道买什么可以送什么或者打几折这些事喽。

于是，靠着不同的、严格的岗位、职责的区分，我们的商场尚且还可以运作。并且要知道那是20年前，国人的消费能力有小部分已经开始起色而市场上商品的供应还不如现在的“百花齐放”。因此一些国外的大型商超明显在当时是属于“朝南坐”、“躺着挣钱的”。

因此，大型商超在当时对于IT系统的定位是次要中的次要（很悲哀），而货物、商品甚至不乏国外进口商超内的商品在那时才是真正深深吸引国人的主要因素。

于是过了大约10年，这也是零售业黄金的10年，随着国人消费能力的越来越高，随着iPhone、微信、淘宝的兴起，零商开始迈向了电商时代。

于是这些大型商超、大型零售超市想当然的认为其实电商就是把原来站在各个服务前的一个个人肉导购、促销、专柜的这些个人取代成一个个的手机应用APP，于是，在当时的大型零售商眼里的电商也是类似下面这样的一个图。

先有了想法，通过“想法”有了下面的系统“架构”。

零售电商1.0模式

转型1.0模式

不要笑，当时一堆一堆的零售（在当时还算是比较有钱）设计出来的系统就是这样的。

“喏，要数字化，我把人变成了一个个的APP了，这不就是数字化！”

所以大家直到现在也能看到类似的案例：一些传统的快销、零售商用微信、用APP、用微信小程序哪怕只是做出了一个会员登记系统也会把它当成“公司内部巨大的创新”，也是基于这样的想法。

可是，它依旧没有从根本上解决客户的问题。为什么？中国客户的电商使用习惯是什么？

中国人的电商使用习惯

中国，人多的很、市场大的很，我们説我们是世界第2电商大国，这个世界上没人敢説它是世界第1。

那么多APP、那么多小程序、那么多微信公众号，而你只有一个企业实体却要做成“为了一个服务就放一个APP”的模式，比如説：我为了来一次“某干发”大超市、“某得福”网上超市购物你要我去下不止一个APP才能完成“会员、认证、购物、积分”本就应该集中在一个APP中的“功能”，甚至客户做一些兑换还要让我打开一个不知道什么地方的网页去登录一个网址才能完成兑换？你是不是觉得我们客户的时间太“无用了”？

张小龙説过：哪个APP可以每天占用客户30分钟，这个APP就是巨大的成功。

在百花齐放、百家争鸣的数字化时代，况且在当时淘宝连续使用4次双11打折活动打造了中国客户的使用电商APP的习惯后，你这边突然来了一个，有几个功能就要有几个网址、几个APP或者就算你是APP混合微信号，你觉得中国的顾客会买你的帐？

下载APP的时间是很宝贵的！

在当时，APP与微信间还没做到数据共享，因为背后的legacy systems还是孤立的那么客户一些登记、购买行为、数据、历史消费记录都要我们的中国客户重复的操作2遍、操作3遍......

对不起，中国顾客对于这种重复操作2次以上而做的事是在完成同一件事的APP的使用不会超过1次，1次就删掉你！甚至拉黑你！并且还会去朋友圈把你数落一顿。这就是中国人的电商使用习惯。

中国人喜欢 “一键式”，喜欢 “快速定位”，喜欢“3步操作内就完成一件事”。

所以，大型零售商们错失了第一次电商黄金发展阶段即培养顾客消费习惯的这个阶段，那么这些大型零售商也意识到了问题：

哦，这个问题出在后面的系统本来在打造的时候就是CS架构、本来就是一个个孤立的而导致的。

在此时，大型零售商还是没有意识到自己的危机因为这时阿里淘宝还没有完全起势，大家都认为阿里脑子有水了，连续4次的双11。再説了，他们卖的东西不如我们的有“品牌”，对吧？

那么现在大量的客户反馈説，你们的几个APP要变成一个APP才好用，所以大家就不约而同的想到了把后面的系统集成在一起，使得每一个系统不是孤立的对外服务了。

同时，业内不乏I.O.E体系等造势宣称SOA，于是乎在“SOA可能是未来20年仅有的发财机会”这句口号的带领下，零售系统的改造进入了“集成1.5时代”。

零售电商1.5模式-集成模式

2007~2012年是“集成模式”概念被抛出率最高的年代，它有一个名字叫“SOA”，SOA就是那个时代的“全渠道中台”。

以I.O.E为首尤其是IBM对SOA进行了系统化、理论化甚至到了产品化的密集布局与宣传，人们提起SOA一定会想到IBM或者是Oracle。

嘿嘿！

笔者突然想起2000年初时，有关于互联网的一个笑话：説人人都説这座山上有金子，于是所有人上山挖金子。结果挖金子的人没有发财，倒是山下那个“卖铲子的人”发了财。

系统集成就由如上图一样，复杂无比。

一堆的Legacy，每个接口不同，要把它们集成光开发人员的付出就需要花费大量的时间与精力，很多企业为了不自己去养开发团队，为了图快于是使用了各种商业级别的、恶狠狠的集成工具（SOA开发环境）乃至付出了小型机的代价来集成一堆的Legacy。

这些恶狠狠的工具的使用、错综复杂的系统间如蜘蛛网的连线的一切目的就是为了一个“one app can integrate all function”，一个APP所有功能。

看似是这么一回事，可是，这次一些“巨头甲方”们却付出了更惨重的代价！！！

上面説了，集成这些Legacy本身是一件很复杂的事，因此需要使用不少在当时被称为“RAD-快速应用开发工具”来做这样的集成，这样的工具基本出自I.O.E体系，动辄几千万RMB一套，甚至还要用上百万的小型机去部署。

钱花了，如果东西出来了倒也成了，关键是SOA还有一整套完整的“系统集成”体系化的概念。所以经历过SOA集成的都领教过所谓的“流程”。

大家知道，所谓流程是一套best practice，它是用来帮助我们更好的更有条理的在一个如此宠大繁杂的、多达十几个甚至几十个legacy系统集成中遵循的一条最佳途径，它并不是条条框框的死板的理论。

至于流程是否我们真的学到了？消化了同时是否运用得当？这是后话不会在本章展开，后面的章节我们会来讨论，我们就先説用SOA没有用好拿它集成完了的东西带来了什么样的噩梦吧。

好，下面是一个运行SOA系统集成理念集成好的东西，当年国内很多大公司就是这么干的！

这是后台用SOA理念集成好的东西，但是它在面临中国市场时又被打得体无完肤了。为什么呢？

因为在I.O.E准备恶狠狠的、用昂贵的SOA的RAD套件进行密集推销时，我们国内的电商已经开始面临百万、千万甚至亿万级的流量了。什么东西到了中国，都会使用到各种高技术，国外对这点非常想不通！为什么呢？其实事情很简单，因为中国的人多，人多那么数字化流量也一定大！中国人已经在开始思考解决大并发大流量的时候而国外还在考虑如何把“昂贵的铲子”去卖给大型零售商。于是，差距开始造成了！

一个欧州国家的人口甚至整个欧州人口加在一起都不一定有我们的一个门户级网站的流量的人口多，势必这些国外的“高大上”会遇到水土不服，于是。。。买完了铲子，更可怕的噩梦发生了。

频繁的CR导致系统开发维扩成本急剧上升

大家都知道，一个系统、一段代码它一定会经历“分析、设计、编码、测试、部署”几个阶段。如果这段代码有任何修改，它要再进行bug fix后再需要走一遍“分析、设计、编码、测试、部署”这几个阶段。

大家知道吧，很多供应商有时为了进入一家企业做项目，它们在一开始可以跳水价、可以大甩买甚至可以0元进入，那么它挣的是什么钱呢？CR！

对，有任何一个CR，如果再加上它是一个高大上的国外的所谓著名品牌，那么它的man day的费用会很高。比如説国内的人天单价在2,000~3,000，国外可能起板要收你4,000~6,000元的人天单价，其实人天单价6,000也已经算便宜的啦 ，你们真的没尝过8,000~1万、4万的人天单价呢！！！

那么对于这样的公司来説，它最开心的就是甲方给他做CR，最好你依赖它，改个接口都要靠它。接口一个收8万，爽啊！！！

好，一个复杂的系统集成完了，稍稍有任何改动，它牵连的可不只是它自己这一块代码，它会牵连到其它相关的代码，这种问题我们把它称为regression bug，为了做好regression bug的控制我们就要做regression test来保证我的这次改动不会影响到其它无关的功能。

要知道，系统集成和"系统融和”是完全不一样的。系统集成的内部就是一团“乱麻”，业务层代码咬合在了一起，改一个功能就会引发一系列连锁反映。

举个例子，国外的系统集成或者説是很多国内软件供应商并未真正把SOA的理念吃透、甚至在瞎用，它们的手法就有点像“把一个人放在病床上，然后为了给这个病人安装一根假手指而需要把这个病人的整条手臂先卸下来，装上手指后再把这个手给病人安上”。

它就由如下图哪怕是新增一个功能它要动到的也是一系列的“翻原代码”的行为，加上国内IT从2012年后发展越来越快，整体行业较浮躁导致国内程序员水平普遍很低。缺乏整体数据流、业务串联的能力，那么这样的改动引起的连锁反应会更大。

拿我司曾发生过的一个案例来説，要在原有系统上做一个大闸蟹打折活动，这种设计的做法就是：

设计数据库底层

制作DAO

制作SERVICE

制作Controller

制作页面

然后有任何bug，bug的修复会把整个软件开发生命周期从头到尾再来一遍，这样的事不断的again, again, again。

于是，一个活动做个80多人天，花掉十几万、二十万很正常。如果碰到“高大上”的外企来给你集成，那么把80人天乘4,000、6,000...那么做一个活动用掉个50万～80万，很合理呀。这就是我们很多国内的一 些大型零售企业在系统集成时碰到过的大血坑。

钱花了很多，效率又低，质量又差。

这次的赫兹公司花了2亿做电商做砸了正是碰到这样的一个血坑。

如果只是钱的问题还可以容忍，关键在这样的系统集成来到了国内碰上的最坑爹的是“系统并发”问题。

前面説了，国内的人多，数字化流量高，这样的一种其本身后台legacy system还未经过改造，只是遵照着SOA理念去做的系统集成出来的东西，是根本挡不了大规模的“并发”的，国内动不动就来个十万级、百万级并发。

这种后台实际上充满着“单体”应用的电商应用APP，实际上是一个连千级并发都撑不住的东西，于是花了钱又做不好事。很多企业没有死在“业务领域的竞争”中，而是死在了“在国内上了电商系统”这个原因上。

成就了一上电商就死，电商领域成了一个“95%的电商项目都失败”的“炼狱”。

于是基于“系统集成1.5”后又诞生了“系统集成2.0”模式，这次，卖铲子的又没有错过挣钱的好机会，于是它提出了SOA 2.0模式。

SOA2.0模式

这是I.O.E相关的体系们提出的SOA 2.0模式，它很理论。但是它在2012~2014年间在其理论框架的指导下诞生了不少衍生技术。

比如説它的“松耦合，高内聚，组件间无状态，外部模块间需要使用引用,强调系统整体监控、性能上的governance”，等衍生出了轻量级的Nginx、JSON API，ELK，NOSQL等一系列概念和组件甚至优化改造过了一系列之前的时代没有出现过的组件。

可是当I.O.E体系还只停留在提出这些理念和这些组件的时侯，而我们国内的电商正在发生着巨变。历尽4次双11消费习惯培养后阿里完成了40亿到百亿规模的转变，此时它开始做一件事，那就叫去I.O.E。不要你那些动不动几百、几千万的软硬件了，我们国人一切靠自己来还比你们做了好！

阿里去I.O.E引起了一股MySQL浪潮。而此时的I.O.E体系也已经日落西山了，IBM在惨败苏宁案例后退出了，很多SOA的精华其实从未被真正落地过，同时它被很多国内的开发商错误地理解和使用了，使用的目的也只是为了炒概念、卖高价。在当时，国内有超过90%的开发商认为：Nginx取代Apache，轻TOMCAT，JSON API，ELK，MySQL的组合就可以做电商了。

OH...MY...GOD！

首先理念错误、理解不透彻加上整体IT环境浮燥、只求实现不求精的风貌导致了又出现了一个API时代的怪胎，我们説API是一个好东西，可是它造出的怪胎更诡异！

先从开发团队来错误的理解SOA 2.0理念开始分析，下面是一个标准的从当时直到现在还有很多开发团队这么认为的一种项目分工上的划分模式。

我们拿Java项目来説，把系统划分成这么多子模块，再分别开发和打包以及分布式部署，这就是SOA！

一切看似那么的自然......那么的应该......那么的......最后在面临国内十万、百万、千万级并发时死得那么的惨。

淘宝惨烈过

JD也惨烈过

要不然怎么会出现“JD老刘的两把菜刀”的故事呢？以前去深圳学习JD 618保卫战时还听説这个“两把菜刀”是真事呢！！！

我们来看看工程项目上折的细又小、看似专业实际没有深入理解SOA 2.0时代的精髓而只学到了表面的东西，导致在当年产出的是一种什么样的怪胎吧。让我们直接从系统层面入手分析。

两个架构，先説一下其实都是“怪胎”；

尚且不説第二个“看似专业设计架构”，很多国内的供应商、软件开发团队还未达到或者只达到了前一种“通用设计架构”的水平，第二种架构再怎么説也比第一种要好一点，我们把它称为怪胎1.0和怪胎2.0版吧。

怪在哪呢？下面来分析怪胎2.0版。

场景发生在某大促的当天，在平时怪胎架构一点问题都不会发生，一切看似相当的正常和完美。而当大促这天一到，抢券、秒杀、折上折一开始：

Web层汹涌压力扑面而来，这时的反映就是用户手机APP端卡死、白屏、卡顿、没反映；

于是运维一看Zabbix，哇~所有Web服务器标红，业务老板在屁股后面催的紧“快点搞定”，于是运维紧急增加Web服务器；

好，Web流量进来了，tomcat层吃不消了，zabbix频频告警，老板在屁股后面又开始催了“怎么还没搞定？”。于是我们增加tomcat服务器；

tomcat扩了N个自以为没事了，加完后整个DB挂了，CPU飙升到100%以上，内存使用率高达95%以上，一堆的死锁，APP还是卡、白屏，这时已经距离活动开始过去了1小时了，业务老板破口大骂：“你们有没有做过电商呀，你们到底懂不懂，搞不定，滚”；

这时运维傻了......介个问题......需要研发来帮忙了；

好吧，活动第一天，失败。老板组织了研发、运维浩浩荡荡一大批开了个总结大会来研究第二天的方案，研发终于提出了靠谱的方案。很多内容可以走缓存，我们不该走DB的。于是大家开始了不要命的熬夜改造DAO层代码，把一些通用的都移到缓存；

此时，离第二天还剩4个半小时左右了，抓紧睡一觉吧，很多开发睡觉时还在做美梦，梦到第二天因为开发团队的给力付出我们终于顶下了流量，老板重点表扬开发；

第二天活动开始了，哇~一开始30秒时整个流量似乎比昨天大了2-3倍，这个很正常呀因为系统放开了吃流量肯定这个量超过昨天的量，然后30秒过了没多久，整个APP卡死、白屏。哈哈哈，再一看，缓存爆了，缓存爆了后流量落到DB，DB又来了一个CPU飙升到100%以上，内存使用率高达95%以上......

再加DB，DB加完后发觉第三天量更大了，再加Web，Web加完后Tomcat中间群被压跨了，再回到以上第3点

多少企业经历了上述的过程？我告诉大家一个值，超过90%的企业都有过上述的大血坑。

这个大血坑会造成不少创业型公司秒死、见光死，也造成很多大企业一整批IT被干掉，也造就了那传説中的“两把菜刀”。

这样的系统和设计它其实是由如下面的这样的一个怪胎的长相：

脑袋小，脖子细的要命，肚子大，下盘小。吃饭吃多了他就呕，走路一快他就摔！这么样的一个怪胎！

那么我们説系统性能没有做好？业务功能就一定做好了吗？

嘿嘿嘿，我们回看I.O.E体系们在SOA 2.0时代提出的一个概念图，再来看一遍这个图

然后我们结合以下的一个场景再来考虑一下：

小龙虾节活动，从数据库设计->存取层->服务层->控制层。从头到尾做了一遍，用掉了80多人天的价格。

来了一个阳澄湖大闸蟹打折活动，从数据库设计->存取层->服务层->控制层。从头到尾做了一遍，又用掉了80多人天的价格。

嘿嘿嘿，我们把以上深奥的理论，抽像成以下一个这样的业务场景大家看一下，是不是就可以理解为什么上述两个都同样是打折活动的业务场景分别都要用80多人天呢？

上图已经可以很好的说明我们的程序员是如何沦落到程序猿、码农的了。

性能达不到、加速业务、快速响应多变的由其是中国大陆市场几乎每天都在变动的业务也做不到，这是2005~2015年这10年国人特别是国内很多知名500强在电商领域经历的痛苦的10年，各种抱怨IT不给力。

IT各种想办法找I.O.E相关体系来做企业整体解决方案，钱出了一大波，然并卵，各种继续不给力、抱怨。。。。。。again，again and again！！！

而这10年，阿里和一些走在比较前沿或者説曾经在那10年内没有“死”的一些民营体制、特别接中国地气的企业已经开始深刻地总结反省，并依靠自身之前学习到那些外资高大上的一些理论、知识、方法论后把它们再“本土化”并结合了中国自身特色，继而打造出来了一个新的产物，这个新的产物就是“全渠道零售中台”。

回过头来看中台，什么是中台

也有画成下面这样风格的图

其实第二张图无非就是第一张的level3级别功能扩充了，比较丰富，颜色鲜明一些。

That's it，仅此而己！

然后很多外资包括国内的一些甲方型企业拿着这样的图説“这就是中台”......现在知道错在哪了吧。

我上面列举的1.0，1.5，2.0时代的任何一种架构，其实都可以做成这样的“业务功能图”。

这只是业务功能图而己，它不是代表"我“做出来的就一定是中台。

我们看事务不能光看“外表”，我们需要看事物的“本质”，遵循着本质的那些公司都成功了，如阿里、苏宁、保洁、立白、海尔、华为......有很多不再多叙。

那么中台的本质到底在什么？而且是一个全渠道中台，也有人管它叫云中台它必须具备以下几样东西。

从业务功能上来分

全渠道订单中心，它必须是一个全渠道的订单中心，订单属性拥有线上、线下、O+2、第三方等各种渠道的特性；

全渠道商品管理中心，可以管理线上、线下甚至是虚拟商品；

全渠道会员中心，这个会员中心一分为二，一个合格的中台需要具备其中的CRM Foundation即会员中心基础功能，另一个叫“营销中心”，对，整个会员中心由“基础功能+营销中心”两部分构成，而很多好的中台不一定包括这个“营销中心”，因为营销中心可以诞生出另一个全渠道的产品，叫SCRM。我们不要求一个全渠道的零售中台内必须包括全渠道营销中心，必竟术业有专精；

全渠道的促销中心，促销和营销很多人会搞起来，促销中心和营销中心在功能上是有相近的，有人把促销归为营销，也有人把促销和营销进行分离，分离的条件就是“以会员为中心”和根据一个企业内的业务组织架构来决定的。这一定一定是一个全渠道的促销中心，它可以对线上线下同时促销，説白了就是你在手机APP商城内使用的券同时也可以使用在自助机、扫码购、微信小程序甚至在同一个零售企业门店POS结帐时使用，让客户无论是在线上还是在线下消费时“无缝/无差别”体验，这就叫全渠道。不管你什么活动、打折、促销，它还都是可以支持图形化界面可配置的；

内容中心，它又被称为CMS即Content Management System。它可以把手机、微信小程序、Web网站通过图形化类似于Photoshop或者説它比较接近于以前的DreamWeaver或者是FrontPage的一种“傻瓜”界面把这些活动给配置出来，它在配置的时候是可以通过结合前面的促销中心去做“协同工作”的；

财务共享中心-支付渠道、支付中啦，支持各种支付，接入支付渠道时它也是可配置或者説是“半可配置”来完成一个支付渠道的接入的；

物流库存中心，支持全渠道的物流和库存，不管是自营、O+O、第三方还是自提，全部支持；

多租户管理中心，咦......这是什么东西？唉呀，很简单！都上全渠道中台了，你这个电商不可能只是面向垂直单一名牌吧？一定是类似于“天猫店”那种多商户玩法吧？也有人管它叫B2B2C或者干脆简称成BBC功能。

从技术上来分（月球的背面到底是什么）

我们前面説了，业务功能它的表现出给到大众的一面很美丽、很灿烂。可是它不是本质，它不代表全渠道中台，我们需要了解月球的背后到底是什么？是不是真的有ET？喂......老婆，出来看上帝啊！

从技术上来説一个全渠道必须具备如下几大功能，缺一不可：

微服务总线，这是必须要有的，真正的微服务讲究的是什么？我们先不説微服务所有的细节功能单説涉及到我们性能的那么几个功能：1）平峰削谷 2）服务自发现 3）服务升级降级 4）可弹性扩充。有这4个点绝大多数的零售电商网站够用了，除非你能达到淘宝的量，我们后面章节会把微服务功能逐个剖析、亲自动手设计、乃至实现；

各业务模块可纵向扩展，横向扩展是很简单的事，什么叫业务模块纵向扩展？比如説订单的写入和读都可以作分开的部署；

可弹性的分布式的并且是多样化的缓存群；

异步消息队列-MQ，必不可少；

规则引擎，你当促销中心是怎么实现的？

HTTP请求级别缓存，这个缓存可和后台的那个分布式缓存群是不一样的东西哦，它缓存的是用户请求，相当于一个CDN功能但是和CDN又不一样，因为CDN只能缓存绝对静态的内容；

分布式批处理任务-类似于网络计算，它比网格计算更轻、更小；

标准的安全认证登录接口，支持最常用的如：JWT，OAUTH2等协议；

支持分步式数据库，此处可不只是一个数据库，你要有钱可以去烧Oracle RAC，阿里在20~40亿时为什么它要去I.O.E？那么用开源的数据库你需要怎么去实现原来的Oracle RAC的功能呢？当然你雇了一堆的架构师自己也是可以去打造这样的分布式数据库的结构应用的，只是一个产品如果它的原生就支持分布式数据库、分布式事务、可折表折库（此处指的可是纵向折），横向谁不会无非就是加slavers：）；

成熟的性能监控；

成熟的CI（持续集成）组件；

配置中心，一个全渠道中台，组件少的有10多个模块，每个模块至少2-3个服务器，多的几十个模块，oh my god，全部写在properties文件里？Are you kidding me?

所以，月球的背面长的是个什么样的呢？即什么是真正的全渠道零售中台？

全渠道零售中台的“真容”

我用下面的这张图来解析全渠道零售中台的技术的面长成个什么样！

把我这篇文章的第1张图配合着全文最后一张图来看，那么你看的才是一个真正的全渠道中台！

这两张图：

只看第1张，你会被人忽悠的体无完肤，出了钱买不到好东西；

只看第2张而不看第1张的结果是，你可能买到的不是一个产品级的解决方案而只是一个技术框架，一切业务功能需要从头开发，这是巨大的工作量和成本的付出；

但是，不代表你把上述2张图结合起来看了就一定可以找中你“命中的中台”，还有很多、很多其它因素需要考虑。

从业务层面解析为什么叫“中”台

中台，我们的国人为了解决“TO C端业务的快速多变”，使用的是诸多非功能性需求如CMS+规则引擎+图形化编程，其实就是把TO C端的前端的逻辑“下沉”，下沉到了中台系统中而不是停留在APP端 ，把APP端的功能做成了可以通过后台配出来，我之前的博客説过，所谓IT上口头説的“业务业务”，指的就是用户端功能，而不是让你去考上岗证。

中国人做的这种高度一体化方案是基于可以彻底抛弃ERP的思想来做的，做什么legacy system的改造呢？这些功能在中台里已经有了，把你原来企业那10几个legacy system的数据做一次性的迁移，然后系统一刀切掉就好了，这是中国人的思路！但是中台在推出不久后它又要兼顾着中国人自古的“包容”精神，即我又要可以支撑原有legacy system和我的集成。那么，把原有后台legacy system的功能也放到这个中台系统中，因此它是后台业务功能的“上浮”。

一个TO C端业务的下沉；

一个后台业务功能的上浮；

而中台它处于当中这一块地位，因此它就叫“中”台！

而不是很多人认为，它处于后台和APP手机端应用的当中因此才叫中台的，不是的。这个理解太表面了没有真正理解中台的中到底为什么要叫中的背后的原理，中台的“中”是我上述这一段总结，这是业界真正公认的“中”。

因此我这一系列文章才不仅仅只是写业务（解决方案）或者写技术，还要写数字化变形、写管理、写策略。后面我们还会有更多精彩！