系统容量评估，借助数据优化，过载保护由于是首次开展活动，我们缺乏实际的运营数据，一切都是摸着石头过河。所以从项目伊始，我们便强调对系统各个层次的预估，既包括了活动参与人数、每个 APP 界面上的功能点潜在的高峰流量值、后端请求的峰值、缓存系统请求峰值和数据库读写请求峰值等，还包括了整个业务流程和服务基础设施中潜在的薄弱环节。后者的难度更大因为很难量化。此前我们连超大流量的全链路性能压测工具都较缺乏，所以还是有很多实践的困难的。
在这里内心真诚的感谢开源社区的力量，在我们制定完系统的性能指标参考值后，借助如 wrk 等优秀的开源工具，我们在有限的资源里实现了对整个系统的端到端全链路压测。实测中，我们的核心接口在单个容器上可以达到 20,000 以上的 QPS，整个服务集群在 110,000 以上的 QPS 压力下依然能稳定工作。
正是一次次的全链路压测参考指标，帮助我们了解了性能的基准，并以此做了代码设计层面、容器层面、JVM 层面、MySQL 数据库层面、缓存集群层面的种种优化，极大的提升了系统的可用性。具体做法限于篇幅不在此赘述，有兴趣的读者欢迎交流。
此外，为了确保线上有超预估流量时系统稳定，我们做了过载保护。超过性能上限阈值的流量，系统会快速返回特定的页面结果，将此部分流量清理掉，保障已经接受的有效流量可以正常处理。
完善监控系统在线上运行过程中，我们需要对运行情况实时获取信息，以便能够对出现的问题进行排查定位，及时采取措施。所以我们必须有一套有效的监控系统，能够帮我们观测到关键的指标。在实际的操作层面，我们主要关注了如下指标：
借助系统的请求日志，观测服务接口的 QPS，接口的实时响应总时间。同时通过 HTTP 的状态码观测服务的语义层面的可用性。
结合总的性能指标以及各个模块应用层的性能日志，包括模块接口返回耗时，和应用层日志的逻辑错误日志等，判断系统的健康度。
尽量观测每个点到点之间的网络状态，包括应用服务器的网卡流量、Redis 节点、数据库节点的流量，以及入口带宽的占用情况。如果某条线路出现过高流量，便可及时采取扩容等措施缓解。
应用服务器的 CPU、Memory、磁盘 IO 状况，缓存节点和数据库的相应的数据，以及他们的连接数、连接时间、资源消耗检测数据，及时的去发现资源不足的预警信息。
对于关键的数据指标，在超过预估时制定的阈值时，还需要监控系统能够实时的通过手机和邮件实时通知的方式让相关人员知道。另外，我们在系统中还做了若干逻辑开关，当某些资源出现问题并且自动降级和过载保护模块失去效果时，我们可以根据状况直接人工介入，在服务不停机的前提下，手动触发逻辑开关改变系统逻辑，达到快速响应故障，让服务尽快恢复稳定的目的。
服务降级当服务器压力剧增的时候，如果某些依赖的服务设施或者基础组件超出了工作负荷能力，发生了故障，这时候极其需要根据当前的业务运行情况对系统服务进行有策略的降级运行措施，使得核心的业务流程能够顺利进行，并且减轻服务器资源的压力，最好在压力减小后还能自动恢复升级到原工作机制。
我们在开发红包系统时，考虑到原有 IDC 机房的解决方案对于弹性扩容和流量带宽支持不太完美，选择了使用 AWS 的公有云作为服务基础环境。对于第三方的服务，缺少实践经验的把握，于是从开发到运维过程中，我们都保持了一种防御式的思考方式，包括数据库、缓存节点故障，以及应用服务环境的崩溃、网络抖动，我们都认为随时可能出问题，都需要对应的自动替换降级策略，严重时甚至可手动触发配置开关修改策略。当然，如果组件自身具有降级功能，可以给上层业务节约很多成本资源，要自己实现全部环节的降级能力的确是一件比较耗费资源的事情，这也是一个公司技术慢慢积累的过程。
结束语以上就是我们整个系统研发运维的一些经验分享。对于这类瞬时大流量的秒杀系统而言，高可用是最大的优化目标，分而治之是核心的架构思想；防御式思维，假定任何环节都可能有弱点，能够提升系统的稳定性。另外，一定要加强监控，及时发现问题，解决问题。做好了如上几点，相信各位读者在应对类似问题时，也能更加全面的思考，少走一些弯路，做出更加优秀的系统。
这次春节红包活动，在资源有限的情况下成功抵抗超乎平常的流量峰值压力，对于技术而言是一次很大的挑战，也是一件快乐的事情，让我们从中积累了很多实践经验。未来我们将不断努力，希望能够将部分转化成较为通用的技术，沉淀为基础架构组件，去更好的推动业务成功。真诚希望本文的分享能够对大家的技术工作有所帮助。 |
