概述

前段時(shí)間項(xiàng)目要做服務(wù)化，所以我比較了現(xiàn)在流行的幾大RPC框架的優(yōu)缺點(diǎn)以及使用場(chǎng)景，最終結(jié)合本身項(xiàng)目的實(shí)際情況選擇了使用dubbox作為rpc基礎(chǔ)服務(wù)框架。下面就簡(jiǎn)單介紹一下RPC框架技術(shù)選型的過(guò)程。

RPC簡(jiǎn)述

該系列文章將講述以下RPC框架的helloword實(shí)例以及其實(shí)現(xiàn)原理簡(jiǎn)述，由于每一種RPC框架的原理實(shí)現(xiàn)不同且都比較復(fù)雜，如果想深入研究還請(qǐng)自行到官網(wǎng)或者其他技術(shù)博客學(xué)習(xí)。
RPC框架職責(zé)
RPC框架要向調(diào)用方屏蔽各種復(fù)雜性，要向服務(wù)提供方也屏蔽各類復(fù)雜性：

調(diào)用方感覺(jué)就像調(diào)用本地函數(shù)一樣
服務(wù)提供方感覺(jué)就像實(shí)現(xiàn)一個(gè)本地函數(shù)一樣來(lái)實(shí)現(xiàn)服務(wù)

RPC框架是架構(gòu)(微)服務(wù)化的首要基礎(chǔ)組件，它能大大降低架構(gòu)微服務(wù)化的成本，提高調(diào)用方與服務(wù)提供方的研發(fā)效率，屏蔽跨進(jìn)程調(diào)用函數(shù)（服務(wù)）的各類復(fù)雜細(xì)節(jié)
RPC框架的職責(zé)是：讓調(diào)用方感覺(jué)就像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端函數(shù)、讓服務(wù)提供方感覺(jué)就像實(shí)現(xiàn)一個(gè)本地函數(shù)一樣來(lái)實(shí)現(xiàn)服務(wù)

對(duì)于不是很理解服務(wù)化的同學(xué)可以看看這兩篇文章：
服務(wù)化架構(gòu)的演進(jìn)與實(shí)踐
 淺談服務(wù)化架構(gòu)

服務(wù)化的好處
互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化？

服務(wù)架構(gòu)的拆分原則

來(lái)源：李林峰的文章：華為內(nèi)部如何實(shí)施微服務(wù)架構(gòu)？基本就靠這5大原則

服務(wù)拆分原則：圍繞業(yè)務(wù)功能進(jìn)行垂直和水平拆分。大小粒度是難點(diǎn)，也是團(tuán)隊(duì)爭(zhēng)論的焦點(diǎn)。

不好的實(shí)踐

以代碼量作為衡量標(biāo)準(zhǔn)，例如500行以內(nèi)。
拆分的粒度越小越好，例如以單個(gè)資源的操作粒度為劃分原則。

建議的原則

功能完整性、職責(zé)單一性。
粒度適中，團(tuán)隊(duì)可接受。
迭代演進(jìn)，非一蹴而就。
API的版本兼容性優(yōu)先考慮。

代碼量多少不能作為衡量微服務(wù)劃分是否合理的原則，因?yàn)槲覀冎劳瑯右粋€(gè)服務(wù)，功能本身的復(fù)雜性不同，代碼量也不同。還有一點(diǎn)需要重點(diǎn)強(qiáng)調(diào)，在項(xiàng)目剛開(kāi)始的時(shí)候，不要期望微服務(wù)的劃分一蹴而就。
微服務(wù)架構(gòu)的演進(jìn)，應(yīng)該是一個(gè)循序漸進(jìn)的過(guò)程。在一個(gè)公司、一個(gè)項(xiàng)目組，它也需要一個(gè)循序漸進(jìn)的演進(jìn)過(guò)程。一開(kāi)始劃不好，沒(méi)有關(guān)系。當(dāng)演進(jìn)到一個(gè)階段時(shí)，微服務(wù)的部署、測(cè)試和運(yùn)維等成本都非常低的時(shí)候，這對(duì)于你的團(tuán)隊(duì)來(lái)說(shuō)就是一個(gè)好的微服務(wù)。

服務(wù)架構(gòu)的開(kāi)發(fā)原則

微服務(wù)的開(kāi)發(fā)還會(huì)面臨依賴滯后的問(wèn)題。例如：A要做一個(gè)身份證號(hào)碼校驗(yàn)，依賴服務(wù)提供者B。由于B把身份證號(hào)碼校驗(yàn)服務(wù)的開(kāi)發(fā)優(yōu)先級(jí)排的比較低，無(wú)法滿足A的交付時(shí)間點(diǎn)。A會(huì)面臨要么等待，要么自己實(shí)現(xiàn)一個(gè)身份證號(hào)碼校驗(yàn)功能。

以前單體架構(gòu)的時(shí)候，大家需要什么，往往喜歡自己寫什么，這其實(shí)是沒(méi)有太嚴(yán)重的依賴問(wèn)題。但是到了微服務(wù)時(shí)代，微服務(wù)是一個(gè)團(tuán)隊(duì)或者一個(gè)小組提供的，這個(gè)時(shí)候一定沒(méi)有辦法在某一個(gè)時(shí)刻同時(shí)把所有的服務(wù)都提供出來(lái)，“需求實(shí)現(xiàn)滯后”是必然存在的。

一個(gè)好的實(shí)踐策略就是接口先行，語(yǔ)言中立，服務(wù)提供者和消費(fèi)者解耦，并行開(kāi)發(fā)，提升產(chǎn)能。無(wú)論有多少個(gè)服務(wù)，首先需要把接口識(shí)別和定義出來(lái)，然后雙方基于接口進(jìn)行契約驅(qū)動(dòng)開(kāi)發(fā)，利用Mock服務(wù)提供者和消費(fèi)者，互相解耦，并行開(kāi)發(fā)，實(shí)現(xiàn)依賴解耦。

采用契約驅(qū)動(dòng)開(kāi)發(fā)，如果需求不穩(wěn)定或者經(jīng)常變化，就會(huì)面臨一個(gè)接口契約頻繁變更的問(wèn)題。對(duì)于服務(wù)提供者，不能因?yàn)閾?dān)心接口變更而遲遲不對(duì)外提供接口，對(duì)于消費(fèi)者要擁抱變更，而不是抱怨和抵觸。要解決這個(gè)問(wèn)題，一種比較好的實(shí)踐就是管理 + 技術(shù)雙管齊下：

允許接口變更，但是對(duì)變更的頻度要做嚴(yán)格管控。
提供全在線的API文檔服務(wù)（例如Swagger UI），將離線的API文檔轉(zhuǎn)成全在線、互動(dòng)式的API文檔服務(wù)。
API變更的主動(dòng)通知機(jī)制，要讓所有消費(fèi)該API的消費(fèi)者能夠及時(shí)感知到API的變更。
契約驅(qū)動(dòng)測(cè)試，用于對(duì)兼容性做回歸測(cè)試。

服務(wù)架構(gòu)的測(cè)試原則

微服務(wù)開(kāi)發(fā)完成之后需要對(duì)其進(jìn)行測(cè)試。微服務(wù)的測(cè)試包括單元測(cè)試、接口測(cè)試、集成測(cè)試和行為測(cè)試等，其中最重要的就是契約測(cè)試：

這里寫圖片描述

利用微服務(wù)框架提供的Mock機(jī)制，可以分別生成模擬消費(fèi)者的客戶端測(cè)試樁和提供者的服務(wù)端測(cè)試樁，雙方可以基于Mock測(cè)試樁對(duì)微服務(wù)的接口契約進(jìn)行測(cè)試，雙方都不需要等待對(duì)方功能代碼開(kāi)發(fā)完成，實(shí)現(xiàn)了并行開(kāi)發(fā)和測(cè)試，提高了微服務(wù)的構(gòu)建效率?；诮涌诘钠跫s測(cè)試還能快速的發(fā)現(xiàn)不兼容的接口變更，例如修改字段類型、刪除字段等。

服務(wù)架構(gòu)的部署原則

測(cè)試完成之后，需要對(duì)微服務(wù)進(jìn)行自動(dòng)化部署。微服務(wù)的部署原則：獨(dú)立部署和生命周期管理、基礎(chǔ)設(shè)施自動(dòng)化。需要有一套類似于CI/CD的流水線來(lái)做基礎(chǔ)設(shè)施自動(dòng)化，具體可以參考Netflix開(kāi)源的微服務(wù)持續(xù)交付流水線Spinnaker：

這里寫圖片描述

最后一起看下微服務(wù)的運(yùn)行容器：微部署可以部署在Dorker容器、PaaS平臺(tái)（VM）或者物理機(jī)上。使用Docker部署微服務(wù)會(huì)帶來(lái)很多優(yōu)先：

一致的環(huán)境，線上線下環(huán)境一致。
避免對(duì)特定云基礎(chǔ)設(shè)施提供商的依賴。
降低運(yùn)維團(tuán)隊(duì)負(fù)擔(dān)。
高性能接近裸機(jī)性能。
多租戶。

相比于傳統(tǒng)的物理機(jī)部署，微服務(wù)可以由PaaS平臺(tái)實(shí)現(xiàn)微服務(wù)自動(dòng)化部署和生命周期管理。除了部署和運(yùn)維自動(dòng)化，微服務(wù)云化之后還可以充分享受到更靈活的資源調(diào)度：

云的彈性和敏捷。
云的動(dòng)態(tài)性和資源隔離。

服務(wù)架構(gòu)的治理原則

服務(wù)部署上線之后，最重要的工作就是服務(wù)治理。微服務(wù)治理原則：線上治理、實(shí)時(shí)動(dòng)態(tài)生效。
微服務(wù)常用的治理策略：

流量控制：動(dòng)態(tài)、靜態(tài)流控制。
服務(wù)降級(jí)。
超時(shí)控制。
優(yōu)先級(jí)調(diào)度。
流量遷移。
調(diào)用鏈跟蹤和分析。
服務(wù)路由。
服務(wù)上線審批、下線通知。
SLA策略控制。
微服務(wù)治理模型如下所示：

這里寫圖片描述

最上層是為服務(wù)治理的UI界面，提供在線、配置化的治理界面供運(yùn)維人員使用。SDK層是提供了微服務(wù)治理的各種接口，供服務(wù)治理Portal調(diào)用。最下面的就是被治理的微服務(wù)集群，集群各節(jié)點(diǎn)會(huì)監(jiān)聽(tīng)服務(wù)治理的操作去做實(shí)時(shí)刷新。例如：修改了流控閾值之后，服務(wù)治理服務(wù)會(huì)把新的流控的閾值刷到服務(wù)注冊(cè)中心，服務(wù)提供者和消費(fèi)者監(jiān)聽(tīng)到閾值變更之后，獲取新的閾值并刷新到內(nèi)存中，實(shí)現(xiàn)實(shí)時(shí)生效。由于目前服務(wù)治理策略數(shù)據(jù)量不是特別大，所以可以將服務(wù)治理的數(shù)據(jù)放到服務(wù)注冊(cè)中心（例如etcd/ZooKeeper），沒(méi)有必要再單獨(dú)做一套。

服務(wù)最佳實(shí)踐

介紹完微服務(wù)實(shí)施之后，下面我們一起學(xué)習(xí)下微服務(wù)的最佳實(shí)踐。
服務(wù)路由：本地短路策略。關(guān)鍵技術(shù)點(diǎn)：優(yōu)先調(diào)用本JVM內(nèi)部服務(wù)提供者，其次是相同主機(jī)或者VM的，最后是跨網(wǎng)絡(luò)調(diào)用。通過(guò)本地短路，可以避免遠(yuǎn)程調(diào)用的網(wǎng)絡(luò)開(kāi)銷，降低服務(wù)調(diào)用時(shí)延、提升成功率。原理如下所示：

這里寫圖片描述

服務(wù)調(diào)用方式：同步調(diào)用、異步調(diào)用、并行調(diào)用。一次服務(wù)調(diào)用，通常就意味著會(huì)掛一個(gè)服務(wù)調(diào)用線程。采用異步調(diào)用，可以避免線程阻塞，提升系統(tǒng)的吞吐量和可靠性。但是在實(shí)際項(xiàng)目中異步調(diào)用也有一些缺點(diǎn)，導(dǎo)致使用不是特別廣泛：
需要寫異步回調(diào)邏輯，與傳統(tǒng)的接口調(diào)用使用方式不一致，開(kāi)發(fā)難度大一些。
一些場(chǎng)景下需要緩存上下文信息，引入可靠性問(wèn)題。
并行調(diào)用適用于多個(gè)服務(wù)調(diào)用沒(méi)有上下文依賴，邏輯上可以并行處理，類似JDK的Fork/Join, 并行服務(wù)調(diào)用涉及到同步轉(zhuǎn)異步、異步轉(zhuǎn)同步、結(jié)果匯聚等，技術(shù)實(shí)現(xiàn)難度較大，目前很多服務(wù)框架并不支持。采用并行服務(wù)調(diào)用，可以把傳統(tǒng)串行的服務(wù)調(diào)用優(yōu)化成并行處理，能夠極大的縮短服務(wù)調(diào)用時(shí)延。

微服務(wù)故障隔離：線程級(jí)、進(jìn)程級(jí)、容器級(jí)、VM級(jí)、物理機(jī)級(jí)等。關(guān)鍵技術(shù)點(diǎn)：

支持服務(wù)部署到不同線程/線程池中。
核心服務(wù)和非核心服務(wù)隔離部署。
為了防止線程膨脹，支持共享和獨(dú)占兩種線程池策略。

這里寫圖片描述

談到分布式，就繞不開(kāi)事務(wù)一致性問(wèn)題：大部分業(yè)務(wù)可以通過(guò)最終一致性來(lái)解決，極少部分需要采用強(qiáng)一致性。

這里寫圖片描述

具體的策略如下：

最終一致性，可以基于消息中間件實(shí)現(xiàn)。
強(qiáng)一致性，使用TCC框架。服務(wù)框架本身不會(huì)直接提供“分布式事務(wù)”，往往根據(jù)實(shí)際需要遷入分布式事務(wù)框架來(lái)支持分布式事務(wù)。

微服務(wù)的性能三要素：

I/O模型，這個(gè)通常會(huì)選用非堵塞的，Java里面可能用java原生的。
線程調(diào)度模型。
序列化方式。

公司內(nèi)部服務(wù)化，對(duì)性能要求較高的場(chǎng)景，建議使用異步非阻塞I/O（Netty） + 二進(jìn)制序列化（Thrift壓縮二進(jìn)制等） + Reactor線程調(diào)度模型。

這里寫圖片描述

最后我們一起看下微服務(wù)的接口兼容性原則：技術(shù)保障、管理協(xié)同。

制定并嚴(yán)格執(zhí)行《微服務(wù)前向兼容性規(guī)范》，避免發(fā)生不兼容修改或者私自修改不通知周邊的情況。
接口兼容性技術(shù)保障：例如Thrift的IDL，支持新增、修改和刪除字段、字段定義位置無(wú)關(guān)性，碼流支持亂序等。
持續(xù)交付流水線的每日構(gòu)建和契約化驅(qū)動(dòng)測(cè)試，能夠快速識(shí)別和發(fā)現(xiàn)不兼容。

現(xiàn)在流行的ＲＰC框架:

服務(wù)治理型

dubbo
dubbox
motan

多語(yǔ)言型

grpc
thrift
avro
Protocol Buffers (google)

這里寫圖片描述

上圖來(lái)自于dubbo。服務(wù)治理型RPC框架結(jié)構(gòu)大多如此，大致分為服務(wù)提供者，服務(wù)消費(fèi)者，注冊(cè)中心，監(jiān)控報(bào)警中心幾大模塊。

服務(wù)性能

在服務(wù)化，或者微服務(wù)化過(guò)程中，首先考慮的問(wèn)題就是性能問(wèn)題，因?yàn)樵诜?wù)化之后，會(huì)增加以下額外的性能開(kāi)銷：

客戶端需要對(duì)消息進(jìn)行序列化，主要占用CPU計(jì)算資源。
序列化時(shí)需要?jiǎng)?chuàng)建二進(jìn)制數(shù)組，耗費(fèi)JVM堆內(nèi)存或者堆外內(nèi)存。
客戶端需要將序列化之后的二進(jìn)制數(shù)組發(fā)送給服務(wù)端，占用網(wǎng)絡(luò)帶寬資源。
服務(wù)端讀取到碼流之后，需要將請(qǐng)求數(shù)據(jù)報(bào)反序列化成請(qǐng)求對(duì)象，占用CPU計(jì)算資源。
服務(wù)端通過(guò)反射的方式調(diào)用服務(wù)提供者實(shí)現(xiàn)類，反射本身對(duì)性能影響就比較大。
服務(wù)端將響應(yīng)結(jié)果序列化，占用CPU計(jì)算資源。
服務(wù)端將應(yīng)答碼流發(fā)送給客戶端，占用網(wǎng)絡(luò)帶寬資源。
客戶端讀取應(yīng)答碼流，反序列化成響應(yīng)消息，占用CPU資源。

RPC框架高性能設(shè)計(jì)

要想提高效率，除了硬件的提升，主要考慮以下三個(gè)方面：

I/O調(diào)度模型：同步阻塞I/O（BIO）還是非阻塞I/O（NIO）。
序列化框架的選擇：文本協(xié)議、二進(jìn)制協(xié)議或壓縮二進(jìn)制協(xié)議。
線程調(diào)度模型：串行調(diào)度還是并行調(diào)度，鎖競(jìng)爭(zhēng)還是無(wú)鎖化算法。

IO調(diào)度現(xiàn)在主流的就是netty。
高性能序列化目前性能最好的是ice,google 的 pb協(xié)議，F(xiàn)B的thrift協(xié)議等
線程沒(méi)啥好說(shuō)的，肯定多線程了。當(dāng)然也可以是AKKA（java）

總結(jié)

綜上所述，服務(wù)化是現(xiàn)在大型互聯(lián)網(wǎng)公司主流的架構(gòu)模式，現(xiàn)在還有更流行的微服務(wù)，docker部署等等。

個(gè)人建議采用dubbox，集成其他各種協(xié)議，在該系列文章最后有各個(gè)協(xié)議的性能對(duì)比。

之所以建議采用dubbox是因?yàn)?，dubbox有比價(jià)完善的服務(wù)治理模型，其包含ZK注冊(cè)中心，服務(wù)監(jiān)控等，可以很方便的為我們服務(wù)。
雖然dubbo本身不支持多語(yǔ)言，但是我們可以集成其他的序列化協(xié)議，比如thrift、avro，使其可以支持多種入門語(yǔ)言，讓部門間的協(xié)作溝通更加靈活方便

當(dāng)然，在實(shí)際使用過(guò)程中，尤其是集成其他協(xié)議的過(guò)程中，肯定需要對(duì)協(xié)議本身有比較深入的了解，才能正確的使用。

motan

新浪微博開(kāi)源的RPC框架

helloword示例直接去官網(wǎng)下載運(yùn)行即可

github地址：https://github.com/weibocom/motan
文檔地址：https://github.com/weibocom/motan/wiki/zh_quickstart
用戶指南;https://github.com/weibocom/motan/wiki/zh_userguide

grpc

中文版官方文檔：gRPC 官方文檔中文版

helloWord示例，我就是根據(jù)這個(gè)文章做的，寫得挺詳細(xì)的：rpc框架之gRPC 學(xué)習(xí) - hello world

grpc原理: grpc原理分析

dubbo

dubbo 已經(jīng)與12年年底停止維護(hù)升級(jí)，忽略

thrift

請(qǐng)參考我寫的另一篇文章：thrift學(xué)習(xí)筆記（一） thrift簡(jiǎn)介及第一個(gè)helloword程序

dubbox

dubbox 是當(dāng)當(dāng)團(tuán)隊(duì)基于dubbo升級(jí)的一個(gè)版本。是一個(gè)分布式的服務(wù)架構(gòu)，可直接用于生產(chǎn)環(huán)境作為SOA服務(wù)框架。
dubbo官網(wǎng)首頁(yè)：http://dubbo.io/ 上面有詳細(xì)的用戶指南和官方文檔，介紹的比較詳細(xì)，這里不再贅述。

當(dāng)當(dāng)官方的github地址：https://github.com/dangdangdotcom/dubbox

升級(jí)為spring4.X（及其他依賴組件）版本dubbox的github的地
址：https://github.com/yjmyzz/dubbox。

參考資料【博客：菩提樹(shù)下的楊過(guò) 的文章寫得非常全面，介紹的已經(jīng)非常詳細(xì)了】：
dubbox升級(jí)spring到4.x及添加log4j2支持
 分布式服務(wù)框架 dubbo/dubbox 入門示例
 dubbox 的各種管理和監(jiān)管
 dubbo/dubbox 增加原生thrift及avro支持

各個(gè)RPC框架性能比較

測(cè)試環(huán)境

jdk7
win7 64位
idea
個(gè)人筆記本配置：

這里寫圖片描述

person對(duì)象：

private int age;
private String name;
private boolean sex;
private int childrenCount;

測(cè)試數(shù)據(jù)，入?yún)ⅲ?/p>

private int ageStart;
private int ageEnd;

返回值：

Person.PersonBuilder builder = Person.builder();
List<Person> list = new ArrayList<Person>();
for (short i = 0; i < 10; i++) {
    list.add(builder.age(i).childrenCount(i).name("test" + i).sex(true).build());
}
return list;

各協(xié)議測(cè)試使用的配置

grpc

rpc getPersonList (yjmyzz.grpc.study.dto.QueryParameter) returns (yjmyzz.grpc.study.dto.PersonList) {}

motan

<motan:basicService export="demoMotan:8002" group="motan-demo-rpc" accessLog="false" shareChannel="true" module="motan-demo-rpc" application="myMotanDemo" registry="registry" id="serviceBasicConfig"/>

dubbox

<dubbo:protocol name="dubbo" serialization="kryo" optimizer="com.alibaba.dubbo.demo.SerializationOptimizerImpl"/>

<dubbo:service interface="com.alibaba.dubbo.demo.person.PersonService" ref="personService" protocol="dubbo"/>

thrift

TNonblockingServer + TFramedTransport

測(cè)試結(jié)果


rgpc 100000 次NettyServer調(diào)用，耗時(shí)：53102毫秒，平均1883次/秒 【簡(jiǎn)單grpc】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：52138毫秒，平均1917次/秒 【簡(jiǎn)單grpc】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：51800毫秒，平均1930次/秒 【簡(jiǎn)單grpc】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：51313毫秒，平均1948次/秒 【簡(jiǎn)單grpc】

rgpc 100000 次NettyServer調(diào)用，耗時(shí)：56812毫秒，平均1760次/秒[2016-10-08 19:17:31] Dubbo service server started! 【dubbox.kryo】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：55133毫秒，平均1813次/秒[2016-10-08 19:18:42] Dubbo service server started!【dubbox.kryo】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：52280毫秒，平均1912次/秒[2016-10-08 19:20:01] Dubbo service server started! 【dubbox.kryo】

rgpc 100000 次NettyServer調(diào)用，耗時(shí)：44414毫秒，平均2251次/秒[2016-10-08 19:13:34] Dubbo service server started! 【dubbox.fst】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：44805毫秒，平均2231次/秒[2016-10-08 19:12:25] Dubbo service server started! 【dubbox.fst】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：46245毫秒，平均2162次/秒[2016-10-08 19:14:43] Dubbo service server started! 【dubbox.fst】

rgpc 100000 次NettyServer調(diào)用，耗時(shí)：12203毫秒，平均8194次/秒[2016-10-09 19:52:34] Dubbo service server started!【dubbox.thrift】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：14142毫秒，平均7071次/秒[2016-10-09 19:30:17] Dubbo service server started!【dubbox.thrift】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：13762毫秒，平均7266次/秒[2016-10-09 19:30:43] Dubbo service server started!【dubbox.thrift】

rgpc 100000 次NettyServer調(diào)用，耗時(shí)：44334毫秒，平均2255次/秒 【motan】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：37844毫秒，平均2642次/秒 【motan】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：39007毫秒，平均2563次/秒 【motan】
rgpc 100000 次NettyServer調(diào)用，耗時(shí)：38610毫秒，平均2590次/秒 【motan】

測(cè)試結(jié)果說(shuō)明

使用的自己的筆記本電腦測(cè)試的，測(cè)試的方式可能不太專業(yè)，但能夠說(shuō)明問(wèn)題。
通過(guò)上面結(jié)果可以看到，thrift的性能最好,而且是相當(dāng)?shù)暮?

網(wǎng)上其他人做的測(cè)試

ice-dubbo-thrift-grpc性能測(cè)試對(duì)比
 RPC框架的性能比較

總結(jié)

影響RPC性能的因素主要有：

序列化性能
IO性能
線程模式

序列化的話，肯定是Google的PB協(xié)議和thrift最好，IO和線程的話，先流行的性能比較好的都是采用多線程非阻塞IO。

grpc是Google出品，使用了PB協(xié)議，但是由于它出現(xiàn)的比較晚，還不怎么成熟，而且采用http協(xié)議，非常適合現(xiàn)在的微服務(wù)，不過(guò)性能上差了許多，而且像服務(wù)治理與監(jiān)控都需要額外的開(kāi)發(fā)工作，所以放棄grpc。
thrift和grpc一樣，性能優(yōu)越，但是開(kāi)發(fā)難度相比較于dubbox和motan也是高了一點(diǎn)點(diǎn)，需要編寫proto文件（其實(shí)對(duì)于程序員來(lái)說(shuō)這算不上難度）。像服務(wù)治理與監(jiān)控也是需要額外的開(kāi)發(fā)工作。
dubbo比較老了，直接棄用。
dubbox和后來(lái)的motan都比較適合我們的團(tuán)隊(duì)。dubbox后來(lái)經(jīng)過(guò)當(dāng)當(dāng)?shù)拈_(kāi)發(fā)，引入了rest風(fēng)格的http協(xié)議，并且還支持kryo/fst/dubbo/thrift等其他協(xié)議，而且其他團(tuán)隊(duì)也在使用dubbo，集成方便，服務(wù)治理監(jiān)控功能齊全，所以最終采用dubbox。

其實(shí)我個(gè)人而言還是喜歡thrift，畢竟性嫩優(yōu)越，在大型分布式系統(tǒng)中，哪怕一點(diǎn)點(diǎn)性能提升累計(jì)在一起也是很可觀的。不過(guò)再具體選型的過(guò)程中還要結(jié)合團(tuán)隊(duì)目前的狀況和團(tuán)隊(duì)其他開(kāi)發(fā)人員的接受程度進(jìn)行取舍。

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

服務(wù)化實(shí)戰(zhàn)之 dubbo、dubbox、motan、thrift、grpc等RPC框架比較及選型

服務(wù)化實(shí)戰(zhàn)之 dubbo、dubbox、motan、thrift、grpc等RPC框架比較及選型

概述

RPC簡(jiǎn)述

服務(wù)架構(gòu)的拆分原則

不好的實(shí)踐

建議的原則

服務(wù)架構(gòu)的開(kāi)發(fā)原則

服務(wù)架構(gòu)的測(cè)試原則

服務(wù)架構(gòu)的部署原則

服務(wù)架構(gòu)的治理原則

服務(wù)最佳實(shí)踐

現(xiàn)在流行的ＲＰC框架:

服務(wù)治理型

多語(yǔ)言型

服務(wù)性能

RPC框架高性能設(shè)計(jì)

總結(jié)

motan

grpc

dubbo

thrift

dubbox

各個(gè)RPC框架性能比較

測(cè)試環(huán)境

各協(xié)議測(cè)試使用的配置

測(cè)試結(jié)果

測(cè)試結(jié)果說(shuō)明

網(wǎng)上其他人做的測(cè)試

總結(jié)

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九 欧美,1769亚洲,黄色成人av

服務(wù)化實(shí)戰(zhàn)之 dubbo、dubbox、motan、thrift、grpc等RPC框架比較及選型

概述

RPC簡(jiǎn)述

服務(wù)架構(gòu)的拆分原則

不好的實(shí)踐

建議的原則

服務(wù)架構(gòu)的開(kāi)發(fā)原則

服務(wù)架構(gòu)的測(cè)試原則

服務(wù)架構(gòu)的部署原則

服務(wù)架構(gòu)的治理原則

服務(wù)最佳實(shí)踐

現(xiàn)在流行的ＲＰC框架:

服務(wù)治理型

多語(yǔ)言型

服務(wù)性能

RPC框架高性能設(shè)計(jì)

總結(jié)

motan

grpc

dubbo

thrift

dubbox

各個(gè)RPC框架性能比較

測(cè)試環(huán)境

各協(xié)議測(cè)試使用的配置

測(cè)試結(jié)果

測(cè)試結(jié)果說(shuō)明

網(wǎng)上其他人做的測(cè)試

總結(jié)

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

服務(wù)化實(shí)戰(zhàn)之 dubbo、dubbox、motan、thrift、grpc等RPC框架比較及選型