一、聊天室架构应满足哪些条件
1.高可用：任何一个节点故障都不应该引起服务不可用；
2.易扩展：具有水平扩展的特性，对不同量级的在线用户数都有应变的能力；
3.高并发低延迟：能支持大量的用户同时收发消息，消息从发出到送达所有在线端的延时在毫秒级；
4.客户端兼容性：新型的应用都是能同时跨多种设备实现消息互通的，比如网页端，手机端和桌面端，甚至智能电视等。
二、设计架构
1.客户端层
处理各种设备的兼容问题，包括对ios，Android，Windows，Web等各种开发平台的语言适配；消息通道的管理维护，包括移动设备上的弱网络管理，断线重连等；保证数据安全，所有上行下行的数据包都需要加解密处理，规避数据泄露或中间人攻击等各种安全风险。
2.网关接入层
管理大量客户端连接，单个节点可以维护的客户端数量在数十万量级；处理不同类型客户端的协议兼容，由于客户端实现技术的多样性，导致客户端与网关之间底层的数据通信协议存在差异，需要由不同的接入网关做协议转换；处理数据安全逻辑；跨网络的高可用逻辑，网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?)；广播消息的高效下行分发，将收到的广播消息分发到所有连接在本节点上的客户端。
3.路由层
作为业务层接入的中转，同时承担负载均衡和高可用的作用，单个业务节点处理能力达到瓶颈时更方便的扩容，路由层使业务层扩容对前置网关层完全透明；当一个网络的业务集群出现网络故障时，可以切换到备用网络，保证服务可用性。
4.业务层
处理聊天室内的业务消息，一个集群内有众多节点，节点角色相互对等，任何一个节点的故障会使整个集群的处理能力下降，但不会引起服务的中断，因为其他节点可以继续接管业务数据包的处理；业务集群同样有多个网络环境的热备，以应对可能出现的区域性网络故障。
三、难点在哪里
1.客户端多样性
目前的应用都存在跨平台的需求，iOS、安卓和PC端，网页端，甚至IOT物联网设备，能连多少是多少，多多益善；但是不同开发平台之间的技术差异性极大，不是所有公司都有这么全的全栈程序猿的；如果团队开发的话单就客户端开发人员就不是几个人可以完成的。
2.数据安全的保证
当前的网络安全形势异常复杂，开发应用时如果不在通信安全上花心思，那你的用户就是在互联网上裸奔；开发者需要针对不同的平台，不同的通信技术实现可靠的安全方案，避免用户数据在传输过程中泄露，避免中间人攻击等安全风险。
3.跨机房网络级的高可用方案
当机房网络出现故障时把责任推给市政施工队或者“网络抽风”已经不流行了，用户需要的是故障无感知。
4.所有环节的单点故障排除
任何硬件和软件都存在故障的可能，我们无法避免应用罢工，那就需要随时准备替补上场。
5.能应对任何用户量级的需求
架构级做到水平扩展的能力，当用户量增长时随时可以通过堆服务器来解决，而不是将架构推倒重来。
四、这么难，怎么做
技术发展到现在已经不流行重复造轮子了，因为轮子的结构越来越复杂，功能性和非功能性的指标要求越来越高；而我们的用户却不会再等我们了。当我们还在画轮子的图纸的时候，竞争对手可能已经把车子都造好，在路上跑了。虽然我们不是非得自己造轮子，但是了解如何完成一个完美的轮子的制作过程和质量标准却是非常有必要的，这也是我前面和你介绍了这么多的原因。
就像近几年大数据技术非常流行，如果你对这个领域有所了解你就会发现几乎所有公司都在使用现有的平台，比如Hadoop；或者直接使用，或者在上面做二次改造，原因无非就是上面说的几点。现在你遇到的也是同样的问题，聊天室这种功能在最近两年又火了起来，主要还是视频直播业务的大规模扩张；所以能借用目前已有的平台或工具是最快捷的路径，应用需要关注的是怎么以最快的速度抓住用户。
