阅读 436

一场关于系统架构的讨论

背景

公司新业务有视频点播与直播需求,经过一番对比分析,最终选择了腾讯云作为视频服务的供应商。

对于如何接入有如下争论点:
1.由中台统一对接视频服务,封装统一对外接口,如后续要切换视频服务供应商,上层无需更改

一致点: 统一封装对外服务
争议点: 要不要做到可无缝切换视频播放供应商而不影响上层业务

2.APP与WEB侧基于腾讯视频上传&播放SDk封装通用组件

一致点: 统一封装SDK
争议点: 封装粒度是强封装还是弱封装。即隐藏内部实现,只暴露自定义参数;还是组件参数透传腾讯SDk相关参数,只简单封装通用业务逻辑

对于上述争议点,会议最终也没讨论出结论来。个人觉得,这两个争论点实际上是一个业务架构问题与技术架构问题,只有把这两个问题理清楚,才能做出清晰的判断。

业务架构

业务架构:实际上就是理清各方如何分工,如何交互,如何设计的问题。

对于该场景的有两种架构方式,一种为中控式、一种为并行式。

中控式

中控式可理解为由一个中枢统一控制,大致结构图如下所示:

核心思路: 由中台统一对接视频服务,抹平各服务商的差异,做到底层视频服务切换对上层无感知

好处:

  1. 视频服务切换,对业务方无影响,无额外开发工作量

难点&弊端:

  1. 视频服务灰度切换问题
  2. 中台需抽象化视频服务为共有服务,制定自有功能与交互逻辑;功能取交集,无法使用特有视频服务独有亮点功能
  3. 中台逻辑复杂化,兼容维护成本高,不易迭代

并行式

并行式从字面意思可理解为并行设计,两条路线不冲突,大致结构图如下所示:

核心思路: 对接不同的视频服务上采用并行方案,互不影响

好处:

  1. 灰度切换方便,影响范围可控制在较小的业务范围
  2. 无需兼容处理,代码逻辑清晰,精简;全部切换后相关代码可整体废弃
  3. 可充分利用视频服务商的全部功能

难点&弊端:

  1. 切换视频供应商时需重新设计与开发,带来巨额工作量

技术架构

技术架构:技术实现细节如何做到高内聚、低耦合、易扩展、良好的版本迭代与向下兼容等,设计思路依赖业务架构。

对于争论点二,有如下两种技术架构思路,一种为集中兼容处理,一种为特定处理。

集中处理-强封装

对于各个视频服务SDK集中处理,统一对外参数,大致结构图如下所示:

核心思路: 隐藏内部实现逻辑,提供统一的对外出口

好处:

  1. 强有力的控制,可做到内部变更对外部无感知

难点&弊端:

  1. 事前需要超前规划,强有力的抽象,需保持克制只提供最小功能集,避免兼容问题
  2. 前期即需考虑封装不同视频服务保证后续能无缝切换问题,实现复杂,工作量大

特定处理-弱封装

对各个视频服务SDK特定处理,不同视频服务对应封装不同的前端组件,大致结构图如下所示:

核心思路: 最小开闭原则,不对视频SDK的做二次封装是,透传参数即可;额外扩展自定义通用业务封装。

好处:

  1. 可获得特定视频服务商全量的功能服务
  2. 组件文档无需单独编写,开发人员参考官方文档即可,鼓励DIY,遇到问题自己排查,而不是推给组件提供者
  3. 无需考虑兼容其他视频服务,代码简洁、清晰,可维护强

弊端:

  1. 切换视频服务需重新设计对应的组件,顶层业务侧也需根据新组件的参数规范做调整

个人想法

1.克制、恰到好处

这条实际上是一个平衡与取舍问题,不能一点不往将来考虑,但也不能一下考虑得太遥远,考虑太远的问题在于前期投入巨大工作量后期可能一点用不上。

2.干净、利落、清晰

个人在做业务架构时,会更多的考虑什么样的架构能够让技术架构更简洁、清晰,便于维护。尽量避免架构设计划定的框,造成技术实现细节繁琐复杂。

3.低成本,高收益

对于这个问题,干一件事总成本是相对固定的,对于上面的问题,我更倾向于前期采用低成本,后续真正要切的时候再投入另外的成本。

4.清晰而坚定的开头、清晰而坚定的收尾

选择了一种架构就应该从上到下保持一致,在一条道上做到最好,避免三心二意,这也要一点,那也要一点,最后几不像。

最后,不同的选择对应不同的代价;系统架构的难点很多时候不在于如何架构,而在于如何平衡与取舍;萝卜白菜,各有所爱。

作者公众号:

关注下面的标签,发现更多相似文章
评论