阿里巴巴中台架構筆記：前台、中台、後台，與「大中台，小前台」

前台、中台、後台是什麼

前台（Front Office）：直接面對使用者的業務入口，例如電商 App、官網、行銷活動頁、小程式。特性是變化快——今天要做一個促銷活動、明天要 A/B test 一個新版面，前台必須能快速迭代、快速試錯，離使用者越近，改版壓力越大。

後台（Back Office）：企業核心的交易紀錄與底層基礎設施，例如財務總帳、ERP、核心資料庫、機房與雲端基礎設施。特性是極度穩定、變化慢，任何改動都要求高一致性——財務資料算錯、資料庫壞掉，代價是無法接受的，所以後台通常寧可慢也要求穩。

中台（Middle Platform）：介於前台與後台之間的一層共用能力平台。它把多個前台業務都需要、卻各自重複開發的能力（會員、交易、商品、支付、風控、資料統計……）抽象沉澱下來，變成一組可以被多個前台快速呼叫、組裝的公共服務，前台不需要每次都從零打造底層邏輯。

為什麼會有中台：它解決的問題

中台的概念在阿里巴巴內部從 2015 年底開始被系統性推動。當時阿里旗下有淘寶、天貓、聚划算等多個前台業務，各自維護一套自己的會員、商品、交易系統，長期下來出現幾個問題：

• 重複造輪子：每個前台業務都各自寫一套會員系統、交易系統，開發資源被大量浪費在「重新發明」已經有人做過的東西上
• 資料與體驗不一致：不同前台的會員資料互相不通，使用者在一個平台累積的權益、行為紀錄，換一個前台就等於歸零
• 新業務上線慢：任何一個新的前台業務構想，都要先花好幾個月把底層的會員、交易、支付能力重新搭一遍，才能開始做真正的業務創新

中台要解決的核心問題，就是把這些「共性能力」統一沉澱、統一維護，讓前台只需要「組裝」既有的中台服務，而不是每次都「重新建造」，藉此換取新業務更快的上線速度。

大中台，小前台

「大中台，小前台」是這套架構戰略最核心的一句口號，對應的是組織與技術架構同步的調整：

• 大中台：把通用、共性的能力集中收攏，投入大量資源建設成一層強大、穩定、經過反覆驗證的共享服務層
• 小前台：前台團隊因此可以變得精簡、輕量、敏捷，只需要專注在業務創新、使用者體驗與快速試錯上，底層能力全部交給中台提供

可以把它想成軍隊的比喻：前台是機動性高、快速應變的小規模特種部隊，中台則是後方龐大而穩固的補給、火力與情報支援體系——前線部隊不需要自己造槍造炮，只需要專心打仗。

中台再細分：業務中台、資料中台、技術中台

實務上「中台」不是單一一層，通常會再細分成三種：

• 業務中台（Business Middle Platform）：把業務邏輯抽出來的共用能力中心，例如會員中心、交易中心、商品中心、支付中心、行銷中心、風控引擎——這一層「懂業務語意」，知道什麼是「訂單」「會員」「優惠券」
• 資料中台（Data Middle Platform）：統一資料的採集、清洗、建模與指標定義，讓所有前台都用同一套「資料語言」看同一份事實，而不是每個前台各自算出不同口徑的「日活躍使用者數」
• 技術中台／研發中台：底層通用的技術能力，例如容器編排、CI/CD 流水線、可觀測性（日誌、追蹤、監控）、服務網格——這一層不懂業務語意，它不知道什麼是「訂單」，只提供運算、部署、監控這類跟業務無關的通用技術能力

三層定位速查表

Web／App 算哪一層？Kubernetes 又算哪一層？

Web 官網、App 屬於前台。 它們是直接面對使用者的展示與互動層，會隨著不同市場、不同活動、不同 A/B 測試快速改版。就算 Web／App 背後呼叫的是中台的 API，UI 本身、頁面組裝、互動邏輯、轉換率優化，都還是前台的範疇。

這裡有個常見的反模式值得注意：如果 Web／App 裡面不只有 UI，還把業務規則也寫死在前端（例如訂單金額的計算邏輯直接寫在前端程式碼裡），代表中台化並不徹底——理想狀態下，前端只負責展示與互動，實際的業務規則應該呼叫業務中台的 API 取得結果，而不是自己算一份。

Kubernetes 屬於技術中台，或者用更寬鬆的三層分法來說，可以歸在「後台的基礎設施層」。判斷的關鍵在於：K8s 提供的容器編排、彈性擴縮、服務發現，是跟業務完全無關的通用技術能力——它不知道也不需要知道什麼是「訂單」「會員」，任何前台、業務中台、資料中台的服務，全部都跑在它上面、共用同一套部署與維運能力。這正是技術中台跟業務中台最大的差異：業務中台懂業務語意，技術中台只管運算與部署，兩者提供「共用能力」的方式一樣，但共用的東西完全不同層次。

中台架構圖

把前面幾節串起來，一個典型的中台架構大致長這樣：

前台在最上層負責跟使用者互動，遇到需要「共用能力」的地方（會員、交易、風控、部署、監控）就往中台這一層呼叫，而不是自己重寫；中台再往下依賴後台的核心資料與基礎設施。三層分工清楚，才有辦法讓前台維持「小而快」，中台維持「大而穩」。

一句話總結

前台負責「變化快、貼近使用者」，後台負責「穩、慢、強一致」，中台則是夾在中間、把多個前台重複需要的能力沉澱成共用服務的那一層；業務中台懂業務語意，技術中台（像 Kubernetes）不懂業務、只提供跟業務無關的通用技術能力，兩者都是「中台」，但服務的對象與內容完全不同層次。