建設中臺最直接的目的一般是為了幫助企業快速且低成本的創新，這就要求了中臺必須降低使用方的學習成本，能把各個業務進行集中管理以及需要有較低的學習門檻，簡單來講就是：可視化、配置化、低代碼。中臺產品設計如何實現可視、可配、可復用？本文作者從常見的中臺架構出發，對這個問題展開了詳細解析，與大家分享。

中臺在這兩年是一個非?；鸬母拍?，其出現的目的只有一個：幫助企業快速且低成本的進行創新。

二十年前，中國的互聯網剛剛起步，在線交易一片荒蕪，商品信息極難通過在線進行展示，更別論在線交易；十年前，中國互聯網蓬勃發展，以阿里、京東為代表的企業實現了在線交易基礎設施的搭建，大部分的消費則能夠在網上查找商品并進行交易；

而如今，互聯網日益向著成為水電煤的趨勢發展，各種模式、形態的電商不斷涌現，昨天剛出現蘑菇街、小紅書，今天就有有贊、拼多多；昨天剛大力吹捧微博、公眾號的自媒體營銷，今天又有小程序的出現。

在這個極其不確定的時代里，任何一家企業都害怕錯失機會，不斷出現的新鮮事物，讓企業創新的成本越來越高，如何能夠通過盡量少的成本，而不失嘗試新鮮事物的機會，成為企業經營中遇到的難題之一。

一、常見的中臺架構

在聊中臺的時候，我們一定需要聊一聊軟件架構，軟件架構是系統發展到一定的復雜程度后的必然產物，當系統足夠復雜以后我們需要大規模的協作才能完成開發，必然要求我們對整個系統進行橫向和縱向的切分，再按切分后的系統進行團隊劃分。

在切分系統時我們需要從垂直的角度考慮，例如：頁面、應用、領域和基礎設置；也需要從橫向角度考慮，例如：店鋪、商品、訂單、支付等。對系統進行切分后我們需要定義切分后的模塊之間的通信、同步等機制。

而且分系統最終的目的是能夠以更小粒度調配人力、物力、財力去完成系統的開發工作，而更小粒度的團隊也更加便于管理，有效的降低企業成本。狹義的中臺也是一種軟件架構（如圖），面向消費者的是各種端中的應用，通過統一的API網關能夠使用中臺各個業務中心的業務能力，而各個中心之間也能通過統一的協議進行調用。

這樣一種架構是與我們現在大部分的互聯網企業的組織架構相匹配的，離消費者或者客戶最近的是各個事業部，也就是軟件架構中的應用層；而中臺的各個業務中心就像技術部門、財務部門、市場公關等部門，能夠為前臺的應用提供支撐。而我們把業務中心拆散后也更利于我們進行微服務化，其直接的好處就是硬件資源變得可以按需投入了。

至此，我們簡單的對中臺的理念以及一些好處進行了說明，那真實的中臺就是像我們上圖這種架構嘛？答案是：不是。

二、如何解決快速和低成本的創新

首先我們回顧下推行建設中臺最直接的目的是：幫助企業快速且低成本的創新。如上的架構我們對企業的系統進行分層，并對中臺進行領域的劃分，看上去似乎是能夠讓上層的應用直接通過API網關調用中臺的能力進行快速的應用開發。

但我們忽略了一個重要的問題：系統開發不只是API調用，他是包括從產品規劃、開發測試、部署上線以及業務運營等一系列的活動。如果中臺只是能提供API是無法為應用提供便利，即使有一些便利也會應用接入中臺的復雜性而抵消這種便利。那復雜在哪里呢？

首先要能實施中臺我們一定會使用微服務，而要實現微服務我們必須要制定一系列的標準進行微服務的劃分，也要把業務進行更高層次的抽象，為何要進行抽象呢？

例如：以前我們是單體應用，我的交易流程只有一種就是現款后貨，但是由于我們是中臺我們面對大量的應用每一個應用雖然只有一種業務流程，但對我們來說可能就是很多種，如此我們需要對所有的業務進行拆解，相同部分進行合并，而不同的部分者需要獨立出來，同時在這些業務邏輯之上能夠提供統一流程編排服務。

而在這樣做了之后，對中臺每一個業務中心來說都有巨量的API可供使用，而如何能夠進行使用只能通過API文檔或者是中臺開發直接的講解，而這種學習域熟悉的成本完全會抵消API復用的便利性。同時由于要中臺化，我們制定的諸多標準也會使得應用處處受制，原本可以按照自己喜歡的方式進行開發，而如今需要按照他人的標準執行。

那到底應該如何通過中臺進行快速且低成本的創新呢？答案是：可視化、配置化、低代碼。

中臺的復用性相信大家一定是能夠感受到的，但由于其復用性所帶來的復雜確實我們缺少思考的?？梢暬軌蛴行У慕档褪褂梅降膶W習成本，讓其能夠直觀的感受中臺的業務能力；配置化能夠把各個業務使用的能力集中起來管理，讓最熟悉業務的人員直接控制應用中的業務邏輯，能夠把標準更好的執行下去；而低代碼則是降低了開發人員學習中臺復雜技術框架的門檻，讓其能夠忽略底層的技術實現，只關心業務邏輯部分。

三、為了實現可視化、配置化、低代碼我們需要做些什么？

中臺最顯現的優勢就是復用，復用是快速和低成本創新的基礎，那電商中臺為什么能夠復用呢？首先我們可以對電商業務進行拆解。如圖：

在所有的電商中其核心的基礎流程都是：開店-發布商品-下單-支付-履約/售后-結算，在商品部分會和庫存有直接關聯，簡單點的直接使用虛擬庫存，復雜的庫存系統則會包含出入庫管理、庫存管理、配補管理、盤點等相關功能，而我們主要還是基于虛擬庫存進行設計。

而能夠對基礎流程產生影響的主要有以下這幾個方面的因素：業務模式、營銷方式和商品類型。具體每一種因素可能對交易流程的影響可見上圖。

在應用的分層架構中，我們可以從用戶能夠接觸的層次往系統抽象層次依次分為：頁面、功能、能力、數據模型或者是界面接口、應用、領域、基礎設施。

而在業務架構下我們電商業務又是怎樣的，我們分別看下BBC、B2C商城是怎樣的，如圖：

我們可以看到在不同的業務模式下，其實我們有大量的業務模塊是可以在頁面、功能、能力、數據模型這四個維度中的某幾個進行共用的，那我們是否可以可以做一個這樣的設想：是否能夠把每一個應用中的頁面、功能、能力和數據模型都打散 分別沉淀到對應的頁面、功能、能力、數據模型的公用庫中，這樣以后每層次來一個新的業務只要通過從共用庫中選擇自己所需要的頁面、功能、能力、數據模型就可以搭建匹配自己業務邏輯的應用。

通過以上的推演，我們可以看到在頁面、功能、能力、數據模型這些維度上進行復用是符合邏輯的。我們知道中臺不只是能為應用提供接口，而應該是能夠提供全套復用資源的，包括頁面、功能、能力、和數據模型。而我們設計中臺的時候也需要設計相應的管理和使用的工具，以達到可視化、配置化和低代碼的最終目的。

四、真實的電商中臺架構

在聊電商中臺架構之前，還需要和大家說說系統的運行域和管理域。

運行域指的是人們在系統上開展業務時系統運行代碼的空間；管理域指的是系統管理員控制系統參數或實現預留業務擴展點的工具的代碼運行的空間。運行域是為了解決實際業務而存在的，而管理員則是為了對運行域的業務流程、規則進行動態調整而存在的。

在上文所說的頁面、功能、能力、數據模型都是屬于運行域的內容，而由于這些內容在隨著企業業務不斷的發展過程中會越來越豐富，所以我們需要提供一個工具來對這些內容進行管理，隨之管理域就出現了。如圖基于中臺的整體應用架構：

在管理域中有如下三個基礎功能模塊：元數據管理、能力管理、組件管理。

元數據管理主要完成對數據模型的管理，包括對內置對象的數據結構進行擴展、部分字段的定，也包括對應用中的定制對象進行定義、字段設置等功能，更多元數據相關的功能在此不做表述，在整個業務邏輯中元數只是作為配置參數存在，而更多元數據的能力并未涉及；

能力管理主要是對能力和功能的管理，主要包括兩部分，一、是對中臺預置的配置項進行注冊和發現，二、中臺預留抽象類，可讓應用自己進行定制化開發，在通過機制進行注冊和發現并提供給應用使用。具體的實現機制可參考Java中的SPI機制，簡單來說步驟如下：

• 在代碼中使用統一注釋，通過掃描可以自動把注釋部分的代碼上報到能力管理實現注冊；
• 在能力對應的代碼進行修改了之后，掃描機制也能在一定的時機進行更新；
• 通過統一的編碼規范，對某些類預留抽象類，可暴露給應用方自己進行實現；
• 應用方對抽象類進行實現后，可通過掃描機制發現，并讓應用進行調用。

組件管理主要可以分為頁面組件和服務組件的管理，頁面組件在設計時需要區分面向用戶商城頁面組件管理和面向商家或運營人員的管理后臺的頁面組件庫。前端的組件最終是以頁面編輯器的方式進行實現，在此不做詳細表述，而管理后臺的頁面組件庫則需要與全局管理的中的資源、菜單、角色管理配合起來一起滿足業務的需求。

其核心業務邏輯在于：所有系統中的頁面、菜單、頁簽、按鈕以及其它頁面元素都可以由統一的提供方提供，放到公共庫中，消費方只需要按照標準進行調用即可，如此能夠實現最大限度的資源復用。統一UI資源的管理還有一個巨大的好處，能夠保證數據模型的穩定性，不至于由于頁面的交互或視覺而造成對數據模型的沖擊，

功能服務組件則是把業務和平臺分離的關鍵，大量具有業務特性的聚合服務從核心業務邏輯中抽離，形成一個一個的服務組件，以插件的方式裝配到主干業務流程中，由于使用統一的標準進行開發，在業務組件中預設大量的配置項，通過自動注冊和發現機制實現配置項自動化上報，而組件一被生產方生產出來后就會進入統一的服務組件庫中，能夠被任一業務方進行調用。

通過以上三個能力，能夠實現對數據模型、能力、功能以及頁面的統一管理的需求，只是對這些內容的管理還是不夠的，我們還不能實現最終目的，在能夠對其進行管理之后，我們需要能夠按業務需求把這些內容組裝起來，以滿足業務的實際需求，且是通過配置化、低代碼的方式。

所有的業務系統按我們第二部分的內容介紹都可以分為頁面、功能、能力、數據模型四個部分，電商系統普遍都是由前端商城+管理后臺組成。而在電商中整體的業務流程：開店-發布商品-下單-支付-履約/售后-結算，造成業務不同的因素主要是：行業（不同的類目）、賣家、和商品（不同的類型、模式）。

為了解決不同業務動態化配置的問題 我們需要引入業務身份這一概念，業務身份主要是把前后臺的應用放在同一個空間下進行管理，我們在管理域可在業務身份下進行業務邏輯的配置，這些配置可以讓系統中包含的各個應用在運行域時能夠識別所需要使用的頁面、功能、能力和數據模型。

業務身份是一個標識，能夠在虛擬空間中劃分一個獨立的系統運行空間，在這個空間內業務可以按設置好的配置在系統中完成，在這個空間中可以有多個應用，空間中應用所對應的頁面（也即資源）、功能、能力和數據模型都會被業務身份進行標識。業務空間的示意圖如下：

而在端到業務應用之間最為關鍵的就是如何進行業務身份識別。業務身份不同的影響因素主要有：行業（不同的類目）、賣家、和商品（不同的類型、模式），我們在設計業務身份時首先需要明確這個業務身份是在那個租戶下，其次需要把對應的應用關聯到業務空間，關聯的應用決定了在該業務空間能夠設置的配置項的范圍，然后我們可以對我們這個業務空間進行四個因素的選擇。

例如：行業為酒水、賣家為自營時我們加入購物車和立即下單時需要進行認證，且在商品類型為預售分階段時訂單需要走分階段訂單流程。在用戶操作頁面產生一個請求后，業務身份識別的過程如下圖：

業務身份的整體邏輯示例：在基礎的BBC電商系統中我們已經實現了實物商品先款后貨的整體業務流程，但我們有些業務需要實現預售這種交易模式，此時我們能很好的運用業務身份進行業務邏輯的擴展。我們需要對BBC商城中的發布商品（此處為設置營銷活動）、下單、支付這三個環節進行相關的業務配置：

1. 定義業務身份，當“類目包涵茅臺”且“商家為直營”的業務身份為xxx.maotai.zhiying；
2. 把云商APP端關聯到該業務身份，把云商APP端對應的發布商品應用、下單應用關聯到該業務身份下；
3. 我們需要在業務身份下進行相關的配置設置，在營銷活動的配置中開啟預售模式，在下單節點需要開啟訂單支持分階段交易，支付支持對一個訂單進行多次支付；
4. 把相應的配置配好之后，我們把配置以及配置對應的功能組件進行重新打包并發布上線；
5. 我們需要把預售對應的菜單、頁面及按鈕等資源配置出來（在BOC中）
6. 在發布成功后，后臺管理（運營及商家）能夠出現預售管理的菜單及相關的功能操作按鈕
7. 在發布商品時選擇的類目為茅臺且發布人對應的商家為自營則能夠發貨預售活動，
8. 在用戶對預售商品進行下單時能夠根據類目與賣家的標識進行業務身份識別從而選擇對應的業務空間中的交易流程。

以上就是業務身份在整體的業務流程中如何使用的邏輯，業務身份其實是我們自己定義的一個分隔業務的標準協議，在不同的企業可以選取不同過的業務維度決定業務身份，但主要從商品、類目、賣家這幾個業務維度，再加上端、應用、租戶這幾個基礎維度即能準確定位到具體的業務空間。

在不同的業務空間中配置有可能會出現沖突，此時需要對沖突進行處理，才能真正把配置發布成功，配置沖突的場景如下：商品ID包涵0947（促銷活動那個）時需要校驗活動庫存；商家為自營時需要校驗邏輯庫存，此時由于配置都是對庫存校驗進行作用，需要確定配置是互斥還是疊加起作用，若是互斥，優先使用哪一個？而如果是在業務空間的父子業務空間中的配置則取子業務空間中的配置項值。

通過以上的功能，我們能夠做到在復雜業務體系中對能力、功能、頁面/資源的可視、可配，而通過建設能力共享中心、業務組件庫、服務組件庫我們能夠沉淀大量的數字資產，實現業務的復用，從而降低重復開發的工作。

在以上的所有業務邏輯中，還需要強調以下幾點：

1. 由于所有的實體模型均在中臺進定義，所以能夠有統一的實體編號生成機制，而這個統一的機制是能夠與業務身份所需要的信息進行關聯，例如：需要在商品ID中預留6位，表示特定含義，而這種含義是需要被各個應用進行識別的；
2. 組件都是由生產方生產，可以被任一消費方進行調用，而不需要進行代碼上的重復開發；
3. 業務中臺的能力都是通過接口提供給上方的功能或者頁面進行調研，所以所有應用對應的底層業務邏輯代碼都是使用業務中臺的代碼；

以上就是我對整個電商業務中臺如何實現可視、可配、可復用的整體思考，而這只是一個真正中臺的業務及產品的部分，中臺是一個涵蓋組織、工程、業務產品、技術、運營等方方面面的系統工程，而這種多維度的復合系統其復雜度與以往的后臺系統相比是指數級增長，而這種復雜性也是中臺戰略落地中的最大障礙。

本文由 @不可分類者 原創發布于人人都是產品經理?，未經許可，禁止轉載。

題圖來自 unsplash，基于 CC0 協議