华夏视频服务
# 遇到的问题
空中柜面项目上线生产之后，陆续出现其他业务想要接入视频服务的情况，然而在我们为不同需求定制业务逻辑的时候发现以下问题：
- 大量兼容性代码和视频各模块的生产监控机制充斥在主要的业务逻辑中，导致想要将其中的业务逻辑单独拎出来重写十分的困难
- 空中柜面项目集合了客服系统的三条业务线(机器人、人工客服、视频客服)，由于当时经验不足且考虑不周，三条业务线的耦合性很高，拆分时即使是单独保留视频服务，依旧存在很多另外两条业务线的残留逻辑不敢删
这些问题在将视频服务接入视频保全项目的时候暴露出来，光是无关的业务逻辑的删减就花了将近一周时间，可以想象后续接入其他业务时这些问题将依旧存在，严重影响开发进度。
# 共通的业务
在帮助其他业务接入视频的过程中，我们发现以下内容是无论哪种业务场景都真正关心的：
排队：
- 开始排队
- 取消排队
- 排队人数减少 | listener
- 排队成功 | listener
- 排队失败 | listener
视频：
- 连接视频 (包括第一次连接和重连)
- 挂断视频 (完全结束)
- 获取视频记录 (视频次数、分别时长、总时长)
- 视频异常断开 (远程流) | listener
其他的可注册的监听：
- 接收C2C消息 (包括任何来源：机器人、在线、视频 。。。) | listener
- 视频过程中的双击事件 | listener
- 。。。
另外需要暴露的方法：
- 获取用户信息
- 坐席信息的注册及获取，相当于作为全局的状态保存着，可后续增量
- 发送C2C消息 (包括任何来源：机器人、在线、视频 。。。，通过type区别发送对象)
- 。。。
这些说白了依旧属于业务逻辑，但是无论是哪个项目接入，这些都是统一的视频的逻辑，是作为我们视频能力的体现。我们可以将它们整体包装出来单独做成视频的公共服务。
在视频的整个流程中还包括其他的子逻辑，比如排队时候的心跳机制、排队和视频接通的超时机制、视频质量的检测和上报等等。这些都是视频流程中的很重要的机制，但是对于不同的业务线(比如视频保全)来说他们并不关心，他们的业务逻辑只关心我啥时候能排队成功，啥时候能看到视频坐席。因此如果将这些和各业务逻辑写在一起，无论是今后的拆分还是维护工作，都将存在巨大的人力成本和学习成本。
# 状态切换
另外，考虑到之后接入其他不同的业务线的拓展性，以及将空中柜面的三条业务线可能都要迁移至小程序，在抽象公共服务的时候个人觉得需要保留现有的三条业务线及其转换接口，这个全局的状态切换在空中柜面就没做好。
我现在的想法是：
- 通过Redis拿到的不同业务的配置信息在前端维护一个当前业务的状态机机制，在三个客服业务(机器人、在线、视频)以及客服列表、排队等几个子状态之间形成闭环。从配置信息生成出状态机就需要约定数据结构及算法了。
- 三个客服业务中某些统一的接口(发消息接口、排队接口)用策略模式做成三个控制器，状态机的切换控制不同控制器的切换，这样就不用写一堆
if else的逻辑。
当然这些都是我现在自己YY的想法，可能存在对场景和设计模式的理解误区，也可能根本不需要设计的这么复杂，需要大家讨论协商。
现在有资源A、B、C，它们的依赖关系是：B依赖于A，C依赖于B，而每次请求了一份资源之后都需要缓存下来避免下次需要用到的时候再去请求，现在的需求是我想要在项目中的任何地方只需要调用获取某个资源的方法就可以获取到，不关注这份资源的依赖是否已经请求过，若没有请求过则先去获取依赖资源，若请求过则直接拿缓存 我可以做个工具，用于维护一份资源列表以及相关依赖，初始化之后对应关联起资源和对应的依赖，分别导出获取这些资源的方法。使用的时候自动去检索这份资源相关的依赖，全部获取到之后再去拿这份资源返回 现在有俩疑问：
- 这样类似的工具现在是否存在，或者说在这种场景下需不需要封装这样的工具
- 如果A、B、C这三份资源的依赖性这么强，是不是说明资源C这个从设计上就存在问题
等等。。我好像在写webpack。。。。。。。。。。。。。。。。。。