阿里技術分享：阿里自研金融級資料庫OceanBase的艱辛成長之路
本文原始內容由作者「陽振坤」整理髮佈於OceanBase技術公眾號。
1、引言
OceanBase 是螞蟻金服自研的分散式資料庫，在其 9 年的發展歷程裏，從艱難上線到找不到業務場景瀕臨解散，最後在雙十一的流量考驗下浴火重生，成為螞蟻金服全部核心系統的承載資料庫。這一路走來的艱辛和故事，螞蟻金服高級研究員、OceanBase 團隊負責人陽振坤將為你娓娓道來。
什麼是OceanBase資料庫？
是阿里巴巴集團自主研發的分散式關係型資料庫，融合傳統關係型資料庫強大功能與分散式系統的特點，具備持續可用、高度可擴展、高性能等優勢。廣泛應用於螞蟻金服、網商銀行等金融級核心系統。 在2015年雙11承載了螞蟻核心鏈路100%的流量，創下了交易、支付每秒支付峯值的新紀錄，在功能、穩定性、可擴展性、性能方面都經歷過嚴格的檢驗。
（本文同步發佈於：http://www.52im.net/thread-2072-1-1.html）
2、關於作者
陽振坤：博士、YOCSEF榮譽委員。
1984年進入北京大學，先後獲得數學學士、碩士以及計算機博士學位後留校，1997年破格晉陞為教授，1999年成為北京大學首批「長江學者獎勵計劃」特聘教授之一；
先後獲得北京市科學技術進步獎一等獎、國家科學技術進步獎一等獎（排名第四）、第六屆中國青年科技獎、北京市五四青年獎等；
曾先後擔任方正研究院副院長、北大計算機研究所副所長、聯想研究院首席研究員、微軟亞洲研究院主任研究員、百度高級科學家等；
現擔任淘寶研究員，主持淘寶海量資料庫系統的研究和開發。
3、相關文章
《阿里技術分享：深度揭祕阿里資料庫技術方案的10年變遷史》
《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》《現代IM系統中聊天消息的同步和存儲方案探討》《騰訊資深架構師乾貨總結：一文讀懂大型分散式系統設計的方方面面》《新手入門：零基礎理解大型分散式架構的演進歷史、技術原理、最佳實踐》《一套高可用、易伸縮、高並發的IM羣聊架構方案設計實踐》
4、資料庫：技術和市場的「死亡之谷」
資料庫在每個人的生活裏無處不在，不管是通訊、交通、金融行業，抑或是每天大家都在接觸的互聯網，所有這些業務的背後都是資料庫在支撐。
▲ 螞蟻金服 OceanBase 團隊負責人陽振坤
資料庫經歷了近半個世紀的發展，在理論上很成熟，在技術應用上也已經非常成熟了。
但是資料庫偏偏有一個特別高的門檻，原因是資料庫有三條特別苛刻的要求：
1）事務須並發處理： 資料庫要支持事務，所有人都希望用最小的處理資源，做到最大價值的事情。所以事務持續要做大量的並發處理；
2）數據一條不能錯： 一個資料庫如果數據錯了，就永遠沒有機會了。對於使用者而言，如果你會錯一條，你就有可能會錯一千、一萬條，這是沒有公司願意承擔的風險；
3）服務片刻不能停： 通訊系統、列車系統，甚至飛機航行系統的背後都是資料庫在支撐，這些系統一旦啟動，一分一秒都是不能終止的。
上面提到的這三條要求，任何兩個其實都好滿足。但是大家仔細想一想，這三個要求如果要同時滿足，就會變得極其困難。
同時，資料庫又是一個巨大的市場，對國家、對整個社會都非常重要。這就導致很多國家、很多企業都想做也正在做這件事，但是結果大家都做到了同一個思路上。後來者都成了先行者的模仿者，那麼這個模仿的代價就會變得很大。
今天作為一個後來者，你再去做這麼一套資料庫系統的時候，就真的很難說清楚你與先行者相比有多大的優勢。這也就造成了強者恆強、寡頭壟斷的局面，後來者很難居上。
資料庫同樣也有開源這條路徑，比如大家都瞭解的 MySQL。開源是免費的，對於很多對成本敏感的公司而言開源資料庫成為了替代商業資料庫的另一種選擇。
那麼在面對資料庫的「死亡之谷」這樣的困境下，為什麼我們還去花這麼多錢，投入這麼多設備，花這麼多年時間和人力再去做一個資料庫，究竟它的意義在哪兒？它又能夠產生多大的經濟價值？
既然有了開源的資料庫，阿里巴巴和螞蟻金服還要做這麼一個商業資料庫產品，其實這裡面是有本質原因的。很多人知道阿里巴巴今天已經 全面去 IOE：去掉了 Oracle 資料庫、IBM 小型機、 EMC 存儲。那麼很多人就在想，能不能在其他的行業，在鐵路、交通，電信、政府這些行業推而廣之，全部完成去 O 的進程呢？這個答案是否定的。
因為像阿里巴巴發展的這一套系統是基於 MySQL 的開源資料庫，跟商業資料庫在功能和性能上其實是有很大差距的。阿里巴巴當時在用它的時候，有很多事情資料庫是做不了的，那麼這些做不了的事情當時就放在應用軟體裏做。所以阿里巴巴在資料庫和應用軟體上都投入了很大的技術力量。這套系統拿到外部業務去用是不能徹底解決問題的。本質上這套系統是服務於阿里巴巴的專用系統，而不是一個通用的系統。
那麼有人會問，在我的企業裏，如果真的想去掉 IOE，該怎麼辦？你同樣要投入兩撥人，一撥人要去做資料庫，針對你的企業的需求來做相應的修改；還有一撥人要去做應用系統。但是問題是並不是所有的企業都像阿里巴巴有這麼多優秀的技術人員，這套東西其實很難去直接推廣應用。
所以，從一開始我們做 OceanBase 的目標就是——我們不想只做一個專用的系統，要做就一定要做一個通用的系統。我們希望今後 OceanBase 能夠服務於各行各業，再也不需要企業投入幾十幾百甚至幾千個人去改造、去重新做一套業務系統。
5、OceanBase 的機遇與創新
當時做 OceanBase 資料庫一個最根本性的原因就是需求的變化。因為這麼一套基礎系統，如果背後沒有需求的變化，從 0 到 1 自己做出來基本是不可能的。
2010 年春夏之際，我來到了阿里巴巴。去了之後發現當時有兩個因素影響了阿里巴巴關係資料庫的應用。
一個因素是並發，資料庫它是按照並發量來賣錢的。說直接點，就是按照處理器來賣錢。之所以要買這麼多處理器就是因為業務有這麼大的需求。那麼傳統的業務比如商場，一個商場就那麼幾個收銀臺，它是一個相對穩定而且比較小的並發量，大多數情況就是幾十幾百的並發量。
▲ 陽振坤分享經驗心得
隨著互聯網的高速發展，阿里巴巴天貓雙 11 幾乎完全改變了過去行業內相對穩定的並發量，突破了幾百萬人甚至是千萬人的同時在線購買。這個並發量跟過去的傳統業務場景相比是幾個數量級的增長，按照這個數量級去買商業資料庫，沒有一家企業買得起。
還有一個因素，當時我們叫它建站，其實就是搭建一個資料庫。過去建一個商場，建一個銀行的分店，這個週期是非常長的，有足夠的時間來規劃 IT 業務系統。互聯網業務是等不了的，就像當時 OceanBase 接的第一個業務給到我們的時間就是最多一個星期。現實是一個星期的時間根本連小型機的安裝調試都完不成。
原來的模式已經完全無法支撐互聯網快速發展的業務。所以這兩個需求的變化，是催生我們自己來做資料庫的很關鍵的因素。
6、OceanBase 關鍵性的技術革新
當時我找了幾個同事商量這個事情，我跟大家說，我們是天時地利人和都趕上，這件事情除非是被拍死掉，否則我們是肯定要把它做成的。這個過程真的非常艱辛，我們花了差不多五年的時間，才真正讓 OceanBase 有了關鍵的應用。
過去做資料庫的公司，不管是國內還是國外，大家都是為了做資料庫而做資料庫，那麼最後結果就是所有做傳統資料庫的廠商，大家的方案都很像。
因為資料庫有很成熟的理論和工程的方法，那麼如果我們按照以往的原則做過去，結果肯定也是一樣的。所以，其實我們走了另外一條路——做分散式。最早做這個東西可能都不叫資料庫，它更像是一個分散式系統，但是支持了事務的特性。這條路後來被證明確實是具有特別大的價值和意義。
當時我們在做 OceanBase 的時候，首先確定了幾件事情。第一件事就是我們要做分散式，因為我們的業務要建站，不做分散式靠大型機和小型機是不可能做得到的。
另外一件事是成本，什麼東西最便宜，量最大最主流的東西最便宜，它就是 PC 伺服器。小型機少則幾十萬，多則幾百萬，PC 伺服器頂多就是幾千幾萬塊的成本。
第三個要解決的就是可靠性問題。大家對資料庫的期望是永不宕機，永遠不出問題。可是 PC 伺服器到處都有，性價比也非常好，但是不容忽視的是它的故障率高。普通 PC 伺服器它遠遠達不到資料庫所要求的年可靠性五個九的要求。對普通 PC 伺服器而言，差的可能是兩個或者三個數量級，所以我們得首先把這個問題解決掉。我們用的就是分散式的辦法來解決。
我們運用的是分散式的一致性協議，直白一點就是一個多數派的選舉和投票協議。同時，我們把修改的增量直接放在內存裏，每次要查詢的時候，把內存硬碟的數據做一個 merge，那麼每天在業務相對的低谷期，再把內存中的數據整理回硬碟去。
做到了這幾件事情，這個系統就有了很好的性價比，我們的成本比傳統的資料庫至少低一個數量級，你只需要用普通的 PC 機，不需要用昂貴的硬體設施。同時，擴展能力會也變得很好。
7、OceanBase 的第一個業務：淘寶收藏夾
理想看起來很美好，但是現實特別骨感。這個項目剛啟動的時候，我們好不容易纔找到了幾個人，人手是嚴重不足的。另外一個更大的挑戰是時間：在做 OceanBase 資料庫之前，我去找我的老闆，他說給你 兩年時間 如果能把一個資料庫做出來就可以。當時我心裡想兩年雖然對於做資料庫來說時間確實太短，但是這兩年對於那時候的我們而言已經足夠支撐起最初的想法了。
技術最終還是需要通過業務落實下去，所以我找了一批業務方，花了很長時間跟對方溝通，最後終於有一個業務願意用我們的資料庫。當時他給我的時間期限是——兩個星期。
當時我就傻了，兩個星期要做個資料庫，這可怎麼辦？後來跟業務的同學反覆討論，最後他們同意說，你們先做個 demo 出來。於是我們就花了兩個月吭哧吭哧的做了一個 demo 出來。他們看了以後覺得比較滿意，後來這個事情就一直堅持做下去了。
最後，我記得是到了第八個月的時候，系統上線了。這個業務就是現在大家都在用的——淘寶收藏夾，這是 OceanBase 的第一個業務。如果沒有這個業務，我們現在也活不下來。
▲ 淘寶收藏夾業務
那麼這個業務到底有什麼特殊的地方？每個人都用過淘寶收藏夾，每次你打開收藏夾的時候，資料庫在背後其實做了很多事情：我們以單個商品為例，它需要到一個叫商品庫的地方，逐條紀錄核對，看看商品有沒有下架，有沒有參與促銷，有沒有參加其他的返點活動等等。
假如你收藏了 100 多件商品，它就要進去一條條的取出來看。本質上來講，這就意味著一百多次的隨機 IO。那麼當很多人同時來看的時候，其實一個 IO 就被放大了幾百倍，這時候有多少個硬碟都不夠用。
當時他們已經用了幾十臺伺服器了，按照業務的預估，第二年他們要買 400 臺機器，第三年的數量都不敢想像。當時我們想了一個辦法——我們做了一個 寬表，確切的講應該稱為 物化視圖。
▲ 淘寶收藏夾的寬表
首先我們把每個用戶收藏的信息聚集起來，這樣可以減少 IO，然後把收藏的商品放在這個列表裡。但是我們怎麼避免去訪問一百多次 IO 呢？我們的辦法就是找到一個時間點，當時是設定在每天晚上凌晨兩點。在這之前，我們就把這些信息全部 merge 到硬碟，然後從兩點開始，我們把新的修改都放在內存裡面。
所以每到兩點的時候，我們把兩點之前所有的信息都合到這張表裡，那麼這張表裡的信息在兩點整的時候是準確的，這時候我們不需要去訪問商品庫。兩點之後的修改，包括商品庫的修改是在內存裏進行的，這時候如果要看這些商品有哪些修改，商品只需訪問內存中的更新即可。
所以其實我們就是通過這樣一個手段，把每次收藏夾的展示，由原來的一百多次 IO 變成了一次。我們一下子就把淘寶收藏夾業務的整個 IO 降下來了。當時 OceanBase 確實是幫助業務實際解決了他們的問題，使得業務能夠更好的快速的發展。業務是一定要發展的，所以只有我們真正能夠解決他們的問題，我們這些做基礎系統做底層的人，才能活下去。
▲ 淘寶收藏夾架構圖
這是當時給淘寶收藏夾做的一個架構，中間是一個做修改的伺服器，所有的修改都在這一臺機器上進行。旁邊的機器是基線數據，就是分片切片以後，放到周圍這一圈進行。所以當時我們就用這個看上去很簡陋的一個方案來真正解決了淘寶收藏夾的問題。
當時收藏夾用了這個方案之後，伺服器的數量從原來預計的第二年要用幾百臺，最後其實只用了差不多二十幾臺伺服器，就把整個問題解決掉了。
8、OceanBase 0.3-0.4 版本：團隊面臨解散
從淘寶收藏夾項目之後，我們陸陸續續也做了不少項目，但是沒有一個項目能像淘寶收藏夾這樣對業務有明顯的價值和貢獻。
從那之後的整整兩年，我們找不到對 OceanBase 資料庫而言特別有價值的業務。那兩年對於我們而言特別特別困難，甚至整個團隊隨時面臨著解散。
2012 年底，公司把我們從淘寶調到支付寶，當時預估到支付寶在資料庫方面所面對的挑戰更大，後來證明確實如此。即使是這樣，當時仍然還處在一個非常困難的時期。到了支付寶一年多的時間，我們仍然很難找到新的業務，或者說價值比較大的業務來證明我們的價值。
9、OceanBase 0.5 版本：成功抗住 10% 流量
2013 年的夏天，支付寶希望全面去掉 IOE——去掉 IBM 的小型機，Oracle 的資料庫和 EMC 的存儲。當時面臨了一個問題，就是去掉之後是可以用 MySQL 來代替 Oracle，但是 MySQL 的主備鏡像其實是做不到主備完全一致的。
這個時候我們意識到：OceanBase 的機會來了。因為我們可以通過分散式的選舉跟投票來做，哪怕硬體本身不可靠，我們也能保證數據的不丟失。傳統資料庫本質上是藉助硬體的可靠性，也就是硬體需要達到五個九的可靠性來實現高可用的。就算出了故障，它的數據也能救得回來。但是這種手段需要非常高的成本，同時沒有足夠的擴展能力。
銀行雖然有很高的可用性，但是它的高可用性是用很高的硬體成本換來的。我們建議一定要淘汰這些高可靠的硬體，因為他們的成本實在太高了。一旦真的使用了高性能，高性價比的 PC 伺服器，那麼你就不可能再花那麼多錢去買高端的硬體。
所以我當時心裡很明白，如果這件事情我們做不成，這個項目就只有死路一條。
那麼，OceanBase 到底如何做到主備完全一致的呢？理論上我們也沒有辦法說完全做到主庫備庫的一致。我們用了另外一個辦法：主庫還是主庫，還是需要它快速的做事務，但同時主庫還要把事務的日誌同步給至少兩個備庫。兩個備庫中至少有一個收到了，那麼加上它自己就超過了半數，或者我們叫多數派。當多數的節點收到了這個事務，並且把它持久化到硬碟了，我們就認為這個事務是成功的。
所以這時候任何一臺機器壞掉，每筆事務在剩下兩臺機器裡面至少一臺存在。所以說即使主庫突然壞掉，另外兩臺機器經過握手，它們再選舉出一個新的主庫，那麼肯定可以繼續工作下去，同時可以保證數據是沒有損失的。
2014 年的時候，我們在會議室裏討論 支付寶交易庫的上線，當時吵得面紅耳赤，爭論了很久別人就是不願意上 OB。他們原來的交易、支付系統全都在 Oracle 上，當時的 Oracle 無論是在穩定性、可靠性還是性能方面，肯定比 OceanBase 要好得多。所以沒有人願意用。
最後，在 魯肅（螞蟻金服 CTO） 的力挺下決定切給 OceanBase 1% 的流量試試。因為那幾年業務發展的太快，當時 Oracle 的共享存儲已經扛不住這個流量，按照當時的業務流量去做壓測的時候，幾分鐘就要壞一塊盤。最後發現，把業務切掉 10%，才能勉強扛得住。所以那一年的雙 11 就把 10% 的流量切到了 OceanBase。OceanBase 也成功扛過去了那一年的雙 11。
10、OceanBase 1.0 版本：唯一支持分散式事務的商業資料庫
但是其實在 0.5 這個版本上線的時候，我們心裡非常清楚，這個版本是臨時的。我們當時選擇做多數派協議的時候，還是用了原來的想法，每個集羣還是中間有一個中心節點。這個事情一定不會是長久持續下去的，我們知道這個一定會遇到問題。所以當時其實交易庫還沒有完全上線，我們就已經啟動了 1.0 版本的開發。
2014 年到 2016 年，整整兩年的時間，我們投入了 40 多個人，全部投在 OceanBase 1.0 版本的開發上。整整兩年，這 40 多個人沒幹任何別的事情。所有的線上問題，版本修改、升級都是我們調出來的五個同學全部扛下來的。
有人會問什麼樣的因素讓這麼多人做了兩年才能把這個版本做出來？這個版本裡面我們主要做的一件事就是分散式。
如果你問分散式事務有這麼難嗎？我可以自豪地回答你：今天的商業資料庫裏有且只有一個是能夠支持分散式事務的，它就是 OceanBase。
OceanBase 通過分散式的一致性協議做到了系統的高可用性，就是說哪怕我們今天用的是比較廉價的，可靠性比較低的 PC 伺服器，但是我們的可用性其實會變得更高。因為單機的故障我們完全能夠自動的容忍掉，而且我們做到了現在的數據做不到的一件事情——哪怕主庫出故障，我們能夠保證數據沒有任何損失。
今天的銀行每年國家都要求他們至少做一次消防演習，銀行要到最前端的網關把交易紀錄撈出來核對，把這些賬對平了，備庫才能繼續服務。我們今天根本沒有這個問題，主庫出故障了，也就是幾十秒以後，新的主庫就會被選出來。因為只要剩下的機器超過半數，他們互相之間會通過握手把數據補齊，很快就能工作。其實這 30 秒大部分還是消耗在確定主庫是否真的有故障。
所以，我們用不可靠的硬體反而做到了更高的可用性，而且做到了數據真正的一致。
傳統的資料庫因為涉及到共享存儲，共享存儲是一個單一的設備，你只能放在一個機房。所以一旦那個機房出現了故障，你就只能靠備庫容災把系統恢復起來。
OceanBase 通過「三地五中心」部署實現城市級故障自動無損容災。比方說相當於你一共寫了五份日誌，放在三個不同的城市裡。任何一個城市哪怕出故障，比方說杭州斷網了，那麼剩下的依然超過半數，這個系統還是可以恢復工作的。這也是原來的傳統資料庫，不管想什麼辦法，都做不到的事情。
▲ 2018年 9 月 20 日雲棲大會 ATEC 主論壇現場剪光纜實況
前段時間，大家可能也看到了雲棲大會的新聞。螞蟻金服副 CTO 胡喜在 ATEC 主論壇現場模擬挖斷支付寶近一半伺服器的光纜。結果只過了 26 秒，模擬環境中的支付寶就完全恢復了正常。而這場 26 秒自斷伺服器現場演示的技術核心其實正是基於 OceanBase 的三地五中心架構方案。
2017 年，天貓雙 11 中螞蟻金服的全部核心系統，包括很多業務系統都放在了 OceanBase 上。去年我們創造了 25.6 萬筆 / 秒 支付峯值的世界紀錄，這下面還有一個數據，就是說我們為了要執行這 25.6 萬筆的支付，執行了 4200 萬條 SQL。
11、新的歷史機遇：走出去
所以從今天來看，OceanBase 在過去的歷史進程中面臨了一個個新的機遇，無論是處理器、操作系統還是資料庫，這些都是非常大的挑戰。
從 2016 年底，我們就開始做準備，OceanBase 一定要走出去。從我們成立的第一天起，團隊裏的每個成員的目標都是一致的：我們不是想做一個資料庫只是給自己用，我們要做一個資料庫真的去推動整個社會的進步，能夠讓整個社會的生產力發生變化。
所以，2017 年我們正式開始服務於外部，最早的兩家客戶是 浙商銀行 和 南京銀行，我們現在的客戶要多很多。從內部的應用到真正走出去服務於外部，真的是一個很大的挑戰，是一件很困難的事情。
回想這八年多來，OceanBase 走過的路：開始的頭兩三年，我們真的每天都在掙扎，每分每秒都在想著怎麼能讓自己活下來。到了 2013、2014 年，我們終於找到了一個真正的立足點，就是支付寶的交易庫。然後我們接著花了整整兩年的時間，真正在 OceanBase 1.0 版本把分散式做出來。在接下來的一到兩年時間裡，我們把支付寶的核心業務全部搬到 OceanBase 上。
關係資料庫確實是個門檻很高的東西，但是凡事有利有弊。門檻高意味著我們進來很難，別人進來一樣難。我們集中精力在做事務處理這一塊，它的門檻是很高，很不容易進去，但我們恰恰有這個機會能進去。我們費了很大的力氣跨進來了，別人可能費了全部力氣也進不來。
現在回想起來，能夠把最早的一些想法一些創新變成產品，真的是非常辛苦或者說非常痛苦的一條道路。但是我們做的所有事情其實還是從業務、從客戶中出發，只有技術真的能夠落到生產中去，落到用戶中去纔是真正有價值的，否則你做得再好也是一個空中樓閣。
到了今天，當我們走出阿里巴巴，走出螞蟻金服再來看，發現當你做的事情能夠提供十倍性價比的時候，其實真的有機會去顛覆一個產業，重新塑造一個行業。
附錄：更多精華文章匯總
[1] 有關大型互聯網系統架構設計的文章：
《淺談IM系統的架構設計》《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》《一套原創分散式即時通訊(IM)系統理論架構方案》《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》《蘑菇街即時通訊/IM伺服器開發之架構選擇》《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》《微信技術總監談架構：微信之道——大道至簡(演講全文)》《如何解讀《微信技術總監談架構：微信之道——大道至簡》》《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》《17年的實踐：騰訊海量產品的技術方法論》《移動端IM中大規模羣消息的推送如何保證效率、實時性？》《現代IM系統中聊天消息的同步和存儲方案探討》《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》《IM開發基礎知識補課(三)：快速理解服務端資料庫讀寫分離原理及實踐建議》《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》《微信朋友圈千億訪問量背後的技術挑戰和實踐總結》《王者榮耀2億用戶量的背後：產品定位、技術架構、網路方案等》《IM系統的MQ消息中間件選型：Kafka還是RabbitMQ？》《騰訊資深架構師乾貨總結：一文讀懂大型分散式系統設計的方方面面》《以微博類應用場景為例，總結海量社交系統的架構設計步驟》《快速理解高性能HTTP服務端的負載均衡技術原理》《子彈簡訊光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》《知乎技術分享：從單機到2000萬QPS並發的Redis高性能緩存實踐之路》《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》《微信技術分享：微信的海量IM聊天消息序列號生成實踐（演算法原理篇）》《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》《新手入門：零基礎理解大型分散式架構的演進歷史、技術原理、最佳實踐》《一套高可用、易伸縮、高並發的IM羣聊架構方案設計實踐》《阿里技術分享：深度揭祕阿里資料庫技術方案的10年變遷史》《阿里技術分享：阿里自研金融級資料庫OceanBase的艱辛成長之路》>> 更多同類文章 ……[2] 更多感悟和思考《一個微信實習生自述：我眼中的微信開發團隊》《微信程序員創業總結：如何提高Android開發效率》《如何做一個合格的 iOS Team Leader》《程序員中年危機：拿什麼拯救你，我的三十五歲》《一個魔都程序員的3年：從程序員到CTO的歷練》《為什麼說即時通訊社交APP創業就是一個坑？》《致我們再也回不去的 Github ...》《一名90後二流大學程序員的自述：我是如何從「菜鳥」到「辣雞」的》《一個魔都程序員的3年：從程序員到CTO的歷練》《選擇比努力更重要：我是如何從流水線工人到程序員的？》《程序員的抉擇：必須離開帝都——因為除了工作機會，還有什麼值得留戀？》《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》《幹了這碗雞湯：從理髮店小弟到阿里P10技術大牛》《程序員神級跳槽攻略：什麼時候該跳？做什麼準備？到哪裡找工作？》《感悟分享：在騰訊的八年，我的成長之路和職業思考》《調皮的程序員：Linux之父雕刻在Linux內核中的故事》《老羅最新發布了「子彈簡訊」這款IM，主打熟人社交能否對標微信？》《迷茫中前行：一個專科渣渣菜鳥的編程入門感悟》《盤點和反思在微信的陰影下艱難求生的移動端IM應用》《QQ現狀深度剖析：你還認為QQ已經被微信打敗了嗎？《機會不給無準備的人：一個Android程序員屢戰屢敗的悲慘校招經歷》《笑中帶淚的碼農往事：入職三天被開，公司給100塊叫我走人，有我慘？》>> 更多同類文章 ……[3] 互聯網大廠的技術故事：《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》《QQ和微信兇猛成長的背後：騰訊網路基礎架構的這些年》《閑話即時通訊：騰訊的成長史本質就是一部QQ成長史》《2017微信數據報告：日活躍用戶達9億、日發消息380億條》《騰訊開發微信花了多少錢？技術難度真這麼大？難在哪？》《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》 《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》 《技術往事：「QQ羣」和「微信紅包」是怎麼來的？》 《開發往事：深度講述2010到2015，微信一路風雨的背後》 《開發往事：微信千年不變的那張閃屏圖片的由來》 《開發往事：記錄微信3.0版背後的故事（距微信1.0發布9個月時）》 《一個微信實習生自述：我眼中的微信開發團隊》《首次揭祕：QQ實時視頻聊天背後的神祕組織》《為什麼說即時通訊社交APP創業就是一個坑？》《微信七年回顧：歷經多少質疑和差評，才配擁有今天的強大》《前創始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》《QQ的成功，遠沒有你想像的那麼順利和輕鬆》《QQ現狀深度剖析：你還認為QQ已經被微信打敗了嗎？》《[技術腦洞] 如果把14億中國人拉到一個微信羣裏技術上能實現嗎？》 《QQ和微信止步不前，意味著即時通訊社交應用創業的第2春已來？ 》>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2072-1-1.html）
推薦閱讀：
