圖片由 napkin.ai 產生
中台架構模式（Middle Platform Architecture）淺談
前言：
我一直以來都覺得中台架構大概是某種 buzzword，畢竟把共用資源提取出來是軟體工程中隨處可見的操作。直到最近真實接觸了使用中台架構的大型服務數個月後，我意識到在某些特殊狀況下中台架構可以發揮的價值確實不小，查閱資料並結合我自身經驗後，有感而發完成這篇文章。
簡述：
中台架構（Middle Platform Architecture）是一種將大型系統內部共用資源、服務與技術提取出來單獨運行的架構模式。最早由阿里巴巴提出並推廣，阿里巴巴希望通過建立中台架構，將不同業務線所需的共用資源（如用戶資料、商品庫存、訂單處理等）獨立出來變成給內部共同使用的服務，進而解決大型企業中各業務線獨立運作，資源和技術無法共享的問題。
概念：
圖片由 napkin.ai 產生
中台架構基於模組化設計的理念，將各部門或業務線所需的共用功能、技術進行標準化、集中管理。進而集中開發資源、提高利用率、避免重複開發。中台的目標是通過建立統一的資源來支援各個業務部門，實現協同運作。
可以把它理解為程式設計中的抽象共用，但不是在程式碼層級，而是服務層級。目的是讓不同層級的系統部分，能夠更高效地協作，並擁有更適合自己的開發流程、軟硬體支援以及專業的團隊。
簡單範例：
假設一個 C2C 購物平台，其結構可分為不同的前台和中台層級，前台業務依賴中台提供的核心通用功能發展。
- 前台層級
- 買家前台
- 賣家前台
- 站方管理前台
- 數據報表前台
- 中台層級
- 訂單中台：負責處理所有訂單的管理與調度。
- 用戶資料中台：管理各前台使用者的資料，保持資料一致性。
- Log 中台：管理和分析系統中的各種日誌數據。
圖片由 napkin.ai 產生
中台架構與微服務架構：
中台架構與微服務雖然都是想把一個大服務拆成多個服務，但在拆分邏輯上不同
- 橫向拆分（中台架構）
中台架構強調的是橫向的「技術層次」拆分，通常以技術能力、數據平台、共用功能為核心進行拆分，例如資料傳輸、演算法計算、日誌存取。在中台架構中，更多的是從平台化、服務化的角度來提供共享服務，避免各業務單位分散地重複建設和管理相同的功能，這有助於資源統一與效率提升。
- 直向拆分（微服務架構）
微服務架構則偏向於基於「用戶功能」或「業務流程」進行拆分，這樣的拆分方式是面向具體的業務需求來設計的，例如會員管理、支付處理、訂單管理等。微服務架構強調的是服務的獨立性，每個微服務專注於單一的業務邏輯，這樣能夠使開發更加靈活，並且支援獨立的部署和擴展。
其兩者也可以併行使用，除了一個系統可以同時橫向又直向拆分外，也可能出現中台對外是統一的，但其內部實作是微服務的這種互相包覆對方的狀態。
缺點：
- 依賴性
在橫向拆分的架構中，通常會將共用的基礎功能或服務（如認證、用戶管理、日誌記錄等）放置在較低層（即中台）。這意味著上層的業務模組必須依賴這些低層模組來進行操作。
低階模組的更新或重構變得非常困難，一旦出現問題可能會影響到多個高階模組，從而造成整體系統的故障或降級。反之高階模組的開發和維護也會被迫依賴於低階模組的穩定性和更新頻率。
低階模組統一提供多個前台呼叫也可能會導致系統出現性能瓶頸。而低階模組的性能問題（例如吞吐量不足或延遲過高）即便只是因為單一前台的需求引起，也會直接影響到所有依賴該模組的上層服務。
- 上手程度
中台架構和微服務架構都會增加系統的複雜度。這些架構往往會使用多種不同的技術來進行服務間的通信，如 HTTP、gRPC、Queue。每一種技術都有其特點，工程師必須對這些協議和工具都有了解。
此外，服務之間頻繁互相調用時，故障排查變得更加棘手。通常會需要引入監控工具與 Trace Log 來幫助定位問題並追蹤效能瓶頸。這些工具可以顯示各個服務的運行狀況，並提供錯誤日誌和調用鏈路。然而，這些工具本身又會再提升上手難度。
這些因素讓中台架構和微服務架構的上手門檻相對較高，對開發人員的技術能力提出了更高的要求。
挑戰：
在設計中台架構時，中台為了滿足所有依賴其的前台需求，中台經常面臨必須在三個方案之間做選擇的情況，這三個方案本身互為解決方法，沒有銀彈。因此在選擇時，必須深入考慮安全性、性能、維護性等多方面因素，並平衡這些需求，選擇最符合業務需求和技術能力的方案。
- 方案 1：大量資料回傳
這種設計會造成 over fetching。一次性回傳大量資料，儘管減少後端調用次數，但會導致資料過度暴露，增加安全性風險，不一定每個前台都需要知道這麼多資料，特別是處理敏感資料時；資料量過大，影響系統效能，造成網絡瓶頸；API 介面變複雜，管理與維護困難。
適用於資料量較小且可以接受一定風險的情況，但若資料量增大或敏感性提高，則不太適用。
- 方案 2：多次調用 API
方案 2 是方案 1 的相反，造成 under fetching。中台 API 僅回傳必要資料，前台需要進行多次調用才能取得所需資料，這樣雖能降低資料暴露風險，但會帶來查詢延遲，進而影響用戶體驗。這也會使前台的邏輯變得更為複雜，並依賴更多的錯誤處理與協作。
適合對安全性和資料隱私有較高要求的情境，但會帶來查詢延遲與前台邏輯複雜度的問題。
- 方案 3：複雜查詢規則
為了 over fetching 或 under fetching，可以引入如 GraphQL、聚合 API、Batch API、甚至開發專用的 Domain Specific Language (DSL)，這樣前台只獲取所需資料，減少過多資料回傳的風險。
這些技術可能會破壞中台封裝性，使前台過度理解中台底層資料結構，並可能引入安全性風險，如權限滲透或未經授權的查詢。同時也更進一步提升系統的上手難度。
好中台？
原本我對中台的理解只到上面那段，我認為不論選擇何種方案，最終都會有無法避免的大缺點，直到我看到某篇文章 [1]。他讓我理解到若能妥善處理，方案 3 引入複雜查詢規則，將能發揮中台的真正價值：
| 如何合理地抽象出自家的服務和技術，將業務與底層隔離開來？DSL 該如何設計，才能讓前台不理解底層的前提下依舊能順利使用？ |
DSL 隔離、抽象的越好，中台不只通用性越強還能避免破壞其封裝性，文中對此提出兩個好 DSL 範例。
- SQL
以 SQL 為抽象的例子，資料庫開發者（中台）可以專注於資料儲存、查詢演算法等純技術問題，而使用者（前台）則使用 SQL 操作資料庫，進行各種 CURD 操作，並根據需求在不知道底層原理的前提下創造出多樣有價值的應用。
- Tensorflow 和 Keras
以深度學習框架為隔離的例子，反向傳遞演算法和硬體 GPU 控制等實現需要被隔離，應用開發者其實不需要了解這些底層的實作細節。且這些計算模型的價值足以支撐多種神經網路應用的發展，並且能讓應用開發者大幅提升效率、加速開發。
舉例來說，公司具有強大的搜尋引擎技術，可以提供模糊搜尋、語意搜尋、反向索引等，而這份技術：
- client 調用時會需要對搜尋引擎底層有一定理解才能知道操作方式。
- 需要專業的機器學習工程師來設計、維護。
- 公司各大服務，商城、論壇、內部 ERP 都會使用到。
這時該技術就比較適合單獨拉出來變成搜尋中台，讓其它前台的後端工程師不需要理解底層知識也能直接調用機器學習工程師所包裝好的功能。在開發上也能各司其職不互相影響。
引入中台？
- 共用操作是否真的複雜到需要被隔離？
當決定引入中台時，最基本的假設是，中台應該能夠提供一些共享的服務和功能，這些功能要足夠複雜、跨部門、重複使用，才需要集中管理並減少重複建設。
- 是否有能力設計出足夠優秀的介面來切開前台與中台？
中台成功的關鍵是設計一個能夠很好隔離業務邏輯和底層技術的介面。然而，這樣的設計並不是容易完成的，尤其是在多樣化和複雜的業務需求面前。所謂切開前台與中台的界面，並不是簡單的功能分割，而是要達到以下目的：
- 簡單：業務方應該能夠輕松理解並使用中台提供的服務。
- 穩定和彈性：在保持技術深度和靈活性的同時，設計的介面能夠適應業務需求的變化。
- 抽象：中台應該提供高層次的抽象，讓業務邏輯不必直接接觸到底層技術，這樣才能真正降低複雜性。
- 共用資料是否有價值到足以讓各種業務邏輯圍繞它發展？
這一點與中台的核心價值密切相關。共用資料本身需要具有足夠的價值和可擴展性，才能夠讓多個業務邏輯圍繞它發展。
結論：
中台架構在理念上具備高度價值，它通過將程式碼重複利用的概念提升到架構層級，同時實現資源共享與開發環境獨立，如果公司內真的擁有複雜到需要被隔離、有價值到足以讓各種業務邏輯圍繞它發展的深度技術力，那麼建立此中台就可以成為支撐多樣化業務需求的核心，充分展現其價值。
然而，中台架構也面臨一定挑戰：
- 工程師的高要求：中台架構要求開發團隊具備高度的技術能力，不只在維護與偵錯上需要更強大的技術力，更需要有能力設計出足夠優秀的中台介面或 DSL。
- 團隊協作的管理：中台涵蓋大量前台產品，依賴性極高，在如此多的使用者下安排中台的設計與開發順序使得他的管理層面更加困難。
- 領導者的前瞻性：領導層需具備預見未來需求與技術變化的能力，並有效規劃架構選型與資源分配，以確保中有價值到足以讓各種業務邏輯圍繞它發展。
但中台真的這麼難嗎？我個人認為中台早已存在於我們的日常開發之中，當一個能力同時具備以下特性時：
- 需要專用硬體資源（搜尋、轉檔、機器學習）
- 需要高專業度維護（風控模型、資料一致性）
- 具備高度領域知識，需要抽象與封裝
工程師自然會將這些能力獨立出來，那些就是真正有價值的中台。它會在開發與維護的過程中自然演化出來，而不是盲目追求新技術之下強硬套用的，大家共勉之。
參考資料：
[1] 大型科技企业架构：中台模式的爱与恨 - FerventDesert - 博客园
https://www.cnblogs.com/buptzym/p/8763490.html
[2] napkin AI
