互聯網技術發展之路（1） - 技術發展的驅動力

互聯網技術發展之路（1） - 技術發展的驅動力

互聯網行業是1個快速發展、快速變化的行業，新的業務、新的機會層見疊出，新的技術如雨后春筍般冒出，NoSQL、大數據、云、Node.js、Docker等，無時不刻都在轟炸程序員們的腦袋，難怪中國的程序員都流傳1個說法：過了30歲不能做技術工作了，由于技術發展太快了！

快節奏帶來機會，但對技術人員來講，更多的是帶來挑戰，乃至有時候是困惑。例如：

1）Docker很火哦，我們要不要用呢 ？

2）Node.js好牛逼啊，我們用上就更牛逼了......

3）大數據和云是業界發展趨勢，我覺得我們也應當跟上技術發展的趨勢......

......

還有很多類似的問題和想法，其實歸根結柢可以歸納為1個統1的問題：是甚么推動了1個互聯網企業的技術發展？

關于這個問題的回答，基本上可以分為幾個典型的派別：

1）潮流派

潮流派的典型特點就是對新技術特別熱中，緊跟技術潮流，當有新的技術出現時，迫切的想將新的技術利用到自己的產品中。

例如：

NoSQL很火，我們要大范圍的切換為NoSQL；

大數據好牛逼呀，將我們的MySQL切換為Hadoop吧；

Node.js是的javascript統1前后端，這樣非常有助于我們工作的展開；

......等等

2）守舊派

守舊派的典型特點和潮流派正好相反，對新技術抱有很強的戒備心，穩定壓倒1切，已掌握了某種技術，就1直用這類技術打天下。就像那句俗語說的，“如果你手里有1把錘子，那末所有的問題都變成了釘子”，守舊派就是拿著1把錘子解決所有的問題。

例如：

MySQL我們用了這么久了，很熟習了，業務也用MySQL、數據分析也用MySQL、報表也用MySQL吧；

Java語言我們都很熟，業務用java、工具用java，平臺也用java；

......等等

3）跟風派

跟風派與潮流派不同，這里的跟風派不是指隨著技術潮流，而是指隨著競爭對手的步子走。

簡單來講，判斷技術的發展就看競爭對手，競爭對手用了我們就用，競爭對手沒用我們就等等看。 

例如：

這項技術騰訊用了么？ 騰訊用了我們就用；

阿里用了Hadoop，他們都在用，肯定是好東西，我們也要盡快用起來，以提高我們的競爭力；

Google都用了Docker，我們也用吧；

......等等

相信不用多說，大家都能看出這幾個典型派別存在的問題：

1）潮流派

首先，新技術既需要時間成熟，如果剛出來就趕快用，此時新技術還不怎樣成熟，實際利用極可能遇到各種“坑”；

其次，新技術需要學習，需要花費1定的時間去掌握，這個也是較大的本錢；如果等到掌握了結果技術又不適用，就是1種較大的人力浪費了

2）守舊派

守舊派的主要問題是不能享受新技術帶來的收益，由于新技術很多都是為了解決之前技術存在的固有缺點。就像汽車取代馬車1樣，不是量變而是質變，帶來的收益不是線性變化的，而是爆發式變化的。

如果疏忽技術的發展，形象1點說有了拖拉機，你還恰恰要用牛車。

3）跟風派

可能很多人都會認為，跟風派與“潮流派”和“守舊派”相比，是最有效的策略，既不會承當“潮流派”的風險，也不會遭受“守舊派”的損失，花費的資源也少，簡直就是1舉多得。

看起來很美好，但跟風派最大的問題在于如果沒有風可跟的時候怎樣辦。1種情況就是如果你是領頭羊怎樣辦，其他人都準備跟你的風呢；

另外1種情況就是競爭對手的這些信息其實不那末容易獲得，即便獲得到了1些信息，大部份也是不全面的，1不謹慎可能就變成邯鄲學步了。

即便有風可跟，其實也還是存在問題的。俗語說：橘生淮南則為橘，生于淮北則為枳，葉徒類似，其實味不同。適用于競爭對手的技術，其實不1定適用于自己，盲目模仿可能帶來相反的效果。

既然這幾個典型派別都存在問題，那末互聯網技術發展的驅動力究竟是甚么 ？

這個問題之所以讓人困惑，我覺得關鍵的緣由還是在于不論是潮流派、守舊派，還是跟風派，都是站在技術本身的角度來斟酌問題的，正所謂“不識廬山真面，只緣身在此山中”。

因此，要想看到廬山真面目，只有跳出技術的角度，從1個更廣更高的角度來斟酌這個問題，這個角度就是互聯網企業的發展。

互聯網企業的業務基本上可以大概分為兩類：1類是提供“產品”，1類是提供“服務”。

提供產品：360的殺毒軟件、蘋果的iphone、UC的閱讀器。。。。。。等都屬于這個范疇，這些產品本質上和傳統的制造業產品類似，都是具有了某種“功能”，能夠完成某些任務；

提供服務：百度的搜索、淘寶的購物、微博的資訊、騰訊的IM。。。。。。都屬于這個范疇，和“提供產品”的業務不同是，提供服務的業務更加符合互聯網的特點和本質：“互聯” +“ 網”。

“互聯”是指這些業務將本來分散的個體連結成了1個龐大的整體，可以將人連接，也能夠將信息連接，也能夠將數據連接，連接在1起的群體的價值比群體中單個個體的價值之和要大很多；

“網”有兩種含義：1個是指通過數據網絡連接（與傳統的電話網絡等相比）、1個是指個體互聯成“網狀”的結構。

1個互聯網企業的發展，歸根結柢就是業務的發展，而影響1個互聯網企業的業務發展的主要有3個因素：市場、技術、管理。我稱之為業務發展鐵3角，任何1個因素的不足都將致使企業業務的發展停滯不前。

如上圖，在這個鐵3角中，業務是處于3角形的中心，絕不夸大的說，市場、技術、管理的動作都是為了支持企業業務的發展。市場和管理對業務的影響不在本文的探討范疇以內，我們主要來探討1下“技術”和“業務”之間的關系和相互如何影響。

對“產品”類的業務，答案其實很明顯：技術創新不斷推動業務的發展。

這個道理和傳統的制造行業的產品創新是1樣的：產品上的技術創新 -> 帶來更強大的功能  -> 推動產品的市場不斷擴大 -> 市場擴大競爭更加劇烈 -> 反過來又對技術創新提出了更高的要求，如此循環往復，技術創新不斷的推動產品的提升、業務的擴大。

對“產品”類業務，為了尋求不斷的創新，即便“潮流派”或“跟風派”存在風險或問題，但為了能夠獲得領先，也必須不遺余力的去嘗試，否則等到技術沒有風險的時候再去用，自己可能已落后對手1大截了。而且不但要做“潮流派”，還要做“跟風派”，更要做“領頭羊”，這樣才能在劇烈的競爭市場環境下不斷的保持領先的優勢。

例如：

1）蘋果開發智能手機，將諾基亞推下王座，自己成為全球手機行業的新王者，就是技術創新驅動產品的典型例子；

2） 2G時期，UC閱讀器獨創的云端架構，很好的解決了上網慢的問題；智能機時期，UC閱讀器又自主研發全新的U3內核，統籌高速、安全、智能及可擴大性，這些技術創新是UC閱讀器成了全球最大的第3方手機閱讀器最強有力的推動力。

而對“服務”類的業務，答案和產品類業務正好相反：業務發展推動技術的發展。

為何會出現截然相反的差別呢？這還需要從“產品”和“服務”的本質差別來看。用戶選擇1個產品的根本驅動力是其“功能”，例如功能是不是強大，外觀是不是漂亮，用戶體驗是不是良好；而用戶選擇1個服務的根本驅動力不是功能，而是“范圍”。

例如：選擇UC閱讀器還是選擇QQ閱讀器，更多的人是根據個人喜好和體驗來決定的；而選擇微信還是whatsapp，就不是根據它們之間的功能差異來選擇的，而是根據其范圍來選擇的。就像我更喜歡whatsapp的簡潔，但我的的朋友和周邊的人都用微信，那我也不能不用微信。

當“范圍”成為業務的決定因素后，服務模式的創新成了業務發展的核心驅動力，而產品只是為了完成服務而提供給用戶。以淘寶為例：淘寶提供的“網絡購物”是1種新的服務，這類業務與傳統的到實體店購物是完全不同的，而為了完成這類業務，需要“淘寶網”、“支付寶”、“1淘”、“菜鳥物流”等多個產品。

比如說假設我技術創新，開發1個耗電量只有微信的1/10，用戶體驗比微信好10倍的產品，你覺得現在的微信譽戶都會拋棄微信，而轉投我的這個產品么？我相信絕大部份人都不會，由于微信不是1個互聯網產品，而是1個互聯網服務，你1個人換到其它類微信類產品是沒成心義的。

因此，服務類的業務發展路徑是這樣的：提出1種創新的服務模式 -> 吸引了1批用戶 -> 業務開始發展 -> 吸引了更多用戶 -> 服務模式不斷完善和創新 -> 吸引愈來愈多的用戶，如此循環往復。在這個發展路徑中，技術并沒有成為業務發展的驅動力，反過來由于用戶范圍的不斷擴大，業務的不斷創新和改進，對技術會提出愈來愈高的要求，因此是業務驅動了技術發展。

對“服務”類業務，業務成了技術發展的驅動力。因此“潮流派”、“跟風派”、“守舊派”都是不可取的，甚么時候采取甚么技術是由業務的范圍決定的。

對“產品”類業務來講，技術的發展和具體的產品有很強的關系，比如說UC閱讀器的技術優化和蘋果手機的技術優化差別會非常大，因此難以構成1套技術發展的模式；而對“服務”類業務來講，雖然業務千差萬別，但“范圍”的發展對技術的影響和推動效果是基本1致的，可以歸納出1套成熟的技術發展體系，本文就試圖在這個方向上分幾個主題進行1番探索。

前面講了那末1大堆理論，聽起來有點道理，但實踐是檢驗真諦的唯1標準，究竟事實是不是就是這樣呢？我們可以回顧1下幾個典型互聯網企業的技術發展歷程。這里挑選了兩個最典型的企業：淘寶、騰訊。之所以挑選這兩個，1個是由于大家耳熟能詳，另外1個也是由于資料好找。

【淘寶】

注：以下內容主要摘自《淘寶技術發展》，原文鏈接：http://kb.cnblogs.com/page/132724/

淘寶技術發展主要經歷了“個人網站”、“Oracle/支付寶/旺旺”、“Java時期1.0”、“Java時期2.0”、“Java時期3.0”、“散布式時期”。我們看看每一個階段的主要驅動力是甚么。

1. 個人網站

2003年4月7日馬云提出成立淘寶，2003年5月10日淘寶就上線了，中間只有1個月，怎樣辦？淘寶的答案就是：買1個。

估計大部份人很難想象如今技術牛氣沖天的阿里最初的淘寶居然是買來的，我們看看當初決策的根據：

“當時對全部項目組來講壓力最大的就是時間，怎樣在最短的時間內把1個歷來就沒有的網站從零開始建立起來？了解淘寶歷史的人知道淘寶是在 2003 年 5 月 10 日上線的，這之間只有1個月。要是你在這個團隊里，你怎樣做？我們的答案就是：買1個來。”

大家看到沒有，這個時候沒有過量斟酌技術是不是牛逼、沒有過量斟酌性能是不是海量、沒有斟酌穩定性如何，主要的斟酌就是：快！

由于此時業務要求快速上線，時間不等人，等你花幾個月乃至10幾個月弄出1個牛逼的系統出來，可能市場機會就沒有了，黃花菜都涼了。

一樣，在斟酌如何買的時候，淘寶的決策根據主要也是”快“：

“買1個網站明顯比做1個網站要省事1些，但是他們的夢想可不是做1個小網站而已，要做大，就不是隨意買個就行的，要有比較低的保護本錢，要能夠方便的擴大和2次開發。

那接下來就是第2個問題：買1個甚么樣的網站？答案是：輕量1點的，簡單1點的”

買1個系統是為了”快速可用“，而買1個輕量級的系統是為了”快速開發“，由于系統上線后肯定有大量的需求需要做，這個時候能夠快速開發就非常重要。

從這個實例我們可以看到：淘寶最開始的時候業務要求就是”快“，因此反過來要求技術一樣要”快“，業務決定技術。

第1代的技術架構以下圖：

2. Oracle/支付寶/旺旺

淘寶網推出后，由于正好碰到非典，網購很火爆，加上采取了成功的市場運作，流量和交易量迅速上漲，業務發展很快，在 2003 年底，MySQL 已撐不住了。

1般人或團隊在這個時候，可能就開始優化系統、優化架構了、分拆業務了，由于這些是大家耳熟能詳也很拿手的動作。那我們來看看淘寶這個時候怎樣采取的措施：

“技術的替換方案非常簡單，就是換成 Oracle。換 Oracle 的緣由除它容量大、穩定、安全、性能高以外，還有人材方面的緣由。”

可以看出這個時候淘寶的策略主要還是”買“，買更高配置的Oracle，這個是當時情況下最快的方法。

除購買Oracle，后來為了優化，又買了更牛逼的存儲：

“后來數據量變大了，本地存儲不行了。買了 NAS（Network Attached Storage：網絡附屬存儲），NetApp 的 NAS 存儲作為了數據庫的存儲裝備，加上 Oracle RAC（Real Application Clusters，實時利用集群）來實現負載均衡。”

我們思考1下，為何淘寶在這個時候繼續采取“買”的方式來快速解決問題呢？我們可以從時間上看出端倪：此時離剛上線才半年不到，業務飛速發展，最快的方式支持業務的發展還是去買。如果說第1階段買的是“方案”，這個階段買的就是“性能”。

換上Oracle和昂貴的存儲后，第2代架構以下：

3. Java時期1.0 - 洗心革面

淘寶切換到Java的緣由很有趣，主要由于找了1個PHP的開源連接池SQL Relay連接到Oracle，而這個代理常常死鎖，死鎖了就必須重啟，而數據庫又必須用Oracle，因而決定換個開發語言。最后淘寶挑選了Java，而且當時挑選Java，也是請Sun公司的人，這幫人很牛逼，先是將淘寶網站從PHP熱切換到了Java，后來又做了支付寶。

這次切換的最主要緣由是由于技術影響了業務的發展，你說動不動就死鎖、然后就要重啟，這個是對用戶業務嚴重的影響。從業務的角度來看這是不能不解決的技術問題。

但這次淘寶為何沒有去“買”，是有點疑惑的地方。我們看最初選擇SQL Relay的緣由：

“但對 PHP 語言來講它是放在 Apache 上的，每個要求都會對數據庫產生1個連接，它沒有連接池這類功能（Java 語言有 Servlet 容器，可以寄存連接池）。那如何是好呢？這幫人刺探到 eBay 在 PHP 下面用了1個連接池的工具，是 BEA 賣給他們的。我們知道 BEA 的東西都很貴，我們買不起，因而多隆在網上尋尋覓覓，找到1個開源的連接池代理服務 SQLRelay”

不清楚當時到底有多貴，Oracle都可以買，連接池買不起 ？所以我個人感覺這次切換語言，更多的是為以后業務發展做鋪墊，畢竟當時PHP語言遠遠沒有Java那末火，那末好招人。淘寶選擇Java語言的理由可以從側面驗證這點：

“Java 是當時最成熟的網站開發語言，它有比較良好的企業開發框架，被世界上主流的大范圍網站普遍采取，另外有 Java 開發經驗的人材也比較多，后續保護本錢會比較低。”

從PHP改成Java后，第3代技術架構以下：

4. Java時期2.0 - 堅若盤石

Java2.0時期，淘寶做了很多優化工作：數據分庫、放棄 EJB、引入 Spring、加入緩存、加入 CDN、采取開源的 JBoss。為何在這個時候要做這些動作？ 原文作者很好的概括了做這些動作的緣由：

“這些雜7雜8的修改，我們對數據分庫、放棄 EJB、引入 Spring、加入緩存、加入 CDN、采取開源的 JBoss，看起來沒有章法可循，其實都是圍繞著提高容量、提高性能、節儉本錢來做的”

我們思考1下，為何在前面的階段，淘寶斟酌的都是“快”，而現在開始斟酌“容量、性能、本錢”了呢？而且為何這個時候不采取“買”的方式來解決容量、性能、本錢問題呢？

簡單來講，就是“買”也弄不定了，此時的業務發展情況是這樣的：

“隨著數據量的繼續增長，到了 2005 年，商品數有 1663 萬，PV 有 8931 萬，注冊會員有 1390 萬，這給數據和存儲帶來的壓力仍然山東大學，數據量大，性能就慢?！?/span>

原本的方案存在的固有缺點，隨著業務的繼續發展，已不是靠“買”能夠解決的了，此時必須從全部架構上去進行調劑和優化。比如說Oracle再牛逼，在做like類搜索的時候，也不可能做到純潔的搜索系統如Solr、Sphinx等的性能，由于這是機制決定的。

另外，隨著范圍的增大，純潔靠買的1個典型問題開始成為重要的斟酌因素，那就是本錢。當買1臺兩臺Oracle的時候，可能對本錢其實不怎樣關心，但如果要買100臺Oracle，本錢就是1個關鍵因素了。這就是“量變帶來質變”的1個典型案例。

Java 架構經過各種優化，第4代技術架構以下：

5. Java時期3.0 和散布式時期

Java時期3.0時期我個人認為是淘寶技術奔騰的開始，簡單來講就是淘寶技術從商用轉為“自研”，典型的就是去IOE化。

散布式時期我認為是淘寶技術的修煉成功，到了這個階段，自研技術已自成1派，除支持本身的海量業務外，也開始影響全部互聯網的技術發展。

具體的緣由這里就不詳細分析，留給讀者依照前面的思路去分析。

【手機QQ】

注：以下內容主要摘自《QQ1.4億在線背后的故事》

手機QQ的發展歷程依照用戶范圍可以粗略劃分為4個階段：10萬級、百萬級、千萬級、億級，不同的用戶范圍，IM后臺的架構也不同，而且基本上都是用戶范圍先上去，然后產生各種問題，倒逼技術架構升級。

1. 10萬級 - IM1.X

最開始的手機QQ后臺以下，可以說是簡單的不能再簡單，普通得不能再普通的1個架構了（是不是會感嘆原來神1樣的公司開始也是

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈