一场关于系统架构的讨论
公司新业务有视频点播与直播需求，经过一番对比分析，最终选择了腾讯云作为视频服务的供应商。
对于如何接入有如下争论点：
1.由中台统一对接视频服务，封装统一对外接口，如后续要切换视频服务供应商，上层无需更改
一致点： 统一封装对外服务
争议点： 要不要做到可无缝切换视频播放供应商而不影响上层业务
2.APP与WEB侧基于腾讯视频上传&播放SDk封装通用组件
一致点： 统一封装SDK
争议点： 封装粒度是强封装还是弱封装。即隐藏内部实现，只暴露自定义参数；还是组件参数透传腾讯SDk相关参数，只简单封装通用业务逻辑
对于上述争议点，会议最终也没讨论出结论来。个人觉得，这两个争论点实际上是一个业务架构问题与技术架构问题，只有把这两个问题理清楚，才能做出清晰的判断。
业务架构
业务架构：实际上就是理清各方如何分工，如何交互，如何设计的问题。
对于该场景的有两种架构方式，一种为中控式、一种为并行式。
中控式
中控式可理解为由一个中枢统一控制，大致结构图如下所示：
核心思路： 由中台统一对接视频服务，抹平各服务商的差异，做到底层视频服务切换对上层无感知
好处：
- 视频服务切换，对业务方无影响，无额外开发工作量
难点&弊端：
- 视频服务灰度切换问题
- 中台需抽象化视频服务为共有服务，制定自有功能与交互逻辑；功能取交集，无法使用特有视频服务独有亮点功能
- 中台逻辑复杂化，兼容维护成本高，不易迭代
并行式
并行式从字面意思可理解为并行设计，两条路线不冲突，大致结构图如下所示：
核心思路： 对接不同的视频服务上采用并行方案，互不影响
好处：
- 灰度切换方便，影响范围可控制在较小的业务范围
- 无需兼容处理，代码逻辑清晰，精简；全部切换后相关代码可整体废弃
- 可充分利用视频服务商的全部功能
难点&弊端：
- 切换视频供应商时需重新设计与开发，带来巨额工作量
技术架构
技术架构：技术实现细节如何做到高内聚、低耦合、易扩展、良好的版本迭代与向下兼容等，设计思路依赖业务架构。
对于争论点二，有如下两种技术架构思路，一种为集中兼容处理，一种为特定处理。
集中处理-强封装
对于各个视频服务SDK集中处理，统一对外参数，大致结构图如下所示：
核心思路： 隐藏内部实现逻辑，提供统一的对外出口
好处：
- 强有力的控制，可做到内部变更对外部无感知
难点&弊端：
- 事前需要超前规划，强有力的抽象，需保持克制只提供最小功能集，避免兼容问题
- 前期即需考虑封装不同视频服务保证后续能无缝问题，实现复杂，工作量大
特定处理-弱封装
对各个视频服务SDK特定处理，不同视频服务对应封装不同的前端组件，大致结构图如下所示：
核心思路： 最小开闭原则，不对视频SDK的做二次封装是，透传参数即可；额外扩展自定义通用业务封装。
好处：
- 可获得特定视频服务商全量的功能服务
- 组件文档无需单独编写，开发人员参考官方文档即可，鼓励DIY，遇到问题自己排查，而不是推给组件提供者
- 无需考虑兼容其他视频服务，代码简洁、清晰，可维护强
弊端：
- 切换视频服务需重新设计对应的组件，顶层业务侧也需根据新组件的参数规范做调整
个人想法
1.克制、恰到好处
这条实际上是一个平衡与取舍问题，不能一点不往将来考虑，但也不能一下考虑得太遥远，考虑太远的问题在于前期投入巨大工作量后期可能一点用不上。
2.干净、利落、清晰
个人在做业务架构时，会更多的考虑什么样的架构能够让技术架构更简洁、清晰，便于维护。尽量避免架构设计划定的框，造成技术实现细节繁琐复杂。
3.低成本，高收益
对于这个问题，干一件事总成本是相对固定的，对于上面的问题，我更倾向于前期采用低成本，后续真正要切的时候再投入另外的成本。
4.清晰而坚定的开头、清晰而坚定的收尾
选择了一种架构就应该从上到下保持一致，在一条道上做到最好，避免三心二意，这也要一点，那也要一点，最后几不像。
最后，不同的选择对应不同的代价；系统架构的难点很多时候不在于如何架构，而在于如何平衡与取舍；萝卜白菜，各有所爱。
作者公众号：
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
