看了Joy一篇關(guān)于網(wǎng)絡(luò)部分優(yōu)化的文章，總結(jié)一下，方便以后查閱使用

目前客戶端存在的網(wǎng)絡(luò)問(wèn)題主要有下面幾方面：

1.網(wǎng)絡(luò)成功率低，經(jīng)常請(qǐng)求失敗
2.用戶反饋 DNS 劫持，數(shù)據(jù)被篡改，出現(xiàn)廣告和請(qǐng)求超時(shí)等情況
3.網(wǎng)絡(luò)延遲較長(zhǎng)，且存在較多的長(zhǎng)尾數(shù)據(jù)
4.經(jīng)過(guò)數(shù)據(jù)分析，發(fā)現(xiàn)長(zhǎng)連的時(shí)間明顯比短連的時(shí)間少 100ms 左右（短連指的是，經(jīng)過(guò)DNS解析、 TCP 握手、 SSL 握手等一系列的過(guò)程建立連接，長(zhǎng)連指的是直接復(fù)用前者的連接通道）
5.網(wǎng)絡(luò)經(jīng)常出現(xiàn)抖動(dòng)，本來(lái)大部分請(qǐng)求都是 100ms 左右，突然冒出來(lái)一兩千毫秒的，甚至有10、20秒的延遲情況
6.HTTP 1.1的head of blocking 情況存在，一個(gè)網(wǎng)絡(luò)抖動(dòng)，很容易影響后續(xù)的請(qǐng)求，導(dǎo)致一連串的延遲較高請(qǐng)求（head of blocking：指的是在 HTTP 1.1 中，如果你發(fā)出1、2、3 三個(gè)網(wǎng)絡(luò)請(qǐng)求，那么 Response 的順序 2、3 要在第一個(gè)網(wǎng)絡(luò)請(qǐng)求之后）
7.傳輸?shù)?Payload 太大，延遲高，易超時(shí)
8.蘋(píng)果要求HTTPS ，此時(shí)加入的 SSL 握手較耗時(shí)

下面分別針對(duì)上面的幾個(gè)問(wèn)題，看各個(gè)大廠是如何解決的：

網(wǎng)絡(luò)成功率低，經(jīng)常請(qǐng)求失敗######

1.攜程:
??受TCP協(xié)議重傳機(jī)制來(lái)保證可靠傳輸?shù)臋C(jī)制啟發(fā)，我們?cè)趹?yīng)用層面也引入了重試機(jī)制來(lái)提高網(wǎng)絡(luò)服務(wù)成功率。我們發(fā)現(xiàn)90%以上的的網(wǎng)絡(luò)服務(wù)失敗都是由于網(wǎng)絡(luò)連接失敗，此時(shí)再次重試是有機(jī)會(huì)連接成功并完成服務(wù)的；同時(shí)我們發(fā)現(xiàn)前面提到的網(wǎng)絡(luò)服務(wù)生命周期處于1建立連接、序列化網(wǎng)絡(luò)請(qǐng)求報(bào)文、發(fā)送網(wǎng)絡(luò)請(qǐng)求這三個(gè)階段失敗時(shí)，都是可以自動(dòng)重試的，因?yàn)槲覀兛梢源_信請(qǐng)求還沒(méi)有達(dá)到服務(wù)端進(jìn)行處理，不會(huì)產(chǎn)生冪等性問(wèn)題（如果存在冪等性問(wèn)題，會(huì)出現(xiàn)重復(fù)訂單等情況）。當(dāng)網(wǎng)絡(luò)服務(wù)需要重試時(shí)，會(huì)使用短連接進(jìn)行補(bǔ)償，而不再使用長(zhǎng)連接。
??實(shí)現(xiàn)了上述機(jī)制后，攜程App網(wǎng)絡(luò)服務(wù)成功率由原先的95.3%+提升為如今的99.5%+（這里的服務(wù)成功率是指端到端服務(wù)成功率，即客戶端采集的服務(wù)成功數(shù)除以請(qǐng)求總量計(jì)算的，并且不區(qū)分當(dāng)前網(wǎng)絡(luò)狀況），效果顯著。

2.Peak老師的解決方案（非常完善了）
??可靠性保障也是個(gè)容易被忽視的方面，在深入探討之前，可以先將Request按業(yè)務(wù)屬性分類。
??1.第一類：關(guān)鍵核心的業(yè)務(wù)數(shù)據(jù)，期望能100%送達(dá)服務(wù)器。
??2.第二類：重要內(nèi)容請(qǐng)求，需要較高的請(qǐng)求成功率.
??3.第三類：一般性內(nèi)容請(qǐng)求，對(duì)成功率無(wú)要求。
??之所以要將請(qǐng)求分為三類，是要在可靠性保障上做區(qū)分。理論上我們應(yīng)該盡可能讓所有的請(qǐng)求成功率達(dá)到最高，但客戶端的流量，帶寬，手機(jī)電量，服務(wù)器的壓力等都是有限的資源，所以我們采取的策略是只對(duì)關(guān)鍵性的網(wǎng)絡(luò)請(qǐng)求做高強(qiáng)度的可靠性保障。
??第一類請(qǐng)求類似大家用微信時(shí)發(fā)送的消息，消息數(shù)據(jù)一旦從輸入框發(fā)出，從用戶來(lái)的角度感知這個(gè)消息數(shù)據(jù)是一定會(huì)到達(dá)對(duì)方的。如果網(wǎng)絡(luò)環(huán)境差，網(wǎng)絡(luò)模塊會(huì)自動(dòng)在后頭悄悄重試，一段時(shí)間后仍無(wú)法成功就通過(guò)產(chǎn)品交互的方式告知用戶發(fā)送失敗了，即使失敗，請(qǐng)求的數(shù)據(jù)（消息本身）一直存在客戶端。
??對(duì)于這類請(qǐng)求的處理方式第一步不是通過(guò)網(wǎng)絡(luò)發(fā)送，而是持久化到Database當(dāng)中。一旦入了DB，即使斷網(wǎng)，斷電，重啟，請(qǐng)求數(shù)據(jù)依然還在，只需在App重啟的時(shí)候還原請(qǐng)求數(shù)據(jù)，再次發(fā)送即可。我們用代碼來(lái)進(jìn)一步闡釋

//定義請(qǐng)求可靠性類型
typedef enum : NSUInteger {
    PPRequestReliability_PersistentToDB,
    PPRequestReliability_Retry,
    PPRequestReliability_Normal,
} PPRequestReliability;

//增加持久化接口
@interface PPRequest : NSObject

@property (nonatomic, assign) PPRequestReliability    reliability;
@property (nonatomic, strong) NSNumber*               rowID;
@property (nonatomic, strong) NSNumber*               reliabilityStatus;

- (PPRequestRecord*)serializeToRecord;
- (PPRequest*)deserializeFromRecord:(PPRequestRecord*)record;

@end

??第一類請(qǐng)求是PPRequestReliability_PersistentToDB，新增了rowID用作存儲(chǔ)DB時(shí)的唯一標(biāo)識(shí)，reliabilityStatus表示請(qǐng)求的當(dāng)前狀態(tài)（成功 or 失敗 or 取消 or 進(jìn)行中），我們?cè)倏聪掳l(fā)送請(qǐng)求的流程。

@implementation PPRequestManager

- (void)sendRequest:(PPRequest*)req withDelegate:(id)delegate
{
    if (req.reliability == PPRequestReliability_PersistentToDB) {
        PPRequestRecord* record = [req serializeToRecord];
        //save record to database
    }
    
    //send request
}

- (void)onRequestSucceed:(PPRequest*)req
{
    //add to resend queue
    [_resendQueue addObject:req];
    
    //remove from db
}

- (void)onRequestFail:(PPRequest*)req
{
    //add to resend queue
    [_resendQueue addObject:req];
}

@end

??如果判斷為第一類請(qǐng)求，第一步我們先將請(qǐng)求持久化到DB當(dāng)中。第二步發(fā)送請(qǐng)求，如果請(qǐng)求失敗則將請(qǐng)求加入重試隊(duì)列，成功則從重試隊(duì)列中移除。重試隊(duì)列背后也需要一套通用機(jī)制，比如多久重試一次，重試幾次之后放棄。遇到最惡劣的場(chǎng)景，請(qǐng)求發(fā)送失敗之后，App被kill。我們需要在App重啟之后從DB當(dāng)中重新load所有失敗的請(qǐng)求再次重試。

- (void)resendPreviousFailedRequest
{
    //load from db
    
    //send requests
}

??通過(guò)上述幾步基本上可以使請(qǐng)求的可靠性得到極大的保障。但100%是無(wú)法實(shí)現(xiàn)的理想，失敗的時(shí)候用戶重裝App，所有持久化的數(shù)據(jù)丟失，請(qǐng)求數(shù)據(jù)也就丟了，不過(guò)這種極端的場(chǎng)景非常少。
??第二類請(qǐng)求的可靠性為PPRequestReliability_Retry，這類請(qǐng)求的例子可以是我們App啟動(dòng)時(shí)用戶看到的首頁(yè)，首頁(yè)的內(nèi)容從服務(wù)器獲取，如果第一次請(qǐng)求就失敗體驗(yàn)較差，這種場(chǎng)景下我們應(yīng)該允許請(qǐng)求有機(jī)會(huì)多試幾次，增加一個(gè)retryCount即可。

//PPRequest.h
@property (nonatomic, assign) int                     retryCount;

??一般3次的重試基本可以排除網(wǎng)絡(luò)抖動(dòng)的情況。三次失敗之后即可認(rèn)為請(qǐng)求失敗，通過(guò)產(chǎn)品交互告知用戶。
??第三類請(qǐng)求的重要性最低，比如進(jìn)入Controller的UV采集打點(diǎn)。這類請(qǐng)求只需要做一次，即使失敗也不會(huì)對(duì)產(chǎn)品體驗(yàn)產(chǎn)生什么負(fù)面影響。

用戶反饋 DNS 劫持，數(shù)據(jù)被篡改，出現(xiàn)廣告和請(qǐng)求超時(shí)等情況

1.攜程
??如果是首次發(fā)送基于HTTP協(xié)議的網(wǎng)路服務(wù)，第一件事就是進(jìn)行DNS域名解析，我們統(tǒng)計(jì)過(guò)DNS解析成功率只有98%，剩下2%是解析失敗或者運(yùn)營(yíng)商DNS劫持（Local DNS返回了非源站IP地址），同時(shí)DNS解析在3G下耗時(shí)200毫秒左右，4G也有100毫秒左右，延遲明顯。我們基于TCP連接，直接跳過(guò)了DNS解析階段，使用內(nèi)置IP列表的方式進(jìn)行網(wǎng)絡(luò)連接。
??攜程App內(nèi)置了一組Server IP列表，同時(shí)每個(gè)IP具備權(quán)重。每次建立新連接，會(huì)選擇權(quán)重最高的IP地址進(jìn)行連接。App啟動(dòng)時(shí)，IP列表的所有權(quán)重是相同的，此時(shí)會(huì)啟動(dòng)一組Ping的操作，根據(jù)Ping值的延遲時(shí)間來(lái)計(jì)算IP的權(quán)重，這么做的原理是Ping值越小的IP地址，連接后的網(wǎng)絡(luò)傳輸延遲也應(yīng)該相對(duì)更小。業(yè)界也有使用HTTP DNS方式來(lái)解決DNS劫持問(wèn)題，同時(shí)返回最合適用戶網(wǎng)絡(luò)的Server IP。然而HTTP DNS的開(kāi)發(fā)和部署需要不小的開(kāi)發(fā)成本，我們目前沒(méi)有使用。
??內(nèi)置Server IP列表也會(huì)被更新，每次App啟動(dòng)后會(huì)有個(gè)Mobile Config服務(wù)（支持TCP和HTTP兩種網(wǎng)絡(luò)類型服務(wù)）更新Server IP列表，同時(shí)支持不同產(chǎn)品線的Server IP列表更新。因此，傳統(tǒng)DNS解析能夠解決多IDC導(dǎo)流的功能也可以通過(guò)此方法解決。

2.老司機(jī)Peak老師的解決方法：
??一個(gè)打包到app包里面的默認(rèn)映射文件，這樣可以避免第一次去服務(wù)器取配置文件帶來(lái)的延遲。
??有一個(gè)定時(shí)器能每隔一段時(shí)間從服務(wù)器獲取最新的映射，并覆蓋本地。
??每次取到最新的映射文件之后，同時(shí)把上一次的映射文件保存起來(lái)作為替補(bǔ)，一旦出現(xiàn)線上配置失誤不至于導(dǎo)致請(qǐng)求無(wú)法處理。
??如果映射文件不能處理域名，要能回滾使用默認(rèn)的DNS解析服務(wù)。
??如果一個(gè)映射過(guò)后的ip持續(xù)導(dǎo)致請(qǐng)求失敗，應(yīng)該能從機(jī)制上保證這個(gè)ip地址不再使用。也就是需要一個(gè)無(wú)效映射淘汰機(jī)制。
??無(wú)效的ip地址能及時(shí)上報(bào)到服務(wù)器，及時(shí)發(fā)現(xiàn)問(wèn)題更新映射文件。
3.美團(tuán)（IP直連方案）
??程序啟動(dòng)的時(shí)候拉取"api.dianping.com"對(duì)應(yīng)的所有的IP列表；對(duì)所有IP進(jìn)行跑馬測(cè)試，找到速度最快的IP。后續(xù)所有的HTTPS請(qǐng)求都將域名更換為跑馬最快的IP即可。

Paste_Image.png

• 摒棄了系統(tǒng)DNS，減少外界干擾，擺脫DNS劫持困擾。
• 自建DNS更新時(shí)機(jī)可以控制。
• IP列表更換方便。

此外，如果你的App域名沒(méi)有經(jīng)過(guò)合并，域名比較多，也建議可以嘗試使用HttpDNS方案。參考：http://www.tuicool.com/articles/7nAJBb 對(duì)HTTPS中的證書(shū)處理：
HTTPS由于要求證書(shū)綁定域名，如果做IP直連方案可能會(huì)遇到一些麻煩，這時(shí)我們需要對(duì)客戶端的HTTPS的域名校驗(yàn)部分進(jìn)行改造，參見(jiàn)：http://blog.csdn.net/github_34613936/article/details/51490032 。

經(jīng)過(guò)域名合并加上IP直連方案改造后，HTTP短連的端到端成功率從95%提升到97.5%，網(wǎng)絡(luò)延時(shí)從1500毫秒降低到了1000毫秒，可謂小投入大產(chǎn)出。

4.騰訊(HTTPDns)

Paste_Image.png

HttpDNS的原理非常簡(jiǎn)單，主要有兩步：
A、客戶端直接訪問(wèn)HttpDNS接口，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問(wèn)延遲最優(yōu)的IP。（基于容災(zāi)考慮，還是保留次選使用運(yùn)營(yíng)商LocalDNS解析域名的方式）
B、客戶端向獲取到的IP后就向直接往此IP發(fā)送業(yè)務(wù)協(xié)議請(qǐng)求。以Http請(qǐng)求為例，通過(guò)在header中指定host字段，向HttpDNS返回的IP發(fā)送標(biāo)準(zhǔn)的Http請(qǐng)求即可。
（2）HttpDNS優(yōu)勢(shì)：
從原理上來(lái)講，HttpDNS只是將域名解析的協(xié)議由DNS協(xié)議換成了Http協(xié)議，并不復(fù)雜。但是這一微小的轉(zhuǎn)換，卻帶來(lái)了無(wú)數(shù)的收益：
A、根治域名解析異常：由于繞過(guò)了運(yùn)營(yíng)商的LocalDNS，用戶解析域名的請(qǐng)求通過(guò)Http協(xié)議直接透?jìng)鞯搅蓑v訊的HttpDNS服務(wù)器IP上，用戶在客戶端的域名解析請(qǐng)求將不會(huì)遭受到域名解析異常的困擾。
B、調(diào)度精準(zhǔn)：HttpDNS能直接獲取到用戶IP，通過(guò)結(jié)合騰訊自有專利技術(shù)生成的IP地址庫(kù)以及測(cè)速系統(tǒng)，可以保證將用戶引導(dǎo)的訪問(wèn)最快的IDC節(jié)點(diǎn)上。
C、實(shí)現(xiàn)成本低廉：接入HttpDNS的業(yè)務(wù)僅需要對(duì)客戶端接入層做少量改造，無(wú)需用戶手機(jī)進(jìn)行root或越獄；而且由于Http協(xié)議請(qǐng)求構(gòu)造非常簡(jiǎn)單，兼容各版本的移動(dòng)操作系統(tǒng)更不成問(wèn)題；另外HttpDNS的后端配置完全復(fù)用現(xiàn)有權(quán)威DNS配置，管理成本也非常低。總而言之，就是以最小的改造成本，解決了業(yè)務(wù)遭受域名解析異常的問(wèn)題，并滿足業(yè)務(wù)精確流量調(diào)度的需求。
D、擴(kuò)展性強(qiáng)：HttpDNS提供可靠的域名解析服務(wù)，業(yè)務(wù)可將自有調(diào)度邏輯與HttpDNS返回結(jié)果結(jié)合，實(shí)現(xiàn)更精細(xì)化的流量調(diào)度。比如指定版本的客戶端連接請(qǐng)求的IP地址，指定網(wǎng)絡(luò)類型的用戶連接指定的IP地址等。
當(dāng)然各位可能會(huì)問(wèn)：用戶將首選的域名解析方式切換到了HttpDNS，那么HttpDNS的高可用又是如何保證的呢？另外不同運(yùn)營(yíng)商的用戶訪問(wèn)到同一個(gè)HttpDNS的服務(wù)IP，用戶的訪問(wèn)延遲如何保證？
為了保證高可用及提升用戶體驗(yàn)，HttpDNS通過(guò)接入了騰訊公網(wǎng)交換平臺(tái)的BGP Anycast網(wǎng)絡(luò)，與全國(guó)多個(gè)主流運(yùn)營(yíng)商建立了BGP互聯(lián)，保證了這些運(yùn)營(yíng)商的用戶能夠快速地訪問(wèn)到HttpDNS服務(wù)；另外HttpDNS在多個(gè)數(shù)據(jù)中心進(jìn)行了部署，任意一個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)均能無(wú)縫切換到備份節(jié)點(diǎn)，保證用戶解析正常。

網(wǎng)絡(luò)延遲較長(zhǎng)，且存在較多的長(zhǎng)尾數(shù)據(jù)

1.攜程
??和HTTP協(xié)議中的Keepalive特性一樣，最直接減少網(wǎng)絡(luò)服務(wù)時(shí)間的優(yōu)化手段就是保持長(zhǎng)連接。每次TCP三次握手連接需要耗費(fèi)客戶端和服務(wù)端各一個(gè)RTT（Round trip time）時(shí)間才能完成，就意味著100-300毫秒的延遲；TCP協(xié)議自身應(yīng)對(duì)網(wǎng)絡(luò)擁塞的Slow Start機(jī)制也會(huì)影響新連接的傳輸性能。
攜程App使用了長(zhǎng)連接池的方式來(lái)使用長(zhǎng)連接，長(zhǎng)連接池中維護(hù)了多個(gè)保持和服務(wù)端的TCP連接，每次網(wǎng)絡(luò)服務(wù)發(fā)起后會(huì)從長(zhǎng)連接池中獲取一個(gè)空閑長(zhǎng)連接，完成網(wǎng)絡(luò)服務(wù)后再將該TCP連接放回長(zhǎng)連接池。我們沒(méi)有在單個(gè)TCP連接上實(shí)現(xiàn)Pipeline和Multiplexing機(jī)制，而是采用最簡(jiǎn)單的FIFO機(jī)制，原因有二：
簡(jiǎn)化Mobile Gateway的服務(wù)處理邏輯，減少開(kāi)發(fā)成本；
??在服務(wù)端同時(shí)返回多個(gè)響應(yīng)時(shí)，如果某個(gè)響應(yīng)報(bào)文非常大，使用多個(gè)長(zhǎng)連接方式可以加快接收服務(wù)響應(yīng)報(bào)文速度。
??如果發(fā)起網(wǎng)絡(luò)服務(wù)時(shí)長(zhǎng)連接池中的TCP連接都正在被占用，或者TCP長(zhǎng)連接的網(wǎng)絡(luò)服務(wù)失敗，則會(huì)發(fā)起一個(gè)TCP短連接實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)。這里長(zhǎng)連接和短連接的區(qū)別僅僅是服務(wù)完成后是否直接關(guān)閉這個(gè)TCP連接。
2.美團(tuán)（域名合并方案）
??隨著開(kāi)發(fā)規(guī)模逐漸擴(kuò)大，各業(yè)務(wù)團(tuán)隊(duì)出于獨(dú)立性和穩(wěn)定性的考慮，紛紛申請(qǐng)了自己的三級(jí)域名。App中的API域名越來(lái)越多。如下所示：
search.api.dianping.com
ad.api.dianping.com
tuangou.api.dianping.com
waimai.api.dianping.com
movie.api.dianping.com
…

App中域名多了之后，將面臨下面幾個(gè)問(wèn)題：

• HTTP請(qǐng)求需要跟不同服務(wù)器建立連接。增加了網(wǎng)絡(luò)的并發(fā)連接數(shù)量。
• 每條域名都需要經(jīng)過(guò)DNS服務(wù)來(lái)解析服務(wù)器IP。

??如果想將所有的三級(jí)域名都合并為一個(gè)域名，又會(huì)面臨巨大的項(xiàng)目推進(jìn)難題。因?yàn)椴煌瑯I(yè)務(wù)團(tuán)隊(duì)當(dāng)初正是出于獨(dú)立性和穩(wěn)定性的考慮才把域名進(jìn)行拆分，現(xiàn)在再想把域名合并起來(lái)，勢(shì)必會(huì)遭遇巨大的阻力。
??所以我們面臨的是：既要將域名合并，提升網(wǎng)絡(luò)連接效率，又不能改造后端業(yè)務(wù)服務(wù)器。經(jīng)過(guò)討論，我們想到了一個(gè)折中的方案。

Paste_Image.png

• 域名得到了收編，減少了DNS調(diào)用次數(shù)，降低了DNS劫持風(fēng)險(xiǎn)。
• 針對(duì)同一域名，可以利用Keep-Alive來(lái)復(fù)用Http的連接。
• 客戶端業(yè)務(wù)層不需要修改代碼，后端業(yè)務(wù)服務(wù)也不需要進(jìn)行任何修改。

網(wǎng)絡(luò)抖動(dòng)

攜程：
??攜程App引入了網(wǎng)絡(luò)質(zhì)量參數(shù)，通過(guò)網(wǎng)絡(luò)類型和端到端Ping值進(jìn)行計(jì)算，根據(jù)不同的網(wǎng)絡(luò)質(zhì)量改變網(wǎng)絡(luò)服務(wù)策略：

• 調(diào)整長(zhǎng)連接池個(gè)數(shù)：例如在2G/2.5G Egde網(wǎng)絡(luò)下，會(huì)減少長(zhǎng)連接池個(gè)數(shù)為1（運(yùn)營(yíng)商會(huì)限制單個(gè)目標(biāo)IP的TCP連接個(gè)數(shù)）；WIFI網(wǎng)絡(luò)下可以增加長(zhǎng)連接池個(gè)數(shù)等機(jī)制。
• 動(dòng)態(tài)調(diào)整TCP connection、write、read的超時(shí)時(shí)間。
• 網(wǎng)絡(luò)類型切換時(shí)，例如WIFI和移動(dòng)網(wǎng)絡(luò)、4G/3G切換至2G時(shí)，客戶端IP地址會(huì)發(fā)生變化，已經(jīng)連接上的TCP Socket注定已經(jīng)失效（每個(gè)Socket對(duì)應(yīng)一個(gè)四元組：源IP、源Port、目標(biāo)IP、目標(biāo)Port），此時(shí)會(huì)自動(dòng)關(guān)閉所有空閑長(zhǎng)連接，現(xiàn)有網(wǎng)絡(luò)服務(wù)也會(huì)根據(jù)狀態(tài)自動(dòng)重試。

其他優(yōu)化途徑

數(shù)據(jù)格式優(yōu)化，減少數(shù)據(jù)傳輸量和序列化時(shí)間
??傳輸數(shù)據(jù)量越小，在相同TCP連接上的傳輸時(shí)間越短。攜程App曾經(jīng)使用自行設(shè)計(jì)的一套數(shù)據(jù)格式，后來(lái)和Google ProtocolBuffer對(duì)比后發(fā)現(xiàn)，特定數(shù)據(jù)類型下數(shù)據(jù)包大小會(huì)降低20-30%，序列化和反序列化時(shí)間可以降低10-20%，因此目前核心服務(wù)都在逐步遷移到到ProtocolBuffer格式。另外Facebook曾分享過(guò)他們使用FlatBuffer數(shù)據(jù)格式提高性能的實(shí)踐，我們分析后不太適合攜程的業(yè)務(wù)場(chǎng)景因而沒(méi)有使用。