本文由美团安全研究员乔丹分享，作者硕士毕业于复旦大学，目前在美团致力于云原生安全建设。原题“浅谈硬编码密码及其扫描工具”，下文进行了排版和内容优化。

1、引言

密码是对服务、系统和数据的访问权限进行授权的数字身份凭证，常见的密码有API密钥、非对称私钥、访问Token等。硬编码密码（Hardcoded Secret），或称嵌入式密码（Embedded Secret），是指将密码以明文方式直接写入代码中。这种处理方式极大地提高了攻击者命中密码的概率，使服务或系统暴露在风险中，容易造成严重损失。

针对此问题，本文详细讨论了硬编码密码的成因、危害及治理方法，同时本文从安全人员的角度出发，对现有的硬编码密码检测工具的算法进行了深入调研，并提出了我们的自动化检测工具。

2、系列文章

本文是IM通讯安全知识系列文章中的第15篇，此系列总目录如下：

• 《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
• 《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
• 《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
• 《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
• 《即时通讯安全篇（五）：对称加密技术在Android平台上的应用实践》
• 《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》
• 《即时通讯安全篇（七）：用JWT技术解决IM系统Socket长连接的身份认证痛点》
• 《即时通讯安全篇（八）：如果这样来理解HTTPS原理，一篇就够了》
• 《即时通讯安全篇（九）：你知道，HTTPS用的是对称加密还是非对称加密？》
• 《即时通讯安全篇（十）：为什么要用HTTPS？深入浅出，探密短连接的安全性》
• 《即时通讯安全篇（十一）：IM聊天系统安全手段之通信连接层加密技术》
• 《即时通讯安全篇（十二）：IM聊天系统安全手段之传输内容端到端加密技术》
• 《即时通讯安全篇（十三）：信创必学，一文读懂什么是国密算法》
• 《即时通讯安全篇（十四）：网络端口的安全防护技术实践》
• 《即时通讯安全篇（十五）：详解硬编码密码的泄漏风险及其扫描原理和工具》（* 本文）

3、为什么会用硬编码密码

随着互联网组织转向云架构、SaaS 平台和微服务，密码等数字身份验证凭证的数量和多样性正在快速增长。与此同时，企业也不断推动更短的发布周期，开发人员面临巨大时间压力的同时，需要处理的密码量比以往任何时候都多。许多开发人员采取捷径，选择使用硬编码的方式处理密码。

在企业的代码仓库中普遍存在大量的硬编码密码问题。据GitGuardian统计，在公共Git存储库上每天会泄露数以千计的密码，其中仅2020年就有超过200万个密码被上传至Git存储库中，而2021年该组织发现的密码数量超过600万，同比增长近2倍，而私人存储库的密码泄露事件存在可能性比公共库高4倍。

根据统计，硬编码密码包括API密钥、访问Token、非对称私钥、认证ID、安全证书、口令、特权用户账户等类型。

硬编码密码所涉及的平台十分广泛，包括如下领域：

• 1）开发工具，如Django、Rapid API；
• 2）数据存储，如MySQL、Mongo；
• 3）金融服务，如PayPal、Amazon MWS；
• 4）消息通讯系统，如Gmail、Telegram；
• 5）云提供商，如AWS、Azure、Google；私钥；
• 6）社交媒体，如Twitter、Facebook；
• 7）版本控制平台，如Github、Gitlab 等等。

除了程序代码中，这些硬编码还容易出现在基础设施配置文件、监控日志、运行日志、堆栈调试track记录、git历史中。所有类别的硬编码密码都使企业暴露在攻击之下。

4、硬编码密码的典型危害

硬编码密码主要对安全和研发两方面具有危害。

1） 削弱系统安全性：

攻击者常通过公共代码库或反编译分析获得硬编码密码字符串，利用密码访问敏感数据或获取敏感操作权限。攻击者还可以进一步扩大攻击范围，进行数据勒索、帐户操纵、帐户创建、通过用户数据进行利用等，使得企业和用户都遭受严重损失。在以下案例中，攻击均是从密码的泄露开始的：2014年，Uber数据库被未经授权访问，导致数千名Uber司机私人信息的数据被泄露；2016年，Uber又因外部的未授权访问导致5700万用户的个人信息被泄露；2018年，Github和Twitter在内部日志系统中以明文方式存储密码，分别涉及2700万和3.3亿用户数据泄露；2020年，用户在Github仓库中发现了星巴克的API密钥，涉及重大信息泄露；2021年，黑客组织 Sakura Samurai 在一次重大数据泄露事件中获得了访问联合国 (UN) 员工私人数据和系统的权限……由硬编码密码导致的安全事故层出不穷，也不断有相关CVE和CWE被披露。

硬编码密码对特定设备、固件、服务、应用程序本身，对其连接的IT生态系统其他部分，甚至使用服务的第三方都存在风险，使其同样暴露在风险中。

2）不易于程序维护：

硬编码密码的修复较为困难，密码一旦被利用无法轻易被修正。对于正在线上运行的服务或系统，修复硬编码密码问题需要停服重新发布。大型企业的服务流量较大，服务间还存在依赖，则需要灰度发布，修复流程更长，其间可能持续受到攻击者威胁。

密码的蔓延也使维护变得困难。与传统凭证不同，密码旨在分发给开发人员、应用程序和基础设施系统，这将不可避免地使开发中使用的密码数量增加，一个密码可能出现在代码中多处位置，这进一步增加了修复的难度。

此外，开源的代码造成密码泄露，即使在源码中删除硬编码密码，也会残留在git历史里。

5、怎样避免硬编码密码

企业代码中的硬编码密码问题日益严重，只有通过安全人员和研发人员的共同协作才能解决。源代码中的密码泄露很难彻底避免，但与其他漏洞一样，它完全由内生因素决定：开发人员需要访问更多的资源，以更快的速度构建和部署。这意味着只要有足够的纪律和教育，再加上正确的工具，就有可能大幅改善这种情况。

从开发人员角度：需要注意尽量避免将密码以明文形式写入代码中。代码中需要对密码进行校验时，对入站身份验证可使用强单向散列函数进行密码模糊化，并将这些散列结果存储在具有适当访问控制的配置文件或数据库中；对出站身份验证，可将密码存储在代码之外的一个经过严格保护的、加密的配置文件或数据库中，该配置文件或数据库不会被所有外部人员访问，包括同一系统上的其他本地用户；大型企业可以使用KMS服务进行一站式密码管理。

从安全人员角度：应尽量做到风险左移，尽早发现密码泄露，帮助开发人员降低修复成本。可通过代码检测扫描，将硬编码密码检测集成到开发工作流程中，提前发现硬编码密码问题。

6、硬编码密码的典型检测方法

由于硬编码密码有如此的危险性，学术界和工业界都有许多组织针对此问题研发了代码扫描工具。我们对开源工具和学术文章进行了一系列调研，总结了目前的硬编码密码扫描工具常用的检测算法，并对其优缺点进行了讨论。

6.1 正则表达式匹配

正则表达式通常被用来检索符合某种模式的字符串。对于检测具有固定结构或特征的密码，正则表达式可能很有效。

常用于密码检测的正则表达式可分为：

• 1）针对各种特定平台密码的表达式；
• 2）不针对任何平台的通用表达式。

1）针对各种特定平台密码的表达式：

许多平台的API密钥、访问Token、认证ID等具有平台独有的特征，例如亚马逊AWS密钥均以“AKIA”字符串开头；常用于非对称加密的私钥如RSA、EC、PGP及通用私钥等，常由ssh-keygen、openssl等工具生成，多数情况下私钥以单独的PEM等文件格式存储，其内容也具有一定特征，例如RSA私钥文件由"-----BEGIN RSA PRIVATE KEY-----"字符串作为开头。对于这类密码，可以通过匹配具有其特征的正则表达式进行检测。

下表列举了部分常用平台密码的类型以及正则表达式。本文仅以此表举例，实际上特定平台的密码种类十分丰富，此处不便一一列举。

2）不针对特定平台的通用的表达式：

由于特定平台表达式和平台的一一对应性质，其覆盖范围有限，此时需要用覆盖范围较广的通用表达式来补充。许多平台的密码具有一些通用的特征，例如密码字符串以api_key、access_token等关键字为开头。

此外，根据开发人员的编程命名习惯规范，也可以根据变量名中的关键字进行匹配，例如变量名中含有Secret、Token等关键字的字符串很可能是密码。

优点：

• 1）配置简单；
• 2）自定义扩展方便。

缺点：

• 1）正则表达式覆盖范围不够广则容易漏报；
• 2）使用一组不准确的正则表达式容易出现大量误报；
• 3）即使是正确的正则表达式也有一定程度的误报，例如“AKIAXXXEXAMPLEKEYXXX”虽然符合亚马逊AWS的正则表达式，但并不是有效的密码；
• 4）通用表达式中使用变量名关键字匹配的检测方法容易被对抗。

6.2 熵字符串编码检测

在信息论概念中，熵是对不确定性的量度，越随机的数据的熵越高。大多数API密钥、访问Token等密码字符串具有高度熵的特性，因此可以通过搜索高熵字符串来检测密码。这种算法被以TruffleHog为代表的工具所采用。现有的工具一般采用香农熵算法来计算字符串熵值，对字符串A的香农熵值计算公式如下图所示，其中pi表示第i个字符出现的频率。

1）优点：

• 1）能够检测出无明显特征的密码，对于正则表达式未覆盖到的范围有补充效果；
• 2）可用于对正则表达式检测结果的验证，如上文提到的正则表达式误报字符串“AKIAXXXEXAMPLEKEYXXX”，其熵值较低，可通过验证筛除。

2）缺点：

• 1）字符串被判定为密码的熵阈值难以确定，阈值过高容易漏报，阈值过低又容易误报。即使是学术论文中的阈值也全凭实验经验确定，缺乏坚实的理论支撑；
• 2）一些高熵值的SHA、MD5等字符串容易被误报为密码。对于这一问题，可通过过滤SHA、MD5值出现较密集的文件扩展名来降低误报，例如.lock, .inc文件；
• 3）容易将具有明显升降序的字符串误报为密码。香农熵只对出现频率进行计算，不考虑字符顺序，具有明显升降序的字符串同样会表现出较高熵值，例如Hex编码的“123456789abcdef”和“d9b41a72f683ce5”两字符串香农熵相等，但前者一般不会是一个有效的密码。对于这一问题，需要通过一些启发式处理方式降低升降序字符串的熵值，或通过后期过滤筛除。

7、美团的硬编码密码检测工具研发实践

为了保障美团整体研发环境安全，同时节约安全人员的审计成本，我们研发了针对硬编码密码的代码扫描工具。我们认为在众多字符串中寻找密码如同在沙里淘金，因此将工具命名为Gold-digger。

7.1 工具设计

为服务于全公司研发环境，Gold-digger工具有如下需求：

• 1）编程语言无关：公司各业务使用的编程语言不同，Gold-digger需要无障碍地应用于所有编程语言代码中；
• 2）模块化，方便扩展迭代：为了根据测试反馈结果不断提高效果，Gold-digger需要长期不断迭代；
• 3）能够集成到软件开发生命周期中：Gold-digger侧重预防，需要工具集成在CI/CD管道中，从源头遏制密码泄露风险；
• 4）高精确率召回率：Gold-digger的设计初衷之一是节约人力成本，为降低审计、维护和运营压力，必需尽可能准确、全面地检测密码。

基于上述需求，Gold-digger的架构主要分为四个模块：核心引擎、转换器、检测器、过滤器。

Gold-digger工作流程如下图，箭头表示数据流向。核心引擎依次读取代码仓库中文件，经过预验证和输入处理后将代码以行为单位传输给检测器，其中部分特殊格式由转换器处理后再传输给检测器；检测器在代码中检测密码候选值；过滤器对密码候选值进行后过滤，将过滤后的密码传回核心引擎；最后核心引擎将代码仓库中所有密码进行收集后，将密码相关信息输出为可读性较强的JSON文件报告。

1）核心引擎：

该模块为Gold-digger赋能，负责调度其他模块，也是负责输入输出处理、数据收集存储等。输入处理部分负责读取代码文件，先调用过滤器对文件后缀进行全局预验证，再通过引号标识匹配或调用转换器识别代码中的字符串及其赋值变量；然后核心引擎调用调用检测器和过滤器进行密码收集，将检测到的密码数据以文件为单位存入不同集合，能够方便地对集合进行合并、删减等操作；输出处理部分将仓库中所有密码关键信息，如密码值、文件位置、检测算法等，输出为JSON格式。

2）转换器：

该模块是专为部分特殊格式文件进行格式转换的处理器。尽管核心引擎能处理大部分代码格式，但无法处理.yaml、.ini、.properties等不使用引号作为字符串特征标识的格式。为保证语言无关性，我们使用转换器处理上述特殊格式，将其转换为用引号标识字符串的代码。这种解析方式无需为不同语言分析抽象语法树，能够有效节省算力。

3）检测器：

该模块是Gold-digger的密码检测算法模块。我们在综合调研同类型检测工具后，汲取了各方优点，采用了正则表达式匹配和熵字符串检测两类算法。Gold-digger的检测器包含数十种特定平台正则表达式、通用正则表达式以及Hex编码、Base64编码的熵字符串检测算法。检测器中每种算法以插件方式各自独立，方便扩展、启用或禁用，同时Gold-digger也允许用户自定义检测算法插件。代码将遍历所有检测算法，任一算法命中便记录为密码候选值。

4）过滤器：

该模块为Gold-digger的验证、过滤模块。预验证部分在检测器运行前对文件格式进行验证，筛除压缩文件、多媒体文件等非文本类型；后过滤部分在检测器运行后对所有密码候选值进行启发式过滤，并将过滤后的密码传回核心引擎。后过滤过程中每项密码候选值将遍历所有过滤规则，所有规则都未能筛除的候选值会被记录在密码集合中（检测器和过滤器的主要处理流程如下图所示）。过滤规则主要为开发测试人员凭经验总结的启发式规则，例如：过滤升降序字符串、过滤高度重复字符串、过滤uuid、过滤间接引用赋值等。

5）CI/CD集成：

Gold-digger的最终目标是消除代码中的密码泄露问题，因此检测到密码并不是最后一步，修复才是最后一步。我们把Gold-digger集成到公司研发环境CI/CD管道中，方便开发人员根据密码报告及时修复漏洞，从源头遏制风险。当开发人员向公共存储库提交代码后，Gold-digger会进行on-push扫描，对包含密码的提交进行拦截和告警。此外，我们还允许开发人员在本地使用Gold-digger，进行pre-commit或pre-push检查，整体风险左移。

7.2 数据对比

我们使用Gold-digger与最先进的开源工具进行了对比。

我们对内部服务代码进行了分析，将人工安全审计发现的密码作为测试基准，使用工具对代码进行测试并统计结果。下表结果显示，我们的工具准确率和召回率高于其他所有开源工具，误报率和漏报率低于其他所有开源工具。

分析显示，Gold-digger检测的密码中大部分是通过通用正则表达式和熵字符串检测获得的。这是由于内部代码中包含的密码大多无明显前缀后缀特征，特定平台表达式检测不到。正因如此，大部分工具尽管定义了大量的特定平台的正则表达式但漏报率仍很高，例如trufflehog定义了700多种特定平台正则表达式，但通用正则表达式种类较少，故对特定平台表达式未覆盖到部分的检测能力较弱。Gold-digger可以利用通用正则表达式和熵字符串检测进行弥补，有效降低漏报。

密码检测的一大难点是避免来自非密码字符串的误报。Gold-digger通过多种启发式规则的过滤得到了较低的误报率。其他工具大量误报的主要原因则是正则表达式的匹配范围太宽泛又缺乏有效过滤手段，例如Gitleaks通过通用正则表达式识别到大量密码候选值，但其中既有真正的密码，又有appkey name、间接引用等，但未进行筛除。

8、本文小结

随着互联网组织架构的高速发展和软件发布周期的不断缩短，硬编码密码问题在企业代码仓库中日益严重，其危害已通过多起严重安全事故显示出来。硬编码密码的大规模治理必需由安全人员和研发人员共同合作。

美团为保障研发安全，设计了具有编程语言无关、模块化架构、集成在CI/CD管道等特点的硬编码密码的扫描工具Gold-digger。该工具的效果优于目前所有开源工具，能够有效帮助开发人员尽早发现并修复密码泄露，从源头保障研发安全。

9、相关资料

[1] Over two million corporate secrets detected on public GitHub in 2020

[2] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[3] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）

[4] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[5] 来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享

[6] 简述实时音视频聊天中端到端加密（E2EE）的工作原理

[7] 移动端安全通信的利器——端到端加密（E2EE）技术详解

[8] Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)

[9] 通俗易懂：一篇掌握即时通讯的消息传输安全原理

[10] IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token

[11] 快速读懂量子通信、量子加密技术

[12] 一分钟理解 HTTPS 到底解决了什么问题

[13] 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

[14] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等

[15] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[16] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

（本文已同步发布于：http://www.52im.net/thread-4781-1-1.html）

本文由转转 梁会彬、杜云杰分享，原题“转转IM的实践与思考”，下文进行了排版和内容优化。

1、引言

接上篇《整体架构设计》，笔者将以转转IM架构为起点，介绍IM相关组件以及组件间的关系；以IM登陆和发消息的数据流转为跑道，介绍IM静态数据结构、登陆和发消息时的动态数据变化；以IM常见问题为风景，介绍保证IM实时性、可靠性、一致性的一般方案；以高可用、高并发为终点，介绍保证IM系统稳定及性能的小技巧。

 技术交流：

2、系列文章

本文是系列文章中的第2篇，本系列文章的大纲如下：

• 转转平台IM系统架构设计与实践(一)：整体架构设计
• 转转平台IM系统架构设计与实践(二)：详细设计与实现（* 本文)

3、本文作者

梁会彬：转转架构部资深Java工程师，主要负责服务治理平台、Docker云平台、IM、分布式ID生成器、短域名服务等，有丰富的线上实战经验。

4、 IM架构回顾

应用层：使用IM服务的上游业务方，包括app（ios和android）、小程序/PC/m页、push、业务方等。

接入层：

• 1）tcp entry：使用TCP协议，主要用于长连接保持、会话管理、协议解析；
• 2）http entry：使用http协议，采用long pull技术，主要用于长连接保持、会话管理、协议解析；
• 3）mq：接收电商推广等系统消息。推送量具有脉冲特点，使用mq削峰填谷；
• 4）rpc-server：业务查询用户聊天数据、发送实时系统消息等。

逻辑层：

• 1）logic：核心逻辑服务，负责登陆信息管理、在线消息管理、离线消息管理、在线推送管理等；
• 2）ext-logic：扩展逻辑服务，负责子母账号推送、登陆信息统计、系统消息管理等。

数据层：

• 1）MySQL：联系人数据、消息数据、系统消息数据等；
• 2）Redis：登陆信息等。

5、IM消息收发

5.1场景说明

数据流中以用户A和用户B的对话为例，其中用户A的uid为1，用户B的uid为2。

下图为用户聊天场景图：

下图为用户聊天IM系统的数据流转图：

5.2数据结构

登陆信息存储在Redis中，联系人和消息数据放在TiDB中。

1）登陆信息：

key：uid

value：{entryIp:"127.0.0.1",entryPort:5000,loginTime:23443233}

2）联系人：

说明：

• 1）recent_msg_content：最近一条对话消息的内容，用于联系人列表中展示最近的消息内容；
• 2）recent_read_time：最近一次读取该会话消息的时间，用于控制已读状态，小于该时间的所有消息，都为已读状态。

3）消息：

说明：

• 1）client_msg_id：客户端生成的id，客户端幂等设计，防重复；
• 2）direction：消息方向（0代表较大uid向较小uid发送消息，1则反之）。

数据流=数据+流。上面部分讲数据，即联系人和消息表，从静态的角度介绍了IM的数据结构；下面部分讲流（IM中最重要的两个流程），即登陆和发消息，从动态的角度来阐述IM系统中数据的流转。

5.3主要流程

5.3.1 ）登陆：

1）问题：entry地址发现：app直接访问vip，由vip转发到entry。

2）流程（下面的数字为图中数字的说明）：

• 1）建连：app通过vip发起与entry连接；
• 2）转发：entry转发登陆信息到logic，获取用户uid并管理该用户的连接；
• 3）入库：logic记录用户登陆信息到redis。

3）数据：

Redis中数据如下：

key：1

value：{entryIp:"127.0.0.1",entryPort:5000,loginTime:23443233}

5.3.2 ）发消息（下面的数字为图二中数字的说明）：

1）流程处理：

• 1）发送：通过用户与entry的长连接发送文字"hello world"；
• 2）转发：entry转发文字信息"hello world"到logic；
• 3）入库：logic存入数据库，即更新联系人表和消息表，其中联系人表更新recent_msg_content字段，消息表增加一条新消息记录；
• 4）推送：从Redis中获取用户B登陆entry，如果未登录，走离线逻辑（发送push、推送微信、短信唤起）；
• 5）送达：用户B收到消息；
• 6）确认：发送ack到entry；
• 7）完成：logic收到ack，取消定时器；如果没有收到ack，logic会定时重发（用户在线时）。

2）数据：

联系人数据如下：

消息表数据如下：

5.3.3）关于数据的几个问题：

1）消息和联系人是如何分库分表的？使用TiDB，无需分库分表（现在的表设计支持根据uid_a分表，也就是无缝支持以MySQL为存储）。

2）联系人表一条消息为什么记录了两条数据？业务逻辑上，考量支持已读、删除联系人；索引性能上，考虑用户查询联系人时，sql条件为where uid_a=？，联系人表索引为uid_a，如果存单条数据，无法有效利用索引。

3）消息表一条消息记录一条数据，用户B与用户A的消息怎么查询？该表索引为<big_uid, small_uid>联合索引，无论是用户A查询与用户B的聊天信息，还是用户B查询用户A的聊天信息，其sql统统为where big_uid =max(uid_a,uid_b) and small_uid =min(uid_a,uid_b)，然后根据direction字段展示聊天方向，这样就可以用一条消息，无需和联系人表一样存储两份数据，满足两种查询，节省一半的消息存储。

6、IM常见问题

6.1消息的实时性

1）是什么：

用户A给用户B发送消息"hello world"，用户B怎么第一时间感知到？这里说的实时性，就是指用户如何实时获取发送的消息。

2）io模型带来的启示：

• 1）poll、select、epoll；
• 2）poll/select相比epoll最大的劣势在于轮询，轮询就需要轮询间隔，间隔小会浪费cpu，间隔大会不实时。epoll具有don't call me i will call you的特点，保证实时性；
• 3）IM也面临着轮询还是通知的问题，也就是pull和push的问题。

3）怎么办：

• 1）向epoll致敬：epoll_create、epoll_ctl、epoll_wait（此三者是epoll系统调用api）；
• 2）整个IM系统和epoll模型类似，app和entry保持长连接（epoll_create）；entry session管理（即长连接管理epoll_ctl）；logic等待用户A发送给用户B消息，获取用户B所登陆entry，触发推送消息（epoll_wait）；综述，entry扮演着（epoll_create，epoll_ctl），logic扮演着（epoll_wait）这样IM系统就解决了消息实时性问题。

6.2消息的可靠性

1）是什么：

• 1）用户A给用户B发送消息"hello world"，用户B在线，怎么保证用户B确实收到了消息。这里说的可靠性，就是指用户如何可靠发送的消息。

2）tcp模型带来的启示：

• 1）失败重传、ack确认。

3）怎么办：

• 1）失败重传：图二中（1、发送2、转发3、入库）失败，告知客户端失败，由客户端重传；
• 2）ack确认：图二中（4、推送5、送达6、确认7、完成）失败，即ack处理失败，启动重新通知逻辑。

6.3消息的一致性

1）是什么：

• 1）现象：本来用户A给用户B发送了一个"hello world"，而用户B确收到了两个"hello world"；
• 2）原因：由于可靠性逻辑中的重传逻辑，可能造成客户端认为失败了，但是服务端却成功了；推送ack返回错误，造成重推。

2）身份证带来的启示。

3）怎么办：

• 1）client_msg_id：客户端发送消息时生成客户端id，对于单个客户端，该id具有唯一性，像身份证一样；
• 2）客户端去重：如果客户端发现相同client_msg_id的消息，则仅仅展示一条数据。

7、IM高可用、高并发

1）扩缩容：

依托公司rpc服务注册发现能力，借助docker快速扩容，核心处理逻辑logic服务实现秒级扩容。扩容依据为各种监控指标，包括机器性能指标、 entry/logic qps指标、jvm指标、sql监控等综合考量。

2）熔断：

当大流量进入时，如果核心服务依赖的服务（比如母子账号服务）出现不可用的情况。这时，我们是直接使IM服务不可用吗？是不是有更好的选择？答案是肯定的，我们可以牺牲母子账号功能，也就是熔断不重要的依赖服务，做到柔性可用。

3）限流：

如果遇到瞬时高流量，仅仅扩容有可能适得其反。如果db处理能力达到极限，扩容就不是明智的选择，扩容反而会导致db连接增多，增加db的压力，导致服务崩溃。这时退一步采用限流，应用“fast fail”策略，让部分流量快速失败，减小服务压力，达到部分可用的效果。

4）总结：

IM作为电商应用中的一个重要节点，其重要性不言而喻，对其怎么重视都不为过。我们使用监控工具定义IM的核心metrics，根据指标进行扩缩容，这样做到了高可用；

高可用是万能的吗？IM依赖了很多服务，比如用户，母子账号，风控等服务，如果这些服务出现不可用的情况呢？这个时候就要学习一下古人的智慧，壮士断腕，牺牲小我，换取大我了，也就是柔性可用；

仅仅这样还是不够的，如果遇到突发流量，db（不可瞬时扩大处理能力）等处理能力达到极限时这个时候就要牺牲部分请求了，也就要做到部分可用。从“高可用”到“柔性可用”再到“部分可用”，面对不同case，IM要做到游刃有余。

其实，这种思想又何止IM呢，任何重要的服务都要面对这些问题吧，推而广之，面对自己负责的服务，怎么精细小心都不为过。

8、本文小结

诚然，这篇文章给大家对IM系统简单的认识，阐述了IM的一般架构、主要业务逻辑、常见问题和解决方案以及服务治理相关应用，IM还有很多业务逻辑和技术挑战。

在业务上，如未读数、群聊、多端登陆、母子账号等；在技术上，entry长连接100k问题优化、时间轮计时器实现、海量数据拆分与存储选型等。

路漫漫其修远兮，吾将上下而求索。

9、参考资料

[1] 零基础IM开发入门(二)：什么是IM系统的实时性？

[2] 零基础IM开发入门(三)：什么是IM系统的可靠性？

[3] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

[4] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[5] IM消息送达保证机制实现(二)：保证离线消息的可靠投递

[6] 如何保证IM实时消息的“时序性”与“一致性”？

[7] 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践

[8] 阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践

[9] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[10] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[11] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[12] 一套原创分布式即时通讯(IM)系统理论架构方案

[13] 从零到卓越：京东客服即时通讯系统的技术架构演进历程

[14] 蘑菇街即时通讯/IM服务器开发之架构选择

[15] 现代IM系统中聊天消息的同步和存储方案探讨

[16] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[17] 马蜂窝旅游网的IM系统架构演进之路

[18] 一套分布式IM即时通讯系统的技术选型和架构设计

[19] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

[20] 携程技术分享：亿级流量的办公IM及开放平台技术实践

（本文已同步发布于：http://www.52im.net/thread-4773-1-1.html）

1、前言

一个孤独的小人，面对巨大的地球站在那里，这就是微信的启动画面，许多人对此非常熟悉。而知道画面里是非洲，就不是那么容易了。这是因为图片里的地球为云团笼罩，只露出一部分地貌特征，需要对世界地图比较熟悉的有心人才能发现这一点。

2、图片解读

不过，因为有了我，一切都变得很简单了：

非洲大陆东北角上，那狭长的红海，和东南角上的马达加斯加岛，我都用红圈标注了出来。通过对比，这是一望而知的事情。两张图的区别在于，地图是在赤道上空看地球，而照片要偏南半球很多，以至于欧洲被挤到了图片之外，相反是南极洲在图片下方占据了大量面积。

问题在于，各个国家习惯性地把自己国家置于地图的中心。例如下面英国出版的世界地图，和你平常看到的世界地图绝对不一样：

中国不在地图的中心，是不是这样？那么，为什么微信的启动画面上的地球是正对非洲，而不是中国呢？

因为它不是地图，而是一张照片，一张真实的照片，用哈苏照相机在4万5千公里外拍摄的地球照片。这张照片的官方编号是：AS17-148-22727，民间给它的名字叫“蓝色弹珠”（The Blue Marble）。

3、“蓝色弹珠”（The Blue Marble）

要谈一下这张照片，必须说到美国的“阿波罗登月计划”。从1961年5月到1972年12月的十一年时间里，美国持续进行了一系列载人登月太空飞行。其中，有6次成功登上月球。而大家最为熟悉的失败案例是阿波罗13号登月计划，它被拍成了一部非常精彩的电影。

蓝色弹珠这张照片拍摄于1972年12月7日，当时宇航员在阿波罗17号飞船上，三名宇航员中的某一位用一台80毫米镜头的哈苏照相机，拍下了完整的地球照片。这张照片非常难得，因为阿波罗17号飞船执行的是最后一次阿波罗登月计划，从此以后，人类已经很久没有飞船抵达这个距离对地球进行拍照。我们看到的大量地球的照片，都是合成照，而不是太空实拍。

站在宇航员的角度，于4万5千公里之外看过去，地球就像是一颗很小的蓝色弹珠，这就是这张照片名字的由来。

4、最文艺的解读

微信的启动画面就是用了这张“蓝色弹珠”，人类最近一次在太空中远眺母星的景象。作为一种人际沟通工具，没有第二张图能更好地表达出人类内心的孤独，以及地球家园的美好。所以，整个画面有一种孤清中的淡淡暖意，给人的感觉是文艺到死。等你知道了背后的故事，又会觉得闷骚到死。

5、另外一种解读

我这里有另外一个不同的答案：

— 为什么不是正对着中国?

— 因为他在等待着那人转过来。

— 转过来之后呢?

— I WANT YOU!

6、更多QQ、微信的技术故事

《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》

《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》

《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》

《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》

《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》

《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》

《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》

《技术往事：“QQ群”和“微信红包”是怎么来的？》

《开发往事：深度讲述2010到2015，微信一路风雨的背后》

《开发往事：微信千年不变的那张闪屏图片的由来》

《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》

《一个微信实习生自述：我眼中的微信开发团队》

《首次揭秘：QQ实时视频聊天背后的神秘组织》

《为什么说即时通讯社交APP创业就是一个坑？》

《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》

《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》

《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》

《QQ的成功，远没有你想象的那么顺利和轻松》

《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》

《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》

《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？ 》

《那些年微信开发过的鸡肋功能，及其带给我们的思考》

《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》

《同为IM社交产品中的王者，QQ与微信到底有什么区别》

《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》

《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》

《社交应用教父级人物的张小龙和马化腾的同与不同》

《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》

《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》

《微信纯血鸿蒙版正式发布，295天走完微信14年技术之路！》

>> 更多同类文章 ……

（本文已同步发布于：http://www.52im.net/thread-204-1-1.html）

本文为CSDN的《程序员》杂志原创文章，下文有修订和改动”。

1、引言

南方企业一直有过年找老板“逗利是”的习俗，每年春节后开工的第一天，腾讯大厦都会排上长长的队伍，集体上楼找老板们领红包。按照广东习俗，已经结婚的同事也要给未婚同事发红包，这一天腾讯员工就在春茗和寻找红包中度过。

由此孵化了一个内部项目，通过微信来收发红包，把这个公司全员娱乐活动与最活跃的IM平台微信结合起来。最初这个项目并没有预期对外，但是入口不小心开放后，成为了现象级产品。2014年开始爆发性增长，每年的发放量都是上一年的若干倍。根据腾讯公布的数据，到2016年春节，已经是每秒十万次支付，每天近十亿订单的系统。

微信红包本质是小额资金在用户帐户流转，有发、抢、拆三大步骤。在这个过程中对事务有高要求，所以订单最终要基于传统的RDBMS，这方面是它的强项，最终订单的存储使用互联网行业最通用的MySQL数据库。支持事务、成熟稳定，我们的团队在MySQL上有长期技术积累。但是传统数据库的扩展性有局限，需要通过架构解决。

补充说明：本文对应的演讲PPT详见《微信红包数据架构演变(PPT) [附件下载]》。

技术交流：

二、分享者

莫晓东：微信支付高级DBA，拥有丰富的数据架构和运维实战经验，擅长大规模MySQL数据库集群的架构、优化和高可用。2010年起在腾讯从事DBA工作，目前专注于微信社交支付的存储层运维和架构优化。

三、系列文章

❶ 系列文章目录：

《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》

《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》

《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》

《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》

《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》

《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》（* 本文）

《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》

《社交软件红包技术解密(八)：全面解密微博红包技术方案》

《社交软件红包技术解密(九)：谈谈手Q春节红包的设计、容灾、运维、架构等》

《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》

《社交软件红包技术解密(十一)：最全解密微信红包随机算法(含演示代码)》

《社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践》

《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》

❷ 其它相关文章：

《技术往事：“QQ群”和“微信红包”是怎么来的？》

《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》

《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》

《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》

《微信技术总监谈架构：微信之道——大道至简(演讲全文)》

《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》

《如何解读《微信技术总监谈架构：微信之道——大道至简》》

《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》

《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》

《微信朋友圈海量技术之道PPT [附件下载]》

《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》

《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》

《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》

《微信“红包照片”背后的技术难题》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

4、前端流量控制

发十亿红包，难在哪里？

• 1）大量用户在同一时间发抢红包，瞬间产生每秒数万次的请求，除夕可能成百千万次；
• 2）这个量级的请求如果不加以疏导处理直接到达后台，必定会导致后端服务过载甚至崩溃。

主要思路是缩短关键业务流程，分离可以通过异步、缓存等方式解决的问题，减轻系统压力，加快响应速度，在存储层前面建上一座大坝。

CGI无状态：

接入层无状态，逻辑层也无状态，可以方便地水平扩展。但依赖MySQL事务保证交易完整，保证红包系统的精简，减少瓶颈的存在。

资源静态化：

利用腾讯强大的基础资源优化部署，尽量把动态内容转为静态资源。静态资源和CGI分离，静态资源通过CDN就近接入，减少用户和CGI的交互，减少内网、访问延时和数据请求。

业务流程异步化：

微信红包的发、抢、拆背后都有多个内部环境，关键流程精简，非关键流程和后续业务逻辑进入异步队列进行处理，减少了用户的等待时间，也极大降低了峰值雪崩的概率。繁多的非关键链路也不会影响到主流程。

过载保护：

前端保护后端，能在前端处理，就不传递到后端：

• 1）前端需要按后端能力做削峰限流；
• 2）客户端、接入层、逻辑层逐层控制流量；
• 3）前端更容易容错处理，全力保护存储层。

微信的过载保护在客户端已提前预埋了策略，在连接失败或超时情况下会有相应提示，减少用户重复请求次数。接入层针对频繁发出请求的客户端限制响应速度，并对系统负载划分出若干等级，达到不同阈值时引导客户端使用不同限速速率；在异常情况出现时，异步限流降速减轻服务器端压力防止过载。

多级读缓存：

发一个群红包，抢红包的请求量远大于发红包，如果已经领过完全可以拒绝。逻辑层增加缓存，类似可以缓存的请求都缓存起来，进一步减少存储层流量。

订单写缓存：

订单系统有很多请求不会真正完成全流量，创建这些废单不但浪费存储资源，还会挤占逻辑层和数据层的处理能力，影响其他交易。订单在完成支付前可以先落在缓存中，完成支付后再持久化。

5、存储层的高可用设计

在数百倍千倍的业务增长下，存储层很难简单无限扩容，一方面设备成倍增加的成本巨大，另一方面存储层瓶颈堆积不一定能解决问题。

读写分离：

写请求需要在主机上，实时读也需要走主机。有大量对延时不那么敏感，又影响性能的查询，完全可以放到从机。读写分离策略是MySQL分布式的入门，简洁地提高了系统容量。

水平切分：

数据的水平切分，实质就是分库分表；选取一张数据表按照主要纬度把数据拆分开。实现存储层的平行扩展。有效降低了单台数据库机器的负载，也减小了服务不可用的可能性。单台数据库宕机只会导致部分数据不能访问。主要需要考虑路由规则的选定，方便扩缩容以及数据的均衡分布。

垂直切分：

数据表除了水平切分，行内数据可以按属性进一步分开。核心表只保留最关键的字段，保证数据文件短小紧凑。以红包为例，昵称和祝福语这类较长的信息，不属于核心数据，完全可以切分到别的机器上，进一步提升核心数据库的容量。不同数据适合的存储类型也不一样，这类重复率高的长字符串更适合NoSQL存储，对存储空间和性能都是节约极大。

空间换时间：

按不同维度组织表，比如按订单属性和用户属性进行组织；适应不同的请求场景，避免复杂的查询。不同维度的表可以通过对账对齐，非核心表可以适当冗余，减少多次请求。

锁的优化：

多人争抢红包通过数据库事物来保证，必然存在竞争MySQL行锁。核心事物必须尽量精简，避免死锁。同一个订单的所有请求，尽量在逻辑层进程预排队后通过一个连接发送请求到数据库。

冷热分离：

核心数据库存放高频数据，其他数据可以定时移到成本低的冷数据库中。这样可以为核心数据库使用最好的SSD设备，快速设备容量较小较贵，不可能在全量数据上使用。同时可以保证数据表的容量不会一直积累，大表也会导致性能下降。

6、异地多活

当系统足够大时，就必须开始考虑异地部署的问题，让数据尽可能离用户更近。而且进一步的高可用不能局限在同一地域，必须跨数据中心跨城多活才能抵御系统性风险。因为跨城的几十毫秒延时，微信红包的异地活动设计为多数据中心相互独立。非灾难灰度不会将其他数据中心的数据导入到线上。

就近接入：

以微信红包系统的异步部署为例，第一个好处是用户就近接入，减少跨城的穿越流量。根据发送者的地域标志数据落地到不同数据中心，在不同地域实现业务闭环。

数据分离：

当前的网络技术限制，使用光纤也无法保证跨城数据的同步延时问题。所以微信红包的跨城数据中心并不进行数据实时同步。不同区域各自承载业务流量，地域上实现平衡，各地的订单数据各自独立存储。

异地容灾：

如果出现地域性故障，我们需要有机制去保证服务可用性。有了异步部署，假如深圳出现系统性故障，那么我们可以直接把请求接入上海。各数据中心独立部署，如果某地系统达到最大容量，可以进行跨地域分流。

7、有损服务和柔性降级

我们遇到最多的问题就是海量请求，通过分布式系统来实现海量请求，根据CAP理论不能同时保证一致性和高可用，必须有取舍。我们首先保证可用性，同时实现最终一致性。有以下原则。

有损服务：

要追求高可用性，可以牺牲部分数据一致性和完整性从而保证核心功能。在资源一定的前提下，满足用户的核心需求。微信红包的核心点是抢、拆红包，系统必须尽最大可能保证核心步骤流畅，但在瓶颈时立即降级防止引起系统雪崩。但是要保证数据能最终对齐，金融属性的系统数据安全硬要求。

柔性可用：

柔性可用是在有损服务价值观支持下的方法，结合具体场景提供不同级别的用户体验，保证尽可能成功返回关键数据。把握用户在每一个场景中的核心需求，设计不同层次满足核心诉求的办法。系统首先要实现容灾和自动切换；其次逻辑资源应该隔离；服务过载时必须自动快速拒绝。

8、结束语

本文简单介绍了微信红包的存储层服务设计准则，在业务从起步到小跑再到腾飞的过程中，背后的海量服务能力将对其最终成败有着越来越深远的影响。在互联网爆发性增长中，海量服务能力决定项目成败，必须在项目初期就做好海量服务的准备。

附录1：有关微信、QQ的文章汇总

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》

《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》

《微信团队分享：微信移动端的全文检索多音字问题解决方案》

《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》

《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》

《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》

《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》

《微信团队原创分享：iOS版微信的内存监控系统技术实践》

《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》

《iOS后台唤醒实战：微信收款到账语音提醒技术总结》

《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》

《微信团队分享：视频图像的超分辨率技术原理和应用场景》

《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》

《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》

《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》

《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》

《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》

《微信团队分享：微信Android版小视频编码填过的那些坑》

《微信手机端的本地数据全文检索优化之路》

《企业微信客户端中组织架构数据的同步更新方案优化实战》

《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》

《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》

《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》

《以手机QQ为例探讨移动端IM中的“轻应用”》

《一篇文章get微信开源移动端数据库组件WCDB的一切！》

《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》

《微信后台团队：微信后台异步消息队列的优化升级实践分享》

《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》

《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》

《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》

《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》

《微信Mars：微信内部正在使用的网络层封装库，即将开源》

《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》

（本文已同步发布于：http://www.52im.net/thread-2568-1-1.html）

本文来自腾讯ISUX设计团队，下文有修订和改动。

1、引言

2019年4月16日QQ语音消息新特性突然登上微博热搜，QQ铁粉瞬间集结。是什么让129万人为QQ花式彩虹屁？为何微信却被吃瓜群众疯狂艾特？现在，让我为你揭秘QQ语音消息改版的设计旅程。

关于腾讯ISUX团队：

腾讯社交用户体验设计，简称ISUX (Internet Social User Experience)，成立于2011年1月11日，是腾讯集团核心、全球最具规模的UX设计团队，专业成员包括用户研究、交互设计、视觉设计、品牌设计、视频动画设计、UI开发、产品设计与市场研究等，至今ISUX分布于中国深圳总部、北京、上海、成都及韩国首尔。ISUX主要负责腾讯社交通讯与娱乐类产品服务的用户体验设计与研究，包括主要服务平台如QQ、QQ空间、QQ音乐、腾讯云、腾讯企点、QQ物联、腾讯课堂、兴趣部落、花样直播、全民K歌、全民影帝、企鹅FM、企鹅MV、天天P图、微云和来电等。

即时通讯网整理另一篇来自ISUX团队的文章，也可以一读：《感悟分享：在腾讯的八年，我的成长之路和职业思考》。

技术交流：

2、回归沟通：语音消息能否更方便

QQ已经陪伴了大家20年，但是我们仍然在持续思考怎样让用户的沟通更加高效。语音作为人与人之间最自然的交流方式，也不断引起我们对现有体验的反思。

是否语音消息只能采取这种经典的气泡体验？

现有的这些点击播放的语音气泡真的满足了所有用户需求吗？emm…

总结一下：发送语音一时爽，接收语音想撞墙。

针对这些用户声音，业内已有一些解决方案。但是其目标用户量和场景远没有QQ这样丰富。在此次改版中，我们回归QQ本身，探索在QQ语音消息场景中存在的那些痛点。

面对这些痛点，此次改版将需求聚焦在：

• 1）长语音被打断可以重听；
• 2）识别有效的语音片段；
• 3）重点语音片段反复收听。

对于QQ 8.0此次对语音消息功能的改进目标：

• 1）功能层面上，我们将通过提供语音的暂停和进度拖拽能力，并可视化音量，以满足语音接收者的使用效率需求；
• 2）在体验层面上，语音作为用户的高频沟通操作，其设计必须满足QQ8.0中精致这一设计原则，给用户带来极致体验。

3、美好体验，从第一眼开始

3.1 易学性：让功能更加直觉化

“这么简单的操作，用户试一次就知道怎么用了吧！”

QQ拥有广泛的用户群，所有功能都要尽量降低用户的学习成本。更何况由于没有其他国民级APP的相似特性可以类比，对用户来说语音进度调节不只是一个新功能，更是一种新模式。在这种背景下，功能的易学性显得尤为重要。怎样让用户一眼就明白语音消息可以暂停并拖动呢？怎样让操作更加直觉化？我们不妨从用户熟悉的事物入手，进行联想。

暂停和拖动在语音中不常见，但它却是播放器的通用功能。在播放器设计中，有三个用户行为引导的关键元素：a.按钮—播放和暂停的指示 b.游标—拖动指示 c.颜色—进度指示。本次语音气泡的设计中，我们依旧沿用了按钮、游标、色彩作为指示性元素。

但是这些元素的加入无疑会加重气泡内的信息负担。并且当同时出现多个语音气泡时，我们更加需要保证聊天页面有适当的信息密度。因此在声纹样式设计中，降噪成为了关键。在发散了多种样式后，我们最终选择了这种简约的声纹形态。它既能很好的展示进度信息，又可以平衡气泡内的信息密度，让QQ多样化的用户群都能对语音进度拖拽有更直觉化的操作。

3.2 准确or美：直观体验至上

“声纹是程序直接生成的，难道还需要设计？”

盆友，买家秀和卖家秀了解一下？

呈现准确音量的声纹无法满足我们预期中的流畅视觉体验，反而会让用户感觉到多变声纹信息带来的压力。回归设计目标，声纹是为了帮助用户识别有效语音片段，因此有声音和无声音的声纹对比很重要。这也意味着对于正常音量区间的声音，我们可以适当牺牲准确性以确保良好的视觉体验。

在收集了大量用户真实语音声纹后，我们发现最“丑”声纹来自于两类声音。一类是当用户语音连续达到最大音量时，大量声纹达到最高高度并撑满语音气泡。这种现象常发生在用户对着手机收音孔处说话的场景中。为了解决这个问题，我们将达到最大音量的声纹高度进行削减。被削减的高度按照正弦曲线做随机值，再加回到这些声纹的上方。经过这样的优化后，所有达到最高值的声纹都能够在顶部产生流畅的曲线。

另一类“丑”声纹则来自于音量忽高忽低造成的声纹高度跳变。这是由于人们说话是非连续的，会存在语气词和用户思考的沉默点。解决这个问题的关键是让高声纹和低声纹之间的落差减少。因此我们定义当相邻声纹高度差超过50%时，就对这两个声纹高度做平滑处理，保证所有音量的声纹都有流畅的过渡。

经过与产品和开发团队的多轮参数调整后，这些精心优化后的声纹可以让用户无论怎样说话都能“看到”自己最美的语音。

4、不止拖拽，更要畅快感受

4.1 更大的响应区域

“点击拖拽是常规操作，调用系统交互就好了吧？”

拖拽的确常规，但是在功能之外，我们能否让用户的操作体验更畅快呢？

畅快意味着无拘无束，翻译成交互语言就是要赋予用户更大的操作区域。但是我们的手指宽度和控件大小有时难以匹配。例如，8.0UI改版后的语音气泡高度为118px，而成人手指的宽度范围则在110px-180px。如果拖拽只能在气泡范围内进行，就意味着用户需小心翼翼地去操作。为了实现“无拘无束”的拖拽体验，我们根据用户的行为阶段对响应范围进行了两次放大。

第一次放大：开始拖动阶段，放大触发拖动的范围。拖拽事件的触发范围由气泡本身扩大到气泡的外边缘区域。

第二次放大：拖拽中，拖动行为的响应范围扩大到全屏。一旦用户触发拖拽，系统将屏蔽聊天页面的所有操作，包括右滑返回、上下滚动和页面内的所有点击操作。确保用户在手指未离开屏幕的前提下，可以在整个页面范围内控制进度拖拽。一方面用户不再需要沿着气泡的小小区域去拖拽，体验更加顺畅；另一方面这也可以减少手指对于气泡的遮挡，让用户更好的看清楚当前进度。

4.2 更合理的气泡长度变化规则

-“语音越长，气泡越长，so easy~”

气泡越长代表语音越长。但你可能没注意过，其实气泡长度是随着语音时长呈线性变化。这个本来运行良好的规则在加入了拖拽功能后却出现了问题。从灰度用户的数据来看，大部分用户的语音时长在10s以内。此时语音气泡较短，十分不易于进行拖拽。所以我们既需要短语音气泡变长，又要保证用户可以感知到气泡始终随着时长增长而变长。在气泡最大长度无法改变的前提下，必须改变原有的线性变化规律，转变为更精细的分阶段的曲线变化。

 

• [阶段1] 斜率逐渐增加的曲线。此阶段对应着短时长语音，也是用户的高频使用场景。因此该阶段气泡长度随语音时长的增长需要更加明显；
• [阶段2] 斜率逐渐减小的曲线。此阶段对应的长语音是低频场景，此时气泡长度随语音时长变化的反馈可以适当放缓；
• [阶段3] 达到气泡长度最大值，不再变化。此时为超长语音阶段，用户已经不需要通过气泡长度来判断语音时长。

运用更加精细的气泡长度变化规律，让用户的高频语音消息更好拖拽。

5、懂你所需，为你设计

-“结束了吗，有没有one more thing？”

至此，语音消息的改版设计似乎已经结束，但我们对于设计的追求不止于此。语音进度调节只是语音消息体验中的一个小小功能。我们希望通过这些精致贴心的体验设计，让用户产生一种感觉——QQ懂我。因为懂你，所以希望为你的沟通做更多事情。

关于语音消息，设计团队也在发散更多贴近用户真实生活的场景：

• 1）更加贴近场景的体验：未来我们是否可以利用传感器检测到用户所处的环境和状态，根据不同的环境和用户行为状态，确定这些消息是以语音还是文本显示；
• 2）更加丰富的语音表达：语音比文本承载了更多的情感信息，基于这个属性，我们能否通过特殊声音编辑、视觉化表达、手机触感等方式，帮助发送方传达更加丰富的信息；
• 3）无障碍化体验：对于视障人群、运动障碍人群、老年人群体来说，语音是很好的沟通选择。我们是否能够更进一步，通过语音指令更好的协助他们使用QQ…

做最懂你的语音消息，我们还在继续。

6、未来可期：最美的QQ正在路上

QQ新版语音气泡iOS上线当天喜提微博热搜。看到用户们的花式夸奖，我们的心情美滋滋。但同时网络上也出现了一些负面的评价，这些声音也在鞭策设计团队持续打磨语音消息体验。

一花一世界，一树一菩提。语音消息气泡改版只是体验升级的第一步，但它可以折射出整个QQ8.0版本所遵循的设计原则：降噪、生机和精致。沿着这些原则，我们依旧在打造最美QQ的路上奋力前行。

什么，你还没有下载手机QQ8.0？那你岂不是没法体验到史上最简洁的QQ页面，也不能发现底部tab小惊喜了？你更没法知道我们的语音消息马上就支持<(ˉ^ˉ)><(ˉ^ˉ)><(ˉ^ˉ)>和(>▽<)(>▽<)(>▽<)两个超赞功能（顶级机密，手动打码）。

附录：更多即时通讯产品的实践总结、感悟分享

《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》

《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》

《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》

《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》

《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》

《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》

《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》

《技术往事：“QQ群”和“微信红包”是怎么来的？》

《开发往事：深度讲述2010到2015，微信一路风雨的背后》

《开发往事：微信千年不变的那张闪屏图片的由来》

《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》

《一个微信实习生自述：我眼中的微信开发团队》

《首次揭秘：QQ实时视频聊天背后的神秘组织》

《为什么说即时通讯社交APP创业就是一个坑？》

《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》

《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》

《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》

《QQ的成功，远没有你想象的那么顺利和轻松》

《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》

《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》

《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？ 》

《那些年微信开发过的鸡肋功能，及其带给我们的思考》

《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》

《同为IM社交产品中的王者，QQ与微信到底有什么区别》

《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》

《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》

《社交应用教父级人物的张小龙和马化腾的同与不同》

《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》

《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》

《微信纯血鸿蒙版正式发布，295天走完微信14年技术之路！》

>> 更多同类文章 ……

（本文已同步发布于：http://www.52im.net/thread-2539-1-1.html）