騰訊大講堂中最近分享了周顥演講的微信技術總監解讀微信架構的秘密，看完視頻的一些心得。
技術微創新
微信的技術設計上有很多微創新，看起來都很小，但是對於系統的穩定性、用戶體驗及開發敏捷都具有重要作用。
前輕後重
由於客戶端升級不便，從技術設計上儘量利用後端的設計來減少依賴客戶端升級的方法。如某個版本新增了群聊功能，按常規思路，需要所有客戶端升級才能全部打通。微信採用服務器兼容的方法，在老客戶端不升級情況下讓其增加群聊的功能，通過在服務端將群聊協議轉換成之前舊版兼容的協議返回給老的客戶端。
客戶端輔助設計
微信客戶端做了很多非常規的功能，比如常規的客戶端測速方法是登錄階段輪詢測試多個IP來選擇服務器，這樣會帶來流量及登錄速度雙方面的開銷，因此微信選擇的方法是服務端返回最佳的IP（可能是通過歷史數據分析）。客戶端另外實現了一些容災能力的配合，當一個IDC訪問出現異常自動選擇另外一個IDC。
流量控制
由於大部分無線用戶對流量非常敏感，為了防止由於客戶端不可預知的bug如死循環導致“偷流量”，服務端增加用戶流量實時分析的方法，可以在海量數據下找出流量異常的用戶，並給這些用戶強制下行終止連接信號。
基礎研發的策略
從視頻介紹來看，微信的基礎研發與業務結合非常緊密，提到的有基礎組件比如Client/Server框架，從原理上看類似Twitter 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的理論，創造了一種自定義的做法，用於實現一種分佈式遞增發生器。
不過分佈式遞增算法其實有更簡單的實現方法，twitter也有相關的公開博文，由於視頻相關背景介紹比較簡短，可能大家解決的需求具有差異，就不展開了。
監控
數千的監控項，可以在分鐘發現系統的異常
敏捷
每天20個後臺變更
技術傳承
從視頻和PPT來看，微信的技術體系是從頭搭建的，可能有不少利用qqmail時代的基礎代碼，但與深圳團隊並不存在太大技術沿襲或者傳承關係。從另外一個角度也看到微信技術團隊的戰鬥力。
新人力量
一位畢業生的創意：按SET分佈,全量數據從2G減到200K（具體的情況待了解）
另外一個新特性，漂流瓶及搖一搖，據說也是2個月的本科畢業生一週完成，而且上線後運行穩定。
存儲
上圖中可擴展設計中字段配置表的做法感覺略顯繁瑣，目前大部分NoSQL產品的schema free方式可能更易於維護。
產品驅動
如圖，其中“允許發佈十分鐘前的變更”這樣做法通常在大型團隊通常會引起廣泛質疑，單純學習這種形式並非正解，如何在互聯網產品上實現敏捷值得產品和研發進一步思考。
閱讀更多 架構師的修煉之路 的文章
