摘要：對於移動技術而言，2017年是繼往開來之年。一方面是移動技術領域進入深水區，另一方面移動技術邊界和內涵被不斷重塑。作為專為中國企業打造的免費溝通和協同的多端平台，釘釘在發展和功能的不斷完善過程中沉澱了很多實戰經驗，2017年杭州雲棲大會上，釘釘技術專家格夫結合釘釘發展歷程為大家分享了企業溝通場景的消息服務挑戰以及系統推送鏈路的優化經驗。

演講嘉賓簡介：格夫，釘釘技術專家。入職阿里巴巴之前在百度雲服務平台部門，2014年加入釘釘創業團隊，參與釘釘消息系統設計開發，主導了IM系統性能和穩定性提升項目。目前專註於異地容災單元化系統構建。

以下內容根據演講視頻以及PPT整理而成。

本次的分享主要分為以下四個方面：

1. 釘釘發展歷程

2. 基於企業溝通場景的消息服務挑戰

3. 系統推送鏈路優化

4. 單元容災及未來挑戰

一、釘釘發展歷程

了解釘釘的人都知道，釘釘的團隊是從來往過度來的。2014年，來往分為了產品和技術兩條線，想做一些不同方面的嘗試。但是後來發現個人社交這條路基本上走不通了，所以產品線希望看看在企業服務方面是否能有所作為，於是打造了企業辦公移動平台。在技術線上，來往已經沉澱了多年的無線技術能力，並通過阿里悟空的SaaS服務面向中小APP提供IM能力。隨著產品線和技術線的共同深入，發現在企業社交場景下大有可為，後來工作圈和阿里悟空這兩個組織合併到了一起，誕生了現在的釘釘。釘釘的目標就是打造一個全新的工作方式。

從2015年初釘釘的第一個版本上線到現在，已經發布了幾十個版本，並且即將要發布4.0版本，從當初簡單的溝通協同功能到現在整個企業的一站式管理功能都已經可以在釘釘上實現。截止到2016年底，釘釘上活躍的企業數已經突破了300萬家，可以看到這一數字增長得非常迅猛，從另一個角度也可以說明目前中國的中小企業對移動辦公存在特彆強烈的需求。

二、基於企業溝通場景的消息服務挑戰

消息服務在釘釘中所處的位置

消息服務主要分為三方面：IM主要負責消息管理和會話管理；同步協議主要負責長連接的推送；第三方通知則是通過第三方的鏈路做消息保活以及提高消息服務到達率。消息服務上層承接了釘釘的整個業務層，可以看到企業OA以及通訊錄都位於消息服務的上游，而消息服務的下游就是客戶端了。可以看到消息服務所處在的位置基本上連接了業務層到客戶端整個的通訊能力，所以消息服務的可用性基本上就代表了釘釘的可用性。在消息服務中也有一個完善的監控系統可以實時反饋系統的健康度。「火眼」系統就是釘釘自研的一套系統，它記錄一條消息從發到收的整個生命周期以及垂直鏈路，這些信息都可以在後台實現完全展示，當發生消息丟失或者延遲過大等情況時可以快速定位問題所在。去年，釘釘消息服務的穩定性已經達到99.99%，今年消息服務的目標是可用性達到99.995%，推算時間，也就是全年只能有27分鐘的故障時間，這一目標對於消息服務團隊也是非常嚴峻的挑戰。

消息存儲模型

下圖所示的就是消息的存儲模型。在業界，消息存儲模型可以主要歸為兩類：一類是讀擴散；另一類是寫擴散。讀擴散就相當於一個人在群組中發了一條消息，存儲的時候僅存儲一份，每個群成員都到群組裡拉去最新的消息；寫擴散就相當於為每個人建立一個收信箱，每個群組產生了消息之後，就向每個人的收信箱提交一條消息。釘釘在選擇使用存儲模型的時候進行了權衡，從下圖中可以很明顯地感覺到與寫擴散相比，讀擴散所具備的優勢非常明顯，無論是擴散的存儲成本還是讀寫效率上，讀擴散都具有非常明顯的優勢。但是釘釘卻偏偏選擇了寫擴散的方式，這是因為在梳理了釘釘的業務功能需求後，發現釘釘群聊中每個人的每條消息狀態都是完全不同的，比如釘釘有已讀的功能、消息轉接功能、會話消息的清除和撤回功能等等，所以每個人在會話中的狀態都是不同的。而採用寫擴散的方式更易於維護每個人的消息狀態，所以釘釘最終採用了寫擴散模型。但是很明顯，寫擴散的成本非常大，所以也為以後的架構演進埋了不少坑。

消息發送流程

消息發送流程主要分為消息的接收和消息的處理。在消息的接收鏈路上，儘可能地讓邏輯越少越好，保證用戶發消息的體驗比較順暢。這裡主要實現了三個功能：流控、安全過濾和關係校驗，完成這三步之後就代表消息已經發送成功了。消息接收和消息處理之間通過了非同步的MQ實現了邏輯的解耦。在消息的處理上實現了消息可重錄，也就是每條消息可以至少被消費一次，做到冪等。消息處理中有五個核心功能，除了持久化的依賴比較強之外，其他的功能當出現故障的時候都可以實現主動降級，消息從發出到推送到客戶端的延時可以做到保證，目前消息的延時都是低於200毫秒的。

接下來分享基於以上模型遇到的挑戰。

挑戰一：萬人全員群節日場景

目前，越來越多的萬人企業開始使用釘釘，並且釘釘也提供了全員群。所以當這樣的群異常活躍的時候，特別在發紅包的場景下，大家搶的非常迅猛，因為採用了寫擴散模型，這時候存儲的壓力就會比較大，而更進一步擴散的成本也會比較大。如圖所示的是某個企業在2015年釘釘上線紅包功能之後統計出來推送量，當發紅包時推送量立即突增了20倍，這所造成的存儲壓力是非常大的。

解決這種情況的方案主要分成了以下三個方面：

• 第一，分而治之。雖然給用戶感覺是萬人群是一個大群，但是其實在後台將萬人群切分成了若干個小群，每條消息都會通過小群並行地推到客戶端，這樣一來就降低整個消息入庫的延遲。

• 第二，降級服務&消息管控。當群突然變得異常活躍時，可以主動地將一些已讀、未讀等附屬功能移掉、推薦群主打開群禁言，這樣就能在客戶端上將消息量大大地降低，並且也會在服務端做群粒度的頻次控制，可以根據群成員的數量限制每分鐘所能發送的消息條數。

• 第三，用戶登錄推送消息閾值。當檢測到用戶所收到的消息量超過一定的閾值的時候立即從推的模式變為推拉結合的方式，通過這種方式降低客戶端流量，保證客戶端收消息體驗的順暢性。

挑戰二：考勤打卡提醒、運營活動推送

通過下圖的曲線大家可以看到，流量出現峰值的時候往往是早高峰或者晚高峰，還有釘釘運動會在每天9點半將大家的運動結果推送給各個端。早晚高峰會出現流量的突增，而平時的流量卻沒有這麼多，這樣就只能靠在服務端堆積伺服器才能夠滿足早晚高峰的流量需求，但是服務端的資源是不可控的，隨著企業和用戶數量不斷增加，依靠堆積伺服器來滿足推送需求很明顯是不合理的。

針對於這種場景，釘釘抽象出了兩種概念：

第一，針對考勤打卡場景，其時效性很強，必須要在打卡前的幾分鐘推送完畢，同時它也是一種重複類型的消息，基本上每天都會推一次考勤打卡的提醒。對於這個場景消息釘釘採取了Local Push策略，首先這種消息會通過Server下發一個定時任務，基於每個端Native的通知任務機制將任務埋在客戶端，到時間就觸發任務，之後推送一個本地通知，這樣就將服務端的推送需求轉嫁給客戶端了，進而化解峰值推送需求。

第二，對於時效性需求不那麼強的運營類場景而言，比如釘釘運動從每天9點半開始推送，而實際上10點半推送完畢對於用戶而言也沒有特別大的影響。針對於這種情況，釘釘的消息服務抽象出了一個任務實時調度系統，實現了分散式的LoadController，並通過QS的限制起到削峰平谷的作用。與此同時也起到了推送的安全性檢查的作用，比如某個業務由於Bug向用戶反覆推送同一條消息，這很明顯是有問題的，而通過疲勞度控制、黑名單的過濾的機制可以降低業務端出現Bug所造成的影響以及客戶端體驗的問題。當任務推送完成以後，還可以將這種錯誤的消息撤回，比如說某一類運營消息推送錯了，但是用戶已經收到了，通過這套系統可以瞬間地經由服務端下發將消息撤回，這樣一來用戶也是沒有感知的，不會影響用戶使用釘釘的體驗。

挑戰三：企業信息安全保障

一般而言，企業的信息都具有較高的私密性需求，為了幫助企業用戶降低使用釘釘的疑慮，讓企業可以更加放心地使用釘釘，釘釘團隊也從產品和技術兩個層面上進行了多種嘗試。

首先，釘釘支持內部群的概念，當員工離職之後可以自動地從企業群中退出，這樣以來在職員工所能夠接收到的信息在離職之後就變得完全不可見了。另外，對於單聊消息而言，支持閱後即焚功能，可以實現單聊消息在被接收者閱讀之後從客戶端到服務端這樣全端地被清除掉，其他人無法感知到。在客戶端，釘釘推送消息到服務端的過程基於SSL/TLS協議的加密方式在整條鏈路上進行數據傳輸；在服務端，釘釘也通過阿里巴巴集團強大的加密技術保證內部數據流轉和持久化都可以實現服務端的全鏈路加密。

以上的幾點基本滿足了一般企業的信息安全保障需求。此外，釘釘還提供了第三方加密的方式，也就是根據企業的申請，在客戶端上通過第三方加密的SDK，為每個企業分配一個加密的Key。企業用戶在進行數據傳輸時會根據這個Key進行數據加密，數據傳到服務端就是一堆亂碼，完全無法感知。而且當員工離職的時候加密的Key會在其客戶端上立刻失效，這樣離職員工就完全無法破解和獲得之前通過Key加密的消息，進而保障了企業的消息在釘釘中流轉的安全性。

經過上述幾點的優化，釘釘已經通過了ISO27001:2013信息安全管理體系標準認證以及公安部信息系統三級等級保護認證，所以現在政企、事業單位以及對安全性要求比較高的企業都可以更加放心地使用釘釘這款產品了。

挑戰四：協同工具信息流整合

一個企業不可能只用釘釘這一款產品，因為他們可能會有自己的OA系統、審批系統等，那麼如何進行信息流轉也是一個問題。當時釘釘團隊也參考了一些國內外比較優秀的軟體產品，他們提出了chatbot這個概念，而chatbot存在兩種方式：Incoming和Outgoing，所以釘釘也借鑒了這兩種方式抽象出了自己的方案。釘釘的Incoming方案就是第三方服務的信息聚合到群聊中，實現由外而內的自動化信息同步；而Outgoing則是將釘釘會話內容輸出到指定機器人，和外部系統做信息交換。通過Incoming和Outgoing這兩種方式基本上可以實現跨APP、跨平台的信息流轉，起到了信息整合的作用，這樣企業就可以放心地將自己的系統和釘釘進行對接。

釘釘的信息流整合現在也提供了一些通用的bot，比如互聯網公司比較喜歡使用的Gitlab和Github等工具，當代碼發生變更的時候可以通過Incoming機制將代碼的變更快速地同步到群中，這樣大家都可以看到變更以及提交的日誌等信息，進而實現了一種外部系統和釘釘的交互方式。同時，釘釘引用了企業專有的chatbot。舉兩個例子就是內外小蜜和報警助手，內外小蜜是阿里巴巴內部經常使用的工具，比如需要查詢自己的稅號、福利以及園區地圖等都可以在釘釘上通過內外小蜜的chat方式進行交互，進而快速得到自己所需要的信息，內外小蜜實際上就是由釘釘和阿里巴巴信息事業部進行信息整合所產生的產品；第二例子就是報警助手，阿里巴巴有自己的一套報警信息管理平台，之前當故障發生之後都是通過簡訊、電話等方式快速將系統問題報警給負責人的，現在則是通過Incoming機制將報警平台與釘釘進行整合，當問題出現之後的第一時間通過釘釘發消息給負責人，如果負責人沒有確認還可以轉成ding的提醒方式，這樣報警系統就實現了通過釘釘將問題快速地反饋出來。

三、推送鏈路優化

推送鏈路優化——同步協議推送

之所以需要實現同步協議推送，主要是基於以下兩點：

• 產品角度。在早期的IM 1.0的時代，釘釘的消息和會話狀態不能做到多端同步，比如當使用PC端接收消息之後，在ios端或者Android端就無法看到這條消息了，這對於企業溝通場景而言是完全無法接受的。並且當在一個端讀了消息之後，還會在另外一個端標又注了未讀的信息，造成了一些溝通方面的誤導，所以整體的用戶體驗也是比較糟糕的。

• 系統角度。早期的時候，消息和狀態會無序地推到端，導致了移動端處理起來非常複雜。比如在使用釘釘進行溝通的時候創建了一個群聊並發送了一條消息，這個過程就涉及到了兩個事件：創建群聊和發送消息。在早期，這兩個事件會無序地推到端上，所以如果發送消息的事件先於創建群聊事件達到端上就會出現問題，此時就需要回到服務端上拉取會話狀態，再把消息呈現出來，而且端上還要做相當於回滾的策略。針對於上面所提到問題，早期釘釘在端上做了大量的兼容工作，所以實現起來非常複雜。由於整體是無序的狀態，當特別的大量消息推送到客戶端的時候無法做到下行的擁塞控制，導致了手機端的CPU被佔滿，進而出現卡頓的情況。

基於以上幾點，釘釘參考了業界主流的協議，比如說微信和支付寶等使用的協議，在2015年8月份立項開展同步協議系統的實現工作，2016年3月份，釘釘開始灰度同步協議推送的功能，6月份IM業務開始全量地接入到了同步協議。所以現在大家如果使用釘釘就會發現體驗較兩年前有了較大提升。

簡單介紹一下同步協議推送的思路。如下圖示例，ID為21051的用戶向ID為21254的用戶發送了一條IM文本消息，這條消息首先會進入到同步協議系統中，同步協議會將這個消息打包進行分發，這裡存在一個順序隊列，並且每個用戶只能哈希到一個順序隊列，這是為了保證同一個用戶所產生的消息和狀態能夠順序地進入到一個隊列中。之後handler會消費這個順序隊列，當消費到了ID為21254的用戶有一個消息推送的時候，計數器就會為這條消息分配一個自身位點，這個位點在系統內部叫pts，此時原來的pts 1004就會做自增操作，為新消息分配了pts為1005。在分配完pts之後，會將這條消息插入到存儲中，這樣就完成了同步消息入庫的流程。那麼，消息如何下發到客戶端呢？每個端上都會記錄下當前它接受收過的最大pts位點，當發生重連或者推送超時的情況就會觸發它到服務端上去拉取新消息，當服務端存儲裡面有大於最大pts位點的消息時，釘釘就會把大於最大pts的所有消息都推送到客戶端，這樣就實現了多端的同步。早期的同步協議大致就是這樣的一個信息流轉的過程。

但是在後期的全量業務上線之後，上述的信息流轉過程也出現了問題。前面也提到釘釘使用了順序隊列解決了用戶消息的排序問題，而當某個用戶消息量一大之後，整個順序隊列會非常容易地堆積起來，進而影響其他用戶的消息延時。此外，還需要為每個用戶提供一個pts計數器。早期釘釘利用緩存機制實現了pts計數器，但是當這樣的方案遇到容災故障以後，極易造成pts的回退，而再次分配pts則有可能使得入庫順序變得混亂，進而導致消息丟失。面對性能瓶頸，當時釘釘和阿里雲的Table Store團隊共創引入了自增列的概念。具體而言就是將生成pts的過程和消息入庫的過程進行了整合，將兩個過程整合為一個原子性操作，由存儲分配pts，這樣就解決了性能瓶頸，並且極大地提升同步協議推送效率。如果大家想要更加具體地了解關於自增列的相關內容，阿里雲的官網上面也提供了更加詳細介紹，並且目前這一功能已經對外輸出了。

推送鏈路優化——消息到達率提升

眾所周知，消息的到達率一直都是IM開發人員心中的痛，在消息到達率的定義上，每個公司有自己的標準，釘釘是對每天新產生的消息，從產生到推送給端上的時間進行了分片，用每個分片除以一天內產生的消息總量作為每個分片的推送到達率，這樣就統計出了釘釘每天產生消息的到達率情況。而且釘釘將10秒內產生的消息推送到端上的到達率作為衡量IM的到達率和可靠性的重要指標。2015年，釘釘的10秒到達率才30%，經常收到用戶的投訴和吐槽，那時的到達率也確實很低。後來，釘釘成立了一個專門的優化小組來對消息到達率進行專項優化。

對於ios設備，大家都知道通過APNS推送是不存在消息到達率問題的，因為ios的消息推送體驗還是相當好的。但是當時也存在另外一個問題，因為開始時國內是直聯到蘋果伺服器的，當APNS量非常大的時候，丟包率就會非常高。針對這個問題，釘釘搭建了海外的加速節點，在消息產生之後先通過阿里巴巴內部專線投遞到海外節點，再投遞給蘋果伺服器，這樣ios上的消息到達率就有了很好的保證。

但是提到Android，大家往往會默默地流淚，這是因為國內推送的環境實在太糟糕了，所以釘釘針對安卓設備做了重點設備的適配。釘釘團隊將使用Android系統的手機產生的整體佔比拉出來，針對重點機型，比如排在前幾位的華為、VIVO以及小米等進行了重點適配。釘釘還和華為廠商進行合作，接入到了華為智能心跳，與華為自己的推送通道結合保證了釘釘在華為Android端的消息到達率。OPPO和VIVO對於應用存在嚴格的功耗測試，需要保障待機時間等性能指標。而小米的系統有自己的Push，可以實現類似於APNS的系統級推送，接入到小米Push之後基本上就可以保證消息的到達率。針對海外用戶，釘釘使用了Firebase推送鏈路確保海外設備高可用的到達率保障。2016年，釘釘的10秒消息到達率提升到60%多，而且使用Android設備的用戶的投訴率也大大降低了。

四、單元容災及未來挑戰

釘釘目前主要在單元化容災方面進行發力。之所以需要實現單元化支持，主要是因為三點：第一，企業高可用需求；第二，國際化戰略；第三，政企專有雲。基於以上三點，釘釘採取了單元化的方式進行實現，各個單元之間的流量和數據都是不能互通的，基本上滿足了這三點的需要。

在單元的可用性方面抽象出了三個概念：高可用單元、普通可用單元和低可用單元。高可用單元的實現類似於「兩地三中心」的思想，當主機房掛掉之後，異地機房可以立即承擔起來自主機房的流量，數據在異地單元也有完整的熱備。普通可用單元基本上在同城的雙機房進行數據互備。而低可用單元就是數據單點了。通過以上的三個概念，基本上可以滿足企業對於不同層次的高可用需求，同時也降低了釘釘的消息存儲成本。

釘釘IM系統未來的挑戰與規劃

• 萬人大群推送策略。釘釘現在採用的是寫擴散方式，而目前使用釘釘的萬人企業越來越多，寫擴散的推送策略可能無法承接大群的需要，所以未來需要思考是否可以採用讀擴散的方式。

• 消息存儲成本管控。釘釘支持消息路由，用戶在釘釘上近一年的消息記錄都是持久化保存下來的，可以隨時拉取到。顯然，數據的存儲成本也會成為需要重點考慮的問題，消息成本的管控也是未來需要優化的方向。

• 用戶跨單元的數據遷移需求。目前釘釘已經實現單元化，勢必會帶來某個用戶從低單元遷移到高單元或者從高單元遷移到低單元的場景，確保數據一致性遷移過程的用戶體驗也是比較嚴峻的考驗。

• IM群組能力開放。目前釘釘的群組能力是通過chatbot機制實現的，未來需要通過更多的方式與外界進行信息流流轉，比如通過群微應用打造更加完整的群聊生態，最終目的是保障整個企業在釘釘上的溝通實現高效率和高可用。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！