[{"data":1,"prerenderedAt":304},["ShallowReactive",2],{"article-\u002Farticles\u002Falibaba-middle-platform-architecture":3},{"id":4,"title":5,"body":6,"date":289,"description":278,"excerpt":290,"extension":291,"meta":292,"navigation":293,"path":294,"seo":295,"stem":296,"tags":297,"__hash__":303},"articles\u002Farticles\u002Falibaba-middle-platform-architecture.md","阿里巴巴中台架構筆記：前台、中台、後台，與「大中台，小前台」",{"type":7,"value":8,"toc":277},"minimark",[9,14,26,36,46,50,53,75,78,82,85,99,102,106,109,133,136,232,236,242,245,255,258,261,268,271,274],[10,11,13],"h2",{"id":12},"前台中台後台是什麼","前台、中台、後台是什麼",[15,16,17,21,22,25],"p",{},[18,19,20],"strong",{},"前台（Front Office）","：直接面對使用者的業務入口，例如電商 App、官網、行銷活動頁、小程式。特性是",[18,23,24],{},"變化快","——今天要做一個促銷活動、明天要 A\u002FB test 一個新版面，前台必須能快速迭代、快速試錯，離使用者越近，改版壓力越大。",[15,27,28,31,32,35],{},[18,29,30],{},"後台（Back Office）","：企業核心的交易紀錄與底層基礎設施，例如財務總帳、ERP、核心資料庫、機房與雲端基礎設施。特性是",[18,33,34],{},"極度穩定、變化慢","，任何改動都要求高一致性——財務資料算錯、資料庫壞掉，代價是無法接受的，所以後台通常寧可慢也要求穩。",[15,37,38,41,42,45],{},[18,39,40],{},"中台（Middle Platform）","：介於前台與後台之間的一層",[18,43,44],{},"共用能力平台","。它把多個前台業務都需要、卻各自重複開發的能力（會員、交易、商品、支付、風控、資料統計……）抽象沉澱下來，變成一組可以被多個前台快速呼叫、組裝的公共服務，前台不需要每次都從零打造底層邏輯。",[10,47,49],{"id":48},"為什麼會有中台它解決的問題","為什麼會有中台：它解決的問題",[15,51,52],{},"中台的概念在阿里巴巴內部從 2015 年底開始被系統性推動。當時阿里旗下有淘寶、天貓、聚划算等多個前台業務，各自維護一套自己的會員、商品、交易系統，長期下來出現幾個問題：",[54,55,56,63,69],"ul",{},[57,58,59,62],"li",{},[18,60,61],{},"重複造輪子","：每個前台業務都各自寫一套會員系統、交易系統，開發資源被大量浪費在「重新發明」已經有人做過的東西上",[57,64,65,68],{},[18,66,67],{},"資料與體驗不一致","：不同前台的會員資料互相不通，使用者在一個平台累積的權益、行為紀錄，換一個前台就等於歸零",[57,70,71,74],{},[18,72,73],{},"新業務上線慢","：任何一個新的前台業務構想，都要先花好幾個月把底層的會員、交易、支付能力重新搭一遍，才能開始做真正的業務創新",[15,76,77],{},"中台要解決的核心問題，就是把這些「共性能力」統一沉澱、統一維護，讓前台只需要「組裝」既有的中台服務，而不是每次都「重新建造」，藉此換取新業務更快的上線速度。",[10,79,81],{"id":80},"大中台小前台","大中台，小前台",[15,83,84],{},"「大中台，小前台」是這套架構戰略最核心的一句口號，對應的是組織與技術架構同步的調整：",[54,86,87,93],{},[57,88,89,92],{},[18,90,91],{},"大中台","：把通用、共性的能力集中收攏，投入大量資源建設成一層強大、穩定、經過反覆驗證的共享服務層",[57,94,95,98],{},[18,96,97],{},"小前台","：前台團隊因此可以變得精簡、輕量、敏捷，只需要專注在業務創新、使用者體驗與快速試錯上，底層能力全部交給中台提供",[15,100,101],{},"可以把它想成軍隊的比喻：前台是機動性高、快速應變的小規模特種部隊，中台則是後方龐大而穩固的補給、火力與情報支援體系——前線部隊不需要自己造槍造炮，只需要專心打仗。",[10,103,105],{"id":104},"中台再細分業務中台資料中台技術中台","中台再細分：業務中台、資料中台、技術中台",[15,107,108],{},"實務上「中台」不是單一一層，通常會再細分成三種：",[54,110,111,117,123],{},[57,112,113,116],{},[18,114,115],{},"業務中台（Business Middle Platform）","：把業務邏輯抽出來的共用能力中心，例如會員中心、交易中心、商品中心、支付中心、行銷中心、風控引擎——這一層「懂業務語意」，知道什麼是「訂單」「會員」「優惠券」",[57,118,119,122],{},[18,120,121],{},"資料中台（Data Middle Platform）","：統一資料的採集、清洗、建模與指標定義，讓所有前台都用同一套「資料語言」看同一份事實，而不是每個前台各自算出不同口徑的「日活躍使用者數」",[57,124,125,128,129,132],{},[18,126,127],{},"技術中台／研發中台","：底層通用的技術能力，例如容器編排、CI\u002FCD 流水線、可觀測性（日誌、追蹤、監控）、服務網格——這一層",[18,130,131],{},"不懂業務語意","，它不知道什麼是「訂單」，只提供運算、部署、監控這類跟業務無關的通用技術能力",[10,134,135],{"id":135},"三層定位速查表",[137,138,139,158],"table",{},[140,141,142],"thead",{},[143,144,145,149,152,155],"tr",{},[146,147,148],"th",{},"層級",[146,150,151],{},"定位",[146,153,154],{},"特性",[146,156,157],{},"舉例",[159,160,161,176,190,204,218],"tbody",{},[143,162,163,167,170,173],{},[164,165,166],"td",{},"前台",[164,168,169],{},"直接面對使用者的業務入口",[164,171,172],{},"變化快，需要快速迭代與試錯",[164,174,175],{},"電商 App、官網、行銷活動頁、小程式",[143,177,178,181,184,187],{},[164,179,180],{},"業務中台",[164,182,183],{},"沉澱共用「業務」能力，供前台組裝呼叫",[164,185,186],{},"穩定、可重用、懂業務語意",[164,188,189],{},"會員中心、交易中心、商品中心、風控引擎",[143,191,192,195,198,201],{},[164,193,194],{},"資料中台",[164,196,197],{},"統一資料採集、建模與指標口徑",[164,199,200],{},"全公司共用同一份「事實」",[164,202,203],{},"資料倉儲、指標平台、BI 報表",[143,205,206,209,212,215],{},[164,207,208],{},"技術中台",[164,210,211],{},"提供跟業務無關的通用技術能力",[164,213,214],{},"服務所有前中後台，不懂業務語意",[164,216,217],{},"Kubernetes、CI\u002FCD、服務網格、可觀測性",[143,219,220,223,226,229],{},[164,221,222],{},"後台",[164,224,225],{},"核心交易紀錄與底層基礎設施",[164,227,228],{},"極度穩定，變化慢，強一致性",[164,230,231],{},"ERP、財務總帳、核心資料庫、雲端基礎設施",[10,233,235],{"id":234},"webapp-算哪一層kubernetes-又算哪一層","Web／App 算哪一層？Kubernetes 又算哪一層？",[15,237,238,241],{},[18,239,240],{},"Web 官網、App 屬於前台。"," 它們是直接面對使用者的展示與互動層，會隨著不同市場、不同活動、不同 A\u002FB 測試快速改版。就算 Web／App 背後呼叫的是中台的 API，UI 本身、頁面組裝、互動邏輯、轉換率優化，都還是前台的範疇。",[15,243,244],{},"這裡有個常見的反模式值得注意：如果 Web／App 裡面不只有 UI，還把業務規則也寫死在前端（例如訂單金額的計算邏輯直接寫在前端程式碼裡），代表中台化並不徹底——理想狀態下，前端只負責展示與互動，實際的業務規則應該呼叫業務中台的 API 取得結果，而不是自己算一份。",[15,246,247,250,251,254],{},[18,248,249],{},"Kubernetes 屬於技術中台","，或者用更寬鬆的三層分法來說，可以歸在「後台的基礎設施層」。判斷的關鍵在於：K8s 提供的容器編排、彈性擴縮、服務發現，是",[18,252,253],{},"跟業務完全無關","的通用技術能力——它不知道也不需要知道什麼是「訂單」「會員」，任何前台、業務中台、資料中台的服務，全部都跑在它上面、共用同一套部署與維運能力。這正是技術中台跟業務中台最大的差異：業務中台懂業務語意，技術中台只管運算與部署，兩者提供「共用能力」的方式一樣，但共用的東西完全不同層次。",[10,256,257],{"id":257},"中台架構圖",[15,259,260],{},"把前面幾節串起來，一個典型的中台架構大致長這樣：",[15,262,263],{},[264,265],"img",{"alt":266,"src":267},"阿里巴巴中台架構圖：前台呼叫中台的業務中台、資料中台、技術中台三塊共用能力，中台再依賴後台的核心資料與基礎設施","\u002Fimages\u002Farticles\u002Falibaba-middle-platform.svg",[15,269,270],{},"前台在最上層負責跟使用者互動，遇到需要「共用能力」的地方（會員、交易、風控、部署、監控）就往中台這一層呼叫，而不是自己重寫；中台再往下依賴後台的核心資料與基礎設施。三層分工清楚，才有辦法讓前台維持「小而快」，中台維持「大而穩」。",[10,272,273],{"id":273},"一句話總結",[15,275,276],{},"前台負責「變化快、貼近使用者」，後台負責「穩、慢、強一致」，中台則是夾在中間、把多個前台重複需要的能力沉澱成共用服務的那一層；業務中台懂業務語意，技術中台（像 Kubernetes）不懂業務、只提供跟業務無關的通用技術能力，兩者都是「中台」，但服務的對象與內容完全不同層次。",{"title":278,"searchDepth":279,"depth":279,"links":280},"",2,[281,282,283,284,285,286,287,288],{"id":12,"depth":279,"text":13},{"id":48,"depth":279,"text":49},{"id":80,"depth":279,"text":81},{"id":104,"depth":279,"text":105},{"id":135,"depth":279,"text":135},{"id":234,"depth":279,"text":235},{"id":257,"depth":279,"text":257},{"id":273,"depth":279,"text":273},"2026-02-16",null,"md",{},true,"\u002Farticles\u002Falibaba-middle-platform-architecture",{"title":5,"description":278},"articles\u002Falibaba-middle-platform-architecture",[298,299,300,301,302],"中台","架構設計","平台工程","Kubernetes","系統設計","GGSimJ53pO4cPMr9IEF12V1R6tA27nVE6Ma0JhDpyFg",1792959150201]