2026年可組合商務架構：建構者指南
我在過去三年裡拆解了龐大的電商平台，將它們重建成可組合的架構。其中一些項目發布得很漂亮。另一些則變成了由中間件膠帶和開發者眼淚粘合在一起的科學怪人。這兩種結果之間的區別幾乎從不取決於我們選擇了哪個廠商 -- 它取決於我們從第一天起如何思考架構。
可組合商務不再是你在會議上聽到的流行語。在 2026 年，它是任何年收入超過 1000 萬美元的電商運營的主流架構模式。但「可組合」已經成為那些術語之一，意思是銷售商想要它代表什麼就代表什麼。所以讓我們切入重點，談談你在構建這些東西時真正重要的是什麼。
目錄
- 2026 年可組合商務的真正含義
- MACH 原則：仍然相關還是只是營銷？
- 廠商格局：誰做什麼最擅長
- 編排層：最難的、沒人談論的部分
- 關注點分離：PIM、OMS 和商務核心
- 構建與購買：真實決策的框架
- 可組合世界中的前端架構
- 性能、成本以及可組合性的隱藏稅費
- 常見問題
2026 年可組合商務的真正含義
可組合商務是從獨立的、最佳實踐的服務中組裝你的電商堆棧的做法，而不是依賴單一的龐大平台。每項服務擁有特定的業務功能 -- 購物車管理、產品信息、訂單管理、搜索、支付 -- 並通過 API 與其他服務通信。
這個想法並不新穎。面向服務的架構自 2000 年代初期就存在了。不同的是，生態系統現在已經成熟到你可以不從頭開始構建一切就能實現它。在 2024 年，也許 15-20% 的企業電商真正是可組合的。到 2026 年初，根據 Gartner 的估計，這個數字已經超過 35%，而且還在加速增長。
但這裡是我想讓你理解的：可組合商務是一種架構模式，不是一種產品。沒有任何單一廠商能給你一個可組合的架構。你構建一個。廠商給你組件。
龐大系統並未消亡
在我們進一步之前，我需要說一些不受歡迎的話：龐大系統對很多企業來說都很好。如果你用 Shopify Plus 商店做了 200 萬美元/年的業務，你不需要可組合商務。你需要賣出更多東西。可組合架構的複雜性稅只有在以下情況下才能自償：
- 你在多個市場運營，有不同的監管要求
- 你的業務邏輯有平台無法滿足的真正獨特要求
- 你需要能夠獨立地部署對堆棧不同部分的更改
- 你的規模已經達到廠商鎖定成為財務風險的程度
如果這些都不適用，請關閉本文，改為優化你的轉化漏斗。
MACH 原則：仍然相關還是只是營銷？
MACH 代表微服務、API 優先、雲原生和無頭。成立於 2020 年的 MACH 聯盟一直在推推這些原則作為現代商務架構的基礎。讓我們誠實地評估 2026 年每一個。
微服務：原則是健全的 -- 將你的系統分解為獨立可部署的服務。但該行業已經從 2020-2022 年「每個函數都是微服務」的瘋狂中進行了更正。實際上，大多數成功的可組合堆棧使用我所謂的「大小適中的服務」。你的購物車服務不需要是十二個微服務。它只需要是一項做好購物車工作的服務。
API 優先：這一個已經很好地經受了時間考驗。每個值得考慮的廠商都公開完整的 API。2026 年真正的問題不是某樣東西是否是 API 優先，而是 API 是否設計得好、版本管理是否一致，以及是否沒有「graphQL 端點實際上只是帶有額外步驟的 REST」的問題。
雲原生：表中的賭注。我想不出任何一個嚴肅的商務廠商在這一點上不是雲原生的。這個原則不太是一個差異化因素，更多的是一個複選框。
無頭：仍然絕對相關，也是直接影響你前端團隊最多的原則。將表現層與商務引擎解耦可以讓你使用 Next.js、Astro 或任何真正符合你性能要求的框架構建。
MACH 聯盟本身已經進化。在 2025 年，他們圍繞互操作性標準引入了治理，這是很及時的。認證仍然很重要作為一種信號，但我見過非 MACH 認證的工具在實踐中比一些認證過的工具更可組合。
廠商格局：誰做什麼最擅長
讓我們談論具體的事項。以下是主要參與者在 2026 年初的位置：
| 廠商 | 核心優勢 | 定價模型 | 最適合 | 注意事項 |
|---|---|---|---|---|
| commercetools | 商務引擎（購物車、結帳、產品目錄） | 使用量計費，成長層起價約 30K 美元/年 | 企業多市場 | API 表面的複雜性；你需要強開發人員 |
| Fabric | 模塊化商務平台（OMS、PIM、商務） | 基於模塊，約 25K-80K 美元/年，取決於模塊 | 中端市場到想要靈活性的企業 | 更新的生態系統；比 commercetools 的集成少 |
| Commerce Layer | 多市場的 API 優先商務 | 使用量計費，成長層起價約每月 1,200 美元 | 國際商務、多品牌 | 意見不多 = 架構決策更多由你負責 |
| Medusa | 開源商務引擎 | 免費（自託管），2026 年雲定價待定 | 想要完全控制且有開發能力的團隊 | 你擁有基礎設施和擴展 |
| Nacelle | 商務數據編排/無頭中間件 | 起價約每月 2,000 美元 | 已經在 Shopify 上想要無頭前端的團隊 | 它是現有後端之上的一層，不是替代品 |
| Elastic Path | 企業商務引擎 | 自定義定價，通常 50K+ 美元/年 | 具有複雜產品模型的大型企業 | 成本；這是高級定價層 |
2026 年的 commercetools
commercetools 仍然是大規模可組合實現的默認選擇。他們的可組合商務產品已經成熟了很多。他們在 2025 年底推出的 Foundry 層使他們對中端市場公司來說更容易獲得，定價從每年約 30,000 美元開始，而不是 100,000 美元以上的企業層。
我喜歡什麼：他們的事件驅動架構和訂閱對構建反應式工作流很出色。API 表面非常龐大 -- 坦白說，可能太龐大了 -- 但這意味著你很少遇到牆。
什麼讓我沮喪：學習曲線很陡峭。commercetools 給你樂高積木，不是預製模型。你需要理解商務領域建模的經驗豐富的開發人員。預算比你的銷售代表告訴你的實現時間多 2-3 倍。
Medusa：開源競爭者
Medusa 變得真正有趣。他們的 v2 重寫（現在穩定）轉向了模塊化架構，讓你只使用你需要的部分。它是基於 Node.js 的，這意味著你的 JavaScript 團隊實際上可以在不學習新語言的情況下使用它。
經濟學對某些團隊來說很有吸引力：自託管 Medusa 在配置良好的雲設置上的成本可能比相同交易量的 commercetools 實現低 60-80%。權衡是顯而易見的 -- 你負責正常運行時間、擴展和安全補丁。
// Medusa v2 模塊模式 - 擴展產品模塊
import { Module } from "@medusajs/framework/utils"
import CustomProductService from "./services/custom-product"
export default Module("customProduct", {
service: CustomProductService,
})
Medusa 的模塊系統很乾淨，遵循如果你使用過 NestJS 或類似框架會熟悉的模式。
Nacelle：編排發揮
Nacelle 佔據了一個有趣的利基。它不是商務引擎 -- 它是一個數據編排層，位於你現有的商務後端（Shopify、BigCommerce 等）和你的無頭前端之間。它預索引你的商務數據並通過針對前端消費優化的 GraphQL API 提供服務。
如果你是想要無頭前端但不想完全撕裂後端的 Shopify Plus 商家，Nacelle 就很有意義。但要理解你在購買什麼：它是一個緩存和規範化層，不是對你商務邏輯的替代。
編排層：最難的、沒人談論的部分
這是大多數可組合商務項目出問題的地方。你已經選擇了你的商務引擎、你的 PIM、你的 OMS、你的搜索提供商、你的 CMS。現在你需要它們相互通信。這是編排層，這是你將做出的最具架構重要性的單一決定。
編排層負責：
- 將來自多個服務的數據聚合成你的前端需要的形狀
- 路由跨越多個服務的業務邏輯（例如，「訂單下達時，在 OMS 中遞減庫存並觸發履行工作流」）
- 處理一個服務關閉但其他服務沒有時的故障情況
- 跨越服務邊界管理身份驗證和授權
我見過有效的模式
後端對前端 (BFF)：構建位於你的前端和商務服務之間的薄 API 層。這個 BFF 聚合呼叫、處理緩存並為每個前端（web、移動、POS）的具體需要塑造數據。我們通常用 Node.js 或 Go 構建這些，部署為無服務器函數或輕量級容器。
// BFF 路由，從多個來源聚合產品數據
export async function GET(request: Request) {
const productId = getProductId(request)
const [commerceProduct, pimEnrichment, inventory, reviews] =
await Promise.allSettled([
commercetools.getProduct(productId),
akeneo.getProductData(productId),
oms.getInventoryLevels(productId),
reviews.getProductReviews(productId),
])
// 優雅降級：即使評論已關閉，產品頁面仍然工作
return Response.json({
...resolveSettled(commerceProduct),
enrichment: resolveSettled(pimEnrichment, {}),
inventory: resolveSettled(inventory, { available: true }),
reviews: resolveSettled(reviews, []),
})
}
注意 Promise.allSettled 模式。這至關重要。在可組合架構中，你不能讓一個服務的故障級聯到整個頁面。如果你的評論服務正經歷糟糕的日子，產品頁面應該仍然呈現。
事件驅動編排：對於非同步工作流，使用事件總線（AWS EventBridge、Google Pub/Sub 或自託管解決方案如 Kafka）。訂單下達時，發布 order.created 事件。你的 OMS、你的電子郵件服務、你的分析管道和你的庫存系統都獨立地訂閱該事件。
什麼不工作：將所有編排邏輯放在你的前端。我見過團隊試圖在每個頁面加載時讓他們的 Next.js 應用呼叫六個不同的 API。性能很糟糕，錯誤處理是一場噩夢，最終你最終會將業務邏輯分散在 React 組件中。不要這樣做。
我們定期為可組合商務堆棧構建編排層。如果你正在評估這種架構，我們應該談談。
關注點分離：PIM、OMS 和商務核心
可組合商務中最大的架構決策之一是弄清楚哪個系統是哪個數據的「真實來源」。搞錯了，你會花費數月調試數據同步問題。
產品信息管理 (PIM)
你的 PIM（Akeneo、Salsify、Pimcore 或 Fabric 中的 PIM 模塊）應該擁有：
- 豐富的產品描述、營銷文案
- 產品分類法和分類
- 數字資產（圖像、視頻、文檔）
- 產品關係（交叉銷售、向上銷售、捆綁）
- 多市場的本地化內容
你的商務引擎應該擁有：
- 定價和貨幣邏輯
- 庫存可用性
- 購物車和結帳行為
- 影響定價的產品變體配置
我最經常看到的錯誤：試圖讓 PIM 擁有定價，或試圖讓商務引擎擁有豐富的內容。這些系統為不同的東西優化。尊重這一點。
訂單管理系統 (OMS)
OMS 問題變得更複雜。你是使用商務引擎中的內置訂單管理，還是引入專用 OMS，如 Fluent Commerce、Manhattan Associates 或 Fabric OMS 模塊？
我的經驗法則：如果你有超過兩個履行地點，或者你需要複雜的訂單路由邏輯（例如，拆分銷售、商店履行、直運），你需要專用 OMS。商務引擎（如 commercetools 或 Shopify）中內置的訂單管理是為簡單的履行流程設計的。
| 場景 | 建議 |
|---|---|
| 單一倉庫，僅國內 | 使用商務引擎的內置 OMS |
| 2-5 個履行地點 | 評估專用 OMS；可能仍然使用內置 |
| 5+ 個地點，混合履行（倉庫 + 商店 + 直運） | 專用 OMS 幾乎肯定是必需的 |
| 多市場，每個地區有不同的履行夥伴 | 專用 OMS，沒有疑問 |
CMS 部分
你的無頭 CMS 處理編輯內容、登陸頁面、促銷橫幅和內容驅動的商務體驗。將商務邏輯保留在 CMS 之外。將編輯內容保留在商務引擎之外。CMS 和商務引擎應該只共享一個產品標識符，讓它們相互引用。
構建與購買：真實決策的框架
每個可組合商務項目都涉及數十個構建與購買決策。以下是我使用的框架：
購買時機：
- 該功能已被充分理解和商品化（支付、稅收計算、電子郵件傳送）
- 涉及監管合規性（支付的 PCI-DSS、稅收司法管轄區規則）
- 廠商的定價隨着你的收入線性擴展（你不為未使用的容量付費）
- 上市時間比自定義更重要
構建時機：
- 該功能是你業務的真正競爭差異化因素
- 沒有廠商在沒有大量變通的情況下處理你的特定業務邏輯
- 廠商的長期成本超過構建和維護成本
- 你有工程人才來維護它（對這個要誠實）
編排層：幾乎總是構建。這是你的業務邏輯。從廠商購買編排層意味著你正在將核心業務流程耦合到他們的抽象。
搜索：購買。Algolia、Typesense 或 Elasticsearch 即服務。構建生產質量的搜索是一項多年投資。Algolia 在 2026 年的電商層定價起價約為每 1,000 次搜索請求 1 美元。
支付：購買，顯然。Stripe、Adyen 或類似的。永遠不要構建支付處理。
自定義定價邏輯：通常構建。如果你的定價涉及複雜的規則（合同定價、量階、具有監管約束的地理定價），你可能需要一個自定義定價服務，位於你的前端和商務引擎之間。
可組合世界中的前端架構
前端是可組合商務要麼履行其承諾，要麼失敗的地方。你的前端團隊需要從多個 API 消費數據並呈現快速、可訪問的頁面。
Next.js 在 2026 年仍然是可組合商務前端的主導框架。應用路由器結合服務器組件和 Next.js 15 中的緩存原語，很好地映射到可組合模式。你可以在服務器組件級別從你的 BFF 獲取，在數據到達時流式傳輸，並保持客戶端包精簡。
我們也在內容豐富的商務網站中有 Astro 的優異結果。Astro 的島嶼架構讓你將整個產品目錄呈現為靜態 HTML，並僅水合互動部分（添加到購物車按鈕、動態定價）。對於一個擁有 50,000+ SKU 的客戶，與他們之前的 Next.js 實現相比，我們看到最大的內容繪製改進了 40%。
前端的關鍵架構模式：
// Next.js 15 服務器組件從 BFF 獲取
async function ProductPage({ params }: { params: { slug: string } }) {
const product = await fetch(
`${process.env.BFF_URL}/products/${params.slug}`,
{ next: { revalidate: 60 } } // ISR：每 60 秒重新驗證
).then(r => r.json())
return (
<main>
<ProductHero product={product} />
<Suspense fallback={<ReviewsSkeleton />}>
<ProductReviews productId={product.id} />
</Suspense>
<Suspense fallback={<RecommendationsSkeleton />}>
<Recommendations productId={product.id} />
</Suspense>
</main>
)
}
注意 Suspense 邊界。每個部分可以獨立加載。如果推薦需要 800 毫秒來計算，頁面的其餘部分已經是交互式的。
如果你正在評估基於 Next.js 的可組合商務前端，實現細節非常重要。緩存無效策略、ISR 定時和錯誤邊界設計將決定你的網站是感覺快速還是令人沮喪。
性能、成本以及可組合性的隱藏稅費
讓我們談論金錢。可組合商務的構建成本高於龐大系統。任何告訴你不是這樣的人都在向你銷售什麼。
以下是中端市場電商運營（年收入 2000 萬至 5000 萬美元）的粗略成本比較：
| 成本類別 | 龐大系統（Shopify Plus） | 可組合堆棧 |
|---|---|---|
| 平台許可 | 24K-48K 美元/年 | 60K-150K 美元/年（所有服務的總和） |
| 實現 | 100K-300K 美元 | 300K-800K 美元 |
| 年度維護（開發團隊） | 1-2 名開發人員 | 3-5 名開發人員 |
| 上市時間 | 3-6 個月 | 6-14 個月 |
| 基礎設施 | 包括 | 2K-15K 美元/月 |
這些數字是真實的。我見過這些發票。可組合堆棧的前期成本高 2-3 倍，需要更大的持續團隊。
那麼你為什麼要這樣做？因為總所有權成本在規模上會翻轉。當你做了 1 億美元以上的收入並在多個市場運營時，龐大系統的限制開始花費你更多的收入損失和變通複雜性，而不是可組合堆棧的維護成本。交叉點對每項業務都不同，但通常在 3000 萬至 8000 萬美元的收入範圍內。
隱藏成本
集成維護：API 改變。廠商棄用端點。每個集成都是破裂的表面積。預算將 15-20% 的工程時間用於集成維護。
廠商管理：你現在有與 5-10 個廠商的關係，而不是一個。每個都有自己的支持流程、SLA 和計費週期。你的團隊中需要有人擁有這個。
可觀察性：當你的龐大系統破裂時，你查看一個儀表板。當你的可組合堆棧破裂時，你需要跨多個服務的分布式跟踪來弄清楚出了什麼問題。從第一天開始投資可觀察性工具（Datadog、Grafana Cloud 等）。
對於我們的可組合商務實現定價，我們構建參與度，以便從一開始就預先考慮這些隱藏成本，而不是讓它們在六個月後讓你吃驚。
常見問題
可組合商務和無頭商務之間有什麼區別？ 無頭商務是可組合商務的一個方面 -- 它意味著將前端表現層與後端解耦。可組合商務進一步：它意味著將整個後端分解為獨立的服務（商務引擎、PIM、OMS、搜索、支付等），這些服務可以獨立交換。你可以是無頭而不是可組合，但你不能真正是可組合而不是無頭。
對中端市場企業來說，commercetools 值得花費嗎？ 這取決於你的複雜性。commercetools 的成長層在 2026 年起價約為 30K 美元/年，對中端市場來說是可以接受的。但實現成本是成本飆升的地方 -- 你需要經驗豐富的開發人員，他們理解他們的 API 模型。如果你的業務有多市場、多貨幣或複雜的產品建模需求，投資通常會得到回報。對於更簡單的使用情況，Medusa 或 Commerce Layer 可能給你 80% 的功能，成本只有 40%。
可組合商務實現通常需要多長時間？ 對於完整的可組合堆棧（商務引擎 + PIM + OMS + 無頭前端 + 編排層），假設一個 4-6 名開發人員的團隊，預期 8-14 個月的初始啟動。你可以通過分階段推出來大大縮短這個時間 -- 首先啟動商務引擎和前端，然後在後續階段中添加 PIM 和 OMS 集成。我們見過分階段方法在 4-6 個月內獲得初始啟動。
我應該使用 Medusa 而不是 commercetools 來節省成本嗎？ 如果你有一個有能力的 Node.js 團隊並且對管理你自己的基礎設施感到滿意，Medusa 是一個很好的選擇。許可成本差異很大（Medusa 是免費/開源的，對 commercetools 為 30K-150K 美元/年）。但要計入基礎設施管理、安全補丁和擴展的成本。對於開發人員少於 5 人的團隊，自託管的運營負擔可能會消耗許可節省。對於擁有 DevOps 能力的更大團隊，Medusa 的經濟學非常有吸引力。
編排層在可組合商務中是什麼？ 編排層是協調你各種商務服務之間通信的自定義中間件。它處理數據聚合（將你的 PIM 的產品數據與你的商務引擎的定價結合在一起）、業務工作流協調（訂單下達時觸發履行）和故障管理（一個服務不可用時優雅降級）。將其視為你服務樂隊的指揮。大多數團隊將其實現為後端對前端 (BFF) API 層結合非同步工作流的事件驅動系統。
我可以逐步從 Shopify 遷移到可組合架構嗎？ 絕對可以，這是我會推薦的方法。首先開始無頭 -- 使用 Next.js 或 Astro 構建一個新前端，與 Shopify 的 Storefront API 對話。然後逐漸提取功能：將搜索移動到 Algolia，將產品內容移動到 PIM，最終用 commercetools 或 Commerce Layer 之類的東西替換 Shopify 的商務引擎。Nacelle 可以在此轉換期間用作有用的橋樑，將 Shopify 的 API 規範化為更友好的前端格式。關鍵是永遠不要進行大爆炸遷移。
MACH 聯盟是什麼，認證是否重要？ MACH 聯盟是一個倡導微服務、API 優先、雲原生和無頭架構原則的行業組織。成員廠商包括 commercetools、Contentful、Algolia 和截至 2026 年約 100 個其他人。認證意味著廠商已獨立針對 MACH 原則進行評估。在評估廠商時，它是一個有用的過濾器，但不是唯一重要的。一些優秀的工具（如 Medusa）沒有 MACH 認證，因為它們是開源的，不參與聯盟。將認證用作許多信號中的一個。
我如何處理可組合堆棧中多個服務之間的數據一致性？ 這是分布式系統中最難的問題之一。簡短的答案：接受最終一致性。你的 PIM 更新不會立即反映在你的商務引擎中，對大多數使用情況來說是可以的。使用事件驅動架構非同步傳播更改。對於少數幾個需要強一致性的情況（結帳期間的庫存遞減，例如），使用適當重試邏輯和冪等鍵的同步 API 調用。實現分布式跟踪系統，以便你可以跟踪跨服務的數據流並在發生一致性問題時調試。