注册
登录
「足记」是 青云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. 解决问题
经过整整一周夜以继日的艰苦工作，「足记」在系统能力快速扩充之后实现了访问量的平稳增长（流量日均增长 30% 左右），并在随后逐步改善了服务体验。目前，各项功能已经恢复，客户端崩溃与卡死情况基本消除。 我们将这次非常规的紧急技术支持过程记录下来，目的是为了同更多的移动应用开发者分享产品开发、架构设计以及上线运维的经验；同时也是为了澄清在「足记」业务压力过大、服务响应出现瓶颈的时候，某些将问题简单归结为服务器压力过大的不专业论断。 就本次事件来看，不能想象如果一款迅速爆发的移动应用搭建在物理资源上如何能够短时间实现系统水平扩展。即便是搭建在资源响应不够迅捷、网络功能（私有网络、路由器配置、负载均衡器功能等）不够强大、不具备成熟数据库服务的云服务上，也无法在短短的十几个小时内在不中断业务的情况下快速实现架构调整、系统扩展和流量分担，承载起每分钟超过 180,000 次请求的突发业务压力。 在同足迹团队并肩战斗的这段时间里，我们深入地了解一款社交移动应用在各个层面面临的挑战，并总结了一些经验分享给所有正在或打算进行应用开发和创业的小伙伴们：
我们在这里用尽量简练的语言概括了技术支持的经过，但是实际现场的情况是时间紧、任务重、人手有限。每一个数据的监控、收集、分析，每一行代码的检查和调优，每一个业务逻辑的梳理，每一次扩容和迁移的操作都涉及到大量的具体工作。尤其是代码层面更是非常复杂，需要深入了解业务，逐行查询，而且经常是修改 bug 的同时又发现更多的 bug。因此我们更加觉得将这次的经验分享可以帮助大家提前考虑到未来将会面临的挑战，做好基础工作。 希望这篇内容能够帮到更多的人，相信这也是「足记」团队的愿望。 最后我们想说，经历了这次考验我们更加坚信云服务不是简单的虚拟化资源提供，更要充分保障资源的可靠性、安全性、性能、响应速度与弹性，因为云平台上承载着所有用户的业务与梦想。我们很高兴能够守护着「足记」的成功，我们也会继续日夜兼程，用扎实的技术守护每一个用户的成功。 期待「足记」带给我们更多的惊喜体验。 - FIN - |
