互聯網行業是一個快速發展、快速變化的行業，新的業務、新的機會層出不窮，新的技術如雨後春筍般冒出，NoSQL、大數據、雲、Node.js、Docker等，無時不刻都在轟炸程序員們的腦袋，難怪中國的程序員都流傳一個說法：過了30歲不能做技術工作了，因爲技術發展太快了！
快節奏帶來機會，但對於技術人員來說，更多的是帶來挑戰，甚至有時候是困惑。例如：
-
Docker很火哦，咱們要不要用呢 ？
-
Node.js好牛逼啊，我們用上就更牛逼了......
-
大數據和雲是業界發展趨勢，我覺得我們也應該跟上技術發展的趨勢......
還有很多類似的問題和想法，其實歸根結底可以歸納爲一個統一的問題：是什麼推動了一個互聯網企業的技術發展？
關於這個問題的回答，基本上可以分爲幾個典型的派別：
潮流派潮流派的典型特徵就是對於新技術特別熱衷，緊跟技術潮流，當有新的技術出現時，迫切的想將新的技術應用到自己的產品中。例如：
-
NoSQL很火，咱們要大規模的切換爲NoSQL；
-
大數據好牛逼呀，將我們的MySQL切換爲Hadoop吧；
-
Node.js是的JavaScript統一前後端，這樣非常有助於我們工作的開展；
保守派的典型特徵和潮流派正好相反，對於新技術抱有很強的戒備心，穩定壓倒一切，已經掌握了某種技術，就一直用這種技術打天下。就像那句俗語說的，“如果你手裏有一把錘子，那麼所有的問題都變成了釘子”，保守派就是拿着一把錘子解決所有的問題。例如：
-
MySQL咱們用了這麼久了，很熟悉了，業務也用MySQL、數據分析也用MySQL、報表也用MySQL吧；
-
Java語言我們都很熟，業務用Java、工具用Java，平臺也用Java；
跟風派與潮流派不同，這裏的跟風派不是指跟着技術潮流，而是指跟着競爭對手的步子走。
簡單來說，判斷技術的發展就看競爭對手，競爭對手用了咱們就用，競爭對手沒用咱們就等等看。例如：
-
這項技術騰訊用了麼？ 騰訊用了我們就用；
-
阿里用了Hadoop，他們都在用，肯定是好東西，咱們也要儘快用起來，以提高咱們的競爭力；
-
Google都用了Docker，咱們也用吧；
相信不用多說，大家都能看出這幾個典型派別存在的問題：
潮流派首先，新技術既需要時間成熟，如果剛出來就趕緊用，此時新技術還不怎麼成熟，實際應用很可能遇到各種“坑”；
其次，新技術需要學習，需要花費一定的時間去掌握，這個也是較大的成本；如果等到掌握了結果技術又不適用，就是一種較大的人力浪費了。
保守派保守派的主要問題是不能享受新技術帶來的收益，因爲新技術很多都是爲了解決以前技術存在的固有缺陷。就像汽車取代馬車一樣，不是量變而是質變，帶來的收益不是線性變化的，而是爆發式變化的。
如果無視技術的發展，形象一點說有了拖拉機，你還偏偏要用牛車。
跟風派可能很多人都會認爲，跟風派與“潮流派”和“保守派”相比，是最有效的策略，既不會承擔“潮流派”的風險，也不會遭受“保守派”的損失，花費的資源也少，簡直就是一舉多得。
看起來很美妙，但跟風派最大的問題在於如果沒有風可跟的時候怎麼辦。一種情況就是如果你是領頭羊怎麼辦，其他人都準備跟你的風呢；
另外一種情況就是競爭對手的這些信息並不那麼容易獲取，即使獲取到了一些信息，大部分也是不全面的，一不小心可能就變成邯鄲學步了。
即使有風可跟，其實也還是存在問題的。俗話說：橘生淮南則爲橘，生於淮北則爲枳，葉徒相似，其實味不同。適用於競爭對手的技術，並不一定適用於自己，盲目模仿可能帶來相反的效果。
既然這幾個典型派別都存在問題，那麼互聯網技術發展的驅動力究竟是什麼 ？
這個問題之所以讓人困惑，我覺得關鍵的原因還是在於不管是潮流派、保守派，還是跟風派，都是站在技術本身的角度來考慮問題的，正所謂“不識廬山真面，只緣身在此山中”。
因此，要想看到廬山真面目，只有跳出技術的角度，從一個更廣更高的角度來考慮這個問題，這個角度就是互聯網企業的發展。
互聯網企業的業務基本上可以大概分爲兩類：一類是提供“產品”，一類是提供“服務”。
提供產品：360的殺毒軟件、蘋果的iPhone、UC的瀏覽器。等都屬於這個範疇，這些產品本質上和傳統的製造業產品類似，都是具備了某種“功能”，能夠完成某些任務；
提供服務：百度的搜索、淘寶的購物、微博的資訊、騰訊的IM。都屬於這個範疇，和“提供產品”的業務不同是，提供服務的業務更加符合互聯網的特徵和本質：“互聯” +“ 網”。所以後續的文章談論的“互聯網技術”，就是指“提供服務的互聯網業務的技術”。
“互聯”是指這些業務將原本分散的個體連結成了一個龐大的整體，可以將人連接，也可以將信息連接，也可以將數據連接，連接在一起的羣體的價值比羣體中單個個體的價值之和要大得多；“網”有兩種含義：一個是指通過數據網絡連接（與傳統的電話網絡等相比）、一個是指個體互聯成“網狀”的結構。
一個互聯網企業的發展，歸根結底就是業務的發展，而影響一個互聯網企業的業務發展的主要有3個因素：市場、技術、管理。我稱之爲業務發展鐵三角，任何一個因素的不足都將導致企業業務的發展停滯不前。
如上圖，在這個鐵三角中，業務是處於三角形的中心，毫不誇張的說，市場、技術、管理的動作都是爲了支撐企業業務的發展。市場和管理對業務的影響不在本文的探討範疇之內，我們主要來探討一下“技術”和“業務”之間的關係和互相如何影響。
對於“產品”類的業務，答案其實很明顯：技術創新不斷推動業務的發展。
這個道理和傳統的製造行業的產品創新是一樣的：產品上的技術創新 -> 帶來更強大的功能 -> 推動產品的市場不斷擴大 -> 市場擴大競爭更加激烈 -> 反過來又對技術創新提出了更高的要求，如此循環往復，技術創新不斷的推動產品的提升、業務的擴展。
對於“產品”類業務，爲了追求不斷的創新，即使“潮流派”或者“跟風派”存在風險或者問題，但爲了能夠取得領先，也必須不遺餘力的去嘗試，否則等到技術沒有風險的時候再去用，自己可能已經落後對手一大截了。而且不但要做“潮流派”，還要做“跟風派”，更要做“領頭羊”，這樣才能在激烈的競爭市場環境下不斷的保持領先的優勢。
例如：
-
蘋果開發智能手機，將諾基亞推下王座，自己成爲全球手機行業的新王者，就是技術創新驅動產品的典型例子；
-
2G時代，UC瀏覽器獨創的雲端架構，很好的解決了上網慢的問題；智能機時代，UC瀏覽器又自主研發全新的U3內核，兼顧高速、安全、智能及可擴展性，這些技術創新是UC瀏覽器成爲了全球最大的第三方手機瀏覽器最強有力的推動力。
而對於“服務”類的業務，答案和產品類業務正好相反：業務發展推動技術的發展。
爲什麼會出現截然相反的差別呢？這還需要從“產品”和“服務”的本質差別來看。用戶選擇一個產品的根本驅動力是其“功能”，例如功能是否強大，外觀是否漂亮，用戶體驗是否良好；而用戶選擇一個服務的根本驅動力不是功能，而是“規模”。
例如：選擇UC瀏覽器還是選擇QQ瀏覽器，更多的人是根據個人喜好和體驗來決定的；而選擇微信還是WhatsApp，就不是根據它們之間的功能差異來選擇的，而是根據其規模來選擇的。就像我更喜歡WhatsApp的簡潔，但我的的朋友和周邊的人都用微信，那我也不得不用微信。
當“規模”成爲業務的決定因素後，服務模式的創新成爲了業務發展的核心驅動力，而產品只是爲了完成服務而提供給用戶。以淘寶爲例：淘寶提供的“網絡購物”是一種新的服務，這種業務與傳統的到實體店購物是完全不同的，而爲了完成這種業務，需要“淘寶網”、“支付寶”、“一淘”、“菜鳥物流”等多個產品。
比如說假如我技術創新，開發一個耗電量只有微信的1/10，用戶體驗比微信好10倍的產品，你覺得現在的微信用戶都會拋棄微信，而轉投我的這個產品麼？我相信絕大部分人都不會，因爲微信不是一個互聯網產品，而是一個互聯網服務，你一個人換到其它類微信類產品是沒有意義的。
因此，服務類的業務發展路徑是這樣的：提出一種創新的服務模式 -> 吸引了一批用戶 -> 業務開始發展 -> 吸引了更多用戶 -> 服務模式不斷完善和創新 -> 吸引越來越多的用戶，如此循環往復。在這個發展路徑中，技術並沒有成爲業務發展的驅動力，反過來由於用戶規模的不斷擴展，業務的不斷創新和改進，對技術會提出越來越高的要求，因此是業務驅動了技術發展。
對於“服務”類業務，業務成爲了技術發展的驅動力。因此“潮流派”、“跟風派”、“保守派”都是不可取的，什麼時候採取什麼技術是由業務的規模決定的。
對於“產品”類業務來說，技術的發展和具體的產品有很強的關係，比如說UC瀏覽器的技術優化和蘋果手機的技術優化差別會非常大，因此難以形成一套技術發展的模式；而對於“服務”類業務來說，雖然業務千差萬別，但“規模”的發展對技術的影響和推動效果是基本一致的，可以歸納出一套成熟的技術發展體系，本文就試圖在這個方向上分幾個主題進行一番探索。
前面講了那麼一大堆理論，聽起來有點道理，但實踐是檢驗真理的唯一標準，究竟事實是否就是這樣呢？我們可以回顧一下幾個典型互聯網企業的技術發展歷程。這裏挑選了兩個最典型的企業：淘寶、騰訊。之所以挑選這兩個，一個是因爲大家耳熟能詳，另外一個也是因爲資料好找。
淘寶
注：以下內容主要摘自《淘寶技術發展》。
淘寶技術發展主要經歷了“個人網站”、“Oracle/支付寶/旺旺”、“Java時代1.0”、“Java時代2.0”、“Java時代3.0”、“分佈式時代”。我們看看每個階段的主要驅動力是什麼。
1. 個人網站
2003年4月7日馬雲提出成立淘寶，2003年5月10日淘寶就上線了，中間只有1個月，怎麼辦？淘寶的答案就是：買一個。
估計大部分人很難想象如今技術牛氣沖天的阿里最初的淘寶竟然是買來的，我們看看當初決策的依據：
“當時對整個項目組來說壓力最大的就是時間，怎麼在最短的時間內把一個從來就沒有的網站從零開始建立起來？瞭解淘寶曆史的人知道淘寶是在 2003 年 5 月 10 日上線的，這之間只有一個月。要是你在這個團隊裏，你怎麼做？我們的答案就是：買一個來。”
大家看到沒有，這個時候沒有過多考慮技術是否牛逼、沒有過多考慮性能是否海量、沒有考慮穩定性如何，主要的考慮就是：快！
因爲此時業務要求快速上線，時間不等人，等你花幾個月甚至10幾個月搞出1個牛逼的系統出來，可能市場機會就沒有了，黃花菜都涼了。
同樣，在考慮如何買的時候，淘寶的決策依據主要也是”快“：
“買一個網站顯然比做一個網站要省事一些，但是他們的夢想可不是做一個小網站而已，要做大，就不是隨便買個就行的，要有比較低的維護成本，要能夠方便的擴展和二次開發。
那接下來就是第二個問題：買一個什麼樣的網站？答案是：輕量一點的，簡單一點的”。
買一個系統是爲了”快速可用“，而買一個輕量級的系統是爲了”快速開發“，因爲系統上線後肯定有大量的需求需要做，這個時候能夠快速開發就非常重要。
從這個實例我們可以看到：淘寶最開始的時候業務要求就是”快“，因此反過來要求技術同樣要”快“，業務決定技術。
第一代的技術架構如下圖：
2. Oracle/支付寶/旺旺
淘寶網推出後，由於正好碰到非典，網購很火爆，加上採取了成功的市場運作，流量和交易量迅速上漲，業務發展很快，在 2003 年底，MySQL 已經撐不住了。
一般人或者團隊在這個時候，可能就開始優化系統、優化架構了、分拆業務了，因爲這些是大家耳熟能詳也很拿手的動作。那我們來看看淘寶這個時候怎麼採取的措施：
“技術的替代方案非常簡單，就是換成 Oracle。換 Oracle 的原因除了它容量大、穩定、安全、性能高之外，還有人才方面的原因。”
可以看出這個時候淘寶的策略主要還是”買“，買更高配置的Oracle，這個是當時情況下最快的方法。
除了購買Oracle，後來爲了優化，又買了更牛逼的存儲：
“後來數據量變大了，本地存儲不行了。買了 NAS（Network Attached Storage：網絡附屬存儲），NetApp 的 NAS 存儲作爲了數據庫的存儲設備，加上 Oracle RAC（Real Application Clusters，實時應用集羣）來實現負載均衡。”
我們思考一下，爲什麼淘寶在這個時候繼續採取“買”的方式來快速解決問題呢？我們可以從時間上看出端倪：此時離剛上線才半年不到，業務飛速發展，最快的方式支撐業務的發展還是去買。如果說第一階段買的是“方案”，這個階段買的就是“性能”。
換上Oracle和昂貴的存儲後，第二代架構如下：
3. Java時代1.0 - 脫胎換骨
淘寶切換到Java的原因很有趣，主要因爲找了一個PHP的開源連接池SQL Relay連接到Oracle，而這個代理經常死鎖，死鎖了就必須重啓，而數據庫又必須用Oracle，於是決定換個開發語言。最後淘寶挑選了Java，而且當時挑選Java，也是請Sun公司的人，這幫人很牛逼，先是將淘寶網站從PHP熱切換到了Java，後來又做了支付寶。
這次切換的最主要原因是因爲技術影響了業務的發展，你說動不動就死鎖、然後就要重啓，這個是對用戶業務嚴重的影響。從業務的角度來看這是不得不解決的技術問題。
但這次淘寶爲什麼沒有去“買”，是有點疑惑的地方。我們看最初選擇SQL Relay的原因：
“但對於 PHP 語言來說它是放在 Apache 上的，每一個請求都會對數據庫產生一個連接，它沒有連接池這種功能（Java 語言有 Servlet 容器，可以存放連接池）。那如何是好呢？這幫人打探到 eBay 在 PHP 下面用了一個連接池的工具，是 BEA 賣給他們的。我們知道 BEA 的東西都很貴，我們買不起，於是多隆在網上尋尋覓覓，找到一個開源的連接池代理服務 SQLRelay”
不清楚當時到底有多貴，Oracle都可以買，連接池買不起 ？所以我個人感覺這次切換語言，更多的是爲以後業務發展做鋪墊，畢竟當時PHP語言遠遠沒有Java那麼火，那麼好招人。淘寶選擇Java語言的理由可以從側面驗證這點：
“Java 是當時最成熟的網站開發語言，它有比較良好的企業開發框架，被世界上主流的大規模網站普遍採用，另外有 Java 開發經驗的人才也比較多，後續維護成本會比較低。”
從PHP改爲Java後，第三代技術架構如下：
4. Java時代2.0 - 堅若磐石
Java2.0時代，淘寶做了很多優化工作：數據分庫、放棄 EJB、引入 Spring、加入緩存、加入 CDN、採用開源的 JBoss。爲什麼在這個時候要做這些動作？ 原文作者很好的概括了做這些動作的原因：
“這些雜七雜八的修改，我們對數據分庫、放棄 EJB、引入 Spring、加入緩存、加入 CDN、採用開源的 JBoss，看起來沒有章法可循，其實都是圍繞着提高容量、提高性能、節約成本來做的”
我們思考一下，爲什麼在前面的階段，淘寶考慮的都是“快”，而現在開始考慮“容量、性能、成本”了呢？而且爲什麼這個時候不採取“買”的方式來解決容量、性能、成本問題呢？
簡單來說，就是“買”也搞不定了，此時的業務發展情況是這樣的：
“隨着數據量的繼續增長，到了 2005 年，商品數有 1663 萬，PV 有 8931 萬，註冊會員有 1390 萬，這給數據和存儲帶來的壓力依然山大，數據量大，性能就慢。”
原有的方案存在的固有缺陷，隨着業務的繼續發展，已經不是靠“買”能夠解決的了，此時必須從整個架構上去進行調整和優化。比如說Oracle再牛逼，在做like類搜索的時候，也不可能做到純粹的搜索系統如Solr、Sphinx等的性能，因爲這是機制決定的。
另外，隨着規模的增大，純粹靠買的一個典型問題開始成爲重要的考慮因素，那就是成本。當買一臺兩臺Oracle的時候，可能對成本並不怎麼關心，但如果要買100臺Oracle，成本就是一個關鍵因素了。這就是“量變帶來質變”的一個典型案例。
Java 架構經過各種優化，第四代技術架構如下：
5. Java時代3.0 和分佈式時代
Java時代3.0時代我個人認爲是淘寶技術飛躍的開始，簡單來說就是淘寶技術從商用轉爲“自研”，典型的就是去IOE化。
分佈式時代我認爲是淘寶技術的修煉成功，到了這個階段，自研技術已經自成一派，除了支撐本身的海量業務外，也開始影響整個互聯網的技術發展。
具體的原因這裏就不詳細分析，留給讀者按照前面的思路去分析。
手機QQ注：以下內容主要摘自《QQ1.4億在線背後的故事》
手機QQ的發展歷程按照用戶規模可以粗略劃分爲4個階段：十萬級、百萬級、千萬級、億級，不同的用戶規模，IM後臺的架構也不同，而且基本上都是用戶規模先上去，然後產生各種問題，倒逼技術架構升級。
1. 十萬級 - IM1.X
最開始的手機QQ後臺如下，可以說是簡單的不能再簡單，普通得不能再普通的一個架構了（是否會感嘆原來神一樣的公司開始也是屌絲一個呀 ）：
2. 百萬級 - IM2.X
業務發展：2001年，QQ同時在線突破一百萬
第一代架構很簡單，但也很明顯不可能支撐百萬級的用戶規模，主要的問題有：
-
以接入服務器的內存爲例，單個在線用戶的存儲量約爲2KB，索引和在線狀態 50字節，好友表 400個好友 * 5字節/好友 = 2000字節，大致來說，2G內存只能支持一百萬在線用戶；
-
CPU/網卡包量和流量/交換機流量等瓶頸；
-
單臺服務器支撐不下所有在線用戶/註冊用戶；
於是針對這些問題做架構改造，IM2.X的最終架構如下：
3. 千萬級 - IM3.X
業務發展：2005年，QQ同時在線突破一千萬。
第二代架構支撐百萬級用戶是OK的，但支撐千萬級用戶又有問題，表現如下：
-
同步流量太大，狀態同步服務器遇到單機瓶頸；
-
所有在線用戶的在線狀態信息量太大，單臺接入服務器存不下，如果在線數進一步增加，則甚至單臺狀態同步服務器也存不下；
-
單臺狀態同步服務器支撐不下所有在線用戶；
-
單臺接入服務器支撐不下所有在線用戶的在線狀態信息；
針對這些問題，架構需要繼續改造升級，IM3.X的最終架構如下：
4. 億級用戶 - IM1.X
業務發展：2010.03，QQ同時在線人數過億
第三代架構此時也不適應了，主要問題有：
-
靈活性很菜：“暱稱”長度增加一半，需要兩個月、增加“故鄉”字段，需要兩個月、最大好友數從500變成1000，需要三個月。
-
無法支撐這些關鍵功能：上萬好友、隱私權限控制、PC QQ與手機QQ別互踢、微信與QQ互通、異地容災。
除了不適應外，還有一個更嚴重的問題：
“IM後臺從1.0到3.5都是在原來基礎上做改造升級，但是：持續打補丁已經難以支撐億級在線，IM後臺4.0必須從頭開始，重新設計實現！”
決定重新打造一個這麼複雜的系統，不得不佩服當時決策人的勇氣和魄力！！
重新設計的IM4.0架構如下，和之前的架構相比，架構本身都拆分爲兩個主要的架構：存儲架構和通信架構：
通過上面對淘寶技術發展和手機QQ的架構發展，我們可以看到，這兩個實例證明了我們之前的推斷：對於提供互聯網服務的企業來說，互聯網技術的發展，背後的驅動力是業務的發展。