架構選型可說是一門複雜的學問，因團隊目標與資源的差異，不會有固定的答案，我們只能從中做理性的分析，尋求一個最適合的作法，而非一昧的追尋潮流，而忽略選型的本質

1. 大電商架構選型與執行思考
一站式購物平台架構方案與執行計畫
Simon Liang (YC)

2. 大綱
● 公司整體目標
● 目標訂定與問題
● 架構方案
● 架構方案比較
● 架構規畫
● 決策因子
● 實務執行方案
● 後續執行

3. 商業目標設定 (1/2)
● 統合集團旗下電商，打造一站式購物平台
○ 購物中心 (B2C)
○ 超級商城 (B2B2C)
○ 品牌電商 (Single Brand)
● 統一入口與單一站台併存
○ 統一入口作整體性導流操作，提供一致性體驗
○ 單一站台可作個別操作行銷，並依照調性，提供差別化服務
● 求同存異，盡可能統一處理，減少管銷成本
○ 統一帳務處理
○ 統一商品理貨處理
○ 統一金流發票處理

4. 商業目標設定 (2/2)
大電商入口
品牌電商 超級商城 購物中心
品牌
站1 購物
中心
福利網..
品牌
站2
品牌
站n..
店1 店2 店n..
B2B2C 平台 B2C 平台
延伸模組
大電商共用平台 (商品, 訂單, 供應商, 會員....)
Portal
Site / Shop
Platform
Business Platform

5. 系統目標設定
● 單一大電商平台，減少維護成本
● 面對業務需求複雜度提升，具備靈活的擴充能力
● 面對業務量成長，具備橫向擴展能力
● 因團隊人力現況，可能需要有跨語言系統整合能力 (Java & PHP)
● 需在商業目標與技術發展間做出平衡計畫
● Monolithic vs Microservice ?

6. 問題與挑戰
● 新系統為PHP團隊負責，而既有購物中心為Java團隊開發
○ 跨語言方案?
○ 團隊優勢與劣勢
● 購物中心Java系統老舊，能沿用的功能組件應不多
● 除了開發新系統，各自業務仍需持續推進
● 3合1平台帶來的高複雜度，如何做好架構拆分，達到所謂的”求同存異”
● 3合1平台帶來的量級提升，如何預留橫向擴充可能，因應未來倍速成長
● 時程的考驗，不可能一步到位，如何讓技術架構，循序漸進分階段達成

7. 設計策略
● 新平台以B2B2C切入，後整合B2C服務
● 業務面思考
● 評估資源現況
● SOA原則
● 設計可行之架構方案

8. 架構方案
● 子母系統
● 微服務化
● 單體式底層服務

9. 架構方案 - 子母系統 (1/2)
B2B2C系統
一站式Portal
Shop1 Shop2 Shop n
B2C系統
Mall 1 Mall 2 Mall n
Portal系統
API"取"資料 API "取"資料
● 三系統系統與資
料庫完全獨立
● 可先建立商業服
務，後建立整合
Portal
● Portal系統介由
API拉取兩系統做
資料串連
API 交換資料API 交換資料

10. 架構方案 - 子母系統 (2/2)
● 優點
○ 三個系統各別存在，互不干擾
○ 各別商務皆可同時推進
○ 可先達成商務，後建 Portal
● 缺點
○ 未來一站式整合成本高
○ 兩子系統分離，能整合的項目有限
○ 一站式訴求因跨系統整合困難，可能淪為形式
● 適用情境
○ 整合平台需求低，商務連結性低
○ 跨平台Portal延伸需求低

11. 架構方案 - 微服務化 (1/2)
B2B2C系統
一站式Portal
Shop1 Shop2 Shop n
B2C系統
Mall 1 Mall 2 Mall n
Portal系統
Platform 中控
Gateway
Order微服務 Product微服務 Payment微服務 xxxx微服務
API 交換資料
API 交換資料
API 交換資料
● 三系統共通資料
與商務部分由底
層platform控制
● 透過API銜接各微
服務
微服務化底層平台
API 交換資料

12. 架構方案 - 微服務化 (2/2)
● 優點
○ 耦合性低
○ 彈性高，覆用性高
○ 可應付未來各種商務需求
● 缺點
○ 初期成本高，難以呼應短期商業目標
○ 開發成本高，人力素質需求高
● 適用情境
○ 公司有大型整合商務需求，且願意提供資源支持
○ 公司有大型技術團隊編制，或是有計畫建立大型開發團隊

13. 架構方案 - 單體式底層服務 (1/2)
B2B2C系統
一站式Portal
Shop1 Shop2 Shop n
B2C系統
Mall 1 Mall 2 Mall n
Portal系統
Platform 中控系統
Order模組 Product模組 Payment模組 xxxx模組
API 交換資料
API 交換資料
單體式底層平台
API 交換資料
● 三系統共通資料
與商務部分由底
層platform控制
● 透過API銜接底層
平台

14. 架構方案 - 單體式底層服務 (2/2)
● 優點
○ 耦合性適中，開發難度可接受
○ 未來可循序微服務化
○ 可應付未來商務需求
● 缺點
○ 對比直接微服務化，需有多次重構
○ 開發成本與人員素質仍有一定要求在
● 適用情境
○ 公司商務端與技術端期望能同時併進之方案
○ 公司長期開發資源願意支持

15. 架構方案比較
開發難度 開發人力 維護難度 開發時程 未來擴充性
子母系統 低 中 低 中等 低
微服務化 高 特高 高 長期 高
單體式底層 中 高 中 中長期 中
商務面架構面

16. 方案決策因子
● 商務面
○ 一站式購物, 包含B2C & B2B2C
○ 時程目標 (business road map) ?
○ 是否有擅長大型系統 SA的product manager?
● 資源面
○ 人力資源
○ 團隊經驗

17. Monolithic vs Microservice?
● 技術方案目的在於達成目標與解決痛點，而非追尋潮流
● 微服務是顯學但不是萬靈丹
○ https://dwmkerr.com/the-death-of-microservice-madness-in-2018/
● 選擇對現況與需求最合適的方式
○ 團隊規模與能力?
○ 短中長期目標為何?
○ 開發成本?

18. 方案決策
● 要能做到一站式購物，必須要有底層拆分
● 公司人力有限且無擴編空間，無法進行大規模開發
● 團隊成員較無分散式系統相關經驗，學習曲線長
● 單體式底層未來仍有可能逐步微服務化
● 商業目標與時程必須達成，系統無法一步到位
● 除技術端，規劃端系統分析能力也會是影響時程的因素
● 考量開發成本與商務目標，”單體式底層平台”是較好的選項

19. 實務執行
● 拆分階段，循序執行，逐步重構
● 短中期能達成商業目標為前提，逐步做到微服務化
● 活化人力資源運用
● 擴編技術團隊

20. 實務執行 - 階段拆分
● 階段0 : 既有系統盤點
● 階段1 : 導入與基礎工程
○ 建構單體式底層系統框架
○ 挑選業務耦合性較低之模組，搬移至底層
○ B2C系統串接至底層，並開放給 B2B2C團隊參考介接
● 階段2 : 循序模組重構
○ 持續將共用模組拆分至底層
○ B2C與B2B2C對應功能因應底層調整，也需重構
● 階段3 : 循序微服務化
○ 將大單體中的模組逐步進行微服務化

21. 階段執行計畫 - 既有系統盤點
B2C 平台
Order模組
Cart模組
Product模組
xxx模組
購物X App購物X mweb
API 交換資料
● 模組以composer載入, 非獨立服務
● 模組業務邏輯與資料需進行拆分，才能給其它
產品使用
● 模組間仍有一定耦合性，故只能循序處理
● 系統設計無多站台支援

22. ● 加購系統增加多站台支援
● 建立大單體底層
● 下放共用模組至大單體
● 提供B2B2C系統介接的可能性
階段執行計畫 - 導入與基礎工程
B2C 平台
訂單模
組
帳務模
組
購物車
模組
xxx模組
福利網購物
API 交換資料
Platform 中控系統
會員模組商品模組 供應商模組
API 交換資料
B2B2C 系統
訂單模
組
購物車
模組
Shop1 Shop2

23. 階段執行計畫 - 循序模組重構
● 持續將可共用之模組下放至底層
● 兩平台需同時進行並重構
B2C 平台
訂單模
組
帳務模
組
購物車
模組
xxx模組
福利網購物
API 交換資料
Platform 中控系統
會員模組商品模組 供應商模組
API 交換資料
B2B2C 系統
訂單模
組
購物車
模組
Shop1 Shop2
訂單模組

24. 階段執行計畫 - 循序微服務化
● 建立微服務框架
● 挑選大單體中模組，逐步微服務化
B2C 平台
行銷模
組
購物車
模組
福利網購物
API 交換資料
Platform 中控系統
會員模組商品模組 供應商模組
API 交換資料
B2B2C 系統
B2B模
組
購物車
模組
Shop1 Shop2
Platform 中控
Gateway
供應商微
服務
API 交換資料

25. 整體架構Overview
B2B2C
系統
一站式Portal
S1 S2 Sn
B2C系統
M1 M2 Mn
Portal
系統
Platform 中控系統
Order
模組
Produc
t模組
Payme
nt模組
xxxx模
組
API 交換資料
API 交換資料API 交換資料
Portal
Site /
Shop
Platform
大電商入口
品牌電商 超級商城 購物中心
品
牌
站
1
購物
中心
福利
網..
品
牌
站
2
品
牌
站
n..
店
1
店
2
店
n..
B2B2C 平台 B2C 平台
延伸模組
大電商共用平台 (商品, 訂單, 供應商, 會
員....)
Business
Platform

26. 人力資源運用
● 因應底層開發需求，可拆分成Feature team 與 Platform team
○ Feature team : 跨專業成員組成 (Backend, app, PM, QA ….)，負責feature開發與底層溝通
○ Platform team : 後端RD組成，負責底層開發並與功能團隊溝通
● 底層平台建立初期，建議將後端人力投注於Platform team，可能比例約為70%
以上
● Java team可負責獨立拆出之微服務，不受語言影響
● 既有RD人力不足以應付未來開發，增補員額是持續要做的事情

27. 後續執行建議
● 規劃端需有跨商務的”產品經理”角色，才有辦法統籌所謂的”求同存異”
● 規畫端需提供相關business road map
○ business road map技術端可進行更完整之架構規畫與工作安排
● 針對新的business需提供完整的flow&spec (如B2B2C)
○ 不論對架構規畫或是功能開發都有其必要性
● 可逐步提供上述資料，同時跨部門間會有更多的討論
● 專案進行方式要貼近實務開發，上述提出之人力分組建議可納入參考

28. Q&A