首先名字要取得霸氣才能吸引人氣，哈哈~~
　　下面簡單介紹下情況。框架是騰訊電商平臺的分布式框架。雖然騰訊拍拍已經玩完了。但是這套框架還是很不錯的。而且據原騰訊同事說微信也是用的這套框架。源碼肯定是不能說的。但是介紹大體的思想我想應該沒問題。雖然在這個框架下寫了一年多的業務代碼。但是平臺框架的代碼一直沒怎么看。最近有開始看平臺代碼雖然沒看完。但是大體的思想已經清楚。可以分享下我看的心得。具體細節我琢磨下看哪些能分享。

　　現在我們框架依然是用來做電商業務。框架可以分布式部署。
　　簡單來說是多進程+協程 并沒有用到網上一直說的多線程。

下面來具體介紹下框架的內容

一、框架總體介紹

框架總體分4個部分。config_center、netio2、back_netio2、container3

config_center： 作用是 獲取命令字并通知netio2、back_netio2、container3

netio2： 收取網絡包 發給container3 去執行

container3：執行具體的業務

back_netio2：如果是跨機調用。則需要back_netio2來轉發包

二、這里我先介紹下一個包的基本流程。

首先 先簡單介紹一下我們框架的基本常識。后面會詳細介紹
a)我們是使用的rpc接口遠程調用的模式，每個接口都有一個命令字。
b)然后 每個container進程就是一個服務。每一個負責具體的不同業務。 一個服務里會用很多個接口。
c)每個服務 會分為 ao 和 dao 。 ao做業務邏輯。但是是非阻塞的 ，dao 專門用來存取數據可以是阻塞的。

接下來我們說下包的流轉過程

1） 前端 發送一個 調用接口的請求過來 比如調用GetShopName接口
2） netio 收到包以后。 做一些處理。比如打上時間戳等。 然后把包丟到消息隊列里。 netio是一個單線程的進程。 可以起多個netio來收包。
3）container服務 在消息隊列里發現有包。 就取出來處理。然后切換協程。 它會把包丟給具體的AO業務服務去處理。
4）Ao服務 發現 需要取數據。 它會生成一個請求包。把數據丟到消息隊列里去。然后會切回主進程。繼續監聽消息隊列
5）container 從消息隊列里接收到了 函數A處理完的結果。 就會立馬在切到服務Ao里去，繼續執行。
6） 在掉到 函數B的時候 發現需要去別的進程取數據。 然后跟函數A的處理一樣。這里就不說了。
打字好累。。。
7）container處理完了所有數據。 生成一個返回包。然后把它丟到消息隊列里。
8）netio 拿到返回包。 找到請求時的socket發送回去。

到這里一個基本的流程完了。
由于很多東西都沒有介紹。所以圖話的比較簡陋、說明的也比較泛泛。 等后面慢慢介紹完細節。就明白了。
光看一個圖。很多東西看不出來的


下面先介紹下貫穿整個框架兩個比較核心的東西。
一個是消息隊列還有一個是協程。
這兩個東西 支持了系統的分布式部署。以及大并發的處理能力。以及無鎖編程

三、消息隊列

有比較才能看的更清晰
這里首先我們看下多線程編程下怎么處理包的。
（由于我沒有接觸過像騰訊、阿里這樣大型的多線程框架所以我這里只說以前公司寫的多線程處理模式。）

在多線程模式下。服務端會生自己成一個任務隊列。然后對這個隊列進行加鎖操作。
然后服務每次收到一個請求包。就把請求包扔到任務隊列里。 然后繼續收包。仍包。
然后線程池會去 任務隊列里取任務 并處理

我們現在的這個框架中的消息隊列。就相當于 一個任務隊列。

1） 因為我們用系統消息隊列。 然后我們限制了消息隊列的大小。所以即使并發往消息隊列里塞消息。頂多也就是賽不進去。對系統影響不到。 而且不用不用給隊列上鎖之類的操作。速度杠杠的。
2） netio 進程起來的 時候會有一個消息隊列。 專門用來接收處理完的請求。然后把這些請求發送回給前端。
3）每個服務 會有兩個隊列。 一個叫請求隊列 一個叫回包隊列。
請求隊列是用來接收別的服務發送過來的請求的包。
回包隊列是服務本身請求別的服務。別的服務返回結果則放到這個回報隊列里
4） 所以 ipcs -q 的時候 會看到有一堆的消息隊列。


這樣的話可以看到 每個服務跟每個服務是相互獨立的。
他們都有自己的任務隊列。每個服務即可以是開始 也可以是結束。

但是 消息隊列并不是最快的。如果做的復雜可以用共享內存。
但是 平臺用系統自帶消息隊列 給人感覺很清晰。也不會那么復雜。

四、協程

協程這個東西如果要說的話。還是有挺多東西說的。這里就細說。說些基本的東西

在我沒接觸協程的時候。 寫多線程服務端程序的時候。覺得多線程很牛逼。后臺接觸了這個框架。慢慢熟悉協程，發現協程更牛逼。。。。
但其實不能說協程比線程更厲害。只是應用場景上不同。

多線程的好出我就不說了。這里說下多線程的缺點。
1）多線程 切換的時候 需要陷入內核。切換的成本比較大。而且線程數過多。這個切換的成本會足增
2）多線程 編寫代碼的時候。常常會用到鎖。一來代碼沒寫好會造成死鎖，二來用鎖會減慢程序執行的速度

而協程 剛好解決了這兩個問題
1）協程 切換 是在用戶空間，不需要陷入內核。有程序員手動控制。所以協程的切換成本非常低。
可以創建大量協程 而不會對系統有運行有影響
2）寫協程代碼 其實大體上是順序思維。 基本上用不到鎖。
所以這里其實有個很重要的問題。由與協程相當于順序執行。所以一定不能阻塞。

在我們的平臺中。
1）AO服務一般是一個進程。然后起50個協程。具體看業務量。如果業務量大可以起多個AO進程
2）AO由于是用協程的。所以AO服務不能阻塞。任何阻塞的動作。都不會在AO中出現。AO一把做業務處理。 就是 比如參數校驗、if else 、賦值 、業務邏輯等等。
3）如果要去db或者緩存里取數據。 AO服務會調用DAO服務。
4）DAO服務 一般起10個進程。主要用來去mysql和redis、等取數據。可以阻塞

所以這個模型下。再加上超時處理機制。
可以處理大量并發場景。

拍拍雖然沒有達到淘寶那樣的請求量。
但也是上億的請求并發。
so ,看完框架代碼以后 才發現這個框架寫的真是好。

但是我反而更好奇 淘寶那種。高并發的框架是什么樣的。
是否用到了多線程




先就介紹這么多吧。還有很多細節才組成了這個框架
后面再慢慢說
爭取每一個星期更新一篇吧。
努力在兩個月內把框架看完

總結

以上是生活随笔為你收集整理的大型分布式C++框架《一：框架简介》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。