本文以一个“多直播间消息互通”的需求为背景，分析如何进行技术方案设计。

需求

在开启某PK玩法的时候，不同直播间的用户发言需要被其他直播间的用户看到。

说明

PK玩法一般是多个直播间进行连麦，主播和主播之间互相可见，所有观众也都能通过所在直播间看到其他的主播。但是，不同直播间的发言消息都仅限于本直播间内显示。

技术方案

方案一

客户端识别业务场景，在某PK的场景下，把PK唯一ID通过发言接口上报给服务端。由服务端通过PK ID查询参与PK的其他直播间，并把发言消息分发到其他直播间。

方案二

客户端识别业务场景，在某PK的场景下，把参与PK的直播间ID通过发言接口上报给服务端。由服务端根据客户端提供的其他需要互通的直播间ID直接多发消息。

方案三

在开启某PK场景时，服务端告知发言服务，此某直播间的发言消息需要互通给其他的直播间ID列表（或者说某些直播间的发言消息互通）。当客户端发言时，服务端检查是否在互通直播间列表中，如果在，则互发消息到其他直播间。

思考

• 当需要互通的不只是发言消息时各方案应该如何升级？
• 当需要互动的场景不只是某PK时，各方案应该如何升级？

方案一有啥问题？

当需要互通的不止是发言消息时，例如增加送礼消息。则客户端还要按照类似步骤升级送礼接口。送礼接口再带上和送礼无关的PK ID告知消息系统要互通消息。
当不只是某PK业务需要互通时，客户端需要发版支持（存在版本覆盖问题）。发言接口需要带上某PK的ID、某某PK的ID、某某某PK的ID、PK4的ID、PK5的ID、业务6的ID、业务7的ID等，接口还得升级到POST方式请求，因为GET方式有长度限制。
客户端的发言功能耦合了某PK业务、某某PK业务、某某某PK业务、PK4业务。。。。
客户端的送礼功能耦合了某PK业务、某某PK业务、某某某PK业务、PK4业务。。。。

开发成本：
客户端针对每个需要互通的功能进行开发
消息服务端针对每个业务进行开发
劳民伤财，业务迭代慢，技术债务高

方案二有啥问题？

和方案一没有啥本质区别，客户端既然知道了当前的PK ID，那自然知道当前都哪些直播间在参与PK。那把直播ID上传上去，减少了服务端的查询，何乐而不为呢？
其实会引入极大的安全风险：通过修改请求的方式，即可在所有直播间广播发言（广告等）
方案一有的其他缺点，一个没少

方案三有啥问题？

当需要互通的增加礼物消息咋办？
在某PK开始的时候，告知消息服务，参与PK的直播间的礼物消息要互通。消息服务在收到礼物消息的时候，就转发到其他房间。

当其他场景也需要消息互通咋办？
在其他场景需要开始消息互通时（一般以连麦开始为标识：主播互相可见了），服务端调用消息服务，指定某些直播间的消息互通。

无耦合，各司其职。

总结

有一个设计原则可以参考：01N

解释：需求一般都是从没有(0)到有(1)，再到多(N)的。设计技术方案的时候，任何从0到1的设计都可以直接尝试一步到N。一般情况下成本不会增加，反而会减少。如果找不到到N的实现方案，那就再想想。可能过些时候，你就悟了。