一、消息通道高可用设计。

1、连的上

• HTTP Tunnel：在部分公司或酒店的网络代理，只允许通过HTTP访问外网。这时就需要用HTTP Tunnel。就是用HTTP协议封装私有的TCP或UDP等不被网关认可的协议。
• 多端口备用
• 多IP：HTTPDNS提供IP列表

2、连的快：

• 跨网延迟：用户和机房在同一个运营商。
• 跑马竞速：链接前遍历HTTPDNS的IP列表，选一个最快的。

3、通道保持稳定：

• 接入层和业务层解耦：业务层功能迭代发布重启，不会影响接入层，用户的长链接也就不会断开。接入层还可以多节点分别接入不同运营商。
• 上下行通道隔离：大型直播中，下行推送量很大，上行很少。因此，短连接上行，避免维护长链接的开销，可以优化为短连接发完不立即断开，上行消息到达上行业务层，进行业务处理和存储，通过消息给到下行业务层，进行分发，下行是一个长链接。
• 多媒体资源会用新通道，避免占用上下行通道。

二、文件上传

1、直接传到文件存储，返回唯一标识，这个表示作为文本消息进行下发。
2、分片上传：客户端分块并标记，服务器收到后按编号组装存储。重试也只重传一个分片。
3、分片大小：太小时TCP链接太多，报文也是浪费。可以粗略分：wift下2M，4G下1M，3G/2G下256K等。
4、断点续传：每个文件的多个块，都有同一个唯一标记，暂停时告诉服务器这个唯一标记的所有资源先别删（不能永久放）。
5、秒传：微博统计一周30%的图片和视频是重复的，所以先计算MD5并存储，如果已经有了，就不需要传文件了。

三、水平扩展

1、接入层：

• 入口 VIP 瓶颈可以通过 DNS 轮询；
• 接入层服务通过中央的“在线状态”资源，来解耦业务层的依赖。

2、业务层：通过“服务化”改造，用“注册发现”解决接入层寻址问题。
3、资源层：数据分片缓解主从库压力。

四、监控

1、系统层监控：Nagios、Zabbix等工具上报CPU内存等信息。
2、应用层监控：QPS、耗时、推送失败等。为数据规模和聚合查询，一般使用时序数据库，如 OpenTSDB、InfluxDB 等。
3、常见方案：

• Statsd + Graphite + Grafana 方案
• ELK（Elasticsearch + Logstash + Kibana）方案

4、trace链路追踪：

• trace：一个完整的链路，携带一个统一的traceId。
• span：一个服务的请求/响应叫做一个span。一个trace由多个span组成。
• annotation：自定义事件和参数，如房间ID用户ID等。
• 成熟系统：Twitter 的 Zipkin、Uber 的 Jaeger、阿里的鹰眼、美团的 Mtrace等。

5、回环探测：主动监控，模拟真实场景调用服务。

五、万人群聊

1、存储：存一份群消息，一份群最新消息id。先获取最新消息id，把群排序展示，再获取每个群的消息。
2、新入群只看新消息：用加群时间做条件。
3、未读数：对高热度群，通过应用层的“合并变更”，来缓解未读资源的写入压力。
4、离线消息：只存消息ID。
5、ACK：参考TCP的Delay ACK机制，在接收方批量ACK。
6、中央全局的在线状态：超大群用户一般分布在多台网关机中，群聊中优化成“网关机本地自治维护”的方式，以解决高并发下推时全局资源的瓶颈。

六、直播间和群聊的在线关系：

• 直播间：房间之间状态隔离。每次用户进入新房间时，需要“加入房间”、“切换房间”等信令告诉网关机当前连接的是哪个房间。网关机才能够在服务端标记这个“用户 -> 房间 -> 连接”的映射关系。消息从业务层给到网关机时，服务端只需要按房间维度下发消息即可。所以在直播互动场景中，消息的扇出是可以推迟到网关机层的。
• 群聊：群和群之间并不是隔离状态。对于任何群的消息，服务端都需要通过一条长连接通道来进行消息的下推。所以在 App 打开建立好长连后，客户端发出的“上线”这个操作，只是会上报一个当前用户信息，不需要、也没有办法再告知自己当前进入了哪个群，因而在服务端网关机也只会建立一个“用户” -> “连接”的映射。因此，在群聊场景中，当某一个群有一条消息发出时，我们需要在业务层将这条消息从群维度扇出成 UID 维度，再下发给网关机。我们尽量不在网关机做业务逻辑，所以在业务层扇出后，再提交到网关机进行处理。

1、消息风暴：1V1时，每10秒发一个消息，那么每秒消息量是0.1。500人群每10秒一个消息，推送消息量是5001/10500=25000。10万人群直播间每10秒一个消息，推送量是1000001/10100000=1000000000=10亿。无论服务器和客户端都无法承载，服务端会限流和选择性丢弃，客户端上限也就是每秒几十条。

2、链路优化：用户发消息后，业务层服务器需要查询接收方的在线状态（链接在哪台服务器上），高并发场景下，这个在线状态服务将会成为瓶颈。 改为：业务层消息入队，接入层的每台网关都订阅这个队列，然后由网关决定给哪个链接推消息。

3、微服务拆分：把打赏、弹幕、点赞、送礼等核心业务 和 直播回放、第三方同步等非核心业务拆分；把容易成为瓶颈的和不容易成为瓶颈的拆分。

4、扩容缩容：指定监控指标，如机器侧的负载、CPU等，和业务侧的同时在线人数、弹幕数、延迟等指标，自动扩容和缩容。

5、负载均衡：扩容后，如果负载均衡策略不变，新链接可能还是均匀的分布给新老机器，导致老机器先到达瓶颈，因为负载均衡器本身也需要扩容，不同的机器可能采用不同了算法，达不到预期。 因此，可以在入口层建立一个调度器，先通过调度器查询可以链接到哪台机器。

1、基础架构：

• 接入层：连接保持、协议解析、Session 维护（用户和链接的关联关系）、消息推送。

  • 接入层和业务层拆分：消息收发的出入口需要高可用；分开后有助于提升业务开发效率；不需要跟着业务变动频繁发布重启；业务层可以屏蔽协议细节。
• 业务层：未读数变更、最近联系人等业务场景。
• 存储层：持久化存储。用于离线消息等。
• 外部接口：如push等。
  2、特性：

• 实时性

  • 发：

    • 提供一个http接口，客户端发消息给IM服务器
    • 客户端和IM服务器维持一个TCP长链接，用私有协议封装（如protobuf）。

  • 收：

    • 长链接和push。需要维护一个可靠的长链接：

      • 客户端和服务器精确感知可用性，断线快速重连。
      • 通过这个长链接发送的消息不丢失。
      • TCP协议：Websocket最常见。XMPP（成熟，可扩展，但XML太大），MQTT（推送场景下被广泛使用，但不是很契合IM，不支持群组和离线消息）

    • 轮询：

      • 短轮询：不断的发HTTP请求
      • 长轮询：短轮询的优化，无消息是服务器不立即返回，而是挂起，有新消息或超时后再返回。但是并没有解决大量无效请求，也没有降低QPS（只是入口层降低了，后端还是轮询判断）。

    • 未读数（角标）：需要维护一个总未读数，每个会话也需要维护一个未读数。

      • 总未读和每个会话未读，是需要分布式锁/原子操作。

• 可靠性：不丢消息、不重复消息。

  • 客户端发给服务器丢失：消息加唯一ID，客户端重试+服务器去重。

  • 其他异常：如服务器转给客户端失败，客户端存本地DB失败等，业内一般实现一个业务层的ACK机制。

    • 服务器下发后把ID放入待确认列表，收到客户端ACK后服务器从列表删除。
    • 服务器超时未收到ACK后，会把消息重传，客户端也要进行去重。
    • 特殊情况：服务器下发后未收到ACK时，服务器宕机，客户端重连后并不知道刚才丢了消息，所以客户端上线后拿最新的ID来服务器取大于这个ID的所有消息即可。

    • TCP有ACK为什么业务还要做ACK：

      • 服务器写入TCP缓冲区后，客户端从TCP缓冲区读取后，都可能会失败。而且连接断开时（比如手机crash或没电关机），双方的缓冲区都会直接销毁（即时里面还有未发/未读的数据）。

• 一致性：顺序保持一致。分布式下，两条消息间肯定会有时间差。

  • 时序基准：全局序号生成器，可以用redis的incr或snowflake算法。但是无法解决同一精度内多个并发消息的排序。
  • 包内整流：多个消息必须要严格顺序时，比如分手+取关，就不能先取关，否则分手发不过去。这时可以以包为单位，packageId+seqId为一条消息，一个包内的消息全部达到后再进行处理，否则丢弃或重试。

• 安全性：

  • 传输安全：HTTPS/HTTPDNS，明文传输时内容TLS加密。
  • 存储安全：端到端加密，出收发双方，服务器也无法破解。
  • 内容安全：敏感词、图片、语音、外链检测、禁言等。
    3、心跳：除了两端自身问题外，运营商的NAT也会剔除空闲链接以节省资源，这种情况下服务器和客户端均无法感知，只能依赖心跳。
• TCP keepalive：操作系统实现，默认关闭，三个可配的参数默认值是心跳周期2小时、失败9次、超时75秒。不带数据的心跳包，省带宽，但无法感知如死锁/阻塞等业务异常，也无法动态调整心跳周期。因此只代表网络可用。如WhatApps空闲期10秒一次。
• 应用层心跳：微博2分半，微信4分半，WhatApps30秒到1分钟。QQ是固定45秒。
  4、推送：
• 通过中央存储（用户和所在网关的映射关系）进行下推。
• 推送给所有网关机，有网关机查找链接是否在本机，自行推送。

一、基本思想和模式

1. 基本思想：拆。按流程、按服务、按功能。按流程拆难理解，固化的内核，移动的数据，如接口层 - 业务层 - 数据层 - 存储层。

2. 扩展方式：拆了以后修改和扩展不影响其他模块。按流程拆有分层架构、按服务拆有微服务架构和SOA、面向功能拆有微内核架构。

二、分层架构和SOA

1. 分层架构：如B/S、C/S、MVC、MVP等。

2. SOA：可以说某企业使用SOA架构了IT系统，而不是某独立系统采用SOA架构。主要对传统企业IT部门。组织架构、员工信息、请假管理等子系统+企业服务总线ESB，组成一个SOA架构的系统。SOA复杂难学，ESB是性能瓶颈。

三、微服务

1、方法：

1. 关键点：small、lightweight、automated。

2. 每三个人一个服务，根据团队规模来持续拆，而不是上来就拆的很细  

3. 拆分方式；按业务拆、按稳定功能和可变功能拆、按可靠性拆（保证核心功能更可靠）、按性能拆（以免血崩）。不是四选一，而是自由组合。

4. 基础服务完善，包括不限于发现注册、容错、路由第一优先，API网关、接口框架第二优先，自动化测试、部署、配置中心第三优先，监控、跟踪、安全第四优先。技术服务不足，微服务就成了焦油坑。根据团队规模和需要，不一定每一项都有。

2、基础服务：

1. 自动化测试、自动化部署、配置中心：是为了将放人力。

2. 接口框架：提供统一http服务和json格式

3. 接口网关：外部系统不应该调多个服务在组装，而是一个接口搞定。另外权限控制、流量控制、传输加密。

4. 注册发现：自理式是每个服务统一注册自己做发现。代理式是注册发现有独立服务，但是独立服务需要关注可靠性。

5. 路由：服务节点的挑选

6. 容错：故障时剔除节点和服务熔断。

7. 监控、跟踪：排查方便。

8. 安全：数据安全、传输安全、接入安全。可继承到配置中心实现。

四、微内核

微内核指插件化架构，分稳定不动的核心模块和跟随业务发展的插件模块。如手淘的atlas。

1. 设计关键点：插件管理：核心模块可用代码数据库配置中心等配置各插件信息和加载时机。插件链接：插件如何连接到核心模块。插件通信：解耦的插件因业务需要必然会彼此调用。

2. OSGI：如eclips。

3. 规则引擎：常见于保险和促销，满多少减多少，打几折各种规则组合。如Drools 

一、架构模版：存储

1. SQL：最终都会分库分表，避免各业务重复造轮子，会出现独立的中间件，如淘宝TDDL、百度BDProxy，开源方案有Mysql的Mysql route和360的Atlas。当业务继续发展，会出现存储平台，如淘宝UMP系统。

2. NoSql：集群规模不断增大，假如2000台机器，利用率要提高10%的话可以节省200台机器。集群之后都会出现存储平台。

3. 小文件：头像照片等小文件，有Hbase等。淘宝有TFS，京东JFS

4. 大文件：Hadoop、Hbase、hive、storm等

二、架构模版：开发层和服务层

1. 开发层：优选成熟的框架、成熟的web服务器、docker容器技术。

2. 服务器技术：配置中心、服务中心。服务中心分为服务名字系统和服务总线系统。

3. 服务名字系统：服务提供者向服务名字系统注册，调用者向名字系统请求我需要X服务，名字系统返回服务提供者ip port

4. 服务总线系统：调用者不直接访问服务提供者。调用者访问总线系统，总线系统访问服务提供者，最后逐层返回。

三、架构模板：网络层

    单机的高可用高性能不涉及网络层。但是站在整个全局看，网络层是很关键。

1. 负载均衡：DNS、HTTP-DNS（自研DNS，解决DNS不实时）、软件七层Nginx、内核四层LVS、硬件四层F5，虽然Nginx便宜，但是F5性能高，当量很大，有上百台Nginx，这时反而一台F5更便宜。

2. CDN

3. 多机房：同城多机房、跨城多机房、跨国多机房

4. 多中心：以多机房为前提，但却是质的飞越，难度复杂度更高。多机房本质是灾备，切换时允许业务中断一定时间，但多中心要求同时对外提供服务，切业务在多中心间切换，关键难点在与数据已执行和数据事务性。

四、架构内功

1. 先救火（机器扩容、Nginx一键切换等），后优化（组件化、可用性、性能问题等），再重构（单点改为多中心，服务化）。