默認
打賞 發表評論 3
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
閱讀(6678) | 評論(3 收藏3 淘帖2 2

本文來自微信團隊工程師張文瑞的技術分享,由“極客邦科技Geekbang”編輯發布,即時通訊網收錄時有修訂和改動。原文地址:mp.weixin.qq.com/s?__biz=MzAxNDU2MTU5MA==&mid=208037085&idx=1&sn=fb093eecec51c525f1cd3685645cef1a,感謝原作者的分享。


一、開場白


謝謝大家!我是來自騰訊WXG技術架構部的張文瑞,今天下午跟大家分享的主題是:微信團隊是如何從0到1實現“有把握”的微信春晚搖一搖紅包系統的

回憶一下春晚的活動,有什么樣的活動形式呢?

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_1.jpg

當時我們是直接復用客戶端搖一搖入口,專門給春晚搖一搖定制了一個頁面,可以搖出“現金拜年”、“紅包”。底下的紅包肯定是大家比較感興趣的,也是今天下午重點介紹的內容。

精彩的活動背后一定會有一個設計獨到的系統,微信春晚搖一搖紅包系統就是這樣。

二、分享者


社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_zhangwenrui.jpg

張文瑞:微信高級工程師,微信接入系統負責人。一直從事后臺系統設計開發,早期涉足傳統行業軟件,后投身互聯網。作為微信最早的后臺開發之一,見證了微信從零開始到逐漸發展壯大的過程。

張文瑞還分享了微信其它方面的技術文章,您也可能感興趣:

三、系列文章


❶ 系列文章目錄:


❷ 其它相關文章:

四、從理論到實現:v0.1原型系統


4.1、概述


社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_2.jpg

我們看一下這個系統,當時做了一個原型系統,比較簡單,它已經實現了所有的功能。

如上圖所示,搖那個手機的時候會通過客戶端發出一個請求,接入服務器,然后搖一搖服務,進行等級判斷,判斷以后把結果給到后端,可能搖到拜年或紅包,假設搖到紅包,上面有LOGO和背景圖,客戶端把這個LOGO和背景圖拉回去,用戶及時拆開紅包,拆的請求會來到紅包系統,紅包系統進行處理之后會到支付系統,到財富通的轉帳系統,最終用戶拿到紅包。

拿到錢以后,只是其中一份,還有好幾份是可以分享出去,我們稱之為“分裂紅包”,通過信息系統轉發給好友或群里,好友跟群里的人可以再搶一輪。

整個過程歸一下類,叫:資源流、信息流、業務流、資金流,今天講的主要是資源流跟信息流。

原始系統看起來比較簡單,是不是修改一下直接拿到春晚上用就可以了?肯定不行的。

到底它有什么樣的問題呢,為什么我們不能用,在回答這個問題之前想請大家看一下我們面臨的挑戰。

4.2、我們面臨怎樣的挑戰?


社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_3.jpg

第一個挑戰是比較容易想到的,用戶請求量很大,當時預計7億觀眾,微信用戶也挺多的,當時預估一下當時峰值達到一千萬每秒,通過圖對比一下(見下圖),左邊是春運搶火車票,一秒鐘請求的峰值是12萬,第二個是微信系統,微信系統發消息有個小高峰,那時候峰值每秒鐘是33萬,比較高一點的是預估值一千萬每秒,右邊是春晚時達到的請求峰值是1400萬每秒

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_aaa.jpg

這個活動跟春晚是緊密互動的,有很多不確定因素,體現在幾個方面:

  • 1)在開發過程中,我們的活動怎么配合春晚,一直沒有定下來,很可能持續到春晚開始前,顯然我們的客戶端跟我們的系統到那時候才發布出去,這時候我們的開發就會碰到比較多的問題了;
  • 2)在春晚過程中,因為春晚是直播型節目,節目有可能會變,時長會變,順序會變,活動過程跟春晚節目緊密銜接在一起,自己也是會有挑戰的,這也是不確定的因素;
  • 3)再就是我們系統是定制的,專門為春晚定制,只能運行這么一次,這是挺大的挑戰,運行一次的系統不能通過很長的時間,檢查它其中有什么問題很難,發出去了以后那一次要么就成功了,要么就失敗了;
  • 4)因為春晚觀眾很多,全國人民都在看,高度關注,我們必須保證成功,萬一搞砸了就搞砸在全國人民面前了。這么大型的活動在業界少見,缺少經驗,沒有參考的東西。還有就是我們需要做怎樣的準備才能保證萬無一失或者萬有一失,保證絕大部分用的體驗是OK的,有很多問題需要我們不斷地摸索思考。原型系統不能再用的,再用可能就掛了。

4.3、原型系統存在哪些問題?


原型系統有哪些問題呢?

  • 1)第一個問題:是在流量帶寬上,大量的用戶請求會產生大量的帶寬,預估帶寬峰值是3000pb每秒,假設我們資源是無限的能夠滿足帶寬需求,也會碰到一個問題,用戶搖到以后有一個等待下載的過程;
  • 2)第二個問題:在接入質量這一塊,我們預估同時在線3.5億左右,特別是在外網一旦產生波動的時候怎么保證用戶體驗不受損而系統正常運作;
  • 3)第三個問題:請求量很大,1000萬每秒,如何轉到搖一搖服務,搖一搖服務也面臨一千萬請求量,我們系統要同時面對兩個一千萬請求量,這不是靠機器的,大家都有分布式的經驗,這么大請求量的時候任何一點波動都會帶來問題,這是一個很大的挑戰。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_4.jpg

4.4、我們是如何解決這些問題的?


針對以上幾點,我們詳細看一下每一點我們是怎么做到的。

我們首先看一下信心指數,把這個系統拿到春晚去跑有多少信心,這里的指數是10,如果這個系統拿到春晚去用,而且還成功了,這個概率是10%。

當然我們的系統不能建立在運氣的基礎上,應該怎么做?

  • 1)帶寬利用:在帶寬這一塊客戶端可以搖到多種多樣的結果,結果大部分都是靜態資源,靜態資源我們可以提前制作出來下發到客戶端,在后臺做了資源推送的服務,客戶端拿到列表以后可以先行下載,客戶端利用閑時把資源拉過去。碰到幾個問題,資源交付情況的問題,需要增量的發下去;
  • 2)資源更新;
  • 3)下載失敗:資源下載失敗,失敗的話怎么辦呢;
  • 4)資源覆蓋率:依靠這個系統下載資源的用戶,比如覆蓋率只有20%、30%,兩個東西就沒有意義了,覆蓋率要達到90%左右;
  • 5)離線下載:離線資源下載,萬一有些人把里面的東西修改了,可能會產生意想不到的結果,怎么保證離線資源的安全。

這里有個數據,2月9號到2月18號下發資源65個,累積流量3.7PB,峰值流量1Tb/s。通過這種方式解決了下載資源的問題。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_5.jpg

再就是外網接入質量,在上海跟深圳兩地建立了十八個接入集群,每個城市有三網的介入,總共部署了638臺接入服務器,可以支持同時14.6億的在線。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_6.jpg

所有用戶的請求都會進入到接入服務器,我們建立了18個接入集群,保證如果一個出現問題的時候用戶可以通過其它的接入。

但是在我們內部怎么把請求轉給搖一搖服務,搖一搖處理完還要轉到后端,怎么解決呢?

解決這個問題代價非常大,需要很多資源,最終我們選擇把搖一搖服務去掉,把一千萬每秒的請求干掉了,把這個服務挪入到接入服務。除了處理搖一搖請求之外,所有微信收消息和發消息都需要中轉,因為這個接入服務本身,搖一搖的邏輯,因為時間比較短,如果發消息也受影響就得不償失了。

不過,這恰好有一個好處,我們的接入服務的架構是有利于我們解決這個問題的。

在這個接入節點里分為幾個部分。一個是負責網絡IO的,提供長鏈接,用戶可以通過長鏈接發消息,回頭可以把請求中轉到另外一個模塊,就是接入到邏輯模塊,平時提供轉發這樣的功能,現在可以把接入邏輯插入。這樣做還不夠,比方說現在做一點修改,還需要上線更新,搖一搖的活動形式沒有怎么確定下來,中間還需要修改,但是上線這個模塊也不大對,我們就把接入的邏輯這一塊再做一次拆分,把邏輯比較固定、比較輕量可以在本地完成的東西,不需要做網絡交互的東西放到了接入服務里。

另外一個涉及到網絡交互的,需要經常變更的,處理起來也比較復雜的,做了個Agent,通過這種方式基本上實現了讓接入能夠內置搖一搖的邏輯,而且接入服務本身的邏輯性不會受到太大的損傷。解決這個問題之后就解決了接入的穩定性問題,后面的問題是搖一搖怎么玩,搖一搖怎么玩是紅包怎么玩,在紅包過程中怎么保證紅包是安全的呢,紅包涉及到錢,錢是不能開玩笑的。

還有一個問題是怎樣跟春晚保持互動,春晚現場直播,我們怎么跟現場直播掛鉤銜接起來。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_7.jpg

先看紅包如何發放。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_8.jpg

前面說到搖一搖請求,其實是在接入服務做的,紅包也是在接入服務里發出去的。

為了在發紅包過程中不依賴這個系統,我們把紅包的種子文件在紅包系統里生成出來,切分,分到每個接入服務器里,每個接入服務器里都部署了專門的紅包文件。

一個紅包不能發兩次,紅包的發放速率需要考慮,發放紅包一定有用戶拆,拆了還要再搶,我們需要精確控制,確保所有請求量都是在紅包系統能夠接受的范圍內。

在這個過程中還會有另外一個風險,用戶搖到紅包之后還可以有一些分裂紅包分出去,他也可以不分享,不分享的也不會浪費,可以回收過來,會通過本地拉回去。這部分因為是比較少量的,問題不大,因為所有紅包已經發出去了,只是補充的。這里我們就搞定了紅包發放。

再就是怎么樣保證紅包不被多領或惡意領取,每個客戶領三個紅包,這是要做限制的,但這是有代價的,就是存儲的代價。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_9.jpg

我們在我們的協議里后臺服務接入的搖一搖文件里下發紅包的時候寫一個用戶領取的情況,客戶端發再次搖一搖請求的時候帶上來,我們檢查就行了,這是一個小技巧,這種方式解決用戶最多只能領三個、企業只能領一個限制的問題。但這個只能解決正版客戶端的問題,惡意用戶可能不用正版,繞過你的限制,這是有可能的。

怎么辦呢?一個辦法是在Agent里面,通過檢查本機的數據能夠達到一個目的,搖一搖接入服務例有638臺,如果迫到不同的機器,我們是長連,還可以短連,還可以連到另一臺服務器,可以連到不同的地方去。

還有一個問題是人海戰術,有些人拿著幾萬、幾十萬的號搶,搶到都是你的,那怎么辦呢?這個沒有太好的辦法,用大數據分析看用戶的行為,你平時養號的嗎,正常養號的話,都會登記出來。

怎樣跟春晚現場保持互動?需要解決的問題有兩個:

  • 1)是要迅速,不能拖太長時間,比如現在是劉德華唱歌,如果給出的明星搖一搖還是上一個節目不太合適,要求我們配置變更需要迅速;
  • 2)是可靠。

我們怎么做的呢?

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_10.jpg

春晚現場我們是專門有同學過去的,在他們電腦裝了系統,可以跟我們后臺進行交互的,節目變了節切一下,變動的請求會發到后臺。

我們部署兩套,一套在深圳、一套在上海,在這個配置里還準備了三步服務,哪一步都可以,同時還可以同步這個數據,這個數據還可以下發到所有的接入機器,會把它同步過去,不是用一種方式,而是用三種方式。

通過這種方式可以迅速的在一千臺服務器成功,是不是能夠達到配置一定能夠用?不一定,春晚現場是不可控的,萬一指令沒有發出怎么辦?如果六個配置服務都掛了怎么辦,從上一個節目切到下一個節目的時候發生這種問題不是太大,但是主持人在十點三十的時候如果搖紅包一搖啥都沒有,這就怒了,口播出不來也就掛了。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_11.jpg

怎么做的呢?主持人肯定有口播,口播的時間點我們大致知道,雖然不知道精確的時間點,比如彩排的時候告訴我們一個時間,后來變了,我們大致知道時間范圍,可以做倒計時的配置,比如十點半不管你有沒有口播我們都要發紅包了。

如果節目延時太長了,你的紅包十分鐘發完了,之后搖不到,那也不行,這種情況下我們做了校正:在節目過程中我們不斷校正倒計時的時間,設了一個策略,定了一個流程,半小時的時候要通知一下我這個時間,因為它是預估的,節目越到后面能定下來的時間范圍越精確,提前告訴我們,我們就可以調整。

那時候現場是在春晚的小會議室,在小會議室看不到現場什么情況,也是通過電視看,結果電視沒信號了,就蒙了,校準就不知道現在怎么回事,進行到哪一步了,當時很著急,還好后來沒事,后續的幾個節目還是校正回來了,最終我們是精確的在那個時間點出現了搶紅包。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_12.jpg

前面講了怎么在系統解決流量的問題、請求量的問題,最重要的一點是我們預估是一千萬每秒,但如果春晚現場出來的是兩千萬、三千萬或四千萬怎么辦,是不是整個系統就掛掉了。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_13.jpg

我們就是采用過載保護,過載保護中心點是兩點,前端保護后端,后端拒絕前端:

  • 1)一個是在客戶端埋入一個邏輯,每次搖變成一個請求,搖每十秒鐘或五秒鐘發送一個請求,這樣可以大幅度降低服務器的壓力,這只會發生到幾個點;
  • 2)一個是服務訪問不了、服務訪問超時和服務限速。實時計算接入負載,看CPU的負載,在銜接點給這臺服務器的用戶返回一個東西,就是你要限速了,你使用哪一檔的限速,通過這種方式,當時有四千萬用戶在搖我們也能扛得住。

五、進一步優化:v0.5測試版


這是我們的0.5測試版,對這個我們的信心指數是50,為什么只有50%的把握?

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_14.jpg

我們前面解決的問題都是解決用戶能搖到紅包,服務器還不會壞掉,但是對搖紅包來說那是第一步。后面還有好幾步,還要把紅包拆出來,還要分享,分享完以后其它人可以搶,這個體驗是要保證的。

簡單分析一下可以發現前面是本人操作,后面是好友操作。

這里就存在一個契機,你可以做一些服務,一旦出現問題是可以利用的點,可以做延時。剩下的問題是保證本人操作比較好,后面出點問題可以延遲,有延遲表示有時間差處理那個東西。

1)核心體驗是什么?

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_15.jpg

這里面我們需要確保成功,確保體驗是完全OK的,確保成功的時候前面提到原型的系統里解決了搖到紅包的問題,剩下的就是拆紅包和分享紅包。怎么樣確保拆紅包和分享紅包的用戶體驗?

2)如何確保拆/分享紅包的用戶體驗?

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_16.jpg

拆紅包和分享紅包可以做一下切割,可以切割成兩個部分:

  • 1)一個是用戶的操作,點了分享紅包按紐;
  • 2)之后是轉帳。

對我們來說確保前面一點就可以了,核心體驗設計的東西再次縮小范圍,確保用戶操作這一步能夠成功。

怎么確保呢?我們稱之為“鐵三角”的東西,拆/分享紅包=用戶操作+后臺業務邏輯。這是我們能做到的最高程度了。

3)還能做得更極致嗎?

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_17.jpg

但我們還可以做的更好一點,前面這個用戶看起來還是成功的,只是入帳入的稍微遲一點點,用戶感覺不到。如果我們異步隊列這里掛了,或者網絡不可用了,概率比較低,我們有三個數據中心,掛掉一個問題不大。萬一真的不能用呢?

我們又做了一次異步,分兩部分:

  • 1)一個是業務邏輯,校驗這個紅包是不是這個用戶的;
  • 2)還有一個透傳隊列,把這個數據再丟到后邊,其實可以相信本機的處理一般是可以成功的,只要做好性能測試基本上是靠譜的。

在后面出現問題的時候我們用戶的體驗基本不受損,保證絕大多數用戶的體驗是OK的。

六、繼續打磨:v0.8預覽版


我們又做了0.8的版本,預覽版,信心指數70,我們認為這個東西有七成把握是可以成功的。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_18.jpg

大家知道設計并不等于實現,設計的再好實踐有問題也很崩潰。

正式發布前我們必須要保證:

  • 1)是全程壓測;
  • 2)是專題CODE REVIEW;
  • 3)是內部演練;
  • 4)是線上預熱;
  • 5)是復盤與調整。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_19.jpg

技術復盤包括兩部分:

  • 1)有問題的時候可以把異常問題看出來;
  • 2)二是很正常,跑的時候是不是跟想象的一樣,需要對正常情況下的數據做預估的重新評估,看看是不是符合預期。

我們進行了兩次預熱:

  • 1)一次是搖了3.1億次,峰值5000萬一分鐘,100萬每秒,跟我們估算的一千萬每秒差很遠,當時只是針對iPhone用戶,放開一個小紅點,你看到的時候可以搶,發放紅包5萬每秒,春晚當晚也是五萬每秒;
  • 2)后面又發了一次,針對前面幾個問題再做一次。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_20.jpg

七、正式交付:v1.0正式版


做完這兩次連接后面就迎接2月18號春晚的真正考驗。這是1.0正式版,信心指數達到80,我們認為80%是可以搞定的。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_21.jpg

剩下20%在哪里?有10%是在現場,現場不可能一帆風順,有可能現場搖的很High,但后面到處滅火,10%是在現場處置的時候有比較好的預案和方案能夠解決,另外10%是人算不如天算,一個很小的點出現問題導致被放大所有用戶受影響也是有可能的,我們很難控制了。要做出完美無缺的基本不太可能,剩下10%就是留運氣。

當年2月18號跑出來的結果是這樣的,當時搖了110億次,峰值是8.1億每分鐘,1400萬每秒。

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進_22.jpg

我今天跟大家的分享到這里。謝謝大家。

(原文鏈接:點此進入

八、后續:文章中的熱門題解答


提問 1:第一個是有一個壓測,壓測是怎么做的?怎么做到模擬這么大的量?還有兩個不太明白的地方,防用戶重復刷紅包的地方會拉用戶已經發的紅包的歷史記錄,這個地方每次都會請求的話是不是每次單點?

張文瑞:先回答你壓測的問題,壓測分幾個階段,有一個壓測工具,壓測工具符合請求量的去壓它,有了這個東西之后后面有全流程的壓測,從所有東西的起點開始,把整個流程能夠串起來,壓測工具壓的時候肯定要壓線網系統,我們留了測試集群,放的是同樣的機器去壓,能夠產生的結果跟我們是不是對得上。另外我們的接入,如果沒有真正驗證過一千萬每秒的話單機測好像可以,但是比較危險。我們在客戶端里做了一個觸發。

提問 2:實際上還是發了一千萬的請求?

張文瑞:不一定是一千萬每秒。我們部署的幾個集群,每個集群里幾組機器,保證那部分OK就可以了。

對于第二個惡意領取的問題,其實不會有那個請求,第一個是通過Cookie,另外一部分是通過本機的Agent,通過本地計算是通過本地,是本地訪問,是功能內存,不需要跑到后面訪問,客戶請求需要跑到后端訪問。

提問 3:匯總的數據量不是很大嗎?

張文瑞:有的用戶可能搖到好幾個。匯總這里整個掛掉是沒有問題的,也不是完全沒影響,對破解協議之類的,跟用戶對抗的時候會受損,這部分數據就沒有同步了,假設這個服務掛了或同步的網絡出問題了,一般是不會出問題的,你不能讓用戶搖到十個紅包,不能讓大部分用戶搖到十個紅包然后其它用戶沒有。其它的層層遞進,先做單機的,又做跨機的,前一層并不依賴后一層,你掛掉對我們來說也是可以接受的。

提問 4:最終發放的時候是靠紅包系統,紅包系統每秒處理多少個?

張文瑞:紅包發放是在接入那里發出去的,紅包不參與發放。用戶拆紅包的動作是要進入紅包系統的,我們這里放過去的量在每秒鐘五萬,就是放出去,讓用戶搖到紅包五萬,紅包系統本身他們預設處理十秒以上。

提問 5:還有一個問題是跟產品相關的,你用了Cookie和單機的校驗,但可靠性不高,這樣的情況下怎么做承諾你的設計能夠承擔,你怎么做產品方面分析的承諾呢?一個用戶只能收到三個紅包,假設這個時候有六個呢?

張文瑞:用戶能搖到的紅包是三個,但是他還可以搶。

提問 6:他拿到的三個紅包是在接入那一塊你給他算或了?是這樣嗎?

張文瑞:對。

提問 7:六百個服務器并發接入,如果很短的時間去接入的話呢。

張文瑞:用正版的客戶端做不到這一點,他一定是拿了自己寫的自動機或模擬機并發模擬。所以我們對產品的承諾正常用戶是保證領三個紅包,每個企業最多領到一個,但是有惡意用戶,我們會一直提高對抗的水平,但是道高一尺魔高一丈,他永遠想辦法搞定你,我們靠后面的機制,就是多機共享數據來搞定。99.999%的情況下它可能是OK的,但是存在那么一點可能掛掉,如果掛掉我們就犧牲出那一部分,那沒辦法了。因為資源不是無限制的,有限資源你能做到最好的東西。

提問 8:我剛才聽到在微信朋友圈那邊到會有四個IDC,我連接哪個IDC寫入數據的時候就寫那個,再同步到其它的IDC上,怎么保證發紅包的時候有那么大的量。

張文瑞:我們不用同步。用戶只連到其中一個IDC,對用戶進行切分,那個用戶可能是屬于上海的或加拿大的,你是上海的就只能連接上海的。數據本身也不需要同步的。我們的做法是這樣的,我們計算出來每秒發放五萬個,算好每個機發放多少,那臺機按照那個量發就可以了。在紅包這一塊不用同步,后面的數據就靠用戶點、拆。

附錄1:有關微信、QQ的文章匯總


[1] QQ、微信團隊原創技術文章:
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)
微信團隊分享:微信移動端的全文檢索多音字問題解決方案
騰訊技術分享:Android版手機QQ的緩存監控與優化實踐
微信團隊分享:iOS版微信的高性能通用key-value組件技術實踐
微信團隊分享:iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的?
騰訊技術分享:Android手Q的線程死鎖監控系統技術實踐
微信團隊原創分享:iOS版微信的內存監控系統技術實踐
讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享
iOS后臺喚醒實戰:微信收款到賬語音提醒技術總結
騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路
微信團隊分享:視頻圖像的超分辨率技術原理和應用場景
微信團隊分享:微信每日億次實時音視頻聊天背后的技術解密
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)
騰訊團隊分享:手機QQ中的人臉識別酷炫動畫效果實現詳解
騰訊團隊分享 :一次手Q聊天界面中圖片顯示bug的追蹤過程分享
微信團隊分享:微信Android版小視頻編碼填過的那些坑
微信手機端的本地數據全文檢索優化之路
企業微信客戶端中組織架構數據的同步更新方案優化實戰
微信團隊披露:微信界面卡死超級bug“15。。。。”的來龍去脈
QQ 18年:解密8億月活的QQ后臺服務接口隔離技術
月活8.89億的超級IM微信是如何進行Android端兼容測試的
以手機QQ為例探討移動端IM中的“輕應用”
一篇文章get微信開源移動端數據庫組件WCDB的一切!
微信客戶端團隊負責人技術訪談:如何著手客戶端性能監控和優化
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信團隊原創分享:Android版微信的臃腫之困與模塊化實踐之路
微信后臺團隊:微信后臺異步消息隊列的優化升級實踐分享
微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐
騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率
騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)
騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(上篇)
微信Mars:微信內部正在使用的網絡層封裝庫,即將開源
如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源
開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
微信團隊原創分享:Android版微信后臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)
Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]
微信團隊原創分享:Android版微信從300KB到30MB的技術演進
微信技術總監談架構:微信之道——大道至簡(演講全文)
微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]
如何解讀《微信技術總監談架構:微信之道——大道至簡》
微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]
微信異步化改造實踐:8億月活、單機千萬連接背后的后臺解決方案
微信朋友圈海量技術之道PPT [附件下載]
微信對網絡影響的技術試驗及分析(論文全文)
一份微信后臺技術架構的總結性筆記
架構之道:3個程序員成就微信朋友圈日均10億發布量[有視頻]
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
快速裂變:見證微信強大后臺架構從0到1的演進歷程(二)
微信團隊原創分享:Android內存泄漏監控和優化技巧總結
全面總結iOS版微信升級iOS9遇到的各種“坑”
微信團隊原創資源混淆工具:讓你的APK立減1M
微信團隊原創Android資源混淆工具:AndResGuard [有源碼]
Android版微信安裝包“減肥”實戰記錄
iOS版微信安裝包“減肥”實戰記錄
移動端IM實踐:iOS版微信界面卡頓監測方案
微信“紅包照片”背后的技術難題
移動端IM實踐:iOS版微信小視頻功能技術方案實錄
移動端IM實踐:Android版微信如何大幅提升交互性能(一)
移動端IM實踐:Android版微信如何大幅提升交互性能(二)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
移動端IM實踐:iOS版微信的多設備字體適配方案探討
信鴿團隊原創:一起走過 iOS10 上消息推送(APNS)的坑
騰訊信鴿技術分享:百億級實時消息推送的實戰經驗
IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)
IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)
騰訊TEG團隊原創:基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享
微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等
了解iOS消息推送一文就夠:史上最全iOS Push技術詳解
騰訊技術分享:微信小程序音視頻技術背后的故事
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
微信多媒體團隊梁俊斌訪談:聊一聊我所了解的音視頻技術
騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天
騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐
手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
騰訊技術分享:GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐
微信團隊分享:Kotlin漸被認可,Android版微信的技術嘗鮮之旅
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
>> 更多同類文章 ……

[2] 有關QQ、微信的技術故事:
技術往事:微信估值已超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春已來?
那些年微信開發過的雞肋功能,及其帶給我們的思考
讀懂微信:從1.0到7.0版本,一個主流IM社交工具的進化史
同為IM社交產品中的王者,QQ與微信到底有什么區別
還原真實的騰訊:從最不被看好,到即時通訊巨頭的草根創業史
>> 更多同類文章 ……

附錄2:更多架構方面的文章匯總


[2] 有關IM架構設計的文章:
淺談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] 更多其它架構設計相關文章:
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
達達O2O后臺架構演進實踐:從0到4000高并發請求背后的努力
優秀后端架構師必會知識:史上最全MySQL大表優化方案總結
小米技術分享:解密小米搶購系統千萬高并發架構的演進和實踐
一篇讀懂分布式架構下的負載均衡技術:分類、原理、算法、常見方案等
通俗易懂:如何設計能支撐百萬并發的數據庫架構?
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:求教IM中單聊的數據庫設計是怎么樣的設計思想下一篇:社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節

本帖已收錄至以下技術專輯

推薦方案
評論 3
熱乎乎的。。。
引用:踏雪尋梅 發表于 2019-05-10 11:23
熱乎乎的。。。

能把這樣的文章吃下去,下份工作工資一定翻倍。。
簽名: 感覺有點缺瞌睡,今晚早點睡。。
引用:JackJiang 發表于 2019-05-10 11:29
能把這樣的文章吃下去,下份工作工資一定翻倍。。

打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特