前言：
最近在接入多个RTC服务厂商，目前也了解了常用的一些厂商，如：腾讯、网易、声网、即构，阿里等等。在总体调用上类似，但某些SDK的细节处理上较为奇葩。
如果对于RTC服务有很高的要求或者需要做备选方案，那么接入多家RTC厂商就很有必要。值得一提的是，在接入多个SDK厂商之后，可以依据流量的大小，策略的分配不同厂商的RTC服务，从而降低费用。并且，当其中一家厂商的延迟较高时，可以通过切换不同的厂商RTC来提供服务，从而达到高稳定性。
为什么要做策略切换
- 提高稳定性：由于故障性原因导致某些厂商RTC服务异常，或者由于网络阻塞延迟卡顿黑屏等等影响用户体验；服务端在通过对一些关键性指标分析后，从而策略的选择一种更适合当前的RTC厂商服务；
- 降低资费：随着用户量的增长，从而带来了RTC服务的流量大大增长，那么某些厂商的资费也会大大增加，如果通过合理的分配流量到不同的厂商服务，那么即可通过较低的成本使用更为可靠的服务；（并且不会依赖某一家厂商，这点很重要哦）
策略切换
说到策略切换，那么如何去做呢？
客户端：
首先，我们需要确定自己的业务层有哪些需求。确定了业务层需求，接着就是去定义我们需要用到的RTC基础模型，基础定义，基础方法等。我们称之为 RTCManagerDef。
基础定义中包括使用场景(Scene)，角色(Role)，网络质量(NetworkQuality)。
基础模型中包括不同厂商所需要的传参。
基础方法是对RTC服务商的抽象方法，由业务层直接调用，具体实现是基于RTC服务商。
其次，我们就可以用到熟悉的设计模式去设计整个动态切换的层级和功能类。这里是我对自己业务所设计的策略切换的RTC管理类。
结构：
- RTCManager（管理类）：为业务层提供调用的方法；合理封装基础调用方法是这个管理类的重点；
- RTCProtocal（RTC协议） ：为业务层提供的RTC事件回调；
- Context （关联类）：解决内部调用不同RTC厂商服务，切换厂商服务策略以及关联内部实现和外部调用是这个类的作用；
- EngineStrategy （引擎策略类）：引擎策略的基础类，规范化众多RTC厂商服务的调用方法，统一内部方法；
-
ConcreteEngineStrategy （具体策略类）：继承于引擎策略类，实现引擎策略类的方法，以及实现引擎内部事件回调，并回调
RTCProtocal的事件；
整体架构基于设计模式中的策略、工厂、适配器等，这种架构主要是考虑到后期的拓展更多的厂商。 不能说是最好的方案，但是目前比较适合当前项目，对后面拓展比较友好，接入新的厂商不会影响现有的上层逻辑；
这种设计层级上可能会比较多，但是优点也是很明显的，随时可以切换不同的服务。
架构说完，就谈谈具体接入的问题吧；
因为想要做到可以策略切换不同的Service，所以需要将众多的Service providers适配自己的规则，这无疑是一件很难得事情，因为不同的RTC厂商内部的实现都各不相同，所以需要足够了解他们的调用顺序以及方法实现，状态回调等等。这需要和他们的开发者深度沟通之后才可以了解到。策略切换的重点就是使用自己制定的规范适配众多RTC厂商服务；
