來自微信團隊的 6 個開源項目

從github上可以看出，到目前為止，由騰訊微信團隊發起的開源項目已經有6個，并且這其中大部分都是在2016年開源的，領域涉及移動、資料庫、基礎類庫、架構。中國大公司的開源曾經給社群留下不好的印象，比如有人就這麼說，大公司的開源，開源也就意味着結束。也有人說，大公司的開源大部分都是kpi項目，開源與業務不能相得益彰，是以根本無法持續投入。

相比來說，facebook就是網際網路公司裡的開源大戶，目前他們的開源項目已經有近300個。對于為什麼要釋出開源項目，facebook開源項目負責人也曾經解釋過，總結起來說有三點，一是開源能夠幫助他人更快地開發軟體，促進世界創新，主要是社會價值層面的考慮。二是開源能夠倒逼facebook的工程師寫出更好的代碼。三是開源能夠更有效利用社群的力量，幫助facebook一起解決難題。

那微信是如何了解開源這件事，以及他們未來準備通過哪種機制保證開源項目的健康發展，帶着這些問題，infoq記者采訪了微信終端團隊的負責人趙原。

趙原認為開源不僅是一種态度，更是一種能力，微信希望通過開源打通内部團隊和外部社群，一方面可以把微信的頂級技術輸出給了社群，另一方面也可以把外部的優秀的思想傳遞到内部團隊。對于開源的了解，趙原這樣解釋：

第一個關鍵詞價值。微信團隊通過将内部的研究成功優化、整合，并輸出，以幫助更多的開發者更友善地建構他們的軟體。工程師之間最好的交流媒介就是代碼，通過代碼，微信團隊可以将他們的技術思想傳遞到社群，并影響更多的人。

第二個關鍵詞優勢。微信最大的優勢是有海量的使用者，很多外界開發者根本沒有發現或者遇到過的複雜問題，微信團隊都早已經解決掉了，比如在移動開發領域的系統相容性、使用者多樣化的網絡環境等問題。通過開源，微信不僅可以授之以魚，還可以授之以漁。

第三個關鍵詞活力，微信開源的項目必須來自微信，最後必須在微信落地。開源項目最怕沒人維護，通過産品疊代，這些開源的項目持續的更新，給他們一個心跳的機制，使他們依然有活力。

第四個關鍵詞易用。一個優秀程式員可以花上很多的時間研究微信開放的技術源碼的技術思想和設計。但對于不是很有技術實力的開發人員，是否能從微信的開源項目中依然獲益呢？答案是肯定的。他可以将微信開源的項目引入在自己的app中，将微信很多的能力運用在自己的app中。

而對于項目開源之後的營運問題，趙原也做了思考：

活力，不得不提起一個尖銳的問題，在大公司裡面做開源項目，開源通常意味着這個項目的結束。優秀的開源項目意味着開始，和大公司裡的開源項目做法天生有一些沖突。

第一大公司裡面做開源項目其實是有一些短期kpi導向的短期項目，開源項目需要持續的人力投入在其中。第二個問題，每一個團隊裡面員工開發的精力是有限的，做技術研究的時候，需要花很多時間在供應商的開發，這是從員工方面看開發精力的沖突。第三大公司内通常有完備的開發體系，而這些開發是封閉的，很難說和外部的開源體系對接起來。

今天看這個問題，微信也想過很暴力、很簡單的想法，比如說團隊10個人，這10個人可以做功能開發，如果為了解決這個問題，再招10個員工砸在開源項目上，大公司可能最不缺的就是人力，問題是在大公司裡面看上去是可以解決的，但放在微信上面卻覺得行不通，微信講究小團隊作戰，講究精兵政策，不浪費一兵一卒。

為了解決這個問題，微信在開發tinker項目的過程中，大概用了快一年的時間解決，其實解決問題的方法很簡單。簡而言之，就是将微信的開發團隊改造成一個開源化的開發模式。

微信通過對内部系統的改造，使内部的開發和外部的開發模式基本沒什麼不同。一份代碼，既可以在微信中使用，也可以在外部的開發者中使用，這科技減少額外的人力投入。

另外微信還收獲了很多價值。比如外部的開發者還可以提供一些微信團隊沒有發現的問題，對于微信來說是一個很好的優化bug的管道。通過與外部社群的深入交流，團隊的學習能力也能得到很大提升。

下面是infoq編輯整理的微信現有的比較活躍的開源項目清單，歡迎交流讨論。

c/c++協程庫libco

libco是微信背景大規模使用的c/c++協程庫，2013年至今穩定運作在微信背景的數萬台機器上。libco提供了完善的協程程式設計接口、常用的socket族函數hook等，使得業務可用同步程式設計模型快速疊代開發。

早期微信背景因為業務需求複雜多變、産品要求快速疊代等需求，大部分子產品都采用了半同步半異步模型。接入層為異步模型，業務邏輯層則是同步的多程序或多線程模型，業務邏輯的并發能力隻有幾十到幾百。随着微信業務的增長，系統規模變得越來越龐大，每個子產品很容易受到後端服務/網絡抖動的影響。基于這樣的背景，微信開發了libco，實作了對業務邏輯非侵入的異步化改造。

star數量：1043

生産級paxos類庫phxpaxos

phxpaxos是微信背景團隊自主研發的一套基于paxos協定的多機狀态拷貝類庫。它以庫函數的方式嵌入到開發者的代碼當中，使得一些單機狀态服務可以擴充到多機器，進而獲得強一緻性的多副本以及自動容災的特性。phxpaxos在微信服務裡面經過一系列的工程驗證和大量的惡劣環境下的測試，在一緻性的保證上極為健壯。

phxpaxos的特性包括使用基于消息傳遞機制的純異步工程架構、每次寫盤使用fsync嚴格保證正确性、支援checkpoint以及對paxoslog的自動清理、使用點對點流式協定進行快速學習、支援跨機器的checkpoint自動拉取、内置master選舉功能、自适應的過載保護等。

star數量：970

高可用、強一緻的mysql叢集：phxsql

phxsql是一個相容mysql、服務高可用、資料強一緻的關系型資料庫叢集。phxsql以單master多slave方式部署，在叢集内超過一半機器存活的情況下、即可提供服務，并且自身實作自動master切換、保證資料一緻性。phxsql不依賴于zookeeper等任何第三方做存活檢測及選主。phxsql基于mysql的一個分支percona 5.6開發，功能和實作與mysql基本一緻。

mysql主備在主機上支援完整sql、全局事務、以repeatable read和serializable級别的事務隔離，在金融、帳号等關鍵業務中有巨大的價值。但是mysql傳統主備方案也有其缺點。最明顯的就是主機故障後的自動換主和新舊主資料一緻性，即所謂的一緻性和可用性。為了解決這個問題，并同時完全相容mysql，微信在mysql的基礎上應用paxos，設計和開發了phxsql。

star數量：1485

rpc架構：phxrpc

phxrpc是微信背景團隊推出的一個簡潔小巧的rpc架構，編譯生成的庫隻有450k（編譯隻依賴第三方庫protobuf）。phxrpc的特性如下：

使用protobuf作為idl用于描述rpc接口以及通信資料結構。

基于protobuf檔案自動生成client以及server接口，用于client的建構，以及server的實作。

半同步半異步模式，采用獨立多io線程，通過epoll管理請求的接入以及讀寫，工作線程采用固定線程池。io線程與工作線程通過記憶體隊列進行互動。

提供完善的過載保護，無需配置門檻值，支援動态自适應拒絕請求。

提供簡易的client/server配置讀入方式。

基于lambda函數實作并發通路server，可以非常友善地實作google提出的 backup requests 模式。

star數量：467

終端跨平台網絡元件：mars

mars是微信官方的終端基礎元件，是一個結合移動應用所設計的基于socket層的解決方案，在網絡調優方面有更好的可控性，采用c++開發。目前已接入微信 android、ios、mac、windows、wp 等用戶端。

在微信中，任何網絡實作的bug都可能導緻重大事故。例如微信的容災實作，如果因為版本的實作差異，導緻某些版本上無法進行容災恢複，将會嚴重的影響使用者體驗。微信研發了統一的跨平台的網絡基礎庫mars來滿足發展的需要，一方面，基礎元件可以提高研發效率，另外一方面，也可以提高系統的穩健性。

在設計上，mars以跨平台、跨業務為前提，遵從高可用，高性能，負載均衡的設計原則。以網絡的可用性為例，移動網際網路有着丢包率高、帶寬受限、延遲波動、第三方影響等特點，使得網絡的可用性，尤其是弱網絡下的可用性變得尤為關鍵。mars 的stn元件作為基于 socket 層的網絡解決方案，在很多細節設計上會充分考慮弱網絡下的可用性。

star數量：5895

熱更新檔技術tinker

tinker是微信官方的android熱更新檔解決方案，它支援動态下發代碼、so庫以及資源，讓應用能夠在不需要重新安裝的情況下實作更新。

目前市面的熱更新檔方案有很多，其中比較出名的有阿裡的andfix、美團的robust以及qzone的超級更新檔方案，但它們都存在無法解決的問題，是以微信研發了自己的解決方案。總的來說，andfix作為native解決方案，首先面臨的是穩定性與相容性問題，更重要的是它無法實作類替換，它是需要大量額外的開發成本的。而robust相容性與成功率較高，但是它與andfix一樣，無法新增變量與類隻能用做的bugfix方案。qzone方案可以做到釋出産品功能，但是它主要問題是插樁帶來dalvik的性能問題，以及為了解決art下記憶體位址問題而導緻更新檔包急速增大的。