【導語】：新零售時代已經到來，傳統大型零售商家們也在追逐技術潮流，希望通過中臺建設來支撐業務發展。然而中臺建設非一夕之功，大多數的探索都折戟沉沙，踩過的坑更是不計其數。前事不忘，后事之師，本文就將以技術更迭為主線，通過傳統零售行業的碼農們一次次血與淚的教訓，告訴你到底什么才是符合中國國情的「全渠道中臺」？

楔子

零售戰鼓隆，各家齊斗法

云溪論劍后，江湖出寶典

古有葵花經，現有“大中臺”

沒有“兩個億”，別想做中臺

技術道業務道，自求條正道

各家紛説自己好

誰曾想，舊日零售江湖間現己變成了血海滔滔

你也說中臺，我也說中臺，到底什么是中臺？

現如今隨著“新零售”這三個字一再被提及，整個零售界都在提一個“神密的東西”，那就是中臺。甚至中臺被上升到了“推進企業數字化變形”的乃至直接促成企業數字化轉型能否成功的地位了。

那么中臺它到底是個什么樣的東西呢？在人們眼中中臺似乎猶如月球的背面一般神密。

在人們眼中的中臺無外乎于上述類似的組件圖，類似的圖一再被各大零售商或者是不少知名軟件商一再的提及。

它似乎有著“華麗的外表，沉漁落雁的面容，婀娜多姿的身段”？它只是利用了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手機端應用的當中因此才叫中臺的，不是的。這個理解太表面了沒有真正理解中臺的中到底為什么要叫中的背后的原理，中臺的“中”是我上述這一段總結，這是業界真正公認的“中”。

因此我這一系列文章才不僅僅只是寫業務（解決方案）或者寫技術，還要寫數字化變形、寫管理、寫策略。后面我們還會有更多精彩！