通过「足记」紧急技术支持过程看设计和运营一款优秀的移动社交App应该注意哪些技术问题

「足记」是 青云QingCloud 的用户，其后端服务架构在 QingCloud 公有云平台上。在大片功能上线之前，「足记」只使用了主机、路由器、公网 IP 及带宽等少量基础资源构建了一个相对简单的后端架构。在两周前「足记」用户数量和并发访问数爆发式增长，短短几天时间内排名升至 App Store 免费榜的第一名。我们同时也获知了在突发的高并发访问压力下，「足记」的服务体验下降，技术支撑出现严重困难。在同「足记」的技术团队电话沟通之后，QingCloud 派出了熟悉移动社交技术的系统工程师、网络工程师和IOS开发工程师以最快的速度赶到上海，进行问题诊断和技术支持。

第一批抵达的工程师首先快速了解情况，定位主要技术问题，随后制定了紧急技术支持工作的目标与计划。QingCloud 前后两批共 4 位工程师采取了一系列行动在短时间实现了系统层面和数据层面的扩展，解决了服务可用性问题；调整代码，提高Web 程序性能；构建完整的测试环境，创建资源监控和各种管理运维工具；修复各种业务 bug，优化 App客户端代码。

以下是 QingCloud 技术支持过程概况：

1. 了解情况

首先我们详细了解了业务规模和增长情况：「足记」在一个星期的时间内，网络流量升至 300M 左右；每秒请求数（qps）达到 3,000 ，每天 PV 接近 2 亿；新增用户每天将近 200 万，日活跃用户数（DAU）超过 300 万，累计用户超过 1,000 万并保持继续增长。

其次我们体验并询问了服务的主要问题表现在：高峰期服务响应超时甚至不可用，低峰期请求处理缓慢，用户的直观感受就是经常刷新不了页面。同时为了应急采取了服务降级的手段，部分功能不可用；新功能开发已经停止。

根据上述情况，我们了解到「足记」最迫切的需求就是在短时间内调整系统架构，提高业务架构的可扩展能力。

2. 定位问题

QingCloud 工程师在了解情况后迅速收集和分析了所有能采集的数据，包括主机资源负载、数据库慢查询、请求日志、程序日志、以及 QingCloud 平台上可以监控到的其他数据，并根据具体数据诊断问题。

通过数据分析，我们发现了两个关键问题：一是应用服务器 CPU 占用率偏高， 10 台Web服务器的 CPU 利用率都达到80% - 90%，急需水平扩容；二是数据库慢查询（耗时比较长的数据库查询语句）非常多，没有有效利用缓存，导致数据库压力过大、处理效率低。

3. 制定目标和步骤

• 先解决紧急问题，尽快恢复服务的可用性，改善用户体验，为后续的优化争取时间。尽管这种打补丁的工作很可能同最优方案相违背，但是争取留住用户仍是第一需求；

• 用最小代价解决最大问题：进行资源扩容和架构调整，解决数据库瓶颈问题；

• 开放全部功能，并恢复正常功能迭代；

• 长期业务架构调整。

4. 解决问题

• 业务层面的扩展

• 将Web 服务器进行了水平扩容，将应用服务器数量扩充了三倍；

• 利用云的弹性，制作自有映像和部署脚本，快速创建新的主机。

• 网络层面的扩展

• 进行网络架构调整，增加新的私有网络和 Web 服务器；

• 引入公网 LB （负载均衡器）将流量从入口处就分担到多个私有网络的多台服务器上；

• 将处理比较慢的请求调用隔离到单独的服务器上处理。

• 数据层面的扩展

• 构建数据库slave集群，从单节点 MySQL 数据库转变为一主多从的数据库集群；

• 创建内网 LB，对 slave 集群做负载均衡，将数据库读请求分散到多个slave节点上；

• 根据功能做数据库读写分离，将尽可能多的读请求切换到 MySQL slave 集群进行查询；

• 解决数据库瓶颈问题

• 对数据库参数调优，SQL 语句优化，消除 join 查询和没有使用索引的查询（同其他工程师共同完成）；

• 引入 Redis 数据库，将业务中对一致性要求不高又要频繁读写的数据结构（如计数器和列表）从 MySQL 迁移到 Redis，减少关系型数据库压力，提高查询效率；

• 进一步增加缓存，降低缓存粒度，降低失效率，提高命中率。

• 代码的优化

• 代码调整，梳理业务逻辑，尽量减少复杂逻辑计算，改善应用程序性能，提高单机及集群的处理效率；

• 修复服务端代码中的 bug；

• 进行 App 客户端代码优化，解决崩溃、卡死等问题。

• 测试和部署流程的优化

• 构建完整的测试环境，配置专用于测试的主机映像， 测试环境将用于改善上线流程，将 bug 带来的程序故障降到最低；

• 配置 SSH 密钥 、VPN 、AutoScaling 等运维管理工具；

• 为所有资源添加监控告警。

经过整整一周夜以继日的艰苦工作，「足记」在系统能力快速扩充之后实现了访问量的平稳增长（流量日均增长 30% 左右），并在随后逐步改善了服务体验。目前，各项功能已经恢复，客户端崩溃与卡死情况基本消除。

我们将这次非常规的紧急技术支持过程记录下来，目的是为了同更多的移动应用开发者分享产品开发、架构设计以及上线运维的经验；同时也是为了澄清在「足记」业务压力过大、服务响应出现瓶颈的时候，某些将问题简单归结为服务器压力过大的不专业论断。

就本次事件来看，不能想象如果一款迅速爆发的移动应用搭建在物理资源上如何能够短时间实现系统水平扩展。即便是搭建在资源响应不够迅捷、网络功能（私有网络、路由器配置、负载均衡器功能等）不够强大、不具备成熟数据库服务的云服务上，也无法在短短的十几个小时内在不中断业务的情况下快速实现架构调整、系统扩展和流量分担，承载起每分钟超过 180,000 次请求的突发业务压力。

在同足迹团队并肩战斗的这段时间里，我们深入地了解一款社交移动应用在各个层面面临的挑战，并总结了一些经验分享给所有正在或打算进行应用开发和创业的小伙伴们：

1. 重视架构设计，尤其要提前考虑系统、数据、网络、应用等各个层面的可扩展性，以具备在业务稳定增长甚或突然爆发的情况下快速扩展的能力；同时注意设计负载均衡机制；

2. 善于使用云端的资源监控和自动运维工具，及时根据业务变化调整资源数量；

3. 注意SQL语句和数据结构的优化，因为移动社交最核心的事情就是数据的可扩展性；

4. 充分利用缓存，并细化缓存粒度，以最大程度降低数据库的访问压力；

5. 编写高质量的代码，注意代码的抽象和分层，减少复杂的业务逻辑，这样在功能逐渐复杂的时候不仅可以有效提高单机和集群的处理能力，还能保持清楚的业务逻辑，尽量减少bug；

6. 在功能上线之前一定要重视测试，运营过程中要持续进行重构和优化；

7. 工程师要尽早参与产品需求讨论，从技术角度调整需求的可行性；

8. 选择云服务的时候要注意考察以下方面——

• 充分的弹性和极致的资源响应速度，是支撑系统快速扩展的基本保障；

• 健全的监控告警功能及强大的运维管理工具（如可以帮助大家自动调整资源规模的省钱大招 AutoScaling）是保障资源规模与业务规模匹配的有效手段；

• 完整的网络功能：是否支持私有网络？路由器、负载均衡器等组件是否足够完善与强大？多个私有网络之间是否可以便捷地连通？内网通信是否够快？

• 利用云平台提供的数据库和缓存服务可以显著降低部署和运维的复杂度。

我们在这里用尽量简练的语言概括了技术支持的经过，但是实际现场的情况是时间紧、任务重、人手有限。每一个数据的监控、收集、分析，每一行代码的检查和调优，每一个业务逻辑的梳理，每一次扩容和迁移的操作都涉及到大量的具体工作。尤其是代码层面更是非常复杂，需要深入了解业务，逐行查询，而且经常是修改 bug 的同时又发现更多的 bug。因此我们更加觉得将这次的经验分享可以帮助大家提前考虑到未来将会面临的挑战，做好基础工作。

希望这篇内容能够帮到更多的人，相信这也是「足记」团队的愿望。

最后我们想说，经历了这次考验我们更加坚信云服务不是简单的虚拟化资源提供，更要充分保障资源的可靠性、安全性、性能、响应速度与弹性，因为云平台上承载着所有用户的业务与梦想。我们很高兴能够守护着「足记」的成功，我们也会继续日夜兼程，用扎实的技术守护每一个用户的成功。

期待「足记」带给我们更多的惊喜体验。

- FIN -