139 邮箱多中心架构技术研究

［黎伟健 李小青 王钢 梁春章 胡芯菲 吴达玳］

1 引言

139 邮箱在2021 年前一直采用一点集中部署方式，即所有用户节点与一个存储节点支撑业务运行，用户节点与存储节点均设置在广州。

单中心集中部署方式如下缺陷：

（1）单点故障：当服务器出现故障或停机时，整个系统将不可用，导致用户访问中断，可能会带来严重的损失。

（2）服务器维护困难：对于集中的服务器，需要花费更多的时间和资源进行维护、升级和扩容，不利于系统的可维护性和扩展性。

（3）用户访问速度慢：由于服务器只设置在一处，地理位置分布广泛的用户可能需要经过多次跳转才能访问服务器，导致访问速度变慢。

（4）安全风险高：一个中心服务器容易成为黑客攻击的目标，一旦攻陷，将使整个系统数据和用户信息面临严重的安全风险。

2 原邮箱架构及分析

139 邮箱2021 年前的架构见图1 所示。

图1 单中心集中部署架构

下面说明用户上传文件的流程：[1]

（1）应用层：

由用户可以使用的邮箱系统的人机界面WebMail、WAPMail、移动终端应用、邮箱增值功能以及管理员使用的139 邮箱支撑系统、运营系统、支撑上层业务的后台应用服务组成。

（2）基础层：

主要包括基础邮箱系统、分布式文件存储系统、用户数据存储仓库。主要实现邮件数据的存储、收发、用户登录状态的管理，按标准的SMTP、POP3、IMAP 邮件协议提供服务，通过基础平台API 实现与应用层的对接，支撑应用层业务功能的实现和业务发展。

（3）接口层：

邮箱系统通过接口层连接到BOSS 系统、短信网关、统一认证等。

从以上流程可以看出，因用户节点与存储节点都只有一个，任何一个节点出现故障，都将导致用户无法正常访问邮箱及个模业务模块功能业务。

3 邮件系统多中心部署架构

3.1 邮件系统多中心架构[2,3]

139 邮箱现架构如图2 所示。

图2 多中心部署架构

（1）用户入口层

用户入口层，根据部署需要在多地部署多个接入中心，每个同中心为用户提供无差别的HTTP/SMTP/POP/IMAP协议接入服务。为提高访问效率，通过智能DNS 配置实现用户就近访问。当入口层的某一节点故障时把该节点入口IP 从DNS[7]列表移除，把用户切换到其他正常的节点访问邮箱服务。

（2）访问控制层

该层部署两个及以上节点，每个节点保存完全一致的副本数据，入口层访问任一节点，都将获得相同的服务。平时用户接入层根据就近、系统负载等策略接入访问控制层。控制层收到请求后，会根据策略、系统负载等把用户请求分发到数据中心。

接入层会实时同步当前每个访问控制中心的状态，当某个中心出现异常时，接入层会根据系统预定的策略（就近、访问控制中心的负载），把请求分流到其他的控制中心，保证某个中心异常不影响用户正常访问邮件系统。

（3）基础数据层

按存储资源物理位置多地灵活部署、扩容。系统部署时，为每个数据中心分配全局唯一的中心ID。当邮件入信保存时，访问控制层根据权重配置选择存储邮件数据节点[4]。存储节点根据内置规则生成全局唯一的邮件ID,该ID 包含存储节点ID，用户下载邮件时根据邮件信息的节点ID 信息，可正确路由到数据中心下载邮件；

139 邮箱系统采用分层的架构设计，实现邮箱系统双活。

3.2 数据访问流程

用户元数据/增值服务访问流程说明，如图3 所示。

图3 数据访问流程

（1）应用入口在本地可设置、缓存访问控制层所有节点的服务状态；

（2）应用入口根据就近访问原则或系统设置的其他规则，选择访问的控制节点副本；

（3）一个控制节点对数据做的修改需要同步到其他所有控制节点副本。

3.3 用户数据同步

访问控制层的每个节点需要保证数据一致性，系统设计统一的数据同步网关，每个业务模块发生数据变更操作，只需要把binlog 日志上传到网关，由同步网关完成多中心间数据同步操作，如图4 所示。

图4 用户数据同步

流程说明，如图5 所示。

图5 数据同步时序

（1）业务处理模块，增加/删除/修改数据成功后，数据同步组件把需要同步的数据提交给数据同步网关；

（2）同步网关收到同步数据后先持久化保存到磁盘，同步成功后再删除数据；

（3）网关按优先级进行排序，优先级高优先执行同步；

（4）根据目标网关收到同步数据后，根据数据类型分发给相应的业务处理模块，完成数据同步操作。

3.4 访问控制策略

3.4.1 入口层访问控制策略：

根据每个分省（城市）与入口节点的距离及网络互通情况，在DNS 服务器配置基于IP 来源（地区）的智能DNS 策略，不同地区的来源IP 返回不同的入口IP 列表，实现用户就近访问。

当入口层的某一节点故障时把该节点入口IP 从DNS列表移除，把用户切换到其他正常的节点访问邮箱服务。不因为节点故障影响用户访问邮箱服务。

3.4.2 访问控制层访问控制策略：

（1）就近选择：如果部署结构中，在同一机房有访问控制层中心，则入口层优先选择本机房的访问控制层；

（2）根据访问控制层的部署规模，配置每个中心的访问权重，每次访问根据权重计算选择合适的访问控制节点。

3.4.3 数据层访问控制策略：

（1）就近选择：如果部署结构中，在同一机房有数据制层中心，则用户入信保存邮件时优先选择本机房的访问控制层。

（2）根据数据层的部署规模，配置每个中心的访问权重，每次存信根据权重计算选择合适的数据层节点。

3.5 故障切换[5]

（1）接入层：

当某个接入节点故障不可用时，将该节点的入口IP从DNS 列表移除，并调整智能DNS 策略[6]，把访问分流到其他节点。

（2）控制层：

当接入层某个节点不可用时，需要运维介入手动调整该节点的服务状态，并调整接入层的访问策略。用户入口层同步接收到信息后，根据策略选择其他控制节点提供服务。

（3）数据层：

（1）当某个数据中心出现故障[7]，运维手动设置该节点暂停使用，入信保存邮件时，控制访问中心会根据状态跳过故障节点，选择正常的数据中心存储邮件；

（2）当某个节点入信保存邮件失败时，访问控制层可根据规则选择下一个存储中心保存邮件，直到成功为止；

（3）存储中心内部实现多副本保存冗余机制，保证一份数据损坏后还可正常访问，并进行数据修复。

3.6 多中心部署前后数据对比

多中心部署是指将应用系统部署在不同的地理区域的数据中心，并构建多个独立的副本，让用户可以就近地访问最合适的数据中心。这种部署方式能够提高应用系统的可用性和可靠性，减少延迟时间，提升用户体验。

对比结果主要包括以下几个方面：

（1）延迟时间：多中心部署前后，用户请求的响应时间可能会有所改变。在单一数据中心部署时，用户请求需要到达数据中心后才能得到响应；而在多中心部署时，用户可以就近访问数据中心，使得响应时间更快。部署前后对比结果如图6 所示。

图6 多中心部署前后对比数据

（2）可用性：多中心部署能够提高应用系统的容错能力和可用性。如果某个数据中心出现故障，其他数据中心可以接管处理该数据中心的请求，从而降低系统宕机风险。部署多中心后CPU 使用情况如图7 所示，部署多种后平均事务相应时间如图8 所示。

图7 系统CPU、内存使用情况

图8 平均事务相应时间

4 结束语

如上所述，采用多中心双活架构，对邮件系统的可用性和稳定性有很大的提升。分层架构的设计和应用层的故障转移和自动容错技术，使得系统更加健壮和可靠。通过优化策略和测试验证，系统的性能和可用性得到了有效的提升。