IM 内容分享(十四)： 分布式三高分析

目录

一、高可用

二、高吞吐

三、高扩展

总结文中关键

---

前面通过几篇文章，非常系统地分析了 IM 的分层架构、每一层的核心职责和关键设计、以及基于分层架构下核心功能逻辑的实现。

分层架构的 IM 系统肯定是分布式部署，作为 “分层架构” 这一篇章的最后，我们再整体分析一下它的三高特性，即：高可用、高吞吐和高扩展。

分析三高之前，先快速回顾一下 IM 系统的分层架构，见下图。

IM 系统的分层架构，由前到后分别是：

• 负责与用户进行交互的终端层

• 负责维护与客户端之间的长连接的入口层

• 负责处理 IM 流程逻辑的业务逻辑层

• 负责维护在线用户状态的路由层

• 负责访问数据库和缓存的数据访问层

• 负责对数据进行持久化的数据存储层

一、高可用

高可用是指系统能持续工作的能力，比如系统可以 7 * 24 不间断地连续工作；在分布式系统中，“副本” 是保证系统可用性的唯一技术手段。

终端层的 “客户端” 发出请求后，首先到达 “入口层”；入口层 Entry 采用多副本方式（集群）部署，任何一个 Entry 节点挂掉之后，客户端的连接和业务请求会由其它 Entry 节点来处理；入口层的流量分配由前面的反向代理 TGW 来实现。

对于业务请求，Entry 会通过 RPC 方式转发到 “业务逻辑层”；同样的道理，业务逻辑层 Logic 也采用多副本方式部署，任何一个 Logic 节点挂掉之后，Entry 会将请求转发到其它的 Logic 节点；从 Entry 到 Logic 是 RPC 调用，业务逻辑层的高可用由 Entry 进程内部的 RPC 连接池实现。

当要查询用户是否在线时，Logic 会访问 “路由层”；路由层 Router 是内存数据库，通过 “主主” 两副本方式部署；任何一个 Router 节点挂掉时，数据不会丢失，Logic 通过 RPC 连接池，访问另外一个 Router 节点，实现高可用。

当要获取联系人数据或消息数据时，Logic 会访问数据访问层；数据访问层  Das 采用多副本方式部署，任何一个 Das 节点挂掉之后，Logic 会访问其它的 Das 节点；和 Entry 访问  Logic类似，从 Logic 到 Das 也是 RPC 调用，数据访问层的高可用由 Logic 进程内部的 RPC 连接池实现。

对数据层 MySQL 数据库和 Redis 缓存来说，通过一主多从的方式进行部署，来保证数据的高可用；严格来讲，一主多从实现了 “高可用读”，而非 “高可用写”，一旦主节点挂掉，则需要人工介入；如何同时保证数据层的高可用读和高可用写，我们在后续文章中进行分析；数据层的高可用由 Das 进程内部的 数据库连接池和缓存连接池实现。

通过上述分析，会发现这样一个规律：每一层的高可用都是需要借助于上一层的代理组件（数据库连接池、RPC连接池、反向代理）来实现的。这样层层向上，到尽头了怎么办呢？比如：反向代理 TGW 是如何实现高可用的。

二、高吞吐

吞吐量是系统在单位时间内完成的请求数量，常见用 QPS、TPS 来描述；高吞吐是互联网系统孜孜不倦的永恒的追求目标。

怎么提高系统的吞吐量呢？一般需要从两个方面着手，一是提高系统的并发量，一是提高系统的处理性能；在一定程度上，“高吞吐” 依赖于 “高并发” 和 “高性能”。

先说 “高性能”，任何一个系统的性能损耗，IO 主要占大头，即对数据的写入和读取；分层架构的 IM 系统，数据主要存储在路由层 Router， 数据层 MySQL 与 Redis；Router 和 Redis 是内存数据库，数据读写过程中只有网络 IO，没有磁盘 IO，关键的性能损耗主要在对 MySQL 的读写上。

对数据库的优化，最常用的三招分别是：添加缓存、分库分表，读写分离，另外加上优化索引的技巧；在千万级日活的分层架构 IM 系统中，主要通过 “分库分表” 和 “索引优化” 提高对数据库的访问效率。

再说 “高并发”，提升并发量包括提升整个集群的并发量和提升单机的并发量。

集群并发量的提升，体现在通过增加节点实现横向的水平扩容，再通过前面部署的 “负载均衡组件” 实现对新增节点的流量分配。

在分层架构 IM 系统中，入口层通过增加 Entry 节点实现更多客户端的并发接入和访问，反向代理 TGW 充当了流量的 “负载均衡” 角色；

业务逻辑层通过增加 Logic 节点实现更多客户端请求的并发处理，其上一层 Entry 进程中的 RPC 连接池充当了流量的 “负载均衡” 角色；

路由层通过增加 Router 节点实现了更多在线用户的状态维护，其上一层 Logic 进程中的 RPC 连接池充当了 “负载均衡” 角色；

数据访问层通过增加 Das 节点实现更多请求的并发处理，其上一层 Logic 进程中的  RPC 连接池充当了 “负载均衡” 角色；

数据层 MySQL 通过分库分表实现了更多数据请求的并发处理，其上一层 Das  进程中的 数据库连接池 充当了 “负载均衡” 角色。

这样一分析，会发现：每一层并发量的提升，也是需要借助于上一层的组件。

单机并发量的提升，体现在对多个网络 IO 通讯句柄的管理上，在底层一般基于 非阻塞IO 或 纯异步方式实现；在很多编程语言中有非常成熟的框架可以直接使用，比如 C 语言的 libevent、Java 语言的 Netty 等。关于高并发的 RPC 框架的设计原理和实现，我们在后面文章中进行分析。

三、高扩展

扩展性包括两个方面，一是系统处理能力的扩展性，一是功能的扩展性。

系统处理能力的扩展性，体现在通过增加节点就可以快速扩容，使系统的作业能力大大增强；上面已经分析过，入口层 Entry、业务逻辑层 Logic、路由层 Router、数据访问层 Das、以及存储层 MySQL，通过增加节点都可以扩展每一层的处理能力。在设计系统的扩展性时，无状态服务扩展性最好，比如业务逻辑层 Logic 和数据访问层 Das；不过有状态的服务也能实现扩展性，比如入口层 Entry。

每一层扩展性的实现，仍然需要借助于上一层的代理组件。

功能的扩展性，体现在基于现有的功能和代码，通过简单的代码扩展和配置，就可以快速实现新的功能；比如，点对点的私信消息功能实现后，就可以基于此快速实现群消息、多媒体消息等；另外，分层架构中每一层职责的划分，业务逻辑层通过 MQ 解耦 Logic 和 Extlogic，数据领域模型的设计等，都体现出了功能的扩展性（前面文章中都有详细分析，这里不再累述）。

对高可用、高吞吐、高扩展进行整体抽象分析，会发现：在分层架构中，每一层的可用性、吞吐量、扩展性都需要借助于上一层的代理组件。

总结文中关键

1. IM 分层架构，从前到后分别是：终端层、入口层、业务逻辑层、路由层、数据访问层和数据层；

2. 高可用是系统能持续工作的能力，“副本” 是保证分布式系统可用性的唯一技术手段；分层架构 IM 系统，每一层的高可用都需要借助于上一层的代理组件，如：反向代理、RPC 连接池、数据库连接池等；

3. 吞吐量是系统在单位时间内完成的请求数量，提高吞吐量需要从两方面着手，一是提高系统的并发量，一是提高系统的处理性能；提升并发量包括提升整个集群的并发量和提升单机的并发量，提升性能主要是对数据存储的优化；

4. 扩展性包括两个方面，一是处理能力的扩展性，一是功能的扩展性；系统处理能力的扩展性，体现在通过增加节点就可以快速扩容，使系统的作业能力大大增强；功能的扩展性，体现在基于现有的功能和代码，通过简单的代码扩展和配置，就可以快速实现新的功能。