互联网产品经理的三大烦恼，你有吗？
随着互联网的迅猛发展，互联网应用在逐步改变着社会，但其自身也面临着诸多挑战。例如双十一抢货的硝烟，春运抢票的战场，让一拨拨的产品经理提心吊胆，殚精竭虑。今天，本文抛出了三个问题，它们或许是每个互联网应用产品经理都会面对的（找不到解决所有挑战的银弹，那么就从一部分入手吧）：
- 如何适应高峰时期骤然上升的用户请求，确保极端环境下应用可以稳定地为用户提供服务？
- 如何在平峰时期缩减不必要的资源开销，以节约产品自身的运维成本？
- 如何在7*24环境中持续不断的保证应用可靠运行？
开放----互联网应用区别与传统企业应用的一个重要特性。而两个维度的开放便为互联网应用造就了上述三个无法逃避的问题。
- 开放的空间：传统企业应用的受众用户边界在互联网应用中逐渐模糊，整个互联网的所有终端接入都可能成为应用的潜在客户。此时，产品经理面临一个抉择：他希望自己的产品能拥有足够多的用户群，但产品上线初期又没有足够的成本进行投资（收益与风险永远是投资不变的主题）。
- 开放的时间：互联网应用竞争时，利用敏捷方式上线赢得的是时间优势。然而，这种方式增加了未来时间轴的不可知性。此时，产品经理又面临一个抉择：他希望日后能通过一系列的活动计划壮大自己的应用，但上线初期又没有资源和条件来规划日后的每一个活动。
- 此外，在的空间与时间维度下，产品在保证了迎接新用户的能力前提下，要维系老用户的信任，7*24的在线服务能力也是一个非常有效的手段（如果竞争对手具备此能力，那么自己要如何应对）。
场景一：偶发的高用户请求量
1、某应用正常情况下在云平台上通过三个服务节点的集群即可满足日常请求流量的访问需求。
2、运营人员安排了一场促销活动，导致活动期间用户访问量急增50%，原来三个服务节点已无法承担正常的请求处理任务。此时，弹性扩展可以为应用自动增加若干个节点资源，以满足增长的访问请求处理需求。
3、促销活动结束后，用户的访问量逐步回落了30%。此时，五个节点出现了一定的资源浪费。由于最后访问量维持在最初状态的120%左右，正常估算范围内，四个节点足以承受如此压力。此时，弹性收缩可以为应用自动减少多余的节点资源，以节约应用的资源使用成本。
如此看来，前两个问题已经被恰如其分的解决了。
场景二：偶发故障
1、某应用正常情况下在云平台上通过三个服务节点的集群可满足常规请求流量的访问需求。假设每个节点的可靠性是90%，则当前集群的可靠性可达99.9%。
2、某一时刻，Node3节点出现未知故障停止工作，此时整个集群的可靠性便从原来的99.9%下降至99%。
3、故障自愈机制可以弹性扩展一个服务节点，用于替换出现故障的Node3节点。投入工作的有效节点依然是三个（Node1、Node2、Node4），系统的可靠性恢复到99.9%。最后，将失效节点（Node3）移除。
可以发现，新的集群环境与原始的集群环境是等效的，弹性又为我们解决了一个大问题。
产品经理是否已体会到云平台真正为我们的应用提供了切实的帮助了呢？看来我们的产品不再是为了云而云了！
平复一下心情，我们再看一种场景（产品经理们就把这当成是买二送一吧^_^）
场景三：灰度升级
1、某应用版本V1正常情况下在云平台上通过三个服务节点的集群对外提供服务。
2、当运维需要为应用进行V2版本升级时，可保持原节点部署不变的情况下，扩展部署了V2版本应用的Node4和Node5节点。然后通过前置的SLB接入层来路由不同版本的请求。
3、当V2版本的测试趋于稳定后，从SLB上调节不同版本的访问流量和访问允许控制，逐步收缩V1版本的占用资源，扩展V2版本的占用资源，最终将请求完全切换至V2版本上来。
这不就是我们经常听到的灰度升级么？原来弹性还能为它服务！
如果要弹性做一个总结，有四个字非常合适：按需分配。本文旨在为互联网应用产品经理解决三个问题，供产品经理在规划自身产品时进行参考，起一个抛砖引玉的作用吧。
