十年前在騰訊做技術，是一種什麼樣的體驗？
那是2009年的一個周五晚上，Ben清楚地記得，那天一坐上公司班車就累得睡著了，直到一路被載到終點站，然後一臉懵逼下了車。在這之前，為了修復多個機房同時掉電對某國民級應用的影響，Ben和團隊十幾位小夥伴已經30多個小時沒合上眼。
因為城市建設或自然災害，機房掉電、電纜挖斷這樣的「黑天鵝」事件幾乎每天都在發生。慶幸的是，騰訊技術團隊在做好機房容災的同時，對數據安全更是重視，除了在線多副本之外，早在那時就建立起了完備的數據災備系統。
每一次的全力作戰，換來的是對數據安全、技術升級愈加上緊發條。
每一項成功的業務背後，必然有一個成功的技術團隊做支撐。21歲的騰訊，伺服器總量超過了100萬台，數據存儲規模達到EB級別，帶寬峰值達到了100T，在全球布局超過1300個加速節點……To C產品動輒數億次的訪問，To B業務安全、穩定的交付，都用到了海量的技術。
站在2019年的尾聲，讓我們來講述一段關於騰訊技術的進化史。
1998-2005，海量之道
「化繁為簡，好鋼用在刀刃上」
QQ 是騰訊最早的核心業務，它的架構演變是騰訊技術發展和成長的一個縮影。
2004年，整個騰訊只有5000台伺服器，那時3G時代還沒有來臨，卻背負著QQ這一「甜蜜的負擔」——QQ同時在線人數短短四年內增長了100倍，到2005年2月正式突破了1000萬，在線人數每提升一個量級，技術難度也陡然上升。
2004年，QQ遊戲也超過了100萬在線，那是遊戲行業黃金期的開啟。隨著QQ秀、QQ遊戲、QQ空間等網際網路增值業務的興起，網際網路世界正在向用戶敞開大門。用馬化騰的話說，那也是騰訊業務發展的海量時代。
社交加上大量日誌、相冊的存儲，對當時騰訊的網際網路基礎設施架構提出了全新的挑戰。
那時，中國網際網路基礎設施還不發達，很多用戶都是撥號上網。北邊是網通，南邊是電信，分布過碎，成本會增加，數據一致性很難保證，用戶體驗會不好。於是，騰訊花了很大力氣做三網融合，這在當時是一個很難的技術。
2005年推出的QQ空間是一個寬頻應用，跟IM、QQ遊戲這種窄帶應用有很大差別，對網絡等基礎設施要求更高，用戶的交叉訪問也帶來很大的技術挑戰和難度。
面對海量服務，騰訊的方法是化繁為簡。做海量業務的時候，技術難度就如同造房子，不光造得高，材料還要省，成本還要低，所以就得抓住關鍵技術支撐點，把好鋼用在刀刃上。
在很多技術細節上，騰訊是精打細算的，主張將更好的技術資源節約出來留給關鍵使用場景，才能支撐QQ的整體上升。比如有很多場景未必要用通用的資料庫來解決問題，用一些簡單的數據技術處理方式，反而成本更低、效率更高；早期QQ有很多關於會員的標記，騰訊捨不得為每一個標記用1個字節（Byte），而用的是1個比特（Bit）。
這套基於「有損服務」、「動態運營」、「大系統小做」、「過載保護」、「柔性可用」、「先抗住再優化」等價值觀和方法論的不斷優化架構體系，被騰訊人稱為「海量服務之道」。
為了推廣這套理念，騰訊聯合創始人、前CTO張志東親自挂帥，在公司內部搞了一系列關於海量之道的面授課程。一時間，海量服務之道被騰訊後台和開發同學奉為圭臬。
「大師兄」張志東早期為QQ設計了整體架構，這個架構支撐著QQ業務從無到有，直到後來上億用戶同時在線。由於沒有錢買那麼多的伺服器，反而迫使團隊自身不斷優化，從而奠定了騰訊在中國首屈一指的技術服務。
騰訊早年有很多業界領先的技術。比方說，QQ同時在線人數從10萬到100萬，單機處理能力已經超過同行業10倍以上。當時騰訊有一個重要的技術創新——PCT架構，它使得別人的一台機器只能做1000個在線連接時，騰訊能做到1萬。
此外，QQ空間時期的支持LRU的sharememorycache，基於裸設備的file system等，對當時的騰訊甚至整個網際網路行業來說都是拓荒者。
多年後，擔任公司副總裁的姚星在內部交流時回憶，2004年他剛加入騰訊時，公司特別重視公共組件技術，當年就有一個著名的公共組件叫TLib，基本上覆蓋了當時所有的BU（當時的事業部），很多代碼也都是公司創立以來就有的，「只不過隨著業務的演進，很多公共技術失傳了」。
2006，互聯網大爆炸
「業務越繁雜，意味著爆炸半徑越大，技術難度越高」
騰訊技術體系經歷了一個從即時通訊到社交圖片、由窄帶到寬頻的「從瘦到胖」的過程，當時騰訊希望用很傳統的Web型業務架構解決問題，而通過解決這些問題，最終在海量存儲方面積累了豐富的經驗。
這裡，不得不提到一個對騰訊技術演進至關重要的應用——QQ相冊。2005年開始，QQ空間大火，那時數位相機開始在國內興起，QQ相冊上線後，很快日均上傳量超過1000萬張，訪問量級和用戶規模與Facebook分庭抗禮。
從幾百萬到1000萬，再到後來的一天1億的上傳量，對帶寬、伺服器消耗很大。當時，國內的存儲伺服器要麼是原來的小型機，要麼是磁碟櫃或刀片機，性能和成本都遇到了非常大的挑戰。
2006年，騰訊開始研究網際網路場景下的海量存儲架構，結合自身業務場景自研了分布式存儲TFS（Tencent File System），支持了QQ相冊每天億級別的圖片上傳。
這是當時國內第一個真正意義上面向網際網路海量數據存儲的技術平台，推動了分布式存儲技術的發展。
從2006年起至今，TFS作為數據存儲的底層平台，一直承載著包括QQ相冊、微雲、微信朋友圈等業務的非結構化大規模數據，並在2013年以雲服務的方式構建出最具代表性的對象存儲等產品，對外提供安全可靠的高性能雲存儲服務。
2008年秋天，華中科技大學的畢業生Ben帶著QQ後台開發的offer走進騰訊辦公樓時，發生了一點小小的插曲。當年，遇上資料庫這一塊大量擴招，公司於是去其他部門拉來了一些應屆畢業生，Ben很「不幸」地成為了其中之一。要知道，那時進QQ後台是多少人羨慕不來的工作。
塞翁失馬，焉知非福。沒想到這一腳，正好踏進了國產資料庫發展的黃金十年。
資料庫作為騰訊最核心最基礎的後台服務之一，是存儲QQ用戶帳戶信息和關係鏈信息的海量集群，它承載了百萬級每秒的訪問量、十億級的帳戶數、百億級關係鏈。
騰訊資料庫的發展經過了幾個階段，在敏捷開發的Web時代，LAMP技術架構非常流行，以MySQL為代表的開源資料庫成為首選。隨著社交業務的迅猛發展，QQ活躍帳戶過億，QQ空間訪問峰值達到百萬/秒，對資料庫的性能、成本和擴展性挑戰非常大，騰訊開始走上自研資料庫的道路。
「計算機、網際網路的世界裡，有多少能真正被稱為『科學』的技術？資料庫算得上一種。」說起來，Ben有些感慨。
2009年，QQ空間內嵌的「QQ農場」、「搶車位」等社交遊戲開始流行起來。QQ農場創造了當時國民網遊的峰值，根據當時的數據，QQ農場的月活躍用戶達到了3.2億，註冊帳號占到了中國人口的2/3。
一時間，「偷菜「風靡全國，成為社交最熱的話題，更有甚者一個晚上設置兩三個鬧鐘爬起來偷菜。然而每偷一棵菜，就要改寫一下資料庫，QQ農場跟相冊的情況還不太一樣，農場的訪問量特別大，數億用戶守在電腦前，菜一熟立馬就去摘，這樣的高並發使得資料庫團隊猝不及防。
當時騰訊面向結構化存儲的SQL/NoSQL資料庫都是基於機械磁碟設計的，內存緩存部分數據，但機械磁碟的性能是有天花板的，光資料庫就要耗上上萬台機器，成本根本無法接受。
Ben和隊友們想了個辦法，借鑑關係型資料庫的日誌技術，實現了All DRAM的分布式存儲系統，並在All DARM和All Disk兩套存儲系統之間通過一個調度系統，把訪問最頻繁的資料庫放在內存里，每隔一段時間，內存再向硬碟同步這部分數據。根據訪問規律，把數據在內存和磁碟之間做調度，這樣一來成本就降低了。
經受過海量業務打磨的CDB(SQL)、CKV(NoSQL)後來也成了騰訊雲資料庫最早的一批種子產品。
技術的積累和前進需要有落地的應用場景。過去21年，騰訊是中國網際網路服務面最廣、場景最多、用戶時長最長的公司，全業務性作戰是騰訊的重要標籤。當業務種類越繁雜，意味著爆炸半徑越大，技術難度也越高。騰訊技術基礎設施的建設就是在這個階段快速累積和疊代。
創業初期，騰訊用的是主流市場通用的2U或者1U機架式伺服器。2007年，騰訊定製了第一款Twins伺服器，將機架上架密度提升了100%。在定製各類機型的同時，實現了一套大規模伺服器上架和管理系統，具備一天內交付1000台以上設備的能力，保障了產品的快速增長。
2006年，整個公司的業務規模直線上升，騰訊已經沒有更多場地去擺放支持業務增長的機架和伺服器了，而光是租用數據中心成本控制力度並不夠。因此，騰訊開始嘗試自建數據中心。
到了2007年，騰訊第一個自建數據中心在深圳寶安落地，得益於自建數據中心的高度自主可控性，騰訊的第一個TMDC微模塊數據中心也在此試驗成功。這種成功的經驗迅速在全國各地複製，騰訊落地於華南、華東、華北三個核心區域的數據中心，覆蓋了至少9個城市。
2012，在微信紅包種一棵「樹」
「微信紅包是什麼？相當於天天秒殺」
騰訊內部有這樣一個傳統，一些快速成長的業務或遇到一些突發事件，公司內會快速集結一直技術團隊來支援，這樣的隊伍被稱為「特種部隊」。
2014年冬天，Eric就加入了微信紅包「特種部隊」。2011年，微信上線，2014年，微信紅包橫空出世，那一年除夕夜，微信紅包搖一搖總次數達到110億次，峰值1400萬次/秒。如何扛住海量數據、高並發的挑戰？
在Eric看來，微信紅包這個場景挺有意思，「電商有一個秒殺，微信紅包是什麼？相當於天天秒殺。」
單一的支付場景其實挑戰不大，發一個紅包到一個一兩百人的群，可能幾秒鐘就被搶完，整個業務鏈完成後需要調用的資料庫、存儲，除了高並發下的平均延時要求是非常高，也需要非常低的尾延時。支付背後的金融屬性又需要被嚴肅對待，一分錢都不能錯。
在這個階段，騰訊引入了一致性協議、廣義事務（包括單機事務、多地多中心分布）等技術方案，保障了數據的可用性和一致性。
2012年是中國網際網路的分水嶺，手機QQ的消息數第一次超過了QQ，大多數用戶的主要時間開始花在手機上。
2012年之前，騰訊幾乎所有人都在做PC網際網路，無線應用部門負責把公司所有的產品無線化。當用戶都開始往手機上轉移，各部門也紛紛醒悟過來。2012年，騰訊完成了大的組織變革和轉型，開始全BU的無線化。
移動網際網路對於技術的要求與PC網際網路並不一樣：首先，PC網際網路是基於幾乎全球唯一的Windows平台，移動網際網路則要面對iOS、Android、WP、黑莓等多種系統平台，各類應用需要開發適配不同OS版本；其次，移動網際網路的地盤面積是三到六寸大的移動終端螢幕，手機、平板電腦等算力較差，硬碟、內存、CPU型號等參差不齊，伺服器就需要體現多樣性。
微信的出現，幫助騰訊獲得了第一張移動網際網路時代的「船票」，同時也提出了新的挑戰——比如需要在用戶基數龐大的情況下處理高並發問題；社交關係鏈對資料庫、存儲調用的安全性和穩定性要求極高；每次微信版本更新都需要適配不同手機型號、不同作業系統。
為此，工程師們決定在資料庫上種上一棵「樹」，也就是在NoSQL資料庫上實現關係資料庫才有的樹結構。
換句話說，整個資料庫結構不再是一個統一的二機制數據了，而是一個關係型資料庫的樹枝狀結構，這棵樹分一、二、三、四級的分級，設置父節點、子節點、生枝節點，整個關係就出來了，當其中某一個枝節需要修改時，只需要改那個枝節，數據量就會減少很多。
「種樹」還有一個好處，查詢效率很高。例如搶紅包這個場景，用戶需要回去查詢朋友圈搶紅包的記錄，按照以前的做法，需要把用戶所有搶紅包記錄全都拉出來，數據量就很大了。而在「樹」的結構中，當你發起一個查詢時，只需要查一個節點就行，不需要把整個數據拉出來再往裡面塞。
2009年至2012年，QQ的體量從1000萬在線發展到1億在線；2012年及隨後的6年間，微信日活躍用戶數從1億發展到10億。在姚星看來，騰訊貢獻的最大價值其實是從1998年開始，經歷QQ、QQ空間、微信積累的技術方法論：動態運營、雲中成長、有損服務。
2012年還有一個重要節點——虛擬化技術的成熟。虛擬化的過程，是把物理機變成虛擬機的過程，這意味著在超大規模數據中心和高速網際網路的基礎上提供雲服務成為了可能，騰訊雲主機管控平台Vstation做到了每分鐘交付千台虛擬機的能力，使得一個中等規模公司的計算需求可以快速得到滿足。
虛擬化是雲計算區別於傳統計算模式的核心特點，也見證著下一個時代的到來。
雲潮湧來
「騰訊走向雲的時代，是長期以來技術發展、演進的必然。」
為了支撐起QQ農場的正常運行,騰訊曾在短短一個月內額外採購與上架了幾千台伺服器到機房。這也讓騰訊意識到，「流量到來前，如何設計一個高可用的IT架構」、「流量激增時，如何快速補充伺服器資源」、「流量下降後，如何不浪費閒置伺服器資源」是業界普遍存在的難題。而這正是騰訊多年服務海量用戶所積累的能力。因此，騰訊要把這種能力通過騰訊雲開放給合作夥伴。
許多人還記得2014年滴滴和快的之戰。那個冬天，為了搶占市場，大量補貼像雪花般投放給用戶，滴滴的訂單量從十萬快速增加到百萬級別，每到早晚高峰，系統和程式設計師們不堪重負：
交易表龐大且訂單量暴增，MySQL性能已跟不上；司機在線量上不去，管理在線的pushserver（司機在線系統）是用java編寫的，LBS（周邊檢索系統）使用mongodb，穩定性和性能沒人能搞定。
當滴滴創始人程維愁眉不展時，騰訊連夜調集了一支「精銳部隊」前去支援。
正月的北京乍暖還涼，時任騰訊架構平台部負責人謝明博士趕到北京時，團隊已連續救火多天。謝明和團隊盤算了一下，隨即做了這樣幾件事：
用騰訊自身的框架和協議重寫了pushserver和LBS，替換了原有的java和php+mongodb實現，解決了接入上限的問題；與滴滴團隊一起在打車業務邏輯中增加了幾個關鍵的柔性降級開關，比如說超過警戒容量之後的訂單丟棄和安撫通知。
因機房條件艱苦，中間同機房其他公司的產品發生疑似攻擊的情況，把帶寬打滿了，一點小小的流量就可能將整個系統弄垮。於是，雙方聯合團隊做出了一個艱難的決定——將滴滴的整個系統，平遷到騰訊內部機房。
幾個月後的騰訊戰略大會，邀請創業夥伴現場分享。程維分享滴滴打車經歷多少次的九死一生時，眼圈紅紅的，最後特別提到了那一夜：2014年2月23日凌晨，滴滴打車的服務，成功的從滴滴自運營機房，遷移到騰訊深圳機房，幾天幾夜的不眠搶修，這一刻終於綻開笑顏。
現任騰訊TEG雲架構平台部總經理的謝明2006 年加入騰訊，主要負責作業系統和晶片相關的計算、CDN和霧計算相關的接入、對象/塊/資料庫相關的存儲技術研發和運營工作。
滴滴不是騰訊雲的第一個客戶，但是表明了騰訊做雲的一個出發點。謝明說：「確實有很多創業公司沒有精力或技術放在基礎設施和業務發展上，有雲的話情況會好很多。」
從2010年開始，QQ空間、相冊、騰訊視頻等一系列自研業務的打磨，幫助騰訊在視頻、直播等領域積累了強大的整套解決方案和能力。於是在2015年，騰訊雲順利抓住了直播的風口，迎來了第一波大爆發。
對於直播而言，平時有明顯的波峰、波谷效應，沒有直播的時候流量不高，一旦有直播的時候有很大突發。今年S9，騰訊云為全網90%流量護航，直播流量承載將再創新高，考驗的是雲廠商智能調度CDN的能力、彈性伸縮的計算能力、支撐海量高並發的資料庫能力，技術保障和護航的能力。
騰訊雲過去使用的是第三方CDN廠商的服務，隨著體量不斷增長，許多技術需求、帶寬壓力以及成本問題都不是一家供應商能夠解決的。因此，騰訊雲走上了CDN的自研道路。
雲時代面臨許多新的場景，對技術體系構成了新的挑戰。2015年前後，騰訊內部已經明顯感覺到了這一變化，於是在網絡設備、伺服器等技術領域，騰訊加快了自研的腳步。
例如在存儲上，雲時代考慮的是如何利用好10G乃至100G網絡，使得這一台的每一個伺服器的計算和存儲能力都能得到釋放，於是騰訊研發了下一代存儲系統，真正做到了按需擴容，利用率整體上可以達到90%以上，單集群可以管理百萬級別節點，同時大幅降低了人工的運維成本。
資料庫上，騰訊通過開源託管、商業合作、自研三線齊發，提供超過20 種資料庫產品，以及數據備份、SQL 審計、數據管理、數據遷移等服務等生態工具，讓用戶獲取最佳的上雲體驗。
網絡方面，騰訊基於自研設備和SDN 來構建第四代網絡架構。比如，在自研設備上，騰訊自研交換機TCS83支持單晶片100G埠，自研光網絡設備OPC-4，單通道轉發能力達到業界頂級600G水平。通過自研，網絡設備TCO下降20%+。
產業網際網路時代，各行各業對雲計算有更高性能和穩定性訴求，騰訊通過DPDK、智能網卡等軟硬體方案，將網絡、存儲等IO消耗卸載到硬體上，實現了虛擬機零損耗和虛擬機之間的零干擾。同時，在國內率先推出FPGA伺服器、高性能GPU伺服器等異構計算，滿足各行業用戶的不同需求。
今年10月29日，騰訊雲正式對外發布的自研伺服器「星星海」，是騰訊第一款真正為雲而生的伺服器。在設計過程中，結合數據中心實際部署環境要求，針對雲端的計算、存儲,網絡等場景做了重點優化，能夠有效滿足騰訊雲98%應用場景需求。同時，通過精細的硬體設計大幅度降低硬體成本和運營成本。
2018，騰訊930變革
「開源協同，自研上雲。」
過往，產品和業務的成功是騰訊公司技術成功的先決條件，而每一個產品為了快速制勝，就要擁有一支只服務於自己的技術團隊。
這也導致騰訊內部的許多業務都各自形成了一個技術閉環，每個業務事業群從邏輯層、數據層到後端的容器或虛機層，都是獨立的一套技術框架和技術體系。
回到2013年甚至更早，騰訊開始做雲業務時，馬化騰就問過一個問題：「為什麼不推動自研的業務上雲？起碼SNG的業務就該做示範去上雲。」
當時，SNG內部做了一些上雲的局部嘗試，但並不太敢鋪到全公司推廣。過去，騰訊的基礎架構經歷過海量業務的百般挑戰，如果把騰訊的自研業務當成一個公司來看，它可能是目前騰訊雲最大的客戶，也是最難服務好的客戶。大家有很高的技術水平，要求也很刁鑽。
騰訊技術全面走向開放「東風」，來自2018年的「930」變革。「930」之後，為了技術體系革新，騰訊內部成立技術委員會，啟動「開源協同」和「自研業務上雲」的兩大戰略方向。
「開源協同，自研上雲」這兩大革命，目標非常明確，就是要打造騰訊自己的技術圖譜和開發武器庫，同時為2萬多名技術人員搭建一個無縫協同的工作機制，同時為全行業輸出更多的雲的經驗。
以資料庫為例，騰訊資料庫目前提供了近二十款產品，開發者可以根據自己的需求取用，做電商的可以選用完全兼容MySQL的CDB，需要用到LBS能力可以選用完全兼容MongoDB的文檔資料庫，需要商業級資料庫能力可以選用新的雲原生資料庫CynosDB。
騰訊自研作業系統、自研網絡設備、自研交換系統是遵循協議的，協議上可以與其他運營商互聯互通，T-Block數據中心在行業中也有聯盟，通過聯盟能夠把技術和開發者共享，讓大家都能從中獲益。
騰訊業務量龐大，僅社交業務就包括QQ 和空間的體量有近二十萬台伺服器，分布在全國三地，要把如此龐大體積的業務搬到雲上，無異於「把大象搬到雲端」；同時，如何撬動體量、影響力比較大的項目進行開源協同，也面臨著重重難關。
但是對於每一個身在其中的開發者而言，這是一個新世界的開始。