视频会议和硬件场景比较类似,都是多端之间的协调.
传统互联网的交互都是同步调用. 硬件和视频会议有个特点是通过多个异步调用组成了端对端的控制交互..
指令是写用例. 读用例会导致写扩散. 特别是全部人员都变动的. 大方数1000*1000的消息扩散,对系统是极端影响. 可优化
一种方式是通过状态来告知是否成功.(例如静音是否成功,通过用户上报状态,操作者更新ui. 会导致一个问题, 其他用户查看用例会导致多用户场景下的扩散问题)
另外一种架构是,
功能或者指令,服务端角度看分类. (指令的好处是,接入方会被比较简单,每次新增一个type即可.服务端的代码变动较少,不需要新增method,不需要去组装调用.)
从功能操作的用户维度:
从操作的主体角度:
1. 操作用户: 静音
2. 操作会议:
3. 两者都有: 例如切换主持人: 会议主持人字段变了, 且两个人的角色变了;
从功能是否是操作设备本身属性的角度:
1. 别人对用户操作指令,模仿了用户操作.但是需要对用户谈toast. 例如静音,例如离开会议.
(自己对自己的操作,也可以抽象为,从端上代码的角度看,算指令,不算服务端的指令范畴) 必须要让端上先改掉,然后通过上报给服务端. 不然会导致操控者看到已经静音成功了,但是实际没有静音成功. 要让操控者能够持续修改,模拟非硬件领域的同步反馈.
2. 别人对用户操作,先端上改状态,然后通知端上ui变更. 例如 主持人t人.