魅族電商運維之路

文章出自：聽雲博客

       電商行業飛速發展，電商事故絡繹不絕，但仍是有很多人熱衷於電商行業，投身於電商行業。

       今天咱們就圍繞魅族電商運維這一塊的內容，來作如下四大塊的分享：

1. 業務背景

2. 搶購系統架構

3. 一次大型活動須要準備什麼

4. 迅速發展的電商業務帶來的思考

       在分享以前我還想給你們看一組數據：

08年魅族電商平臺上線

12年9月第二次改版，MX2在商城平臺首發

13年9月MX3預訂數過百萬

14年6月商城搶購PV過億

14年9月MX4發佈預定用戶數過千萬

15年初註冊用戶數過二千萬

15年6月魅藍note2搶購當天PV過三億

15年完成2000萬臺魅族手機銷售量

       因而可知，魅族的電商也是在飛速發展中。

業務背景：

       爲何要分享這個跟技術無關的內容呢？在我看來，若是一個業務運維對本身手裏的業務不是特別瞭解的話，就算技術再好，也只是一介莽夫。就像一個醫生，他不能對身體的整個運行狀態有一個瞭解的話，那麼你可能看到的是感冒，實際上感冒是由肺熱引發的，咱們永遠不能藥到病除，不能找到根源問題，下次還會出現一樣的問題。

• 多渠道

           官網、天貓、京東、蘇寧、微信……

• 運營活動

           搶購、優惠券、M碼、0元秒殺…….

• 流量導入

           QQ空間、微博、微信、百度……

• 業務邏輯

           ……

    這幾點，咱們主要看運營活動與流量導入。執行一次營銷活動，咱們要考慮的是，流量從哪裏來？來多少？營銷活動是哪一類？優惠活動仍是0元秒殺？等等......

    例如一次0元秒殺活動和優惠券活動，一樣都是從微博導了500萬用戶過來的話，相比之下，固然是0元秒殺活動的流量更大，轉化率也更大。這些經驗，都是在不少次活動總結下來的，包括流量來源。例如咱們一樣是導500萬的流量，哪一家的流量到咱們的商城，用戶轉化率，訂單轉化率更高呢？這些都是值得咱們去考慮去探索的，這些是技術外的事情。還有一點也值得一說，所說的業務邏輯也就是業務直接的關聯性。假設其中一個環節出了了集羣卡頓、處理效率低下，咱們首先想到的是：這個集羣掛了，會不會致使整個業務癱瘓？這個集羣掛了？會產生哪些蝴蝶效應？目前正有哪些業務依賴於這個集羣？若是這些你都答不上來的話，那麼首先趕忙對這個集羣作擴容。再好好去分析，這個集羣的上游和下游，搞清楚壓力來自哪裏。咱們該怎麼杜絕後患，一勞永逸才好。

搶購系統架構：

 

       一、DNS採用的是DNSPOD智能分流，採用了組合式的分流措施。

           地區+運營商+地區運營商的模式

       二、SLB的RS，爲集羣單獨全部。集羣互不影響。每一個集羣按照上面DNS的解析方式去解析

       三、後端的Redis爲主從模式，數據是直接寫到Redis，數據不落地。Proxy作分發，每組Proxy互爲主備。Php經過算法來對Redis進行讀或寫。

       前面三點，是咱們能看到的技術層面的東西。那咱們架構這麼搭建，就必定能作一個好的搶購架構嗎？當時不是，咱們要考慮三點：高可用、高擴展以及咱們的高性能。高可用和高擴展，在集羣中都已經體現了，咱們沒有單點故障，有可容錯性，有災備，有Openresty作流量清洗、過載保護等等。那麼高性能咱們是怎麼作的呢？

       咱們以前也本身作過性能優化，對架構，對代碼等等。架構方面還好，定好的不會輕易去改變。那麼代碼是實時在產生，SQL也是實時在產生，咱們如何去監控這些性能，以及如何優化呢？那咱們就招人作吧。在招人的過程當中，也面臨了不少問題，如今性能優化的人才稀缺，能力良莠不齊，咱們放棄了本身招人本身去作的想法，由於就算招到了人，能不能作好？要花多久時間才能作好？考慮下來，咱們決定外包！作APM的產商五花八門，國內的國外的都有，各有噱頭。篩選的過程就不詳說了，最後咱們選擇的是聽雲APM。

       聽雲APM優勢不少，我特別看中的是：

       一、監控內容豐富且詳細

       二、優秀及時的售後服務。如今使用半年下來，咱們商城的總體效率提升了至少20%，且很好的下降了bug率和系統故障率。把擅長的事情作好，不擅長的事情咱們外包給第三方去作，不只省下人力成本也解決公司HC的問題。

       一次大型活動須要準備什麼：

• 實戰演練+壓測

• 數據監控

• 數據彙總與分析

• 性能優化

       首先必定要通過壓測。那麼壓測的量怎麼算呢？那麼就根據我們上文說的，根據活動類型和流量來源去算出大概的量，咱們再乘以2倍去作壓測。

        在壓測的過程當中，咱們須要利用到聽雲的APM，一邊壓測咱們一邊看監控，MYSQL端，Redis端，代碼層，看看都有什麼性能方面的問題。如圖所示：

       因爲數據隱祕性，沒有展現詳細的性能數據。可是你們仍是能看的出來，性能方面的種種問題，其實最好用的是關鍵應用過程。咱們將核心功能的過程輸入到監控裏面去，展現的數據更爲精細和完整。咱們本身作完一系列優化後，最後還能夠call咱們的聽雲工程師來提供更爲專業的幫助。那麼這是一個過程，壓測 -》 數據監控 –》 數據彙總與分析 – 》性能優化。也是一個循環，咱們能夠一直去作壓測，直到壓到咱們滿意爲止。壓測能夠辛苦咱們本身的測試工程師，也能夠利用聽雲Network功能來模擬交易過程，並制定用戶數，也能達到壓測的目的。OK，那麼壓測經過以後，即將要到來的大型活動，你還怕嗎？

       迅速發展的電商帶來的思考：

       咱們的架構其實作到如今，仍有不少須要完善的地方。咱們也經歷了不少事故，一次一次的吸收經驗，再多點思考，再慢慢調優，不少日日夜夜。

       其實從上文就能看到不少思考的內容。

       系統中有沒有單點故障？能不能有很好的容錯性？一個集羣掛了會不會致使整個交易鏈路癱瘓（電商系統最重要的就是保證交易鏈路通暢）？大流量來了我能不能及時去對個人集羣擴容？流量清洗、用戶、黃牛的控制有沒有保證？一千萬的服務器，我有沒有發揮該有的效率，性能指標能不能達標？

       這是一條漫長的探索之路，業務不一樣，架構不一樣，所面臨的難處也會有所不一樣。須要咱們本身內部優化，也須要及時的藉助外力來完善咱們的系統。世上無難事只怕有心人。

       願各位的系統，永不宕機！

       原文連接：http://blog.tingyun.com/web/article/detail/397