7.1返回上麦API响应
10.3.混流失败，踢出用户
8.3即构上麦
9.1.同步结果API响应
5.麦位信息API响应
一:主播上麦流程图
12.提示主播开播结果
5.1.更新麦位UI
1.进房
7.主播身份请求上麦API
3.第10 如果服务器收到请求参数是：SDK操作失败，服务端重置麦位状态，立即响应（10.5）给用户上麦失败。10.5 中用户只处理上麦失败的响应。
APP
10.2.混流api响应结果
2.请求进房API
用户
10.1 - 11注意：1.测试zego响应耗时。2.可以考虑搞异步队列服务处理zego请求，客户端通过长连接接受处理结果3.如果http请求耗时严重，统一走长连接全局通知。10.3：只有混流失败的时候才走。10.4：zego踢人API请求失败，需要有报警机制，特别是踢房间主播的时候。这个出问题需要开发及时响应。（如果能做到根据请求结果，视情况，给被踢的人下发长链接踢用户离房，90s内不能进房这样最好。）10.5：如果即构服务器响应速度很快，直接通过10.5响应结果。如果响应速度过慢，10.5只返回API请求成功失败即可，客户端不做处理。10.6：同上如果zego服务器响应过长考虑使用异步队列处理请求，结果返回后统一走10.6更新结果。
4.1建立长连接
3.进房API响应
8.2.2创建房间成功
2.10.2如果是混流成功，更新麦位状态为以上麦，直接执行10.5/10.6
10.API同步SDK结果(成功/失败)到服务器
6.1非房间主持直接提示
8.2.1SDK请求zego
8.API响应成功
11.上麦成功更新UI
7.2，AP返回失败直提示用户
服务器麦位状态1.第7的请求到达服务器后，标记变更主持位状态，上麦中，收不到后续的结果请求，需要在麦位监控服务中变更房间麦位的状态。
10.5.API响应上麦结果
6.主持点击上麦
8.2.1创建失败
10.4踢人API响应
8.2创建/加入房间
8.3.1同步麦位状态给zego
9.API同步SDK结果
4.2请求麦位信息API
10.5 及10.6两步待响应测试后再详细定
10.6socket全员通知结果给房内用户
8.1初始化SDK
8.4.上麦结果
zego_server
10.1.SDK上麦成功，api请求混流转推
Server
