对于任何一款互联网应用而言，流量都是非常宝贵和至关重要的, 大家都在渴望流量，甚至花高昂的价格购买流量。这就引来了一个关键问题，从技术的角度，如何让流量能顺利在应用中完成生命周期，创造对应的价值，避免陷入流量旋涡？今天我就根据这些年的实战经验，和大家做一个分享，供大家参考。

系统评测

谈到系统优化，很多同学一上来就谈到了前后端分离、系统拆分、引入各类中间件，分库分表等等。这些方案没错，问题就在于这些都是“正确的废话”。如果我们有足够的人力资源，足够的开发时间，我们都可以搭出一个还不赖的架构来。

所以，对于一个创业或者小团队而言，第一步，决不是先改造，而是清楚自己目前的系统能承受的压力是多少，瓶颈在哪里。然后根据自身情况，进行必要的“小手术”。

对于全链路的压力/性能测试，我这里就不花篇幅讲了，说真的，用好Jmeter就足够了，有资源的朋友，可以基于Jmeter做一些二次开发。在这个网络发达，信息爆炸的时代，基本上对于每个技术点或者问题，都可以迅速地获取到大量资料。关键是对于技术的实现原理和问题的解决方案。

系统报警

摸清楚当前系统的能力后，很多同学认为，第二步就是赶紧修复或者改进服务中的弱点。实际上不然，而是将修复和报警放在一起做，避免修复到一半的时候，流量来了，却不知道问题在哪里。

服务器运行正常的情况下，其各项监控指标基本稳定在一个特定水平，如果这些指标超过某个阈值，就意味着系统可能将要出现故障，监控管理系统可以配置报警阈值和值守人员的联系方式，报警方式除了邮件，必须配置手机短信（切忌“单点”，一个报警点至少有2个以上的报警接收人）。

报警消息务必做到清楚，标明可能的原因和当前的出发数字，似是而非的报警信息，只会“麻木”大家。

流量转移

现在我们有报警了，那么下一步需要什么？就是线上的防御能力，保证线上系统出问题后，为紧急修复赢得时间。

提升防御能力的方法有哪一些？主要可以分为流量转移和服务降级。

我们先说流量转移

系统中，务必要有转移流量的能力，特别是应用访问失败的时候，监控系统能根据情况，做到主动触发。

典型的一个例子，就是redis集群的哨兵模式，可以将这个思路应用到其他系统中。

哨兵模式的流程如下：

• 监控：哨兵不断的检查master和slave是否正常的运行。

• 通知：当监控的某台Redis实例发生问题时，通过API通知运维工程师和我们的应用程序。

• 自动故障转移：如果一个master不正常运行了，哨兵可以启动一个故障转移进程，将一个slave升级成为master，其他的slave被重新配置使用新的master，并且应用程序使用Redis服务端通知的新地址。

• 配置提供者：哨兵作为Redis客户端发现的权威来源，客户端连接到哨兵请求当前可靠的master的地址。如果发生故障，哨兵将报告新地址。

服务降级

上面说了流量转移，但是流量转移不能解决所有的流量问题，所以我们同时需要引入服务降级。

服务降级是指网站为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能正常访问的一个手段。很多电商平台的年度促销活动就属于突然爆发的非常规访问高峰，在高峰访问解决，我们可以关闭一部分非核心功能，如评价、确认收货等功能，保证交易链路的正常运行。

网站在动态计算基础之上实现自动服务降级，是系统柔性架构的理想状态：监控系统实时监控所有服务器的运行状况，根据监控参数判断应用访问负载情况，如果发现部分应用负载过高，而部分应用负载过低，就会适当卸载低负载应用部分服务器，重新安装启动部分高负载应用，使应用负载总体均衡，如果所有应用负载都很高，而且负载压力还在继续增加，就会自动关闭部分非重要功能，保证核心功能正常运行。

线上演练

以上的工作完成后，需要执行最重要的一环，就是线上的演练，对以上所做的工作进行全流程的验证。有两个目的：

1. 对团队配合的演练，一次线上的大流量处理，一般会涉及到技术团队的多个小组，运维和后端开发，以及非技术团队（线上运营、客服）。在演练之前，需要约定明确的分工，确定线上的执行手册。

2. 系统的演练，毫无疑问，各类报警是否能正常触发，系统防御是否奏效，有没有遗漏的场景，工具是否有bug...都是需要在线上实战过后，心里才能做到有数。

最后，做好流量规划，把对流量的管理放入产品迭代之中，系统和业务才会有“神同步”。

                                          -END-

相关阅读

如何做高可用的架构设计

实时日志分析系统的基本架构

服务端流量控制的可行性方案

描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓