默認
打賞 發表評論 11
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
微信技術總監談架構:微信之道——大道至簡(演講全文)
閱讀(173787) | 評論(11 收藏9 淘帖2 1

前言


微信——騰訊戰略級產品,創造移動互聯網增速記錄,10個月5000萬手機用戶,433天之內完成用戶數從零到一億的增長過程,千萬級用戶同時在線,搖一搖每天次數過億...在技術架構上,微信是如何做到的?日前,在騰訊大講堂在中山大學校園宣講活動上,騰訊廣研助理總經理、微信技術總監周顥在兩小時的演講中揭開了微信背后的秘密。

周顥把微信的成功歸結于騰訊式的“三位一體”策略:即產品精準、項目敏捷、技術支撐。微信的成功是在三個方面的結合比較好,能夠超出絕大多數同行或對手,使得微信走到比較前的位置。所謂產品精準,通俗的講就是在恰當的時機做了恰當的事,推出了重量級功能,在合適的時間以最符合大家需求的方式推出去。他認為在整個微信的成功中,產品精準占了很大一部分權重。

相關鏈接


講稿下載:http://www.hqkrtb.live/thread-199-1-1.html(演講PPT)
如何解讀:如何解讀《微信技術總監談架構:微信之道——大道至簡》

前于周顥


微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-0.png 周顥

2001 年畢業于華南理工大學,計算機專業碩士。
2005 年加入騰訊廣州研發部,歷任 QQ 郵箱架構師,
廣研技術總監,T4 技術專家,微信中心助理總經理。

微信的歷程


微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-1.png

敏捷是一種態度:勇于試錯


微信研發團隊里鼓勵一種試錯的信仰:他們堅信,在互聯網開發里,如果能夠有一個團隊在更短的時間內嘗試了更多機會(并能改進過來),就能有(更多的)機會勝出。敏捷是一種態度,在軟件開發過程中,項目管理者都會非常忌諱“變更”這個詞,但是在微信的項目運作中是不可以的。因為微信必須要容忍說哪怕在發布前的十分鐘,也要允許他變更。這是非常大的挑戰,因為打破了所有傳統項目開發的常識。所有人都說不可能做到的,但微信做到了。研發團隊所做的一切都是要給產品決策者有最大的自由度,而這個決策正是微信能夠勝出的關鍵。

懸崖邊的跳舞:海量系統上的敏捷不同以往


敏捷有很多困境,如果做一個單機版程序,是可以做到很敏捷的,但是騰訊正在運作的是一個海量系統,有千萬級用戶同時在線,在一個單獨的功能上每天有百億級的訪問,同時還要保證99.95%的可用性。在海量系統上應對項目開發會有很嚴謹的規范,都說要盡可能少的變化,因為90%-95%的錯誤都是在變更中產生的,如果系統一直不變更會獲得非常高的穩定度,但是微信就是要在懸崖邊跳舞。微信的研發團隊要做一些事情,讓敏捷開發變得更簡單。

如何做到這一切?周顥認為,首先,必須建立起一種狂熱的技術信念,就是一定是可以做到的。然后,需要用一些穩固的技術(理念)來支撐,例如大系統小做、讓一切可擴展、必須有基礎組件、輕松上線(灰度、灰度、再灰度;精細監控;迅速響應)...等等來支撐。

大系統小做


當設計龐大系統的時候,應該盡量分割成更小的顆粒,使得項目之間的影響是最小的。僅僅把模塊變得更為清晰,這在海量系統設計開發中是不夠的,還需要在物理環境上進行分離部署,出現問題的時候可以快速發現,并且在最快的情況下解決掉。

大系統小做,混搭模式:
微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-2.png

將不同的應用邏輯物理分割獨立出來,用戶注冊登錄、LBS邏輯、搖一搖邏輯、漂流瓶邏輯、消息邏輯獨立開來。把關鍵的邏輯混搭在一起,當所有的邏輯部署在同一個服務器上,確實也會帶來很大敏捷上的好處,因為不需要額外的考慮部署和監控的問題。在整個微信的邏輯中,可能現在已經有上百種不同的邏輯,因為會在邏輯的分割上拆分成8-10種做分離部署。

一切皆可擴展


在高穩定度、高性能的系統中間,為了穩定性能把它設計成不變化的系統,但為了支持敏捷需要讓一切的東西都要變得可以擴展。

擴展的關鍵點有兩塊。一個是網絡協議需要擴展,當要升級一個新功能的時候,會有一些比較大的困難,所以所有協議設計都比較向前兼容,但是向前兼容還是不夠的,因為網絡協議設計本身有非常多的功能也會有比較大的字段,相關的代碼可能會有數千行,這一塊不能通過手寫方式完成。可以通過XML描述,再通過工具自動生成所有的代碼,這是微信獲得快速開發的一個重要的點。

另外一塊就是在數據存儲方面是必須可擴展的。在2005年絕大多數海量系統的設計都是采用固定字段的存儲,但是在現代系統中會意識到這個問題,會采用KV或者TLV的方式,微信也做了不同的設計。

把復雜邏輯都固化下來,成為基礎軟件。在微信后臺會有幾種不同的基礎組件。大致包括:

  • Svrkit——Client/Server自動代碼生成框架:10分鐘搭建內部服務器
  • LogicServer——邏輯容器:隨時添加新邏輯
  • OssAgent——監控/統計框架:所見即所得的監控報表
  • 存儲組件——屏蔽容災/擴容等復雜問題

灰度、灰度、再灰度


在變更后的部署方式上,微信在一些規則會限定不能一次把所有的邏輯變更上去,每一次變更一小點觀察到每一個環節沒有問題的時候,才能布局到全網上去。微信后臺每一天可以支撐超過20個后臺變更,在業界來說,通常做到5個已經是比較快了,但是微信可以做到快4倍。

騰訊內部的上線系統:
微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-3.png

而所謂灰度發布,是指在黑與白之間,能夠平滑過渡的一種發布方式。AB test就是一種灰度發布方式,讓一部用戶繼續用A,一部分用戶開始用B,如果用戶對B沒有什么反對意見,那么逐步擴大范圍,把所有用戶都遷移到B上面 來。灰度發布可以保證整體系統的穩定,在初始灰度的時候就可以發現、調整問題,以保證其影響度。(在騰訊,灰度發布是最常采用的發布方式之一)

兵法云:古之所謂善戰者,勝于易勝者也


常識上,解決一個復雜問題的時候,會用高明的技巧解決復雜的問題,這個不是微信團隊的目標,他們追求的要做到讓所有問題很自然和簡單的方式解決掉。在周顥看來,微信架構的技術復雜點在四個要點:協議、容災、輕重、監控。

微信架構:
微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-4.png

  • 協議。手機終端跟后臺服務器之間的交互協議,這個協議的設計是整個系統的骨架,在這一點做好設計可以使得系統的復雜度大大降低。
  • 容災。當系統出現了若干服務器或若干支架(宕機的時候),仍然需要讓系統盡可能的提供正常的服務。
  • 輕重。如何在系統架構中分布功能,在哪一個點實現哪一個功能,代表系統中間的功能配置。
  • 監控。為系統提供一個智能儀表盤。

在協議設計上,移動互聯網和常規互聯網有很大的區別。首先有CMWAP和CMNET的不同,在中國現在有相當多的手機用戶使用WMWAP連接,還有就是在線和離線的概念,當QQ下線的時候叫離線,當你登錄的時候叫在線。但是在移動互聯網這兩個概念比較模糊。從微信的設計中,不管在線還是離線系統表現都應該是一致的。還有一個是連接不穩定的問題,由于手機信號強弱的變化,當時信號很好,5秒鐘走到信號不好的地區,連接就必須斷掉。這個中間帶來不穩定的因素為協議設計帶來較大困難。此外就是資費敏感的問題,因為移動互聯網是按照流量計費的,這個計費會使得在協議設計中如何最小化傳輸的問題。最后就是高延遲的問題。

對此,業界標準的解決方案:Messaging And Presence Protocol:1)XMPP;2)SIP/SIMPLE。它的優點是簡單,大量開源實現。而缺點同樣明顯:1)流量大:狀態初始化;2)消息不可靠。

微信在系統中做了特殊設計,叫SYNC協議,是參考Activesyec來實現的。特點首先是基于狀態同步的協議,假定說收發消息本身是狀態同步的過程,假定終端和服務器狀態已經被遲了,在服務器端收到最新的消息,當客戶端、終端向服務器對接的時候,收取消息的過程實際上可以簡單的歸納為狀態同步的過程,收消息以及收取你好友狀態更新都是相同的。在這樣的模式之下,我們會也許會把交互的模式統一化,只需要推送一個消息到達的通知就可以了,終端收到這個通知就來做消息的同步。在這樣的簡化模式之下,安卓和塞班都可以得到統一。這樣的系統本身的實現是更為復雜的,但是獲得很多額外的好處。

讓剩下系統實現的部分更加簡單,簡化了交互模式,狀態同步可以通過狀態同步的差值獲得最小的數據變更,通過增量的傳輸得到最小的數據傳輸量。通過這樣的協議設計,微信可以確保消息是穩定到達的,而且是按序到達。引用一句俗話:比它炫的沒它簡單,比它簡單的沒它快,沒誰比他更快,哪怕在GPRS下,微信也能把進度條輕易推到底。

追求完美設計的團隊不能勝任海量服務


在容災之前面向最壞的思考,如果系統真的掛了,需要做一些事情,首先是防止雪崩,避免蝴蝶效應。如果關注春節訂火車票就知道了,用戶的請求量會因為系統服務不了而不斷的重試,意味著發生雪崩的時候,系統可能會承載原先3-10倍的流量,使得所有的事情更加惡化。所以微信有很多“放雪”功能的設計。第二個詞是柔性可用,在任何的系統中不要追求完美設計,追求完美設計的是團隊是不能勝任海量服務的。如果在一個系統出現問題的時候,這個系統就掛了,那么這是一個不好的設計,最好的做法是提供0-1中間的選擇。舉一個例子,當一個用戶向另外一個用戶發消息的時候,可能會通過一個垃圾信息過濾的檢測,如果垃圾信息過濾這個模塊突然掛掉了,這個消息難道就不能達到了嗎?在這樣的情況下,要忽略掉這個錯誤,使得消息正常達到對方。要精確定位出哪一個環節是最為重要的,把不是重要的錯誤盡可能的忽略掉。當不能做到完美的時候,盡可能為用戶提供服務。另外一個重要方面叫做“保護點前置”,最前的一個點就是終端,在手機終端上蘊埋更多的保護點,這樣會為用戶系統贏得更大的處理空間。如果終端具備這樣的能力,會獲得更大的反應空間。

周顥介紹了在微信上具體容災設計的做法。在所有的容災中存儲層的容災是最難的,一個系統的設計分為三層:接入層、邏輯層、存儲層。接入層和邏輯層的容災都有比較成熟的方案。邏輯層的容災相對來說比較簡單,盡量不要有狀態的設計,比如說當你做上一個請求的時候,會保持一些狀態,要使得下一個請求發到下一個服務器。如果任何一個請求之間互相不關聯的話,這個就是無狀態的設計,只要做到這一點邏輯層的容災可以隨意的切換。在回到存儲層本身的容災設計上,相對來說困難一些,但是微信研發團隊采用了一些技巧,叫分而治之,分離業務場景,尋求簡單的設計,并不會尋求大而同一的解決方案,因為這樣會使得系統的復雜度大幅度上升,而微信會盡可能把產品拆細,尋求簡化的設計。

首先是主備容災,這是最常見的方案。在有一些業務場景中是可以容忍最終一致性的,比如賬號系統的設計,每天寫入賬號系統的請求是非常少的,但是訪問的請求非常多,這個差異可能會達到數萬倍的規模,在這樣的場景下,微信會在賬號系統中采用簡化的方案,也可以獲得比較大的穩定度。

SET模型+雙寫:
微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-5.png

第二種容災的模式叫雙寫,兩臺Master的機器,當一臺機故障的時候,另外一臺機還是可以接收到寫請求,當兩臺機交錯啟動的時候,會得到數據的丟失。但是有一些場景是可以容忍輕度數據丟失的,比如說會有一個存儲專門記錄用戶終端的類型,比如說安卓還是塞班以及他們使用終端的微信版本是什么,這樣的數據是可以容忍輕度數據丟失的,因為偶爾有一些丟失的話,下一次訪問會把這些數據帶上來,會盡快的修復所有的數據。雙寫也是非常簡單的模式。

微信的研發團隊做了一個叫Simple Quorum的機制,在微信的后臺中,同步協議有一個很重要的基石叫序列發生器,這樣的一個序列發生器需要有極高的穩定度。首先可以看到序列號有一個特點永遠是遞增的,用遞增方式往前推進的時候,最大的序列號就是最新的系列號。有一個畢業才加入廣研的畢業生想到一個絕佳的方案,按SET分布,從2G減到200K。

前輕后重:功能點后移


周顥還談到了輕重的概念。這個概念的提出主要是從終端本身的一些困境所帶來的。首先在終端上需要表現最多的一個產品的邏輯,邏輯非常復雜,變更的成本也非常高,當需要修復的時候必須發布一個新版本,這個新版必須由自己下載才能完成,下載的成本非常高。在這樣的前提下,如果手機終端產生了任何變化的時候,如果這個變化有非常大的問題就會有極大的困境,所以需要在每一個發布之前做一些充分的數據,確保不會發生致命問題。如果一旦出現致命問題難以修復,需要把關鍵的點從終端移到后臺實現,把功能點后移,來充分發揮后臺快速變更的能力。

接入優化:從GSLB到IP重定向
微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-6.png

在接入層的優化,速度很重要的因素,是不是能夠就近接入一個最優的節點,比如說移動用戶最好接入移動的節點,海外的用戶可能需要尋找更佳的路由,有的時候可能無法自動做到這一點,一點是在終端上做測速,微信會通過在后臺IP逆向的能力,通過后臺指揮微信終端聯網的能力,尋找最優的接入點。上圖就是每分鐘收到同一項指令曲線的報表。

如何解決“偷流量”的問題——當國內類微信類產品發布的時候出現一個大的問題就是“偷流量”,當用戶在某一些邏輯下進行一個死循環,不斷訪問某一些數據,這樣的死循環是非常可怕的,如果在用戶不知覺的情況之下,可能會在一個小時之內偷到數10兆甚至數百兆的流量。有非常多業內的同行都需要花大量的精力解決這個問題,微信研發團隊用了非常強大的方式解決它。通過在后臺建立起嚴厲的監控系統,對每一個用戶的行為做一個監控,當發現異常的時候,后臺會給終端發出指令,使得微信終端在一段時間無法聯網,但是可以保證用戶流量不會白白的使用掉。

功能適配的例子——第一期微信版本發布的時候,當時沒有群聊的功能,第二版發布的時候做了這個功能。當時有兩個選擇,對于早期版本的用戶,因為不支持群聊,就無法享用到這個功能,但是微信希望提供更好的選擇,想讓早期不支持群聊的版本,也可以被拉到一個群里面收消息、發消息,通過后臺功能的適配也能做到這個事情。

分而治之:把監控嵌入基礎框架


對于一個海量系統來說,一個精密的儀表盤非常重要。監控是非常痛苦的,對于這樣一個系統來說,每小時會產生數百G的監控日志。微信希望在1分鐘之內監控的數據就能夠顯示在報表上,因為只有這樣的精準和實時度才能夠贏得處理故障的時間。微信會做關聯統計,通過搖一搖加了好友,他們活躍度如何,過了一段時間他們的活躍度變化情況又是如何。這種需求是需要通過大量日志的關聯統計來獲得的。研發團隊也花了一段時間來理解這個問題,發現了中間一個重要的經驗叫做“魚和熊掌不能兼得”。

為了讓監控數值更敏感,需要把監控細化再細化,上面數據表示每一欄子系統的數據,下面這個是按微信版本號來劃分的,這里的數據項是非常多。

微信還需要采集一些異常的點,如果有異常的話會發布緊急的版本,盡可能快的替換它。對收發消息延時做的監控,比如說0—1秒端到端的速度,會對不同的區段做一些統計,當某一個環節出現異常的時候,通常會在中間的延時上體現出來。有一個很重要的點叫自動報警,現在有數千項的數據,不可能每一項都靠人工去看的,必須要跟自動報警相關聯,微信有一些智能的算法,是不是在正常的范圍內,跟歷史的數值進行對比,如果有異常的話,會通過短信、郵件還有微信本身來發出報警信息。

微信技術總監談架構:微信之道——大道至簡(演講全文)_QQ20160402-7.png

微信會把監控嵌入到基礎框架里面去,因為并不是每一個人都會意識到在需要的地方嵌入一個監控點,所以在基礎框架本身內置很重要的監控點,比如說這個表上的欄目,非常多的欄目大概會有數百項的欄目,都不需要程序員自己去寫,當用基礎組件搭建一個系統的時候,就可以直接觀測系統數據。

未來的技術挑戰


在談到微信未來的技術挑戰時,周顥首先希望能夠讓微信成為可用性99.99%的系統;設計出面向現在10倍容量的系統以及完全的IDC容災。

后記


網上盛傳的凌晨兩點,騰訊大廈那多層大片大片的燈光和樓下那長長的出租車隊伍說明了一切。引用一句話做結尾:“可怕的不是微信,真正可怕的是,比你領先比你更有天賦的團隊比你更努力”。

微信技術總監談架構:微信之道——大道至簡(演講全文)_6_120515081630_1.jpg

全站即時通訊技術資料分類


[1] 網絡編程基礎資料:
TCP/IP詳解 - 第11章·UDP:用戶數據報協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連接的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
理論經典:TCP協議的3次握手與4次揮手過程詳解
理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程
計算機網絡通訊協議關系圖(中文珍藏版)
NAT詳解:基本原理、穿越技術(P2P打洞)、端口老化等
UDP中一個包的大小最大能多大?
Java新一代網絡編程模型AIO原理及Linux系統AIO介紹
NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰
NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰
>> 更多同類文章 ……

[2] 有關IM/推送的通信格式、協議的選擇:
為什么QQ用的是UDP協議而不是TCP協議?
移動端即時通訊協議選擇:UDP還是TCP?
如何選擇即時通訊應用的數據傳輸格式
強列建議將Protobuf作為你的即時通訊應用數據傳輸格式
移動端IM開發需要面對的技術問題(含通信協議選擇)
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
理論聯系實際:一套典型的IM通信協議設計詳解
58到家實時消息系統的協議設計等技術實踐分享
>> 更多同類文章 ……

[3] 有關IM/推送的心跳保活處理:
Android進程保活詳解:一篇文章解決你的所有疑問
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
為何基于TCP協議的移動端IM仍然需要心跳保活機制?
微信團隊原創分享:Android版微信后臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
>> 更多同類文章 ……

[4] 有關WEB端即時通訊開發:
新手入門貼:史上最全Web端即時通訊技術原理詳解
Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE
SSE技術詳解:一種全新的HTML5服務器推送事件技術
Comet技術詳解:基于HTTP長連接的Web端實時通信技術
WebSocket詳解(一):初步認識WebSocket技術
socket.io實現消息推送的一點實踐及思路
>> 更多同類文章 ……

[5] 有關IM架構設計:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
>> 更多同類文章 ……

[6] 有關IM安全的文章:
即時通訊安全篇(一):正確地理解和使用Android端加密算法
即時通訊安全篇(二):探討組合加密算法在IM中的應用
即時通訊安全篇(三):常用加解密算法與通訊安全講解
即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險
傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示
理論聯系實際:一套典型的IM通信協議設計詳解(含安全層設計)
微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享
>> 更多同類文章 ……

[7] 有關實時音視頻開發:
即時通訊音視頻開發(一):視頻編解碼之理論概述
即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹
即時通訊音視頻開發(三):視頻編解碼之編碼基礎
即時通訊音視頻開發(四):視頻編解碼之預測技術介紹
即時通訊音視頻開發(五):認識主流視頻編碼技術H.264
即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習
即時通訊音視頻開發(七):音頻基礎及編碼原理入門
即時通訊音視頻開發(八):常見的實時語音通訊編碼標準
即時通訊音視頻開發(九):實時語音通訊的回音及回音消除概述
即時通訊音視頻開發(十):實時語音通訊的回音消除技術詳解
即時通訊音視頻開發(十一):實時語音通訊丟包補償技術詳解
即時通訊音視頻開發(十二):多人實時音視頻聊天架構探討
即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢
即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹
即時通訊音視頻開發(十五):聊聊P2P與實時音視頻的應用情況
即時通訊音視頻開發(十六):移動端實時音視頻開發的幾個建議
即時通訊音視頻開發(十七):視頻編碼H.264、V8的前世今生
簡述開源實時音視頻技術WebRTC的優缺點
良心分享:WebRTC 零基礎開發者教程(中文)
>> 更多同類文章 ……

[8] IM開發綜合文章:
移動端IM開發需要面對的技術問題
開發IM是自己設計協議用字節流好還是字符流好?
請問有人知道語音留言聊天的主流實現方式嗎?
IM系統中如何保證消息的可靠投遞(即QoS機制)
談談移動端 IM 開發中登錄請求的優化
完全自已開發的IM該如何設計“失敗重試”機制?
微信對網絡影響的技術試驗及分析(論文全文)
即時通訊系統的原理、技術和應用(技術論文)
開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀
>> 更多同類文章 ……

[9] 開源移動端IM技術框架資料:
開源移動端IM技術框架MobileIMSDK:快速入門
開源移動端IM技術框架MobileIMSDK:常見問題解答
開源移動端IM技術框架MobileIMSDK:壓力測試報告
開源移動端IM技術框架MobileIMSDK:Android版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:Java版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:iOS版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:Android客戶端開發指南
開源移動端IM技術框架MobileIMSDK:Java客戶端開發指南
開源移動端IM技術框架MobileIMSDK:iOS客戶端開發指南
開源移動端IM技術框架MobileIMSDK:Server端開發指南
>> 更多同類文章 ……

[10] 有關推送技術的文章:
iOS的推送服務APNs詳解:設計思路、技術原理及缺陷等
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
掃盲貼:認識MQTT通信協議
一個基于MQTT通信協議的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三種方案的優劣
移動端實時消息推送技術淺析
掃盲貼:淺談iOS和Android后臺實時消息推送的原理和區別
絕對干貨:基于Netty實現海量接入的推送服務技術要點
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
為何微信、QQ這樣的IM工具不使用GCM服務推送消息?
>> 更多同類文章 ……

[11] 更多即時通訊技術好文分類:
http://www.hqkrtb.live/forum.php?mod=collection&op=all

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


[1] 有關QQ、微信的技術文章:
微信后臺團隊:微信后臺異步消息隊列的優化升級實踐分享
微信團隊原創分享:微信客戶端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版微信的多設備字體適配方案探討
>> 更多同類文章 ……

[2] 有關QQ、微信的技術故事:
技術往事:創業初期的騰訊——16年前的冬天,誰動了馬化騰的代碼
技術往事:史上最全QQ圖標變遷過程,追尋IM巨人的演進歷史
開發往事:深度講述2010到2015,微信一路風雨的背后
開發往事:微信千年不變的那張閃屏圖片的由來
開發往事:記錄微信3.0版背后的故事(距微信1.0發布9個月時)
一個微信實習生自述:我眼中的微信開發團隊
>> 更多同類文章 ……

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

上一篇:微信對網絡影響的技術試驗及分析(論文全文)下一篇:如何解讀《微信技術總監談架構:微信之道——大道至簡》

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

推薦方案
評論 11
騰訊的創新就是會員和各種鉆10元一個月,還有Q幣一個一塊錢.
看了最后一段,恩,騰訊看來是年輕人混的地方,老年人可受不了加班到凌晨兩三點。還有就是這么有天賦這么努力的團隊,做出來的東西實在是……還指望騰訊能開發個Tendows操作系統呢,然后一年也賣120,一次交一年還給打8折;或者來個qq世界騰澤拉斯大陸……
說實話,微信bug太多了,功能也不能讓人滿意,在后臺,一來新消息,手機閃光燈就閃啊閃。還有手機QQ,群里3-5個人聊天,就會出現消息丟失現象。不知道大家有沒有這種情況?
走別人的路,讓別人無路可走。我倒覺得騰訊很牛,給你一片天,我能匯出云彩;給你一塊地,我能蓋出摩天大廈;給你一條路,我能鋪就世紀大道;騰訊很厲害,青“出”于藍而勝于藍,在現在互聯網世界,騰訊無疑是最成功的。別老說別人copy,你有本事copy一個我看看?有的人說了,騰訊這樣子會扼殺創新,創新嗎?那你去申請專利啊!~~
引用:annybudong 發表于 2016-04-02 15:18
走別人的路,讓別人無路可走。我倒覺得騰訊很牛,給你一片天,我能匯出云彩;給你一塊地,我能蓋出摩天大廈 ...

即使在騰訊內部,也承認他們采取的確實是這種追隨戰略,這只能說是一種符合中國環境的企業文化或者戰略,說抄襲有點太尖銳了,但不代表沒有創新,用青出于藍勝于藍形容騰訊很形象,如果非要較真講真正意義上的創新,相信這個詞不會出現在中國,騰訊的技術實力非常著實恐怖,就技術而言國內能與之相提并論的恐怕也只有阿里巴巴了,雖然這兩個企業是完全不同的方向。
大家覺得微信的IM方案怎么樣
簽名: 該會員沒有填寫今日想說內容.
引用:shukaka 發表于 2017-08-17 15:05
大家覺得微信的IM方案怎么樣

這種商業方案,資料都不會公開,沒辦法評價,而且能解決實際問題的方案就是好方案,也沒有資格去評價它
簽名: 《史上最通俗,徹底搞懂字符亂碼問題的本質》http://www.hqkrtb.live/thread-2868-1-1.html
寫的不錯啊
我覺得微信比釘釘的IM體驗要好。
引用:Eilir2018 發表于 2018-10-08 21:57
我覺得微信比釘釘的IM體驗要好。

釘釘除了老板喜歡,應該沒人喜歡吧
簽名: 《史上最通俗,徹底搞懂字符亂碼問題的本質》http://www.hqkrtb.live/thread-2868-1-1.html
同意一個觀點:“追求完美設計團隊是不能勝任海量服務的”。只有在大壓力下宕過很多次機的團隊才有這樣的體會。
簽名: IM新兵開始學習
引用:JamesWu 發表于 2018-11-06 16:22
同意一個觀點:“追求完美設計團隊是不能勝任海量服務的”。只有在大壓力下宕過很多次機的團隊才有這樣的體 ...

說的好
簽名: 《史上最通俗,徹底搞懂字符亂碼問題的本質》http://www.hqkrtb.live/thread-2868-1-1.html
學習
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
乐彩网17500