互聯網技術演進的模式

因爲各行業的業務發展軌跡並不徹底相同，沒法給出一個統一的模板讓全部的架構師拿來就套用，所以我以互聯網的業務發展爲案例，談談互聯網技術演進的模式，其餘行業能夠參考分析方法對本身的行業進行分析。

互聯網業務千差萬別，但因爲它們具備「規模決定一切」的相同點，其發展路徑也基本上是一致的。互聯網業務發展通常分爲幾個時期：初創期、發展期、競爭期、成熟期。

不一樣時期的差異主要體如今兩個方面：複雜性、用戶規模。

業務複雜性

互聯網業務發展第一個主要方向就是「業務愈來愈複雜」，咱們來看看不一樣時期業務的複雜性的表現。

1. 初創期

互聯網業務剛開始通常都是一個創新的業務點，這個業務點的重點不在於「完善」，而在於「創新」，只有創新才能吸引用戶；並且由於其「新」的特色，其實一開始是不可能很完善的。只有隨着愈來愈多的用戶的使用，經過快速迭代試錯、用戶的反饋等手段，不斷地在實踐中去完善，才能繼續創新。

初創期的業務對技術就一個要求：「快」，但這個時候卻又是創業團隊最弱小的時期，可能就幾個技術人員，因此這個時候十八般武藝都須要用上：能買就買，有開源的就用開源的。

我還以淘寶和 QQ 爲例。

初版的淘寶（blog.csdn.net/linlin_juej…）：

初版的 QQ（www.yixieshi.com/20770.html）：

能夠看到最開始的淘寶和 QQ 與如今相比，幾乎看不出是同一個業務了。

2. 發展期

當業務推出後通過市場驗證若是是可行的，則吸引的用戶就會愈來愈多，此時原來不完善的業務就進入了一個快速發展的時期。業務快速發展時期的主要目的是將原來不完善的業務逐漸完善，所以會有愈來愈多的新功能不斷地加入到系統中。對於絕大部分技術團隊來講，這個階段技術的核心工做是快速地實現各類需求，只有這樣才能知足業務發展的須要。

如何作到「快」，通常會經歷下面幾個階段。

• 堆功能期

業務進入快速發展期的初期，此時團隊規模也不大，業務需求又很緊，最快實現業務需求的方式是繼續在原有的系統裏面不斷地增長新的功能，重構、優化、架構等方面的工做即便想作，也會受制於人力和業務發展的壓力而放在一邊。

• 優化期

「堆功能」的方式在剛開始的時候好用，由於系統還比較簡單，但隨着功能愈來愈多，系統開始變得愈來愈複雜，後面繼續堆功能會感到愈來愈吃力，速度愈來愈慢。一種典型的場景是作一個需求要改好多地方，一不當心就改出了問題。直到有一天，技術團隊或者產品人員再也受不了這種慢速的方式，終於下定決定要解決這個問題了。

如何解決這個問題，通常會分爲兩派：一派是優化派，一派是架構派。

優化派的核心思想是將現有的系統優化。例如，採用重構、分層、優化某個 MySQL 查詢語句，將機械硬盤換成 SSD，將數據庫從 MySQL 換成 Oracle，增長 Memcache 緩存等。優化派的優點是對系統改動較小，優化能夠比較快速地實施；缺點就是可能過不了多久，系統又撐不住了。

架構派的核心思想是調整系統架構，主要是將原來的大系統拆分爲多個互相配合的小系統。例如，將購物系統拆分爲登陸認證子系統、訂單系統、查詢系統、分析系統等。架構派的優點是一次調整能夠支撐比較長期的業務發展，缺點是動做較大、耗時較長，對業務的發展影響也比較大。

相信在不少公司都遇到這種狀況，大部分狀況下都是「優化派」會贏，主要的緣由仍是由於此時「優化」是最快的方式。至於說「優化派」支撐不了多久這個問題，其實也不用考慮太多，由於業務可否發展到那個階段仍是個未知數，保證當下的競爭力是最主要的問題。

• 架構期

通過優化期後，若是業務可以繼續發展，慢慢就會發現優化也頂不住了，畢竟再怎麼優化，系統的能力老是有極限的。Oracle 再強大，也不可能一臺 Oracle 頂住 1 億的交易量；小型機再好，也不可能一臺機器支持 100 萬在線人數。此時已經沒有別的選擇，只能進行架構調整，在優化期被壓制的架構派開始揚眉吐氣了，甚至會驕傲地說「看看吧，早就說要進行架構調整，大家偏要優化，如今仍是頂不住了吧，哼……」。

架構期能夠用的手段不少，但歸根結底能夠總結爲一個字「拆」，什麼地方均可以拆。

拆功能：例如，將購物系統拆分爲登陸認證子系統、訂單系統、查詢系統、分析系統等。

拆數據庫：MySQL 一臺變兩臺，2 臺變 4 臺，增長 DBProxy、分庫分表等。

拆服務器：服務器一臺變兩臺，2 臺變 4 臺，增長負載均衡的系統，如 Nginx、HAProxy 等。

3. 競爭期

當業務繼續發展，已經造成必定規模後，必定會有競爭對手開始加入行業來競爭，畢竟誰都想分一塊蛋糕，甚至有可能一不當心還會成爲下一個 BAT。當競爭對手加入後，你們互相學習和模仿，業務更加完善，也不斷有新的業務創新出來，並且因爲競爭的壓力，對技術的要求是更上一層樓了。

新業務的創新給技術帶來的典型壓力就是新的系統會更多，同時，原有的系統也會拆得愈來愈多。二者協力的一個典型後果就是系統數量在原來的基礎上又增長了不少。架構拆分後帶來的美好時光又開始慢慢消逝，技術工做又開始進入了「慢」的狀態，這又是怎麼回事呢？

原來系統數量愈來愈多，到了一個臨界點後就產生了質變，即系統數量的量變帶來了技術工做的質變。主要體如今下面幾個方面：

• 重複造輪子

系統愈來愈多，各系統類似的工做愈來愈多。例如，每一個系統都有存儲，都要用緩存，都要用數據庫。新建一個系統，這些工做又要都作一遍，即便其餘系統已經作過了一遍，這樣怎麼能快得起來？

• 系統交互一團亂麻

系統愈來愈多，各系統的交互關係變成了網狀。系統間的交互數量和系統的數量成平方比的關係。例如，4 個系統的交互路徑是 6 個，10 個系統的交互路徑是 45 個。每實現一個業務需求，都須要幾個甚至十幾個系統一塊兒改，而後互相調用來調用去，聯調成了研發人員的災難、聯測成了測試人員的災難、部署成了運維的災難。

針對這個時期業務變化帶來的問題，技術工做主要的解決手段有：

平臺化

目的在於解決「重複造輪子」的問題。

存儲平臺化：淘寶的 TFS、京東 JFS。

數據庫平臺化：百度的 DBProxy、淘寶 TDDL。

緩存平臺化：Twitter 的 Twemproxy，豆瓣的 BeansDB、騰訊 TTC。

服務化

目的在於解決「系統交互」的問題，常見的作法是經過消息隊列來完成系統間的異步通知，經過服務框架來完成系統間的同步調用。

消息隊列：淘寶的 Notify、MetaQ，開源的 Kafka、ActiveMQ 等。

服務框架：Facebook 的 thrift、噹噹網的 Dubbox、淘寶的 HSF 等。

4. 成熟期

當企業熬過競爭期，成爲了行業的領頭羊，或者整個行業總體上已經處於比較成熟的階段，市場地位已經比較牢固後，業務創新的機會已經不大，競爭壓力也沒有那麼激烈，此時求快求新已經沒有很大空間，業務上開始轉向爲「求精」：咱們的響應時間是否比競爭對手快？咱們的用戶體驗是否比競爭對手好？咱們的成本是否比競爭對手低……

此時技術上其實也基本進入了成熟期，該拆的也拆了，該平臺化的也平臺化了，技術上能作的大動做其實也很少了，更多的是進行優化。但有時候也會爲了知足某個優化，系統作很大的改變。例如，爲了將用戶響應時間從 200ms 下降到 50ms，可能就須要從不少方面進行優化：CDN、數據庫、網絡等。這個時候的技術優化沒有固定的套路，只能按照競爭的要求，找出本身的弱項，而後逐項優化。在逐項優化時，能夠採起以前各個時期採用的手段。

用戶規模

互聯網業務的發展第二個主要方向就是「用戶量愈來愈大」。互聯網業務的發展會經歷「初創期、發展期、競爭期、成熟期」幾個階段，不一樣階段典型的差異就是用戶量的差異，用戶量隨着業務的發展而愈來愈大。

用戶量增大對技術的影響主要體如今兩個方面：性能要求愈來愈高、可用性要求愈來愈高。

1. 性能

用戶量增大給技術帶來的第一個挑戰就是性能要求愈來愈高。以互聯網企業最經常使用的 MySQL 爲例，再簡單的查詢，再高的硬件配置，單臺 MySQL 機器支撐的 TPS 和 QPS 最高也就是萬級，低的多是幾千，高的也不過幾萬。當用戶量增加後，必然要考慮使用多臺 MySQL，從一臺 MySQL 到多臺 MySQL 不是簡單的數量的增長，而是本質上的改變，即原來集中式的存儲變爲了分佈式的存儲。

稍微有經驗的工程師都會知道，分佈式將會帶來複雜度的大幅度上升。以 MySQL 爲例，分佈式 MySQL 要考慮分庫分表、讀寫分離、複製、同步等不少問題。

2. 可用性

用戶量增大對技術帶來的第二個挑戰就是可用性要求愈來愈高。當你有 1 萬個用戶的時候，宕機 1 小時可能也沒有很大的影響；但當你有了 100 萬用戶的時候，宕機 10 分鐘，投訴電話估計就被打爆了，這些用戶再到朋友圈抱怨一下你的系統有多爛，極可能你就不會再有機會發展下一個 100 萬用戶了。

除了口碑的影響，可用性對收入的影響也會隨着用戶量增大而增大。1 萬用戶宕機 1 小時，你可能才損失了幾千元；100 萬用戶宕機 10 分鐘，損失可能就是幾十萬元了。

量變到質變

經過前面的分析，咱們能夠看到互聯網業務驅動技術發展的兩大主要因素是複雜性和用戶規模，而這兩個因素的本質其實都是「量變帶來質變」。

究竟用戶規模發展到什麼階段纔會由量變帶來質變，雖然不一樣的業務有所差異，但基本上能夠按照下面這個模型去衡量。

應對業務質變帶來的技術壓力，不一樣時期有不一樣的處理方式，但無論什麼樣的方式，其核心目標都是爲了知足業務「快」的要求，當發現你的業務快不起來的時候，其實就是技術的水平已經跟不上業務發展的須要了，技術變革和發展的時候就到了。更好的作法是在問題尚未真正暴露出來就可以根據趨勢預測下一個轉折點，提早作好技術上的準備，這對技術人員的要求是很是高的。

小結

今天我爲你講了互聯網技術演進的基本模式，但願對你有所幫助。

這就是今天的所有內容，留一道思考題給你吧，參考今天文章的方法，簡單分析一下你所在行業，看看是否存在典型的技術演進模式？

歡迎你把答案寫到留言區，和我一塊兒討論。相信通過深度思考的回答，也會讓你對知識的理解更加深入。（編輯亂入：精彩的留言有機會得到豐厚福利哦！）