<object id="0o2s2"><acronym id="0o2s2"></acronym></object>
  • <input id="0o2s2"><u id="0o2s2"></u></input>
  • <input id="0o2s2"><u id="0o2s2"></u></input> <menu id="0o2s2"></menu>
    <nav id="0o2s2"><acronym id="0o2s2"></acronym></nav>
    <menu id="0o2s2"><u id="0o2s2"></u></menu>
  • <input id="0o2s2"><button id="0o2s2"></button></input><input id="0o2s2"><acronym id="0o2s2"></acronym></input><nav id="0o2s2"></nav>
  • <input id="0o2s2"></input>
    專業 靠譜 的軟件外包伙伴

    您的位置:首頁 > 新聞動態 > 微信內部微服務軟件開發架構案例分享!

    微信內部微服務軟件開發架構案例分享!

    2017-08-10 20:15:36

    背景介紹

    首先,我們需要敏捷開發。過去幾年,微信都是很敏捷地在開發一些業務。所以我們的底層架構需要支撐業務的快速發展,會有一些特殊的需求。

    另外,目前整個微信團隊已經有一千多人了,開發人員也有好幾百。整個微信底層框架是統一的,微信后臺有千級模塊的系統。比如說某某服務,有上千個微服務在跑,而集群機器數有幾萬臺,那么在這樣的規模下,我們會有怎么樣的挑戰呢?

    我們一直在說“大系統小做”,聯想一下,微服務與騰訊的理念有哪些相同與不同的地方呢?通過對比,最終發現還是有許多相通的地方。所以我挑出來講講我們的實踐。

    看過過去幾個會議的內容,可能大家會偏向于講整一個大的框架,比如整個云的架構。但是我這邊主要講的是幾個特殊的點。

    概覽詳情

    開始看一下我們的結構。全球都有分布,主要有上海、深圳、香港、加拿大幾個數據中心。

    微服務在微信的架構實踐

    其中上海服務國內北方的用戶,深圳負責南方用戶,加拿大服務北美、南美和歐洲,香港服務東南亞、中東和非洲地區。

    然后來看看我們的架構:

    微服務在微信的架構實踐

    • 最上邊是我們的產品;

    • 然后有一個號稱幾億在線的長連接和短連接的服務;

    • 中間有一個邏輯層,后臺框架講的主要是邏輯層往后這塊,包括我們的 RPC、服務分組、過載保護與數據存儲;

    • 底層有個 PaxosStore 存儲平臺。

    整套就是這么個體系。微服務很容易去構建,但是規模變大后有哪些問題,需要哪些能力?這里挑出三個點來講一下:

    微服務在微信的架構實踐

    一、敏捷

    希望你的服務很快實現,不太多去考慮。像我們早期互聯網業務,甚至包括 QQ 等,我們很注重架構師的一個能力,他需要把握很多的東西。他設置每個服務的時候,要先算好很多資源,算好容災怎么做。容災這個問題直接影響業務怎么去實現的,所以有可能你要做一個具體邏輯的時候要考慮很多問題,比如接入服務、數據同步、容災等等每個點都要考慮清楚,所以節奏會慢。

    二、容錯

    當你的機器到了數萬臺,那每天都有大量機器會有故障。再細一點,可以說是每一個盤的故障更頻繁一點。

    三、高并發

    基礎架構

    接下來看看我們的基礎架構。

    微服務在微信的架構實踐

    整個微服務的架構上,我們通常分成這些部分:

    • 服務布局

    • 服務之間怎么做一些遠程調用

    • 容錯(主要講一下過載保護)

    • 部署管理

    服務布局

    微服務在微信的架構實踐

    分兩層,一個是城市間。城市之間的數據是相對獨立的,除了少數賬號全球同步,大部分業務都希望做成電子郵件式的服務,各自有自身的環境在跑,之間使用類似于電子郵件的通信。所以我們選擇讓每個城市自治,它們之間有一個 200-400ms 的慢速網絡,國內會快點,30ms。

    微服務在微信的架構實踐

    而城市內部,就是每個園區是一套獨立的系統,可以互相為對方提供備份。要求獨立的電源與網絡接入。

    城市內部會有整套的劃分,終端 -->接入層 -->邏輯層 -->存儲層都是完全獨立的一套系統。

    遠程調用

    看到很多框架,竟然是沒有協程的,這很詫異。早年我們 QQ 郵箱、微信、圖像壓縮、反垃圾都是一個 web 服務,只有存儲層會獨立到后面去,甚至用 web 直連 MySQL。因為它早期比較小,后來變大之后就用微服務架構。

    每個東西都變成一個小的服務,他們是跨機的。你可以想象一下,每天我們很多人買早餐的時候,掏出手機做一個微信支付,這一個動作在后臺會引起上百次的調用。這有一個復雜的鏈路。在 2014 年之前,我們微信就是沒有做異步的,都是同步的,在這么多調用里,A 服務調用 B,那要先等它返回,這樣就占住了一條進程或者線程。所以其實 13 年的時候,我們發生了大大小小的故障,很大一部分原因就在這里。

    然后 13 年底的時候,這個問題太嚴重了,嚴重到,比如發消息的時候,你去拿一個頭像之類的,它只要抖動,就可能引發整一條調用鏈的問題,并且因為過程保護的不完善,它會把整個消息發送的曲線掉下去,這是我們很痛苦的時間。

    然后當時我們就去考慮這些方案,13 年的時候抽出 3 個人重新做了一個完整的庫 libco。(兩千行),實現時間輪盤與事件處理鏈、常用網絡編程模式、同步原語等。它分為三大塊,事件驅動、網絡 HOOK 和協程機制。

    微服務在微信的架構實踐微服務在微信的架構實踐

    早期是多進程為主,當年切多線程的時候,也遇到一大波修改,后來線程里有了一個線程變量就好多了。如果沒有這個東西,你可能要把許多變量改成參數再一層一層傳遞下去。有了線程變量就好多了?,F在我們的協程變量也是這個意義,效果就像寫一個宏一樣。

    另一個是,我們支持 CGI,早期庫在 CGI 上遇到問題,所以沒有推廣。因為一個標準 CGI 服務是基于一些古老的接口的,像 getENV、setENV,就是說你的 coreString 是通過 ENV 來得到的,那么這個我們也把它給 HOOK 掉了,它會根據你的協程去分派。

    最難的一個是 gethostbyname 方法,我發現很多人就連在異步編程里,處理 hostbyname 也可能是用了一套獨立線程去做,或者你很辛苦地把整個代碼摳出來重新寫一遍,這個肯定是有很多問題的。所以我們 libco 就把這個 gethostbyname 給完整地支持了。

    最后如果你還不爽,說一般業務邏輯可以這么干,那我還有很多后臺代碼怎么辦呢?很多有經驗的老的程序員可能要拿著他們那一堆很復雜的異步編程的代碼來質疑我們,他們不認為他們的代碼已經完全可以被協程所取代了。

    他們有如下兩個質疑:

    • 質疑性能:協程有很多切換,會不會帶來更大開銷?

    • 你可能處理幾萬并發就好,消耗個 1G 內存就行,但是我們這里是處理千萬并發哦,這么大的規模,我不信任你這個東西。

    這樣我們其實是面臨了一個問題,因為一些老代碼,越是高級的人寫的,它的技術棧越深,稍微改動一點代碼,就出 BUG 了。

    所以我們后來做了兩個東西,一個是實際修改了相對簡單的異步代碼到 libco 里,然后性能更好了。因為在做異步編程的時候,你需要自己去維護很多的數據結構,做你的狀態保存,它們的生存期有可能需要很久,你自然地會分配許多內存給它,當然你會用一些內存池去優化它,但是這些是有限的。

    但是你用協程的話,很多變量就自然在一個連續的內存里了,相當于一個小的內存池,就比如 if……else……這個你沒有必要去 new 一個東西保存狀態的,直接放在棧里就行了,所以它的性能更好了。

    第二個是,它要求很高的并發。由于協程要一個棧,我們一般開 128k,如果你對這個代碼掌控得比較好,可能開 16k,就算是這樣,你要開 1 萬個協程,還是要 100 多 M 的內存。所以我們后來就在這基礎上做了一個可以支持千萬連接的協程模式。

    Libco 是一個底層庫,讓你很方便開發,但是大部分開發人員不是直接面對 libco 的,我們花了一年時間把整個微信后臺絕大部分邏輯服務、存儲服務改成基于 libco,整個配置就直接通過配一臺機器上的并發數配 10 倍甚至 20、30 倍,這樣子就一下子把整個問題解決了。

    過載保護

    并發數上去后容易引發另一個問題,早期的時候,后端服務性能高,邏輯服務性能相對弱,很容易被 hold,不可能給后端發起很多連接,不具有“攻擊性”,但修改完成后,整個前端變得很強,那可能對后端產生很大的影響。這個時候就要來考慮一下過載保護了

     

    關于:中科研拓

    深圳市中科研拓科技有限公司專注提供軟件+硬件結合系統解決方案定制開發服務,其中包括:軟件外包、軟件開發、軟件定制、硬件開發、硬件定制、智能硬件開發、物聯網項目等開發外包服務,通過IT技術實現創造客戶和社會的價值,成為優秀的軟件公司,通過客戶需求導向、開放式創新、卓越運營管理等戰略的實施,全面打造公司的核心競爭力。優秀軟件外包公司、軟件開發公司,聯系電話400-0316-532,郵箱sales@zhongkerd.com,網址www.ruige-europe.com


      上一篇   [返回首頁] [打印] [返回上頁]   下一篇
    香蕉97超级碰碰碰免费公开
    <object id="0o2s2"><acronym id="0o2s2"></acronym></object>
  • <input id="0o2s2"><u id="0o2s2"></u></input>
  • <input id="0o2s2"><u id="0o2s2"></u></input> <menu id="0o2s2"></menu>
    <nav id="0o2s2"><acronym id="0o2s2"></acronym></nav>
    <menu id="0o2s2"><u id="0o2s2"></u></menu>
  • <input id="0o2s2"><button id="0o2s2"></button></input><input id="0o2s2"><acronym id="0o2s2"></acronym></input><nav id="0o2s2"></nav>
  • <input id="0o2s2"></input>