群发通知数据结构设计_聊聊影响架构设计的一些因素

一周一保活

今天来水一期最近架构设计中遇到的选型问题。

需求不难，类似的需求可能很多人都遇到过，就是在一个直播的界面上显示在线的人数以及人员的详细信息。

可用的一些基础设施有Redis，Kafka和自研的IM系统。

技术上讲，类似的场景我们可以使用“推”或者“拉”的方式。

推的方式实时性比较高，但实现相对复杂；拉的方式实现简单，但实时性不高，频繁的拉取还有可能影响性能。

经过分析，我们有下面的三种方案，各有优缺点

1. 利用现有的IM组件来实现推的功能

IM组件负责维护客户端的状态，客户端登录，登出以及掉线IM都能感知得到，然后通过MQ发消息通知Live Service，Live Service内部对消息进行过滤、处理后调用IM Service的接口群发消息，通知会议的其他客户端某用户上线或掉线了。

方案优点：

• 客户端收到通知的实时性高
• 节省带宽(相对轮询来说)
• IM是数据的拥有方，如果需要访问其他数据，通过IM能简单实现

方案缺点：

• 实现相对复杂
• IM要做改造
• 问题排查困难(组织内缺乏日志收集，性能指标跟踪手段)
• 跨部门开发协助，容易出现利益不一致

2. 轮询方式，使用Redis记录用户状态，客户端定时轮询 

这种方案绕过IM的改造，直接使用Redis来维护用户的状态，客户端上下线时，需要主动通知LiveServer，LiveServer去Redis更新用户状态。客户端需要每间隔一段时间主动轮询客户端，取得当前直播的用户数据。

方案优点:

• 实现相对简单
• 不涉及对现有系统的改造
• 不涉及其他系统交互

方案缺点：

• 实时性低
• 客户端闪退，掉线后台无法感知
• 自己维护直播和用户状态
• 参加会议人数多时，瞬间大量请求可能对LiveServer接口产生比较大的压力(需要打散客户端请求到不同的时间段)

3. WebSocket实现推功能 

WebSocket是第二种方案的升级版本，也是我个人比较推荐的方式 它拥有方案二的优点，并且克服了时效性以及对Live Server瞬间产生比较大负债的问题，但需要好好处理掉线，重连的问题。

接下来的问题是应该选哪个方案，每个方案都有它自己的优缺点，应该根据什么准则去选选择呢？

这里有一个方法和套路，就是根据质量属性做优先级排序，再按照排序进行选择。

每个组织、公司对不同质量属性的优先级排序不一样。

例如互联网企业、或者新的团队、组织，可能性能和成本是他们优先考虑属性。

拿我们自己做例子，目前性能并不是首要考虑的因素，一定时间内人数的不一致是能够接受的(一致性属性)；另外由于组织的运维缺乏有效的调用链跟踪、日志采集的手段，出问题的时候只能跑机房查日志，问题排查效率十分低效，复杂的方案并不适合(运维属性)；并且也考虑组织内部跨部门的协作，涉及的系统越少越好，还有开发人员技术水平问题(沟通、研发成本属性)。

如果要给质量属性排序，会是下面的一个顺序：

1. 沟通、研发成本
2. 运维属性
3. 性能属性

基于上面的考虑，经过内部讨论，我们采取了方案二。方案三由于要用到WebSocket，部分团队成员怕维护链接比较麻烦就否决了(虽然我觉得这个方案更合适哈)。

至此一次小小的架构设计及选型就结束了。

引申的一些思考：

架构师需要有成本的意识 

做架构就是一个取舍的过程，任何的决策都蕴含成本在里面，我们需要在有限的成本里选择最合适的方案。

先追求合格，再追求优秀 

受生活的影响，我们做事都有一个美好的愿望，希望一步到位。但在很多时候，或者IT领域里，这想法不符合实际，没有一个系统是一出来就是优秀的，能做到合格已经很好了，更何况很多系统做出来是不怎么可用的。

康威定律 

“设计系统的架构受制于产生这些设计的组织的沟通结构”。由于是跨部门间的合作，里面涉及沟通以及不同的利益诉求，我们没有采用采用第一种方案，也就是反映了组织的沟通结构，影响到我们的架构设计。

监控、调用链跟踪、日志采集理应成为一个IT组织的基础能力 

这点是曾经在“非常重要人物”公司基架部(很荣幸也很感谢能该公司工作过)后，明白到各种监控的重要性。只有这些设施建设好了，才能有一个坚实的基础去优化上层应用。毕竟没有这些基础，就等于闭着眼过马路，路上有哪些危险你看不见，有哪些障碍你不知道，自己的速度(能力)到多少，会不会撞上车子你心里也没谱。