今天，我主要分享典型互聯(lián)網(wǎng)電商企業(yè)蘑菇街的發(fā)展歷程，和大家共同探討在發(fā)展過程中，我們是如何進行技術(shù)架構(gòu)和技術(shù)選型的，我認為總結(jié)下來就是四個字——順勢而為。
2015 年 1 月，我離開華為，來到了蘑菇街，主要負責平臺技術(shù)部。在過去的 12 年里，我絕大部分的經(jīng)歷和經(jīng)驗基本上集中于后端的技術(shù)架構(gòu)，如今主要專注于云計算領域。
蘑菇街是一個集時尚內(nèi)容和時尚電商于一體的網(wǎng)站。2011-2013 年是蘑菇街發(fā)展的第一個階段，主要做時尚導購內(nèi)容；2013-2016 年是蘑菇街發(fā)展的第二階段，隨著業(yè)務的發(fā)展和用戶的積累，我們開始投入大量的精力去做電商平臺，完成整個交易體系的建設；2016- 至今是蘑菇街發(fā)展的第三個階段，我們開始投入很大的精力去做直播技術(shù)，與能力超強的主播合作完成銷售體系的建設。
從去年年中開始，蘑菇街進入第四個階段。此時，蘑菇街的線上平臺和技術(shù)體系建設已經(jīng)比較完善，我們希望能把線上的技術(shù)經(jīng)驗賦能到線下，進入線下時尚內(nèi)容生產(chǎn)中，給用戶提供更高品質(zhì)、更具時尚感的產(chǎn)品。
實際上，我們整個技術(shù)的發(fā)展過程與業(yè)務發(fā)展相匹配的。
2011-2013 年，我們正在做內(nèi)容導入，業(yè)務架構(gòu)相對來說比較簡單，在此階段的團隊使命是技術(shù)支撐公司業(yè)務發(fā)展。
因為這時的技術(shù)棧相對比較簡單，整個架構(gòu)是一個單體架構(gòu)，所以我們的技術(shù)選擇策略是簡單直接、快速上手、快速開發(fā)。
2013-2016 年，我們開始做電商的交易體系。這時，我們需要建設相應的用戶體系，包括交易、支付、廣告、搜索、會員、店鋪等一系列內(nèi)容，于是 2016 年，我們的技術(shù)團隊快速擴充到了 800 人。
一方面是因為業(yè)務復雜度上升，另外一方面是因為當時整個業(yè)務的體量在高速發(fā)展，我們?nèi)?PV 可以達到三億，DAU 也突破了百萬，雙 11 大促時規(guī)模會更大。在此階段，我們的技術(shù)團隊使命是通過技術(shù)支撐公司業(yè)務高速發(fā)展。
因為我們的業(yè)務變得更加復雜，業(yè)務體量也變得非常大，單體架構(gòu)已經(jīng)沒有辦法滿足我們對業(yè)務靈活性的響應需求。
于是，我們開始全面轉(zhuǎn)向分布式架構(gòu)和技術(shù)，策略是架構(gòu)設計一定要體系化。我們根據(jù)整個業(yè)務領域進行了模塊劃分，設計了一些基礎的架構(gòu)，考慮最多的是高性能、高并發(fā)和大流量，這對于技術(shù)平臺的要求是非常高的。
我們將分布式架構(gòu)分為了三層，以最底層資源——基礎設施層為主，上面是分布式組件、核心業(yè)務組件層以及業(yè)務應用層。
2015 年，我們開始規(guī)劃分布式體系系統(tǒng)時，中臺的概念并沒有像現(xiàn)在這么火爆，業(yè)界也沒有太多很成熟、很完善的經(jīng)驗供我們借鑒。
但是最后我們發(fā)現(xiàn)，當我們立足于自己的問題或場景，一步步解決問題，最后做出來的樣子基本就是現(xiàn)在的技術(shù)中臺和業(yè)務中臺的樣子。
因此當我們需要做類似的架構(gòu)時，其實只要立足于我們原本的問題，按照正確的方式去做，到最后大家都是殊途同歸的。
技術(shù)團隊面臨的挑戰(zhàn)，尤其是在分布式架構(gòu)下，你會發(fā)現(xiàn)始終離不開三條：效率、穩(wěn)定和成本。
要解決效率問題，首先我們要建設一個 DevOps 體系。微服務實際上是將原先單體的架構(gòu)按照業(yè)務領域進行拆分，每一個細分的業(yè)務領域可能會單獨成立一個開發(fā)小組，用于開發(fā)和維護一些應用。接著，開發(fā)團隊需要與產(chǎn)品、運營部門等做大量的溝通和交流，還需要考慮測試、運維等一系列相關(guān)事宜。因此，想要解決效率問題，不僅在技術(shù)上會面臨挑戰(zhàn)，還會帶來很多跨團隊協(xié)作問題。
在跨團隊協(xié)作過程中，你會發(fā)現(xiàn)項目團隊內(nèi)部也劃分了不少團隊，在這種跨職能或跨組織架構(gòu)協(xié)作的情況下，如何高效的協(xié)作和配合是一件非常重要的事情。所以，我們需要想法設法解決跨團隊的協(xié)作、溝通和管理的問題。
于是，我們做了一些自動化的流水線和幾個關(guān)鍵點的管理機制，以便于打通在流程環(huán)節(jié)中的持續(xù)交付通道。除此之外，我們還做了一些管理工具，比如統(tǒng)一管控平臺等等。
在整個過程中，我們總結(jié)出了三個關(guān)鍵原則：
第一，標準化，避免架構(gòu)失控。我們可以嘗試很多技術(shù)，創(chuàng)造一個開放的氛圍，但是在項目落地時，基本上只會選擇一種主流的框架和解決方案，在保證高效的協(xié)作能力的同時，還要避免架構(gòu)失控。
第二，以應用為核心的架構(gòu)體系。我們整個架構(gòu)是以應用為核心，它拆分出來的功能點一定要對應到應用上，以便于跟蹤、評估和管理。
第三，自上而下的推進機制。當團隊間不能達成一致時，我們需要采取自上而下的推進機制。在自上而下推進的過程中，我們需要一個至少是技術(shù) VP 或者最高的技術(shù)領導者作為決策者，他需要決定整個架構(gòu)體系的標準。在這種情況下，大家會保證步調(diào)一致，達到最高的效率。
穩(wěn)定是所有工作的前提，現(xiàn)實中，很多時候我們會遇到不可預見的情況發(fā)生，比如突然爆發(fā)的流量，這是很難提前預測的。這時，我們不是應該保證系統(tǒng)不出問題，而是應該保證系統(tǒng)在出現(xiàn)異常的情況下仍可以正常工作。
不管是電商，還是社交類軟件，我們所做的工作只有一個核心點——面向極端的場景。在正常情況下，系統(tǒng)一般都不會出現(xiàn)太大的問題，但是在非常極端的業(yè)務場景下，各類問題就會集中爆發(fā)，原來很小的問題，也會被放大，甚至形成雪崩效應，因此我的建議是，如果要做穩(wěn)定性建設，先找準業(yè)務將要面對的極端場景會是什么，比如電商業(yè)務的大促場景、社交類軟件的熱點事件等等，這樣才能做到有的放矢。
而穩(wěn)定性保障中，非常關(guān)鍵的一點是容量評估。比如在雙十一時，我們會對整個用戶模型進行評估，估算參與用戶數(shù)量、用戶消費金額、優(yōu)惠條件等等，根據(jù)歷史數(shù)據(jù)進行統(tǒng)計，統(tǒng)計出來以后，我們將會按照這個模型進行壓測，模擬流量是否足夠支撐。同時，在壓力測試時，會引入限流降級，監(jiān)控等穩(wěn)定性保障手段。
我們都知道，有時越到技術(shù)做得越深入，投入成本會越高，但獲得的收益可能會越小，因此就涉及到了投入、產(chǎn)出，成本取舍的問題。
舉個例子，為了應對雙十一，我們前幾年需要投入幾千萬采購設備擴充容量。峰值過后，大部分容量都是閑置的，這屬于極大的浪費。同時，我們要在基礎架構(gòu)上，投入巨大的精力解決開源軟件的 bug、解決高壓力場景的突發(fā)問題等等。最后，導致我們在基礎架構(gòu)上的投入越來越大。
當我們在這方面投入的資源和精力越來越多時，會導致我們無法集中精力在業(yè)務發(fā)展上。所以，我們開始反思到底是在技術(shù)上繼續(xù)做得更深，還是把更多精力放在業(yè)務上，專注解決業(yè)務問題。
2016 年，我們準備開始做直播業(yè)務時，再次遇到了這個難題。我們調(diào)研發(fā)現(xiàn)，直播技術(shù)需要很多專門人才，比如視頻編解碼專業(yè)的人才；同時，我們也沒有資源做很強大的基礎架構(gòu)，比如建設全國的 CDN 節(jié)點，這該怎么辦？最后，我們決定與公有云合作，找專業(yè)廠商為我們提供整套方案，后來在云廠商的支持下，我們的直播業(yè)務在一個月左右就快速上線了，而且現(xiàn)在已經(jīng)成為我們非常關(guān)鍵一塊業(yè)務，如果當時我們沒有爭分奪秒做下來，這塊業(yè)務可能就不存在了。
當我們面對很多在基礎架構(gòu)和基礎設施上的問題時，通過我們在直播領域與云的合作，讓我們再次感受到云計算技術(shù)的力量。
因此我們開始思考，我們應該如何利用好云計算。我們仔細分析了當時整個云計算的發(fā)展現(xiàn)狀，發(fā)現(xiàn)很多之前遇到的專業(yè)問題，其實早已被云廠商解決了。隨著云技術(shù)架構(gòu)的完善，很多企業(yè)面對的基礎架構(gòu)問題在云上已經(jīng)早已不是問題。
同時，現(xiàn)在很多新技術(shù)都是在云上演進出來的，已經(jīng)很少有跟云不相關(guān)的技術(shù)了，所以，云必然是未來的趨勢。2017 年，我們決定將整個系統(tǒng)遷移上云，將我們更寶貴的精力專注在業(yè)務和業(yè)務架構(gòu)上。
于是，我們的整個技術(shù)架構(gòu)重心開始隨之改變。之前，我們做電商面對的是大流量，高并發(fā)，需要花費很大精力建設技術(shù)平臺，但是當我們的業(yè)務發(fā)展起來后，上到云上了，我們逐步將精力轉(zhuǎn)向產(chǎn)品和運營團隊，加大我們對線下生產(chǎn)環(huán)節(jié)的支持，打磨我們的產(chǎn)品和運營能力，這才是我們公司的核心競爭力。
這時，技術(shù)團隊的職責就變成充分利用云計算，為業(yè)務提供更多的可能性。
在當前的技術(shù)高速發(fā)展背景下，在探索新技術(shù)和新業(yè)務過程中，技術(shù)人員的優(yōu)勢就體現(xiàn)出來了。因為技術(shù)人員對新技術(shù)有一定的敏感度，他們會在第一時間接觸和體驗到最新的技術(shù)，從而聯(lián)想到很多技術(shù)層面的解決方案。但是對于沒有技術(shù)背景的人員，當他們不了解技術(shù)時，就只會想著產(chǎn)品功能和運營的需求，不會想到用什么樣的端到端的技術(shù)解決方案。我相信，未來做技術(shù)的同學一定會有更大的發(fā)展空間。
最后，我總結(jié)一下蘑菇街的整個發(fā)展過程。我們從最初的單體架構(gòu)，到后來的分布式架構(gòu)，最后基于公有云的基礎架構(gòu)，整體遷移上云。在這個過程中，你會發(fā)現(xiàn)我們做的很多事情是立足于我們當下所遇到的問題，立足于實際場景，踏踏實實解決每一個問題，結(jié)合業(yè)界趨勢找到最佳解決方案，四個字總結(jié)——順勢而為。
感謝大家的聆聽，謝謝。
編者注：趙成老師的干貨分享是不是很精彩呢？是不是還沒有看夠呢？下載「極客時間」APP 訂閱趙成的運維體系管理課程吧，帶你直擊運維的本質(zhì)！
美篇 首席架構(gòu)師 張超 | DataPipeline CTO 陳肅
AfterShip CTO 洪小軍 | 知道創(chuàng)宇 CTO & COO 楊冀龍
UCloud CEO 季昕華 | 編程貓 CTO 孫悅
喜馬拉雅 CTO 陸棟棟 | 有贊 CTO 崔玉松
（點擊文字查看文章內(nèi)容）
聯(lián)系客服
