轉：融雲的實踐經驗

http://toutiao.com/a6278194319489892609/?tt_from=weixin&utm_campaign=client_share&app=news_article&utm_source=weixin&iid=4155521039&utm_medium=toutiao_android&wxshare_count=1

QCon 北京2016全球軟件開發大會已於4月23日在北京國際會議中心順利閉幕。在23日進行的「移動開發與即時通信」專場活動中，來自融雲的技術副總裁楊威，分享了他多年工做當中所得到的心得與經驗。

融雲做爲全球最大的即時通信雲服務商，截至2月份，已經累計服務包括土豆、秒拍、百姓網、優信二手車、駕考寶典、大智慧、戰旗 TV等在內的 App 逾8萬款，日活躍用戶量超過2000萬，日消息量超過12億條。在艾瑞諮詢最新發布的《2016年中國 IM 雲服務行業白皮書》中，融雲即時通信雲穩居市場第一。

當前，移動開發者不管是構建用戶生態，仍是豐富業務場景，亦或是打造移動辦公，因此如何使用即時通信雲，也成爲了企業或者開發者必須關注的議題，這次分享，融雲楊威的演講內容涉及融雲 IM SDK 架構、IM SDK 實現過程當中的經驗等，爲正在移動端開發的技術人員提供了大量的技術參考與實踐經驗。

如下是演講精彩內容：

你們好，首先介紹一下我本身，我是北京郵電大學通訊工程本科碩士畢業，前通訊圈人士，曾從事11年手機研發，如今融雲擔任技術管理工做，主要負責 Android，iOS，Web 端的即時通訊 SDK。融雲是一家提供即時通訊(IM)雲服務能力的廠商。咱們的核心技術團隊主要來自於前飛信的後端團隊，和來自三星的移動端團隊。咱們的前端團隊之前主要負責多媒體技術和通訊RCS技術，RCS 是一種電信級領域的即時通訊 IM 技術。因此也都是這個領域內的資深從業人士。

從電信領域轉到互聯網領域作社交 IM，咱們發現互聯網行業的特色是快，開發快上線快。對即時通訊的需求很大。互聯網圈的朋友們，開發者，架構師，對即時通訊技術通常都興趣很高。今天的主題，背後有一個核心思想，就是關於技術選擇」。對於咱們每一位研發工程師，架構師，技術管理者，你的每一次技術選擇，對本身，對公司，都是價值千金，每一次選擇都影響着不少資源的投入。作出正確的選擇須要信心，須要成功的經驗用來參考。今天我分享的是基於咱們衆多工程師十幾年研發經驗，幾萬開發者得來的寶貴經驗，咱們願意分享給你們，讓你們在 IM 技術研發上作出最好的選擇。最近幾天我也參與了大會的其餘一些分享，其中也涉及即時通訊消息，看了以後我更加確信咱們融雲在這件事上真的是很專業，有不少值得分享給你們的經驗，但時間有限，因此我簡單的介紹。

咱們此次要分享的內容是，首先介紹一下融雲，而後介紹一下融雲 IM SDK 架構，第三部分是分享一下 IM SDK 實現過程當中那些價值千金的經驗，最後分享經過 IM 社交如何實現 SaaS 級的服務。

首先，融雲提供了一個 IM 的雲服務平臺，這是一個公有云平臺。其次，融雲提供了一個前端 SDK。這兩部分是這個圖裏面綠色的部分。經過咱們的雲平臺和 SDK，App 之間能夠經過收發消息進行互動。最後，咱們基於這個平臺，提供了一些 SaaS 級的軟件服務。對於即時通訊平臺，咱們不少研發人員都是頗有情懷的，都像本身作一次 IM，同時有微信這種巨頭的存在，不少 App也都有夢想去作一個微信。但總的來講，消息要作到高併發，不丟消息，實時性是很是難的。有些業務，你經過延遲來解決併發問題，或者經過丟包來解決，但對於消息，是一條也不能丟不能延遲的。

今天的分享咱們主要是移動前端。SDK 前端架構是三個部分，協議棧，IMLib，IMKit。咱們選用了 native 語言，即 C++ 來實現協議棧部分，並封裝了兩個 SDK，一個通訊能力 SDK，一個界面組建 SDK，經過通訊能力 SDK，你能夠簡單的收發消息，經過界面組件 SDK，你能夠在短期內迅速的搭建一個整套 IM 社交軟件。這三部分的劃分應該說是比較經典的，曾被不少業內夥伴的所借鑑。

這裏額外聊一下咱們對 SDK 在移動端開發的趨勢。第一，雲服務+SDK 的模式在移動互聯網領域，通過一段時間的發展，已經趨於很是成熟了。App 經過嵌入 SDK，實現雲服務能力，能夠實現快速上線，節省大量的研發運維費用，同時雲服務企業本身發展在技術和資金上也愈來愈強大，你們能夠放心選用。第二，核心功能組件經過 SDK 進行封裝，是一種基本的技術實踐能力。各個公司也都是這麼實踐的，封裝 SDK 的過程自己就是解耦合的過程，資深工程師都知道解耦合是提升軟件性能的一個必要過程。其次，封裝 SDK 能夠提升項目源代碼管理的編譯消息。最後，能夠提升跨部門研發的溝通消息，你們知道程序員最高效的溝通效率是什麼嗎，就是不溝通。不要說話，不要解釋，不要互相說服，你寫的 API 我能看懂而後我去調用就能夠了。固然這是個笑話，固然是越多溝通越好，好比來參加 QCon 大會聽聽你們的分享。

接下來分享咱們第一個有價值的經驗，IM 協議的選擇。

我參與過一些活動和社羣裏，咱們發現你們都對若是實現一個 IM 有很高的興趣。第一個面對的選擇就是如何去選擇和實現 IM 協議，有了協議纔有後面的一切。不少人都在關心，我該選擇 XMPP 仍是私有協議呢。我我的的見解是，移動互聯網和計算機技術發展到今天，已經能夠替 XMPP 宣告死刑了，到目前爲止全部的大型商業機構採用 XMPP 搭建的通訊網絡要麼替換了要麼關閉了，運行中的也有一些很少。因此，你們不要去選擇 XMPP 構建本身的商業 App IM 功能，當作自學仍是很不錯的，畢竟服務端都是開源的。XMPP 的兩個主要問題是，第一基於 XML 的協議體比較重，對其壓縮和解析又耗費內存，第二是其後端設計和開源架構有一些問題，當你的用戶體量大了以後很是耗費服務器資源，並且常見在十萬用戶數量級上頻繁的重連和丟消息。這個數據主要來自於一些咱們客戶的經驗，並非絕對準確。那麼咱們選擇什麼呢，咱們推薦使用 MQTT，或者參考其思路去設計本身的私有協議。序列化咱們推薦 ProtoBuf，這也是 Google 推薦的。選擇私有化協議的優勢是輕量，輕量處理起來就快，節省先後端資源，省電，這都是移動互聯網 App 和核心需求。此外私有協議也會相對更加安全。

商業 IM 軟件還要考慮跨平臺。要支持 Android，iOS，WP，PC，Web 端，甚至 Linux 設備。所以在設計和選擇之初就要考慮到，不然將來每個平臺和語言都要從新開發一次。咱們的協議棧使用 C++開發，基於 Linux，所以能夠無縫的兼容幾乎全部平臺。注意這個圖裏咱們把業務和數據庫放到了 native 協議棧部分，這個核心優勢是跨平臺統一，能夠保證每個細節甚至是響應時間，均可以在多平臺一致。業務和數據是否放在 native 對於架構師是比較重要的一個選擇。數據庫和業務層跟 natvie 協議棧在一塊兒還有一個重要的緣由，就是更快的響應和處理消息，當接收到消息的時候，咱們會首先給服務端發響應包，這樣服務器更快的釋放資源。而後移動端在繼續進行後續的處理。業務數據和協議都經過 native 實現，能夠更好的處理這部分邏輯。凡事有利就有弊，這個缺點也是有的，在 Android 上因爲 NDK 編譯會致使庫文件比較大，而國內 Android App 通常對體積要求比加大。解決辦法是不斷的優化更新減小尺寸。這部分稍後還會介紹。

第二個有價值的經驗是 SDK 的實現。咱們封裝了兩個 SDK。IMLib 和 IMKit，其中 IMLib 主要負責能力，創建鏈接和發送消息等功能。IMLib 實現的是一個跟微信風格相似的界面。相比之下不少產品通常只會選擇一個相似 IMLib 這樣的能力 SDK。作出這個選擇的根源是咱們但願節省開發者的時間，共同的部門實現一次就能夠了，不須要第二次第三次反覆開發，既然80%的 IM 社交界面都是相似的，那麼融雲實現了提供一個標準的模式就能夠了。開發者的創意是無限的，還有20%的需求咱們知足不了，那麼使用咱們的通訊組件 IMLib 就能夠了。咱們作這個界面 SDK 基於一個價值觀：所見即所得。客戶看到咱們宣傳的界面是這樣的，集成了 SDK 以後獲得的也是這樣的。不會像有的產品宣傳的無所不能，其實只是方便麪包裝上的效果圖，都要等着客戶本身去實現。

介紹一下IMkit組件的架構，你們看圖便可。主要是封裝了兩個界面：會話列表和會話。Android 和 iOS上設計架構略有區別。有不少工程師也糾結這個問題，是否應該讓 Android 工程師和 iOS 工程師使用一樣的設計模式，咱們的經驗是讓各類的工程師使用各自的架構，在業務上劃分好就能夠了。MVC，MVVM，MVP，本質上就是顯示層、控制層和數據層的劃分。重要的是劃分好層次便可。讓一類工程師去學習另一類工程師的開發習慣效果很差。這個經驗來自咱們融雲幾萬開發者。第二條經驗是融雲本身內部的經驗，咱們不適用第三方組件，好比說HTTP 和數據庫的第三方組件。第三條是持續的優化結耦，這也跟今天全部相似經驗同樣，選擇以後必定是有利有弊，針對弊端，要不斷的去優化。

咱們爲何選擇作一個界面SDK 呢，由於實際上在移動端，UI 的開發量是極大的，通常佔 80%以上。輸入區，表情，圖片選擇器，會話界面，消息展示等等，通常須要一個工程師1個月的時間開發，1個月的時間調試。兩個端就是4~6個月。並且老闆和產品經理還以爲很容易，雖然確實是不難，可是其實細節上作出來性能效果差異都很大的。咱們的一個價值觀就是：咱們每多作一些，開發者就少作一些，因此咱們選擇把界面封裝起來替客戶作完。固然也有缺點，IMKit 是一個很是重的封裝模式，接口不少，使用方式複雜，咱們選擇不斷的去優化，將來咱們會進一步解耦合把核心的部分再次封裝。另外咱們融雲的客戶支持服務工做作的很好，能夠提工單像咱們諮詢。咱們天天有不少研發工程師回覆200個左右的客戶工單問題，在此也感謝咱們融雲這些工程師。

再介紹一下IMLib的架構，一樣你們看圖理解吧。咱們封裝了兩個核心象，Conversation，Message，這個對象是跨平臺一致的。lib提供了像 connect、sendMesage這樣的接口，同時咱們作了不少工做，讓網絡鏈接更加穩定性。不須要客戶去作重連。不少朋友關心長鏈接和穩定和優化，其實長鏈接就是經過發送心跳包維持，並無什麼祕密。最差的結果就是多重試幾回，但咱們不能這樣，咱們必須確保客戶獲得的版本性能是最優的，因此關鍵是鍥而不捨的優化，發現問題並解決問題。咱們每一個版本都監控電量、流量、內存。確保性能最優。

第三個有價值的經驗是正確的版本迭代姿式。也是今天的點睛之筆。前面介紹的技術選擇，不能說絕對正確，但也都是基於咱們融雲資深團隊這麼多年的經驗，幾萬開發者的集成經驗。有優勢也有缺點，那麼經過什麼方式彌補優勢就很重要。好比使用 native 語言實現協議棧，優勢不少，但缺點是 Android 上的包比較大。那麼解決的辦法就是不斷優化每一行代碼去優化包的大小。提供 IMKit 的優勢是節省了用戶的時間，可是缺點就是支持使用複雜，那麼咱們就進一步去拆解和封裝。技術選擇只是第一步，以後的不斷持續優化纔是一切。

這張圖是融雲至今爲止發佈的 220 多個版本道路中的一部分，橫軸是從2015年1月到2016年4月也就是如今，縱軸是咱們衡量的一個性能參數，基於尺寸，電量，性能綜合評價。在這裏咱們分享一下咱們成功經驗，也分享一下不那麼成功的經驗，融雲於創業之初發布了1.0版本，最第一版本的要求必定是快速上線，快速支持客戶。可是在業務量體量到必定規模的時候，你的架構多是支撐不住的，因此必定要作一次架構的重構，這個狀況在不少人身上都出現過。當時咱們採用了一次大的架構更新。致使了 1.0 和 2.0 兩個版本在幾個月內並行，架構升級必定是性能的提升功能的增長。但此次升級並不能成爲成功，由於長時間版本並行，給客戶帶來了必定的煩惱。這個現象融雲遇到了，不少人也遇到了，即便如今咱們的圈內夥伴內還在進行相似的升級。那麼正確的姿式是什麼呢，咱們能夠看到從2015年8月開始到如今，咱們的總體功能增長了 32%，協議棧包下降了 75.7%，Android/iOS 源代碼量減小了 36.8，電量優化了 36% ~ 77% 不等。而用戶徹底無感知。咱們的版本號沒有變化，但其實代碼已經大變樣。我認爲身爲一個架構師，不該該讓用戶經過版本號增長去感知你架構的改變。這是咱們很驕傲的一件事，咱們在一年的時間內經過不斷迭代、追求卓越的的互聯網精神，持續的提升着軟件質量，給客戶帶來更好的性能，更小的尺寸，更加省電。這纔是咱們正確的開發者服務精神。

因此結合起來講就是，作出正確的選擇，經過不斷的迭代努力去優化本身的產品，永不中止。

第三部分，咱們講一些融雲如何實現 SaaS 級的體驗和服務。SaaS = Software as a Service，軟件即服務，在互聯網時代，SaaS 的核心是「一經要求，便可使用」，最佳實踐是經過瀏覽器，打開一個網頁就可使用。在移動互聯網時代，實現 SaaS 服務的難度相對大了一些。我認爲移動互聯網時代的 App 就是互聯網時代的瀏覽器，一樣是入口，區別是移動互聯網上的入口多了一些。用戶進入一個 App，進行他的核心體驗的同時，也會發消息，也會打電話，購物，發紅包，這些體驗能夠在 App 內閉環完成。這對 App 廠家們來講是一種核心需求，對用戶來講也是一種最佳體驗。要實現這些功能和能力，僅靠 App 廠家本身是不行的，這意味要重複建設很大的研發團隊。所以須要集成第三方服務，須要集成 SDK 發佈版本，這一步是沒法跳過的，但在集成以後，服務是能夠反覆體驗的。因此咱們融雲的目標是提供一種 SaaS 級的體驗，一經集成，便可使用。

融雲在這方面有比較好的實踐經驗，融雲提供的是即時通訊 IM，是一種通訊能力，咱們並不作具體的 SaaS 業務，好比客服。但咱們的不少客戶都須要客服，須要一個完整功能強大的客服工做臺，因而咱們選擇了跟市面上最優秀的一些廠商合做，經過融雲 SDK，讓客戶能夠在移動端使用 IM，在 PC 端使用客服工做臺。這個技術方案大概如圖，首先要在客戶端實現功能抽象化，把標準的客服功能抽象化爲具體的消息，而後經過在服務端實現一個消息轉 API 的適配層，直接訪問客服合做夥伴的服務器。這個實踐模式看起來簡單，其實這並非惟一選擇，但他是最優的，效率高性能好，合做夥伴不須要改變本身的設計架構。咱們能夠同時支持多家客服後臺，而移動端抽象化以後，對後臺使用的是誰徹底無感知，只是基於標準的信令去作處理。而對客戶來講，服務端能夠動態的控制和調整使用哪一個後臺，增長了更多的選擇。

客服是咱們的第一類實踐，咱們的第二類實踐是對音視頻產品能力的整合，對於有些客戶須要的視頻電話，視頻直播聊天室等能力，融雲也選擇了市場上最好的產品，替客戶封裝好。區別於客服的實踐場景，移動端必須使用兩個 SDK，在移動端增長適配層。這類產品融雲如今支持比較好的直播聊天室，由於融雲的 IM 聊天室能力很是強大，今年視頻直播業務火爆以後，很是多的客戶找融雲提供能夠支持超大量併發的聊天室，所以咱們把聊天室跟視頻直播進行了一個比較好的封裝和整合，方便客戶更加容易的使用。介紹這兩種優秀的實踐模式，除了適合企業開發領域，其實更加適合各個 App 廠商去根據本身的需求集成第三方服務，能夠更加靈活的把第三方 SDK 和雲服務集成到本身的 App 裏。

最後謝謝主辦方，謝謝你們。