背景
公司新業務有視頻點播與直播需求，經過一番對比分析，最終選擇了騰訊雲作爲視頻服務的供應商。
對於如何接入有如下爭論點：
1.由中臺統一對接視頻服務，封裝統一對外接口，如後續要切換視頻服務供應商，上層無需更改
一致點： 統一封裝對外服務
爭議點： 要不要做到可無縫切換視頻播放供應商而不影響上層業務
2.APP與WEB側基於騰訊視頻上傳&播放SDk封裝通用組件
一致點： 統一封裝SDK
爭議點： 封裝粒度是強封裝還是弱封裝。即隱藏內部實現，只暴露自定義參數；還是組件參數透傳騰訊SDk相關參數，只簡單封裝通用業務邏輯
對於上述爭議點，會議最終也沒討論出結論來。個人覺得，這兩個爭論點實際上是一個業務架構問題與技術架構問題，只有把這兩個問題理清楚，才能做出清晰的判斷。
業務架構
業務架構：實際上就是理清各方如何分工，如何交互，如何設計的問題。
對於該場景的有兩種架構方式，一種爲中控式、一種爲並行式。
中控式
中控式可理解爲由一箇中樞統一控制，大致結構圖如下所示：
核心思路： 由中臺統一對接視頻服務，抹平各服務商的差異，做到底層視頻服務切換對上層無感知
好處：
- 視頻服務切換，對業務方無影響，無額外開發工作量
難點&弊端：
- 視頻服務灰度切換問題
- 中臺需抽象化視頻服務爲共有服務，制定自有功能與交互邏輯；功能取交集，無法使用特有視頻服務獨有亮點功能
- 中臺邏輯複雜化，兼容維護成本高，不易迭代
並行式
並行式從字面意思可理解爲並行設計，兩條路線不衝突，大致結構圖如下所示：
核心思路： 對接不同的視頻服務上採用並行方案，互不影響
好處：
- 灰度切換方便，影響範圍可控制在較小的業務範圍
- 無需兼容處理，代碼邏輯清晰，精簡；全部切換後相關代碼可整體廢棄
- 可充分利用視頻服務商的全部功能
難點&弊端：
- 切換視頻供應商時需重新設計與開發，帶來鉅額工作量
技術架構
技術架構：技術實現細節如何做到高內聚、低耦合、易擴展、良好的版本迭代與向下兼容等，設計思路依賴業務架構。
對於爭論點二，有如下兩種技術架構思路，一種爲集中兼容處理，一種爲特定處理。
集中處理-強封裝
對於各個視頻服務SDK集中處理，統一對外參數，大致結構圖如下所示：
核心思路： 隱藏內部實現邏輯，提供統一的對外出口
好處：
- 強有力的控制，可做到內部變更對外部無感知
難點&弊端：
- 事前需要超前規劃，強有力的抽象，需保持克制只提供最小功能集，避免兼容問題
- 前期即需考慮封裝不同視頻服務保證後續能無縫切換問題，實現複雜，工作量大
特定處理-弱封裝
對各個視頻服務SDK特定處理，不同視頻服務對應封裝不同的前端組件，大致結構圖如下所示：
核心思路： 最小開閉原則，不對視頻SDK的做二次封裝是，透傳參數即可；額外擴展自定義通用業務封裝。
好處：
- 可獲得特定視頻服務商全量的功能服務
- 組件文檔無需單獨編寫，開發人員參考官方文檔即可，鼓勵DIY，遇到問題自己排查，而不是推給組件提供者
- 無需考慮兼容其他視頻服務，代碼簡潔、清晰，可維護強
弊端：
- 切換視頻服務需重新設計對應的組件，頂層業務側也需根據新組件的參數規範做調整
個人想法
1.剋制、恰到好處
這條實際上是一個平衡與取捨問題，不能一點不往將來考慮，但也不能一下考慮得太遙遠，考慮太遠的問題在於前期投入巨大工作量後期可能一點用不上。
2.乾淨、利落、清晰
個人在做業務架構時，會更多的考慮什麼樣的架構能夠讓技術架構更簡潔、清晰，便於維護。儘量避免架構設計劃定的框，造成技術實現細節繁瑣複雜。
3.低成本，高收益
對於這個問題，幹一件事總成本是相對固定的，對於上面的問題，我更傾向於前期採用低成本，後續真正要切的時候再投入另外的成本。
4.清晰而堅定的開頭、清晰而堅定的收尾
選擇了一種架構就應該從上到下保持一致，在一條道上做到最好，避免三心二意，這也要一點，那也要一點，最後幾不像。
最後，不同的選擇對應不同的代價；系統架構的難點很多時候不在於如何架構，而在於如何平衡與取捨；蘿蔔白菜，各有所愛。
作者公衆號：
