阿里巴巴所提倡的 “大中臺(tái)惧蛹，小前臺(tái)”戰(zhàn)略是非常先進(jìn)的業(yè)務(wù)打法右冻，這個(gè)策略對(duì)技術(shù)的挑戰(zhàn)其實(shí)更大滑频！
文章作者是全程網(wǎng)絡(luò)CTO焦英俊淳地，前阿里巴巴資深技術(shù)專家怖糊，1688總架構(gòu)&垂直開放平臺(tái)負(fù)責(zé)人&云電商平臺(tái)創(chuàng)始人。
阿里店鋪到10年經(jīng)歷了4個(gè)大的主版本颇象。
店鋪系統(tǒng)的挑戰(zhàn)
挑戰(zhàn)劃分為三大維度的問題：全平臺(tái)伍伤、垂直化、個(gè)性化遣钳。
全平臺(tái)：PC端扰魂、App端、Wap端蕴茴，三端統(tǒng)一劝评。我來舉個(gè)實(shí)際例子，某一天業(yè)務(wù)人員找到技術(shù)說下個(gè)月要搞促銷倦淀，我們希望在指定一批商家的店鋪上投放特定優(yōu)惠券付翁，希望每個(gè)端都能同步投放，怎么破晃听？
垂直化：電商領(lǐng)域其實(shí)非常廣泛百侧，你不可能要求做原材料的行業(yè)和做快消品的行業(yè)是一樣的體驗(yàn)砰识。那會(huì)出問題，舉個(gè)例子佣渴，原材料就是需要大量的規(guī)格展示辫狼，越專業(yè)越好；快消品主打營(yíng)銷辛润，希望更多的營(yíng)銷主題膨处；甚至某些企業(yè)還想提供獨(dú)立的官網(wǎng)來提供企業(yè)的知名度。面對(duì)不同行業(yè)砂竖，不同訴求真椿，這勢(shì)必要求系統(tǒng)具備垂直化的能力來應(yīng)對(duì)。
個(gè)性化：這個(gè)更容易理解了乎澄，每個(gè)商家都希望自己的店鋪和其他人是不一樣的突硝，都有自己的特色！千人千面置济。
店鋪的中臺(tái)架構(gòu)策略
模塊化策略
首先解恰，我們一起看下這張圖片，大家應(yīng)該都非常熟悉浙于。商品陳列信息护盈，阿里內(nèi)部稱為offer櫥窗。
逛過電商網(wǎng)站的同學(xué)應(yīng)該知道羞酗，這么個(gè)看似簡(jiǎn)單的內(nèi)容腐宋，會(huì)有非常多的呈現(xiàn)方式，常規(guī)的都能數(shù)上很多檀轨，更不用說個(gè)性化的方式胸竞。
粗略的分析一下：
頁面元素：圖片、價(jià)格裤园、訂購(gòu)
數(shù)據(jù)元素：大圖（需要篩選出來合適的尺寸撤师，阿里為了圖片的美觀做了多次的優(yōu)化，目前可以做到按需加載不同尺寸的圖片）拧揽、價(jià)格（是否有活動(dòng)剃盾、折扣、會(huì)員價(jià)）淤袜、訂購(gòu)按鈕（有沒有權(quán)限痒谴，有沒有庫(kù)存）
顯示要求：平鋪
從這三點(diǎn)要求上來看，可以看出铡羡，這個(gè)小板塊背后的邏輯還是比較復(fù)雜的积蔚。以前我們?cè)趺醋觯?/p>
第一個(gè)版本：硬編碼，開發(fā)寫了一個(gè)web control里面調(diào)用各種service烦周，模板也單獨(dú)寫了一個(gè)（那個(gè)恐怖的時(shí)代尽爆，我印象中怎顾，頁面超級(jí)復(fù)雜，大量的頁面漱贱、JavaScript邏輯是copy出來的槐雾，輕易不敢維護(hù)），這個(gè)版本應(yīng)該持續(xù)了有5幅狮、6年募强，相當(dāng)痛苦。
第二個(gè)版本：control層widget崇摄，當(dāng)時(shí)的架構(gòu)師花了大量的時(shí)間構(gòu)建了基于widget模式的系統(tǒng)擎值。后端的邏輯看起來優(yōu)雅了下一些，但是前端依然是全部寫在一個(gè)頁面當(dāng)中的逐抑。當(dāng)時(shí)web的同學(xué)最大的擔(dān)憂就是發(fā)布鸠儿，一個(gè)小小的VM都能引發(fā)一個(gè)p1故障。這個(gè)狀態(tài)大概持續(xù)了3年左右泵肄。
第三個(gè)版本：組件化捆交，頁面層的種種問題積累了太多的血淋淋的教訓(xùn)淑翼！當(dāng)時(shí)團(tuán)隊(duì)實(shí)在忍受不了了腐巢，決定全面實(shí)施組件化，加強(qiáng)了前端層面分組件開發(fā)的模式玄括。這個(gè)是個(gè)巨大的進(jìn)步冯丙，但是沒有持續(xù)到半年就發(fā)現(xiàn)新問題了！整個(gè)系統(tǒng)設(shè)計(jì)的復(fù)雜度非常龐大（學(xué)院模式的過度設(shè)計(jì)）遭京，加上阿里慣性的擁抱變化胃惜，最后無人可維護(hù)。同時(shí)沒有辦法支持多個(gè)站點(diǎn)的需求哪雕，只能解決單一店鋪船殉。這個(gè)版本最后持續(xù)了一年多的時(shí)間。
第四個(gè)版本：模塊化斯嚎！簡(jiǎn)單的來描述就是前端組件化＋后端組件化利虫，當(dāng)然這里需要遵循同一個(gè)組件協(xié)議！開發(fā)人員也無需關(guān)心是在前端渲染還是后端渲染堡僻，這里最重要的點(diǎn)是讓前后一致了糠惫，下面我們?cè)倬唧w介紹一下。
“前后端一致”的組件化
除了布局钉疫，當(dāng)然還有一些其他技術(shù)的細(xì)節(jié)硼讽，比如校驗(yàn)、session管理牲阁、異步通信等固阁，這里不再描述壤躲。最后看一個(gè)頁面的案例。
統(tǒng)一數(shù)據(jù)中心
整個(gè)子系統(tǒng)由數(shù)據(jù)容器以插件的形式運(yùn)行于客戶端备燃，它管理著數(shù)據(jù)資源柒爵，每個(gè)dataProvider對(duì)應(yīng)一種數(shù)據(jù)源，它通過兩種方式來獲得外部數(shù)據(jù)赚爵。
一種是通過查找serviceInfo資源棉胀，然后基于其配置，以Dubbo協(xié)議（泛化調(diào)用方式）或HTTP協(xié)議的方式獲取冀膝。
另一種通過本地服務(wù)調(diào)用的方式獲取唁奢，接著根據(jù)dataStore中的業(yè)務(wù)代碼（source.groovy）來聚合及處理這些數(shù)據(jù)服務(wù)的返回結(jié)果，并最終將獲取的數(shù)據(jù)提供給app使用窝剖，完成app的取數(shù)與渲染麻掸，呈現(xiàn)在所有基于店鋪平臺(tái)客戶端的應(yīng)用頁面之中。
開放的設(shè)計(jì)平臺(tái)
在核心技術(shù)日趨完善的情況下赐纱，我們發(fā)現(xiàn)生產(chǎn)力依然低下脊奋，因?yàn)槲覀円_發(fā)的業(yè)務(wù)需求還是非常多，雖然大家的開發(fā)效率已經(jīng)得到大幅度的提升疙描！
但是還是會(huì)出現(xiàn)亂拳打死老師傅的情況诚隙，面對(duì)日益增長(zhǎng)的個(gè)性化需求，我們選擇了開放起胰，將店鋪核心體系開放出去久又，接入設(shè)計(jì)師來幫助我們完成個(gè)性化部分！
這其實(shí)也是典型的云服務(wù)開放的案例效五，通過設(shè)計(jì)平臺(tái)地消，我們既解決了自身的資源問題，又養(yǎng)活了40多個(gè)設(shè)計(jì)師畏妖！
最后店鋪業(yè)務(wù)只需要1-2個(gè)人日常維護(hù)就可以滿足不斷增長(zhǎng)的業(yè)務(wù)需求脉执！
店鋪生態(tài)建設(shè)
圍繞著平臺(tái)核心技術(shù)的打造過程，我們自然逐步完成連接開發(fā)者戒劫、設(shè)計(jì)師半夷、第三發(fā)開發(fā)者、運(yùn)營(yíng)人員谱仪，他們都可以很好的工作在店鋪平臺(tái)中完成各自的需求玻熙。整個(gè)店鋪業(yè)務(wù)形成閉環(huán)，自然高效的工作在一起疯攒！
