一、背景
随着建立通道的房间和人数增加到一定规模，给我们的架构之扩展性提出了考验，本文主要是讲述通道服务的水平扩展性，垂直扩展不在本文的范围内。
前文也有讲述，我们的现状是缺乏通道的接入层，连接是随机路由到后端节点。换句话说，同一个房间的用户，会分散到多个后端节点。这样的话，A用户想要发送消息给同房间的B用户，目前是使用Mq广播消息，让所有的后端节点都消费该消费。
缺点是：很多消息广播出去，导致消息的重复处理，每个节点都要消费同等数量的消息。最重要的是，这不利于服务的水平扩展。
二、目标
- 1、弹性扩展
- 2、通道的连接路由到后端节点，有效期默认为当天，允许隔天重新创建通道
- 3、扩展的同时不能随意更换房间
- 4、扩展的同时不能断开已连上的通道
三、方案一--kong plugin改写upstream
自定义kong插件，调用方额外传入header字段，计算hash值，选择对应的upsteam。
既然是upstream，就意味着后端的pod节点可以是多个，对比方案二的高可用相对更好。
主要内容是开发自定义的kong插件，读取websocket header头部字段，求模计算，选择对应的upstream。
好处是：可以记录下各个upstream已连接上的课堂列表，当有新的课堂来临，可以选择路由到连接空闲的upstream。
四、方案二--kong upsteam 的 hash on header
要求调用方的头部，新增上传计算路由的字段。比如学校ID，用户ID，课堂ID等等。
不用额外的开发工作，相对比方案一，它的路由机制没有那么灵活，只保证同一个课堂下的连接请求到同一个节点。而无法对节点的负载进行适当的均摊，比如节点1已连接了2个课堂，节点2还未有1个课堂，来临的第3个课堂还有可能连接到第1个节点。
五、方案三--命名服务之zookeeper
单元化的需要，我们根据不同的学校ID可配置不同的通道地址。本次需求可以进一步细化到课堂ID，在每次进入课堂前，调用命名服务，取得配置好的通道地址。
客户端增加一次获取通道地址的请求，可以在创建课堂的时候，就确定其应该连接的通道地址。
但是业务服务要获取通道地址，改动的代码就比较多了。最主要的是业务服务不可能每次都获取，要求把<课堂ID，通道地址>存储到Jvm内存。
pod在创建的时候，注册到zk，随着节点销毁而从zk下线。这使得通道集群保持最新。
六、方案四--命名服务之gossip
上面额外引入了zookeeper这一中间件，你可以使用分布式协议gossip，使得通道集群的信息在各个节点之间共享。
主要步骤如下：
- 1、客户端向通道服务发起http请求，头部携带课堂ID。
- 2、服务端任意一个节点，根据课堂ID的hash算法，得出它应该连接的通道地址，返回给客户端。
- 3、客户端根据上一步得到的通道地址，建立ws连接。
- 4、业务服务集群的每个jvm节点，在启动的时候，任意连上一个通道地址。由该链路，实时推送课堂和通道的映射关系给业务服务。
- 5、业务服务得到N个连接地址，除自身已连上的通道地址外， 以次和剩下的通道建立连接。
改动点：
- 1、客户端在建立连接前，多一次获取通道地址的请求，可以是ws协议，也可以是http协议。
- 2、业务服务如果有2个节点，通道服务有4个节点，那么每个节点会建立4个通道连接，总共会有4 * 2 = 8 个连接。
上面获取通道地址是通过http协议，你也可以使用ws协议。流程如下：
这里，把kong网关变成了"SLB总入口"，它会可能二次建立连接，好处是通道服务不用额外提供http接口了。
七、问题场景
1、场景一--ws连接数不够
- 解决方法：扩展后端服务的节点数，也即扩容pod。
2、场景二--N个课堂的使用隔离性
- 让通道服务变成有状态的，rabbitmq广播消息通过vhost隔离多个后端集群。
- 不同的课堂路由到不同的后端集群，甚至可以针对一个大课堂对应一个后端节点。
3、场景三--保证通道列表的变更实时刷新
- 业务服务和通道服务保持长连接，由通道实时推送给业务服务。
4、场景四--保证路由关系的变更实时刷新
- 通道服务，在客户端和通道服务建立连接前，我们根据客户端上报上来的头部字段，计算出应该路由到哪个通道。
- 第二步，找到业务服务和自己连接上的通道，实时推送给业务服务。由后者进行刷新内存，供选择通道。
八、总结
数据存储
- 课堂对应的通道地址的映射关系（每次都会根据课堂ID，计算出它应该对应哪个通道）
- 通道列表的刷新（涉及到通道服务的弹性扩缩容）
消息发送的两种方式
- 1、客户端和通道服务建立连接
- 2、客户端调用业务服务的接口，由业务服务告知通道服务。（这里的业务服务充当中转的角色）
