\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n自從8月20號子彈簡訊在錘子發布會露面之後，關於它的討論不絕於耳，7天融資1.5億的傳聞更是將它推到了風口浪尖。同時很多技術人開始分析它的**，挖出了它的im系統其實不是自研，而是使用網易雲信提供的第三方服務。有人質疑說，第三方的sdk做乙個demo跑跑還可以，能拿來開發正式產品嗎？本文就想來談談im開發的難點以及目前第三方im服務的現狀。
\u0026#xd;\n
對於im，更關注的是社交產品使用者體驗層面的東西。具體來說就是怎麼構建乙個更好的溝通邏輯，更快速的幫助使用者達到更好的溝通效果？這其實也是子彈簡訊瞬間能夠火起來的重要原因。
\u0026#xd;\n\u0026#xd;\n
所以，im開發中的技術難點就在於對使用者體驗的追求。
\u0026#xd;\n\u0026#xd;\n
首先，im核心關注點一是訊息傳輸的速度要快，涉及延時方面的問題；第二個是要保證訊息的送達率。同時，現在使用者的裝置多樣化，im通常需要支援多裝置，又涉及到乙個多終端訊息同步的問題。
\u0026#xd;\n\u0026#xd;\n
其次，im產品的使用者量和活躍度通常都很大，在一些特殊的時間點經常容易造成流量的波峰，因此技術上需要能夠應對突發的量級。所以在前期需要設計好彈性擴容，對系統的伸縮能力提前做好設計。
\u0026#xd;\n\u0026#xd;\n
最後，im包含使用者的大量隱私，一旦被黑客攻破不堪設想，同時在公共安全方面的影響也越來越受重視，因此很多im產品都投入精力做內容安全、平台可控方面的工作。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
乙個成熟的通訊協議都是多年經驗沉澱下來的，網易雲信的im服務並不是憑空產生，而是繼承了之前網易泡泡、易信的技術。對於通訊協議需要關注的地方，周梁偉介紹，雲信的私有協議首先關注幾個層面，一是安全性，也就是通訊過程中所有資料序列化的演算法、加密的機制，以及加密的級別，全都是自己定義的。同時也考慮到，在整個傳輸的過程中可能長期存在的安全風險，比方第三方的攻擊，以及資料在網路流轉過程中被拷貝和重放的潛在安全風險，這些在設計過程中都需要被規避掉。
\u0026#xd;\n\u0026#xd;\n
還有乙個很重要的方面是私有協議對擴充套件性的支援，傳統的協議不能做到很好的擴充套件，或者做完擴充套件後整個訊息會變得非常大。對私有協議來說，可以隨時的做各種場景的定義、各種新協議的增加和各種版本的相容。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
對乙個im平台來說，到達率和即時性是兩個核心功能點。對於訊息傳輸機制的設計來說，首先設計的時候把100%的送達率作為乙個核心要求，關鍵性的指標，要抱著必須要達到的態度來設計。
\u0026#xd;\n\u0026#xd;\n
主要的技術手段是通過不同訊息型別的相互組合來補充。
\u0026#xd;\n\u0026#xd;\n
存在資料庫裡的訊息，使用者可以在更長時間的離線以後實時同步，即使快取裡沒有也可以拿到。另外還要考慮更長時間範疇的訊息儲存，應用的場景是什麼呢？使用者可能乙個月以前開始使用這個im產品，或者1年前使用了這個im產品，現在更換手機了，更換手機以後訊息如何在新手機上拿到？這種稱為雲端的歷史訊息。在所有訊息的流轉的過程中，這個訊息到最後被儲存在資料倉儲裡，資料倉儲儲存訊息的時間維度可能是1年或者幾年。在使用者跨平台或者更換新裝置之後，可以隨時從雲端再獲取到這部分的訊息。通過不同訊息的相互組合之後，我們是可以達到訊息100%送達的效果。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
周梁偉介紹，im通訊平台目前承載很多很重要的功能是傳統運營商做的部分業務。以前我們用簡訊、**，現在大家轉移到即時通訊的工具上，對監管層來說是有要求的。從平台角度來說，本身做的是乙個訊息通道的功能，訊息就代表了會有**的傳播，特別在群組或者聊天室這樣參與者眾多的狀態下，所以**監管對平台來說是必須承擔的責任，這是監管層面對平台運營方的要求。平台必須具備內容審核的能力，雲信會按照開發者的配置把平台上產生的內容在雲儲存起來，以備監管層隨時做內容的審核。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
對im來說，除了使用者資料需要做安全防範外，還需要關注訊息內容的安全。包括兩個層面，乙個是訊息傳輸層面的安全，在傳輸過程中，通過協議和加密，以保證傳輸過程中的訊息是不可逆的。惡意使用者即使抓到網路傳輸的包也沒有辦法破譯出來。同時，加密級別做到會話級別，是指乙個使用者的一次長鏈結行為，即使同乙個使用者多次登入，或者在不同時間點登入，加密的金鑰都是不一樣的。所以能夠保證傳輸過程中是安全的。
\u0026#xd;\n\u0026#xd;\n
第二個維度是，訊息儲存過程中是安全的。這裡分為幾個角度，一是對資料做自定義的序列化的方式，包括資料儲存後，序列化或反序列化過程中的效率更高。二是如果洩露，是不可見、不可讀的。另外，對於關鍵資料需要做加密，避免出現脫庫之類的行為。
\u0026#xd;\n\u0026#xd;\n
另外，周梁偉表示，使用者怎麼使用雲平台才能在過程中保證業務資料的安全，一般他們會建議，在使用平台的時候對業務資料做脫敏。比如說開發者自己的平台是用使用者的手機號作為使用者賬號的，在雲信裡面註冊使用者的賬號的時候，可以在業務層做乙個關聯。使用隨機數或者隨機的、無意義的字串作為雲平台資料庫裡的id，手機號的對映關係僅僅在業務方。通過這種脫敏保證資料的安全。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
看完上面的內容，想必你對im系統研發會遇到哪些問題，以及相應的解決方案有了大致的概念。當然這裡只提到了其中的一些，還有其它方面，比如不同使用者量級的系統需要不同的架構，qq在它的發展過程中就經歷多次重構，感興趣的同學可以在infoq**搜尋相關的文章。
網易雲信周梁偉專訪 億級架構IM平台的技術難點解析
自從8月20號子彈簡訊在錘子發布會露面之後，關於它的討論不絕於耳，7天融資1.5億的傳聞更是將它推到了風口浪尖。同時很多技術人開始分析它的 挖出了它的im系統其實不是自研，而是使用網易雲信提供的第三方服務。有人質疑說，第三方的sdk做乙個demo跑跑還可以，能拿來開發正式產品嗎？本文就想來談談im開...
網易雲信周梁偉 聊聊搭建無上限人數直播聊天室
客戶端多樣 資料安全需要保障 網路抽風 單點故障 使用者量上來了 架構撐不住 訊息慢 同時，我們評判乙個穩定 無上限人數的聊天室架構應該具備這些條件 當前的網路安全角勢異常複雜，開發應用時如果不在通訊安全上花心思，那你的使用者就等於在網際網路上裸奔。開發者需要針對不同的平台，不同的通訊技術實現可靠的...
專訪趙加雨 WebRTC在網易雲信的落地
一些網路瀏覽器 如chrome opera和firefox 在已在手機，電腦，智慧型電視和平板電腦等裝置中支援webrtc。2014年，超過10億台裝置支援webrtc。到2016年底，數量增加到40億。並且，截至2016年底，已有超過15億活躍的webrtc使用者。webrtc支援裝置數量的上公升...