網際網路產品經理的三大煩惱，你有嗎？
隨著網際網路的迅猛發展，網際網路應用在逐步改變著社會，但其自身也面臨著諸多挑戰。例如雙十一搶貨的硝煙，春運搶票的戰場，讓一撥撥的產品經理提心吊膽，殫精竭慮。今天，本文丟擲了三個問題，它們或許是每個網際網路應用產品經理都會面對的（找不到解決所有挑戰的銀彈，那麼就從一部分入手吧）：
- 如何適應高峰時期驟然上升的使用者請求，確保極端環境下應用可以穩定地為使用者提供服務？
- 如何在平峰時期縮減不必要的資源開銷，以節約產品自身的運維成本？
- 如何在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版本上來。
這不就是我們經常聽到的灰度升級麼？原來彈性還能為它服務！
如果要彈性做一個總結，有四個字非常合適：按需分配。本文旨在為網際網路應用產品經理解決三個問題，供產品經理在規劃自身產品時進行參考，起一個拋磚引玉的作用吧。