本系列部落格的目标是計劃使用近半年時間創造：
- 國内唯一一部從業務場景到技術設計，從企業戰略考慮到技術細節落地的大全；
- 全文貫穿了企業架構、SOA、微服務，縱橫業務與技術之間説透“全管道”中台；
- 全管道零售中台與數字化轉型(1)-中台的前世今身
- 全管道零售中台與數字化轉型（2）-中台給企業業務帶來什麼實際的價值
- 全管道零售中台與數字化轉型（3）-中台給企業技術帶來什麼實際的價值？
- 全管道零售中台與數字化轉型（4）-作為甲方如何選擇中台-産品還是開發？資料中台還是業務中台的多重考慮
- 全管道零售中台與數字化轉型（5）-中台的架構設計
- 全管道零售中台與數字化轉型（6）-基于微服務的元件設計
- 全管道零售中台與數字化轉型（7）-中台核心架構代碼實作
- 全管道零售中台與數字化轉型（8）-中台的延伸
楔子
零售戰鼓隆，各家齊鬥法
雲溪論劍後，江湖出寶典
古有葵花經，現有“大中台”
沒有“兩個億”，别想做中台
技術道業務道，自求條正道
各家紛説自己好
誰曾想，舊日零售江湖間現己變成了血海滔滔
你也説中台，我也説中台，到底什麼是中台？
現如今随着“新零售”這三個字一再被提及，整個零售界都在提一個“神密的東西”，那就是中台。甚至中台被上升到了“推進企業數字化變形”的乃至直接促成企業數字化轉型能否成功的地位了。
那麼中台它到底是個什麼樣的東西呢？在人們眼中中台似乎猶如月球的背面一般神密。
在人們眼中的中台無外乎于上述類似的元件圖，類似的圖一再被各大零售商或者是不少知名軟體商一再的提及。
它似乎有着“華麗的外表，沉漁落雁的面容，婀娜多姿的身段”。。。but。。。
它隻是利用了2009年TOGAF設計規範從頂向下的設計方法論把業務子產品進行了LEVEL3級别的一個分解的功能圖而己，它隻要業務架構師手繪一些功能甚至公司的一個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年，随着國人消費能力的越來越高，随着IPHONE4、微信、淘寶的興起，零商開始邁向了電商時代。
于是這些大型商超、大型零售超市想當然的認為其實電商就是把原來站在各個服務前的一個個人肉導購啦、促銷啦、專櫃啦的這些個人取代成一個個的手機應用APP，于是，在當時的大型零售商眼裡的電商也是類似下面這樣的一個圖
先有了想法
通過“想法”有了下面的系統“架構”
零售電商1.0模式
轉型1.0模式
不要笑，當時一堆一堆的零售（在當時還算是比較有錢）設計出來的系統就是這樣的。
“喏，要數字化，我把人變成了一個個的APP了，這不就是數字化！”
是以大家直到現在也能看到類似的案例：一些傳統的快銷、零售商用微信、用APP、用微信小程式哪怕隻是做出了一個會員登記系統也會把它當成“公司内部巨大的創新”，也是基于這樣的想法。因為IT不重要嗎，哈哈！
可是，它依舊沒有從根本上解決客戶的問題。為什麼呢？中國客戶的電商使用習慣是什麼？
中國人的電商使用習慣
中國，人多的很、市場大的很，我們説我們是世界第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，幾十個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從12年後發展越來越快、整體行業較浮燥，導緻國内程式員水準普遍很低。缺乏整體資料流、業務串聯的能力，那麼這樣的改動引起的連鎖反應會更大。
拿我司曾發生過的一個案例來説，要在原有系統上做一個大閘蟹打折活動，這種設計的做法就是：
- 設計資料庫底層
- 制作DAO
- 制作SERVICE
- 制作Controller
- 制作頁面
然後有任何bug，bug的修複會把整個軟體開發生命周期從頭到尾再來一遍，這樣的事不斷的again, again, again。
于是，一個活動做個80多人天，花掉10幾萬20萬很正常。如果碰到“高大上”的外企來給你內建，那麼把80人天剩4,000，6,000...那麼做一個活動用掉個50萬，80萬，很合理呀。這就是我們很多國内的一 些大型零售企業在系統內建時碰到過的大血坑。
錢，花了很多，效率又低，品質又差。
這次的赫茲花了2億做電商做砸了正是碰到這樣的一個血坑。
如果隻是錢的問題還可以容忍，關鍵在這樣的系統內建來到了國内碰上的最坑爹的是“系統并發”問題。
前面説了，國内的人多，數字化流量高，這樣的一種其本身背景legacy system還未經過改造隻是遵照着SOA理念去做的系統內建出來的東西是根本擋不了大規模的“并發”的，國内動不動就來個十萬級、百萬級并發。。。。。。
這種背景實際上充滿着“單體”應用的電商應用APP，實際上是一個連千級并發都撐不住的東西，于是花了錢又做不好事，好了。。。很多企業沒有死在“業務領域的競争”中而是死在了“在國内上了電商系統”後死這個原因上了。
成就了一上電商就死，電商領域成了一個“95%的電商項目都失敗”這麼一個“煉獄”了。
于是基于“系統內建1.5”後又誕生了“系統內建2.0”模式，這次，賣鏟子的又沒有錯過掙錢的好機會于是它提出了SOA2.0模式。
SOA2.0模式
這是I.O.E相關的體系們提出的SOA2.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是一個好東西，可是它造出的怪胎更詭異！
先從開發團隊來錯誤的了解SOA2.0理念開始分析，下面是一個标準的在當時直到現在還有很多開發團隊是這麼認為的一種項目分工上的劃分模式。
我們拿JAVA項目來説，把系統劃分成這麼多子子產品，再分别開發和打包以及分布式部署，這就是SOA！
一切看似那麼的自然。。。。。。那麼的應該。。。。。。那麼的。。。最後在面臨國内十萬、百萬、千萬級并發時死得那麼的慘。
- 淘寶慘烈過
- JD也慘烈過
要不然怎麼會出現“JD老劉的兩把菜刀”的故事呢？以前去深圳學習JD618保衛戰時還聽説這個“兩把菜刀”是真事呢！！！
我們來看看工程項目上折的細又小、看似專業實際沒有深入了解SOA2.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體系們在SOA2.0時代提出的一個概念圖，再來看一遍這個圖
然後我們結合以下的一個場景再來考慮一下：
小龍蝦節活動，從資料庫設計->存取層->服務層->控制層。從頭到尾做了一遍，用掉了80多人天的價格。
來了一個陽澄湖大閘蟹打折活動，從資料庫設計->存取層->服務層->控制層。從頭到尾做了一遍，又用掉了80多人天的價格。
嘿嘿嘿，我們把以上深奧的理論，抽像成以下一個這樣的業務場景大家看一下，是不是就可以了解為什麼上述兩個都同樣是打折活動的業務場景分别都要用80多人天呢？
上圖已經可以很好的說明我們的程式員是如何淪落到程式猿、碼農的了。
性能達不到、加速業務、快速響應多變的由其是中國大陸市場幾乎每天都在變動的業務也做不到，這是2005~2015年這10年國人特别是國内很多知名500強在電商領域經曆的痛苦的10年，各種抱怨IT不給力。
IT各種想辦法找I.O.E相關體系來做企業整體解決方案，錢出了一大波，然并卵，各種繼續不給力、抱怨。。。。。。again，again and again！！！
而這10年，阿裡和一些走在比較前沿或者説曾經在那10年内沒有“死”的一些民營體制、特别接中國地氣的企業他們已經開始深刻得總結、檢討、并且依靠着自身之前學習到那些外資高大上的一些理論、知識、方法論後把它們再“本土化”并結合了中國自身特色，繼而打造出來了一個新的産物，這個新的産物就是“全管道零售中台”。
回過頭來看中台，什麼是中台
也有畫成下面這樣風格的圖
其實第2張圖和第1張無非就是第一張的level3級别功能擴充了比較豐富點，第二張呢顔色鮮明一些。
That's it，僅次而己！
然後很多外資包括國内的一些甲方型企業拿着這樣的圖説“這就是中台”。。。。。。現在知道錯在哪了吧。
我上面列舉的1.0，1.5，2.0時代的任何一種架構，其實都可以做成這樣的“業務功能圖”。
這隻是業務功能圖而己，它不是代表"我“做出來的就一定是中台。
我們看事務不能光看“外表”，我們需要看事物的“本質”，遵循着本質的那些公司都成功了，如阿裡、蘇甯、保潔、立白、海爾、華為。。。。。。有很多不再多叙。
那麼中台的本質到底在什麼？而且是一個全管道中台，也有人管它叫雲中台它必須具備以下幾樣東西。
從業務功能上來分
- 全管道訂單中心，它必須是一個全管道的訂單中心，訂單屬性擁有線上、線下、O+2、第三方等各種管道的特性；
- 全管道商品管理中心，可以管理線上、線下甚至是虛拟商品；
- 全管道會員中心，這個會員中心一分為2，一個合格的中台需要具備其中的CRM Foundation即會員中心基礎功能，另一個叫“營銷中心”，對，整個會員中心由“基礎功能+營銷中心”兩部分構成，而很多好的中台不一定包括這個“營銷中心”，因為營銷中心可以誕生出另一個全管道的産品，叫SCRM。我們不要求一個全管道的零售中台内必須包括全管道營銷中心，必竟術業要有專精；
- 全管道的促銷中心，促銷和營銷很多人會搞起來，促銷中心和營銷中心在功能上是有相近的，有人把促銷歸為營銷也有人把促銷和營銷進行分離，分離的條件就是“以會員為中心”和根據一個企業内的業務組織架構來決定的。這一定一定是一個全管道的促銷中心，它可以對線上線下同時促銷，説白了就是你在手機APP商城内使用的券同時也可以使用在自助機、掃碼購、微信小程式甚至在同一個零售企業門店POS結帳時使用，讓客戶無論是線上上還是線上下消費時“無縫/無差别”體驗，這就叫全管道。不管你什麼活動、打折、促銷，它還都是可以支援圖形化界面可配置的；
- 内容中心，它又被稱為CMS即Content Management System。它可以把手機、微信小程式、Web網站通過圖形化類似于Photoshop或者説它比較接近于以前的DreamWeaver或者是FrontPage的一種“傻瓜”界面把這些活動給配置出來，它在配置的時候是可以通過結合前面的促銷中心去做“協同工作”的；
- 财務共享中心-支付管道啦、支付中心啦，支援各種支付，接入支付管道時它也是可配置或者説是“半可配置”來完成一個支付管道的接入的；
- 物流庫存中心，支援全管道的物流和庫存，不管是自營、O+O、第三方還是自提，全部支援；
- 多租戶管理中心，咦。。。。。。這是什麼東西？唉呀，很簡單！都上全管道中台了，你這個電商不可能隻是面向垂直單一名牌吧？一定是類似于“天貓店”那種多商戶玩法吧？也有人管它叫B2B2C或者幹脆簡稱成BBC功能；
從技術上來分（月球的背面到底是什麼）
我們前面説了，業務功能它的表現出給到大衆的一面很美麗、很燦爛。可是它不是本質，它不代表全管道中台，我們需要了解月球的背後到底是什麼？是不是真的有ET？喂。。。老婆，出來看上帝啊！
從技術上來説一個全管道必須具備如下幾大功能，缺一不可，對。。。缺一不可！
- 微服務總線，這是必須要有的，真正的微服務講究的是什麼哈？我們先不説微服務所有的細節功能單説涉及到我們性能的那麼幾個功能吧：1）平峰削谷 2）服務自發現 3）服務更新降級 4）可彈性擴充，隻説這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手機端應用的當中是以才叫中台的，不是的。這個了解太表面了沒有真正了解中台的中到底為什麼要叫中的背後的原理，中台的“中”是我上述這一段總結，這是業界真正公認的“中”。
是以我這一系列文章才不僅僅隻是寫業務（解決方案）或者寫技術，還要寫數字化變形、寫管理、寫政策。。。。。。後面我們還會有更多精彩！
先預告一些下一章内容吧：
下一章我會對全管道零售中台中的業務功能、技術元件一個個折開來、揉碎了和大家講解！