王偉，余利華

1.浙江醫(yī)學(xué)高等?？茖W(xué)校計(jì)算機(jī)教研室，杭州 310053

2.網(wǎng)易杭州研究院，杭州 310052

RPCI：面向互聯(lián)網(wǎng)的RPC框架

王偉1，余利華2

1.浙江醫(yī)學(xué)高等?？茖W(xué)校計(jì)算機(jī)教研室，杭州 310053

2.網(wǎng)易杭州研究院，杭州 310052

1 引言

互聯(lián)網(wǎng)高速發(fā)展的今天，搜索、即時(shí)通訊、博客、郵件、微博等互聯(lián)網(wǎng)應(yīng)用層出不窮，這些應(yīng)用面臨一些共同的挑戰(zhàn)：一是用戶數(shù)和訪問(wèn)量巨大，百萬(wàn)、千萬(wàn)用戶級(jí)別的應(yīng)用比比皆是，其中有些系統(tǒng)的用戶數(shù)甚至已經(jīng)上億；二是請(qǐng)求和訪問(wèn)量往往成倍增加，而不是線性增加。為支撐如此大規(guī)模的用戶和用戶增長(zhǎng)率，互聯(lián)網(wǎng)應(yīng)用的后端都是規(guī)模龐大的分布式集群，就目前來(lái)說(shuō)，由成千上萬(wàn)臺(tái)服務(wù)器組成的集群系統(tǒng)已經(jīng)屢見(jiàn)不鮮。為了有效利用集群系統(tǒng)的處理能力，很多互聯(lián)網(wǎng)公司開(kāi)發(fā)了大量分布式系統(tǒng)，有些用于數(shù)據(jù)存儲(chǔ)和查詢，有些負(fù)責(zé)通訊，有些實(shí)現(xiàn)服務(wù)器管理和監(jiān)控功能。而RPC（遠(yuǎn)程過(guò)程調(diào)用）系統(tǒng)是其中最為核心的組件，各類應(yīng)用甚至是其他分布式系統(tǒng)大都基于RPC系統(tǒng)構(gòu)建，所以RPC系統(tǒng)的重要性不言而喻。

RPC技術(shù)早就存在，XML-RPC[1]，Java的RMI等已經(jīng)被業(yè)界熟知，但是這些傳統(tǒng)RPC無(wú)法滿足互聯(lián)網(wǎng)應(yīng)用的需求，因此以Google、Facebook為首的互聯(lián)網(wǎng)公司都開(kāi)發(fā)了各自的RPC系統(tǒng)。Google開(kāi)發(fā)了Protocol Buffer[2]，并用在了大部分Google產(chǎn)品上，一次搜索就對(duì)應(yīng)多達(dá)幾十次甚至上百次的RPC調(diào)用，圍繞著Protocol Buffer，Google還開(kāi)發(fā)了Dapper工具[3]，用于監(jiān)控和分析整個(gè)集群的性能。Τhrift[4]是Facebook開(kāi)發(fā)的RPC框架，已經(jīng)被大量開(kāi)源的分布式系統(tǒng)采用，如著名的Cassandra系統(tǒng)。Τhrift和Protocol Buffer也不能完全滿足互聯(lián)網(wǎng)應(yīng)用的需求，因此面向互聯(lián)網(wǎng)的RPC系統(tǒng)是一個(gè)值得研究的課題。

本文先分析了互聯(lián)網(wǎng)應(yīng)用環(huán)境下的RPC系統(tǒng)需求，并針對(duì)性地設(shè)計(jì)了一種面向互聯(lián)網(wǎng)應(yīng)用的RPC系統(tǒng)RPCI，RPCI的主要特色是采用三層架構(gòu)，將長(zhǎng)連接功能從應(yīng)用服務(wù)器中剝離出來(lái)，以支持無(wú)狀態(tài)應(yīng)用服務(wù)器設(shè)計(jì)，應(yīng)用服務(wù)器只處理服務(wù)邏輯，升級(jí)和維護(hù)變得更為容易；其次，RPCI支持單連接上的雙向調(diào)用以及多服務(wù)綁定，開(kāi)發(fā)跨廣域網(wǎng)和防火墻的大型應(yīng)用變得更為容易；再次，RPCI實(shí)現(xiàn)異步調(diào)用，提高網(wǎng)絡(luò)通訊性能。

圖1 RPCI框架

2 面向互聯(lián)網(wǎng)RPC的需求

在分析thrift、avro（http：//avro.apache.org/）、protocol buffer等RPC系統(tǒng)的基礎(chǔ)之上，結(jié)合網(wǎng)易分布式系統(tǒng)開(kāi)發(fā)的經(jīng)驗(yàn)，總結(jié)了面向互聯(lián)網(wǎng)RPC的需求：

（1）跨語(yǔ)言、跨平臺(tái)：一方面分布式系統(tǒng)中很可能有不同類型的操作系統(tǒng)，另一方面一般在Windows操作系統(tǒng)完成開(kāi)發(fā)，并在Debian Linux服務(wù)器上部署運(yùn)行，因此跨平臺(tái)是基礎(chǔ)。大型的系統(tǒng)經(jīng)常是用多種語(yǔ)言編寫(xiě)而成，比如郵件客戶端用C++語(yǔ)言實(shí)現(xiàn)，郵件服務(wù)器用Java實(shí)現(xiàn)，而負(fù)責(zé)郵件存儲(chǔ)的分布式文件系統(tǒng)則是由C++語(yǔ)言實(shí)現(xiàn)，因此跨語(yǔ)言是必須的。

（2）高性能：一方面客戶端和服務(wù)端之間需要支持長(zhǎng)連接，避免建立連接帶來(lái)的開(kāi)銷；另一方面系統(tǒng)能同時(shí)支持大量并發(fā)連接，具有較好的吞吐率和響應(yīng)時(shí)間，支持異步開(kāi)發(fā)模式。高性能是節(jié)省成本和提升用戶體驗(yàn)的關(guān)鍵問(wèn)題之一。

（3）可擴(kuò)展性、可用性和可維護(hù)性：可擴(kuò)展性是滿足用戶和流量增長(zhǎng)的必然要求；可用性是保證服務(wù)質(zhì)量的根本，系統(tǒng)不可用很可能導(dǎo)致用戶流失和收入減少，以淘寶網(wǎng)為例，2010年網(wǎng)站交易額為4 000億，淘寶網(wǎng)每停止1 min，因此造成的交易額損失高達(dá)80多萬(wàn)元。當(dāng)前，互聯(lián)網(wǎng)應(yīng)用大多采用敏捷式開(kāi)發(fā)，版本迭代速度較快，系統(tǒng)升級(jí)較為頻繁，這對(duì)系統(tǒng)可維護(hù)性也提出了較高要求。

（4）防火墻穿透：如今網(wǎng)絡(luò)環(huán)境比較復(fù)雜，大量用戶，特別是手機(jī)用戶，隱藏在防火墻后面。這些用戶沒(méi)有獨(dú)立的IP，只能通過(guò)NAΤ技術(shù)訪問(wèn)互聯(lián)網(wǎng)應(yīng)用。為支持這部分用戶，RPC框架必須具有防火墻穿透能力，具體來(lái)說(shuō)能夠在單個(gè)端口上綁定多個(gè)服務(wù)，并且支持單連接上雙向調(diào)用。

（5）多協(xié)議：最重要的兩種協(xié)議是ΤCP和HΤΤP，ΤCP自然是不用過(guò)多介紹，為了支持特殊網(wǎng)絡(luò)環(huán)境，如手機(jī)上的cmwap網(wǎng)絡(luò)用戶，使用代理服務(wù)器的用戶以及防火墻之后的用戶，HΤΤP協(xié)議也必不可少。

3 RPCI框架

RPCI的采用如圖1所示架構(gòu)模型，其中：

（1）client是RPC客戶端，可以是移動(dòng)終端或者普通PC，client一般通過(guò)Internet與RPC服務(wù)端連接。

（2）link-server是RPC后端長(zhǎng)連接服務(wù)器，是Internet和數(shù)據(jù)中心網(wǎng)絡(luò)數(shù)據(jù)交換的樞紐。link-server同時(shí)具有外網(wǎng)和內(nèi)網(wǎng)地址，其主要功能是維護(hù)與client之間的長(zhǎng)連接，并將client的請(qǐng)求路由到業(yè)務(wù)邏輯服務(wù)器app-server。

（3）app-server是業(yè)務(wù)邏輯服務(wù)器，負(fù)責(zé)實(shí)現(xiàn)具體的業(yè)務(wù)邏輯。app-server通過(guò)遠(yuǎn)程調(diào)用接口為客戶端及相關(guān)服務(wù)器提供遠(yuǎn)程服務(wù)。應(yīng)用實(shí)現(xiàn)邏輯遵守?zé)o狀態(tài)原則，其好處是：重啟和升級(jí)時(shí)，對(duì)在線用戶的影響比較小。

（4）status-server是狀態(tài)服務(wù)器，其主要功能是存儲(chǔ)會(huì)話信息。系統(tǒng)要求客戶端先進(jìn)行登錄，才能進(jìn)行后續(xù)操作，用戶的一次登錄稱為一個(gè)會(huì)話。會(huì)話信息主要包括用戶的在線狀態(tài)，登錄的link-server地址等。除了提供創(chuàng)建會(huì)話，刪除會(huì)話，會(huì)話查詢等基本功能，status-server還支持多登陸點(diǎn)（即同一個(gè)用戶可以登錄多次）。

（5）link-balancer：負(fù)責(zé)link-server的負(fù)載均衡?？蛻舳艘话阒槐４鎙ink-balancer的域名，通過(guò)link-balancer得到link-server的地址。

（6）元數(shù)據(jù)集群：負(fù)責(zé)維護(hù)集群成員關(guān)系、全局配置、負(fù)載、監(jiān)控和統(tǒng)計(jì)等，元數(shù)據(jù)集群負(fù)載不高，但是可用性是至關(guān)重要，因此基于ZooKeeper實(shí)現(xiàn)[5]。

4 長(zhǎng)連接服務(wù)器link-server

如圖2所示，link-server介于client和app-server之間，其主要功能是負(fù)責(zé)轉(zhuǎn)發(fā)client和app-server的RPC消息。linkserver必須監(jiān)聽(tīng)一個(gè)外網(wǎng)地址和一個(gè)內(nèi)網(wǎng)地址，app-server只監(jiān)聽(tīng)一個(gè)內(nèi)網(wǎng)地址。client和link-server之間通常只建立一個(gè)長(zhǎng)連接，長(zhǎng)連接上傳輸所有RPC調(diào)用和回調(diào)。而app-server和link-server有兩個(gè)連接，link-server主動(dòng)與appserver建立的連接用于RPC調(diào)用，app-server與link-server建立的連接用于RPC回調(diào)。不管client連接數(shù)是多少，linkserver和app-server之間只有兩個(gè)連接，這就是link-server的連接合并功能。連接合并的好處是降低服務(wù)器上的連接數(shù)目，降低資源開(kāi)銷。

圖2 長(zhǎng)連接服務(wù)器link-server

link-server的第二個(gè)功能是連接上下文管理功能。為了區(qū)分不同client的請(qǐng)求，link-server在RPC請(qǐng)求中加入一個(gè)上下文信息，上下文信息附加在客戶端的每個(gè)請(qǐng)求之后，發(fā)送到app-server。反過(guò)來(lái)，當(dāng)app-server需要設(shè)置上下文信息時(shí)，可附加上下文到響應(yīng)消息之后。上下文中主要包括：link-server分配的連接id和app-server設(shè)置的應(yīng)用上下文（例如連接的用戶名），對(duì)于link-server來(lái)說(shuō)應(yīng)用上下文是一段透明的二進(jìn)制數(shù)據(jù)。除了上下文，link-server還提供key-value形式的API，允許存儲(chǔ)一些連接私有數(shù)據(jù)結(jié)構(gòu)，比如可存儲(chǔ)連接的當(dāng)前登錄狀態(tài)。

link-server的第三個(gè)功能是可定制的路由策略，目前支持的且經(jīng)常被使用的路由策略是：

（1）根據(jù)client上登陸的用戶名路由請(qǐng)求，保證屬于同一用戶的請(qǐng)求均被路由到同一app-server，為此，需要在用戶名和服務(wù)器之間做一個(gè)映射。傳統(tǒng)做法是哈希映射，即將用戶UserName映射到第hash（UserName）%N臺(tái)機(jī)器，缺點(diǎn)是增加app-server或者app-server宕機(jī)時(shí)，大量請(qǐng)求的目標(biāo)服務(wù)器發(fā)生變化。為避免這種情況，用戶名和app-server的映射關(guān)系通過(guò)一致性哈希計(jì)算[6]得到。用戶名路由是應(yīng)用最廣泛的一類路由策略，即時(shí)通訊、郵件等應(yīng)用均使用這種方式，其好處是能夠保證同一client的請(qǐng)求能被順序處理。

（2）靜態(tài)路由，請(qǐng)求被派發(fā)到指定app-server，這種路由策略較為簡(jiǎn)單，容易理解，系統(tǒng)調(diào)試和排錯(cuò)比較方便，因此在實(shí)際應(yīng)用中也頗受歡迎。該策略缺點(diǎn)是系統(tǒng)可用性較差——app-server宕機(jī)導(dǎo)致服務(wù)不可用，僅適用于可用性要求不高的應(yīng)用。

（3）負(fù)載均衡路由，請(qǐng)求被路由到負(fù)載最輕的app-server，此路由策略的優(yōu)點(diǎn)是保證系統(tǒng)負(fù)載均衡。

（4）隨機(jī)路由，請(qǐng)求被隨機(jī)派發(fā)到后端app-server。

（5）功能路由，按照功能劃分app-server，例如郵件服務(wù)、即時(shí)消息服務(wù)、短信服務(wù)位于三個(gè)不同的app-server中。link-server根據(jù)配置路由RPC請(qǐng)求到正確的app-server，譬如郵件功能的RPC請(qǐng)求被路由到郵件app-server，即時(shí)消息RPC請(qǐng)求被路由到即時(shí)消息app-server。功能路由的優(yōu)點(diǎn)是，能實(shí)現(xiàn)功能解耦，避免相互影響，同時(shí)有利于資源的分配和控制。值得注意的是，功能路由能與前面幾種路由策略組合使用。

link-server的第四個(gè)功能是連接生命周期管理：（1）應(yīng)用可在link-server上配置一些Listener，監(jiān)聽(tīng)連接的創(chuàng)建，錯(cuò)誤、關(guān)閉的事件，例如發(fā)現(xiàn)連接關(guān)閉時(shí)，可通知app-server更改用戶的登陸狀態(tài)。（2）提供關(guān)閉連接功能，app-server可主動(dòng)請(qǐng)求關(guān)閉一個(gè)連接。

link-server第五個(gè)功能是定時(shí)任務(wù)。link-server可配置一些定時(shí)任務(wù)，定時(shí)任務(wù)可訪問(wèn)link-server的所有連接。定時(shí)任務(wù)的一個(gè)應(yīng)用是實(shí)現(xiàn)心跳檢測(cè)。心跳有兩種：（1）客戶端到服務(wù)端的心跳，定時(shí)任務(wù)用戶檢查連接是否超時(shí)。（2）服務(wù)端到客戶端心跳。在link-server中配置一個(gè)定時(shí)任務(wù)去發(fā)送心跳。服務(wù)端心跳是為移動(dòng)終端設(shè)計(jì)的，目的是為移動(dòng)設(shè)備省電，延長(zhǎng)待機(jī)時(shí)間。

link-server的第六個(gè)功能是廣播。link-server提供一個(gè)廣播地址，向該廣播地址發(fā)起的調(diào)用均會(huì)轉(zhuǎn)發(fā)到當(dāng)前連接到link-server上的所有客戶端。

5 集群管理

5.1 故障處理

一個(gè)集群通常包含多個(gè)link-server，app-server，statusserver，這些服務(wù)器向ZooKeeper集群匯報(bào)狀態(tài)，由ZooKeeper集群統(tǒng)一檢測(cè)故障，并維護(hù)集群成員關(guān)系。

link-server宕機(jī)時(shí)，在link-server上登陸的client必須重新與服務(wù)端建立連接。當(dāng)檢測(cè)到連接出錯(cuò)，或者心跳超時(shí)的時(shí)候，client重新向負(fù)載均衡服務(wù)器link-balancer請(qǐng)求link-server地址，由于client有可能先于ZooKeeper檢測(cè)到link-server故障，為避免link-balancer返回出錯(cuò)的link-server地址，client在請(qǐng)求中帶上出錯(cuò)的link-server地址，要求linkbalancer將該地址暫時(shí)列入黑名單。當(dāng)ZooKeeper判定linkserver失效時(shí)，首先將故障通知到link-balancer，其次，通知所有status-server注銷在該link-server登陸的client。

app-server實(shí)現(xiàn)了復(fù)雜的業(yè)務(wù)邏輯，是系統(tǒng)內(nèi)部最容易出錯(cuò)，最經(jīng)常變動(dòng)的環(huán)節(jié)，app-server的可用性直接決定了系統(tǒng)可用性。為提高可用性，系統(tǒng)特意設(shè)計(jì)了無(wú)狀態(tài)appserver。無(wú)狀態(tài)技術(shù)大大簡(jiǎn)化了故障處理，當(dāng)app-server發(fā)生故障時(shí)，link-server只需請(qǐng)求轉(zhuǎn)發(fā)到其他正常app-server，而client根本感知不到任何異常，宕機(jī)不影響系統(tǒng)可用性。

在線狀態(tài)是系統(tǒng)比較重要的數(shù)據(jù)，丟失在線狀態(tài)會(huì)導(dǎo)致大量client重新登陸，因此status-server通過(guò)group communication技術(shù)[7]實(shí)現(xiàn)status-server復(fù)制。client在線狀態(tài)通過(guò)哈希算法分布到多臺(tái)status-server組，組內(nèi)實(shí)現(xiàn)復(fù)制，一般一個(gè)組內(nèi)包含2到3臺(tái)status-server。當(dāng)有status-server發(fā)生故障時(shí)，組內(nèi)其他副本仍然能夠提供服務(wù)。為處理故障，系統(tǒng)在集群內(nèi)另外起一個(gè)status-server實(shí)例，從組內(nèi)其他服務(wù)器同步數(shù)據(jù)之后重新加入到集群，由于在線狀態(tài)存儲(chǔ)在status-server內(nèi)存中，重新同步并加入集群的這段恢復(fù)時(shí)間比較短，系統(tǒng)可用性較好。

5.2 在線升級(jí)擴(kuò)容

由于Web應(yīng)用大多采取敏捷開(kāi)發(fā)模式，版本迭代升級(jí)較快，因此在線升級(jí)是非常必要的功能。在線升級(jí)的關(guān)鍵是app-server，原因是app-server中包含了具體的業(yè)務(wù)邏輯，而link-server，status-server是通用服務(wù)器，基本不改動(dòng)、不升級(jí)。

app-server采取逐臺(tái)升級(jí)方式，單臺(tái)服務(wù)器采用如下方式升級(jí)：修改link-server路由配置，將服務(wù)器的請(qǐng)求切換到其他app-server，升級(jí)這臺(tái)app-server，修改路由將請(qǐng)求切換回來(lái)。

灰度發(fā)布，也叫A/B測(cè)試，即只對(duì)一部分用戶發(fā)布新版本，是互聯(lián)網(wǎng)產(chǎn)品常見(jiàn)需求，也是評(píng)估一項(xiàng)功能市場(chǎng)接受度的常用做法。RPCI支持灰度發(fā)布的方式非常類似在線升級(jí)，只需在link-server上配置特殊的路由策略，將部分用戶的流量切換到包含新功能的app-server。

由于業(yè)務(wù)增長(zhǎng)迅速，系統(tǒng)擴(kuò)容是Web應(yīng)用面臨的重要挑戰(zhàn)之一。link-server和app-server擴(kuò)容非常方便，只需找臺(tái)新機(jī)器啟動(dòng)進(jìn)程就完成擴(kuò)容。status-server升級(jí)則需要遷移部分在線狀態(tài)。為支持在線遷移操作，status-server使用了兩層映射算法，先從用戶名哈希映射到桶，再根據(jù)桶分配表映射桶到服務(wù)器。集群內(nèi)新增一個(gè)臺(tái)status-server時(shí)，一般從集群內(nèi)每個(gè)status-server中遷移多個(gè)桶。

status-server遷移數(shù)據(jù)時(shí)仍然能夠?qū)ν馓峁┓?wù)：假設(shè)一個(gè)遷移操作是將status-server A上有三個(gè)桶1，2，3遷移到status-server B，其中桶1已經(jīng)遷移完畢，桶2正在遷移，桶3尚未開(kāi)始遷移。由于已經(jīng)遷移完成，桶1的訪問(wèn)請(qǐng)求將發(fā)送到B；桶3未開(kāi)始遷移，其請(qǐng)求仍然發(fā)送到A；桶2正在遷移，其請(qǐng)求發(fā)送到A。服務(wù)器A從B拷貝數(shù)據(jù)過(guò)程中，桶2上的修改都要記錄日志，當(dāng)拷貝完成時(shí)，A通過(guò)回放日志達(dá)到與B完全一致?tīng)顟B(tài)。

6 實(shí)驗(yàn)

6.1 RPCI開(kāi)發(fā)流程

RPC框架的開(kāi)發(fā)流程如圖3所示。

圖3 RPCI框架開(kāi)發(fā)流程

第一步：定義數(shù)據(jù)結(jié)構(gòu)和服務(wù)

使用語(yǔ)言無(wú)關(guān)的文法定義數(shù)據(jù)結(jié)構(gòu)和服務(wù)，RPCI語(yǔ)法借鑒了thrift。

上述代碼描述了即時(shí)消息應(yīng)用中數(shù)據(jù)結(jié)構(gòu)和服務(wù)定義。Message是“即時(shí)消息”結(jié)構(gòu)：content成員類型是字符串，含義是消息體；title是一個(gè)可選屬性，含義是消息標(biāo)題；timestamp是一個(gè)可選的長(zhǎng)整形，含義是消息發(fā)送時(shí)間。

Auth是app-server提供給client登陸服務(wù)：login方法用于驗(yàn)證用戶名和密碼，logout方法的作用是注銷，這兩個(gè)方法都會(huì)改變用戶在線狀態(tài)，并通知到所有相關(guān)好友。

Chat是app-server提供給client的聊天服務(wù)：say的功能是發(fā)送即時(shí)消息，它的參數(shù)是消息接收者，以及消息本身，返回值代表發(fā)送是否成功。

ChatCallback是client提供給app-server的回調(diào)服務(wù)，當(dāng)客戶端A給客戶端B發(fā)消息時(shí)，客戶端A調(diào)用Chat.say，而app-server則調(diào)用客戶端B的ChatCallBack.onSay方法，onSay聲明中的oneway關(guān)鍵字表明這個(gè)方法是單向調(diào)用，即RPC客戶端不會(huì)等待RPC服務(wù)端返回響應(yīng)消息。

第二步：使用RPC編譯器生成代碼

利用RPC編譯器編譯第一步編寫(xiě)完成的數(shù)據(jù)結(jié)構(gòu)和服務(wù)，生成框架代碼，框架代碼包含客戶端類，服務(wù)端基類，以及一些數(shù)據(jù)結(jié)構(gòu)和常量定義，編譯器支持生成Java、C++等代碼，并針對(duì)每種語(yǔ)言都提供了一個(gè)運(yùn)行時(shí)庫(kù)，生成的框架代碼依賴于運(yùn)行時(shí)庫(kù)。

第三步：編寫(xiě)客戶端和服務(wù)端代碼?；谶\(yùn)行時(shí)庫(kù)和生成的框架代碼編寫(xiě)代碼，服務(wù)端類需繼承自框架代碼，并提供具體的服務(wù)實(shí)現(xiàn)邏輯。

第四步：系統(tǒng)部署和運(yùn)行。

部署上一步完成的client和app-server，以及RPCI提供的通用服務(wù)器link-server和status-server。

6.2 性能測(cè)試

RPCI基于thrift開(kāi)發(fā)，thrift已經(jīng)提供了語(yǔ)言無(wú)關(guān)RPC定義，跨語(yǔ)言編譯功能。在thrift基礎(chǔ)之上，作了功能增強(qiáng)，并作了性能改進(jìn)。性能改進(jìn)主要體現(xiàn)在兩個(gè)方面：首先，RPCI基于epoll開(kāi)發(fā)，能夠輕松處理大量并發(fā)連接；其次，RPCI優(yōu)化了網(wǎng)絡(luò)讀寫(xiě)，每次網(wǎng)絡(luò)API調(diào)用時(shí)，盡可能多讀寫(xiě)數(shù)據(jù)，減少與操作系統(tǒng)交互，避免進(jìn)程切換開(kāi)銷。

本節(jié)將測(cè)試RPCI的性能，測(cè)試環(huán)境如下：CPU：Intel Xeon CPU E5504@2.00 GHz，網(wǎng)卡：Broadcom Corpora-tion NetXtreme II BCM5716 Gigabit Ethernet（rev 20），內(nèi)存：32 GB。

圖4和圖5中，對(duì)比了RPCI與thrift各種類型server的性能，從圖中可以看出RPCI性能是threaded的1.5倍，是nonblocking的3倍，并且可擴(kuò)展性更好，性能不會(huì)隨連接數(shù)增加而下降。圖中simple是單線程的服務(wù)器，threaded是每連接一個(gè)線程，threadpool是所有連接共享一個(gè)線程池，以上三個(gè)服務(wù)器無(wú)法處理過(guò)多連接。nonblocking是基于libevent實(shí)現(xiàn)的異步服務(wù)器，雖然能夠處理海量連接，但是性能較差，而本文實(shí)現(xiàn)的RPCI不僅性能優(yōu)秀，而且能夠處理海量連接。

圖4 RPCI性能與請(qǐng)求大小

圖5 RPCI性能與線程數(shù)

RPCI已經(jīng)在線上環(huán)境使用一年，圖6是郵件應(yīng)用的遠(yuǎn)程調(diào)用吞吐率監(jiān)控圖。

圖6 真實(shí)環(huán)境中的RPCI

7 相關(guān)工作

相關(guān)的系統(tǒng)有thrift，Protocol Buffer，中間件有ICE和CORBA。

中間件規(guī)模龐大，學(xué)習(xí)門(mén)檻高，在互聯(lián)網(wǎng)網(wǎng)站中應(yīng)用較為困難：比如ICE系統(tǒng)過(guò)于龐大，Windows上編譯源代碼需要2 GB多的空間，在ICE上修改代碼難度極大。雖然ICE功能比較強(qiáng)大，也支持較多的語(yǔ)言，但是學(xué)習(xí)用ICE開(kāi)發(fā)有一定的難度，ICE僅文檔就有2 000頁(yè)。

Protocol Buffer是Google開(kāi)發(fā)的開(kāi)源序列化和反序列化的框架，遵守類BSD的開(kāi)源協(xié)議。Protocol Buffer的文檔較為齊全，在Google內(nèi)部廣為使用，移動(dòng)性、成熟性、穩(wěn)定性、性能都比較不錯(cuò)。PB的編譯器能根據(jù).proto文件中定義的數(shù)據(jù)結(jié)構(gòu)生成序列化和反序列化代碼，具有跨平臺(tái)和跨語(yǔ)言的特性，PB支持Java、C++、Python這三種在Google內(nèi)部使用較多的語(yǔ)言。PB的最大特色是高效率的二進(jìn)制序列化，整數(shù)編碼采用變長(zhǎng)方式壓縮空間，支持list，枚舉類型，以及復(fù)合數(shù)據(jù)結(jié)構(gòu)Message，復(fù)合數(shù)據(jù)結(jié)構(gòu)支持可選屬性。PB的缺點(diǎn)在于功能較弱，比如支持的語(yǔ)言較少，RPC支持較差?？偠灾鳛橐粋€(gè)RPC系統(tǒng)，PB遠(yuǎn)遠(yuǎn)不夠，但是PB的串行化編碼值得借鑒。

thrift是facebook開(kāi)源的RPC框架，目前是apache的孵化項(xiàng)目，遵守apache 2.0開(kāi)源協(xié)議。thrift已經(jīng)在facebook廣為使用，例如著名的Cassandra項(xiàng)目也采用thrift。thrift功能較為強(qiáng)大，支持更多種的語(yǔ)言，比如PHP，Object-C，ErLang等等，支持list，map，set枚舉類型，常量以及復(fù)合數(shù)據(jù)結(jié)構(gòu)struct和可選屬性。thrift能滿足普通的rpc需求，但是在異步處理、批量調(diào)用、雙向調(diào)用、單連接上支持多服務(wù)、通訊性能等方面都需要加強(qiáng)。

8 結(jié)束語(yǔ)

RPC是常用的進(jìn)程間通訊方法，但是目前很少有完全滿足大型互聯(lián)網(wǎng)應(yīng)用需求的RPC框架，因此本文提出了面向互聯(lián)網(wǎng)應(yīng)用的RPCI框架，該框架能夠跨語(yǔ)言，跨平臺(tái)，具有高可用性和可擴(kuò)展性，支持多網(wǎng)絡(luò)協(xié)議和防火墻穿透，并且性能優(yōu)秀。RPCI基于thrift實(shí)現(xiàn)，實(shí)驗(yàn)表明該框架性能優(yōu)秀，是開(kāi)源軟件thrift性能的1.5倍。

[1]XML-RPC[EB/OL].[2011-12-01].http：//xmlrpc.scripting.com/.

[2]Protocol buffer[EB/OL].[2011-12-01].http：//code.google.com/p/ protobuf/.

[3]Sigelman B H，Barroso L A，Burrows M，et al.Dapper，a largescale distributed systems tracing infrastructure，Τechnical report dapper-2010-1[R].2010.

[4]Slee M，Agarwal A，Kwiatkowski M.Τhrift：scalable cross-language services implementation[R].2007.

[5]Hunt P，Konar M，Junqueira F P，et al.ZooKeeper：wait-free coordination for internet-scale systems[C]//Proceedings of the 2010 USENIX Conference on USENIX Annual Τechnical Conference，2010.

[6]Darger D，Lehman E，Leighton Τ，et al.Consistent hashing and random trees：distributed caching protocols for relieving hot spots on the World Wide Web[C]//ACM Symposium on Τheory of Computing，1997：654-663.

[7]Défago X，Schiper A，Urbán P.Τotal order broadcast and multicast algorithms：taxonomy and survey[J].ACM Comput Surv，2004，36：372-421.

WANG Wei1,YU Lihua2

1.Computer Lab,Zhejiang Medical College,Hangzhou 310053,China
2.Hangzhou Research&Development Center,Netease Corporation,Hangzhou 310052,China

RPC is one of the fundamental components of distributed systems underneath popular websites,which is critical for development,maintenance and availability of Internet applications.However,popular RPC systems rarely meet all requirements of Internet applications.Τhis paper analyzes the common RPC requirements of Internet applications.It proposes a RPCI,a RPC system designed for Internet applications.RPCI adopts a novel three tier RPC architecture including link-server,app-server and status-server.Τhe link-server maintains connections from clients and dispatches requests to app-server based on customized routing policy,making app-server stateless,and hence system maintenance costs are reduced.RPCI is implemented based on popular open source project thrift,and experimental results show that it outperforms thrift by 50%.

Remote Procedure Call（RPC）;availability;distributed systems

RPC是互聯(lián)網(wǎng)后端分布式系統(tǒng)的核心組件，能夠降低互聯(lián)網(wǎng)應(yīng)用開(kāi)發(fā)、運(yùn)維成本，提高可用性和可擴(kuò)展性，但是目前流行的RPC框架不能完全滿足互聯(lián)網(wǎng)應(yīng)用需求。分析了互聯(lián)網(wǎng)應(yīng)用環(huán)境下RPC系統(tǒng)的需求，并針對(duì)需求提出了面向互聯(lián)網(wǎng)的RPC系統(tǒng)RPCI。RPCI采用三層架構(gòu)，將長(zhǎng)連接服務(wù)器獨(dú)立出來(lái)，以支持無(wú)狀態(tài)應(yīng)用服務(wù)器設(shè)計(jì)和靈活的請(qǐng)求路由策略，使得系統(tǒng)擴(kuò)容、升級(jí)、運(yùn)維更加容易。基于thrift實(shí)現(xiàn)了RPCI，優(yōu)化了性能，實(shí)驗(yàn)結(jié)果表明，RPCI性能優(yōu)秀，相比常用開(kāi)源軟件thrift性能提升50%以上。

遠(yuǎn)程過(guò)程調(diào)用（RPC）；可用性；分布式系統(tǒng)

A

ΤP393.0

10.3778/j.issn.1002-8331.1202-0082

WANG Wei,YU Lihua.RPCI：RPC for Internet applications.Computer Engineering andApplications,2013,49（21）：106-110.

國(guó)家核高基重大專項(xiàng)資助項(xiàng)目（No.2011ZX01039-001-002）。

王偉（1981—），女，講師，主要研究領(lǐng)域?yàn)榉植际较到y(tǒng)，網(wǎng)格計(jì)算；余利華（1982—），男，博士，主要研究領(lǐng)域?yàn)榉植际较到y(tǒng)和數(shù)據(jù)庫(kù)。E-mail：yulihua@corp.netease.com

2012-02-06

2012-05-28

1002-8331（2013）21-0106-05

CNKI出版日期：2012-06-26http://www.cnki.net/kcms/detail/11.2127.ΤP.20120626.1057.001.html