微信架構的啟示

        騰訊大講堂中最近分享了周顥演講的微信技術總監解讀微信架構的秘密，看完視頻的一些心得。

        技術微創新

        微信的技術設計上有很多微創新，看起來都很小，但是對于系統的穩定性、用戶體驗及開發敏捷都具有重要作用。

        前輕后重

        由于客戶端升級不便，從技術設計上盡量利用后端的設計來減少依賴客戶端升級的方法。如某個版本新增了群聊功能，按常規思路，需要所有客戶端升級 才能全部打通。微信采用服務器兼容的方法，在老客戶端不升級情況下讓其增加群聊的功能，通過在服務端將群聊協議轉換成之前舊版兼容的協議返回給老的客戶 端。

        客戶端輔助設計

        微信客戶端做了很多非常規的功能，比如常規的客戶端測速方法是登錄階段輪詢測試多個IP來選擇服務器，這樣會帶來流量及登錄速度雙方面的開銷， 因此微信選擇的方法是服務端返回最佳的IP（可能是通過歷史數據分析）。客戶端另外實現了一些容災能力的配合，當一個IDC訪問出現異常自動選擇另外一個 IDC。

        流量控制

        由于大部分無線用戶對流量非常敏感，為了防止由于客戶端不可預知的bug如死循環導致“偷流量”，服務端增加用戶流量實時分析的方法，可以在海量數據下找出流量異常的用戶，并給這些用戶強制下行終止連接信號。

        基礎研發的策略

        從視頻介紹來看，微信的基礎研發與業務結合非常緊密，提到的有基礎組件比如Client/Server框架，從原理上看類似推ter Finagle，框架封裝了大容量網絡通訊及遠程調用所需各種功能。此外介紹的一些監控與統計框架也較為先進，可以隨時增加監控指標。

        大量可復用的基礎組件讓業務開發非常敏捷，周顥總結的基礎研發策略是“實現已有經驗的固化”。這和其他一些公司中的基礎研發團隊思路有所區別。 業界中基礎研發脫離生產閉門造車的情況并不罕見，一方面業務部門重復低層次開發現象嚴重，另外一方面基礎研發對業務理解欠缺，開發的組件模塊與業務結合不 緊密，無法被有效利用。因此類似微信這樣增強業務團隊的力量，在開發業務同時總結抽象更多的基礎組件或許是一種更為實用的發展思路。

        騰訊海量課程

        視頻中多次提到騰訊內部的一種海量模型的培訓課程，其中的經驗或設計模式包括

        大系統小做

        將一個復雜的大系統分解成多個獨立的、小的、簡單的任務去完成，“分而治之”。

        柔性可用

        服務端系統通常不是0與1之間的選擇，可以在極端情況下做一定優雅降級，在服務端代碼中需要體現這些設計。

        Set模型

        類似最近討論的cell架構， 按一個服務按用戶范圍分成不同的小單元，每個小單元(cell/set)具備全部業務服務能力，當一個set發生故障時候，只會影響這一小部分用戶。微信 架構中所做的補充是，在set之間增加了容錯處理，當一個set發生故障時，使用類似一致性哈希的算法，調用方可以自動切換到下一個set來存儲，并且將 新的位置記錄在index上(類似GFS master)，周顥自稱是一個簡化版的GFS。

        微信的協議

        里面提到了XMPP和類Sync的自定義協議，里面提到XMPP的缺點是流量大和消息不可靠。但是流量大并非XMPP主要矛盾，可以很簡單將其映射成二進制協議。消息ACK也可以添加簡單的擴展協議來實現。較繁瑣的還是兼容CMWAP網關的設計。

        使用XMPP或者簡化的XMPP標準協議有很多好處，類似的場景有業界廣泛使用的open api基本都使用HTTP及JSON，并不是由于這兩種協議優化或高效，而是其簡潔并得到廣泛的認知。一種標準協議的認知及擴展成本要比一個自定義協議小 得多，XMPP流量大的問題可以通過轉換協議來實現，比如用binary 1代表login等全部協商協議，2代表message，消息增量獲取也可以通過自定義擴展協議來實現。標準協議可以讓團隊內部及新人的認知成本降低，每 一個參與者都很容易想到代碼及架構改進建議。而且微信目前也在構建開放平臺，自定義協議在開放方面必然具備一些局限。

        其他

        分布式理論

        從微信的分享也看到，指導業界不同背景的團隊（不管大小）的分布式理論主要還是Google及Amazon系列論文，對互聯網技術的發展具有深遠影響。微信借鑒了Quorum及Merkle tree的理論，創造了一種自定義的做法，用于實現一種分布式遞增發生器。

        不過分布式遞增算法其實有更簡單的實現方法，推ter也有相關的公開博文，由于視頻相關背景介紹比較簡短，可能大家解決的需求具有差異，就不展開了。

        監控

        數千的監控項，可以在分鐘發現系統的異常。

        敏捷

        每天20個后臺變更

        技術傳承

        從視頻和PPT來看，微信的技術體系是從頭搭建的，可能有不少利用qqmail時代的基礎代碼，但與深圳團隊并不存在太大技術沿襲或者傳承關系。從另外一個角度也看到微信技術團隊的戰斗力。

        新人力量

        一位畢業生的創意：按SET分布，全量數據從2G減到200K（具體的情況待了解）。

        另外一個新特性，漂流瓶及搖一搖，據說也是2個月的本科畢業生一周完成，而且上線后運行穩定。

        存儲

        上圖中可擴展設計中字段配置表的做法感覺略顯繁瑣，目前大部分NoSQL產品的schema free方式可能更易于維護。

        產品驅動

        如圖，其中“允許發布十分鐘前的變更”這樣做法通常在大型團隊通常會引起廣泛質疑，單純學習這種形式并非正解，如何在互聯網產品上實現敏捷值得產品和研發進一步思考。