高性能協(xié)議與RPC - phptars助力起點改造
梁晨 ??
Ted
任職起點技術中心前端開發(fā)組，負責起點中文網(wǎng)踪古、起點海外版的web后臺開發(fā)工作。曾負責騰訊上海企業(yè)產(chǎn)品部營銷QQWeb后臺開發(fā)柑司、QQ公眾號Web后臺開發(fā)藕漱，對大型網(wǎng)站技術架構，有自己的經(jīng)驗和見解臀稚。騰訊開源項目TSF2.0框架開發(fā)者吝岭，騰訊開源組件phptars開發(fā)者，也曾是騰訊公司多個php擴展組件的開發(fā)者與維護者吧寺。
高性能協(xié)議與RPC
? ? ? ? ? ? ?---phptars助力起點改造
?閱文集團的起點改造項目中窜管，我們一度遇到了非常多的挑戰(zhàn)，其中包括http協(xié)議的過分冗余以及上層封裝帶來的性能損耗稚机。我們不但要應對同步的http的調(diào)用庫所帶來的吞吐量的極大下降幕帆，還要應對JSON 、XML 協(xié)議在信息傳輸上的低效率赖条。
為了解決這一問題失乾，我們必須要引入在 TCP 協(xié)議層的常熙，簡單封裝的，二進制協(xié)議仗扬。才能保證用更少的傳輸帶寬症概，承載更多的傳輸內(nèi)容蕾额。
同時早芭，在實際開發(fā)的層面上，還有 PHP 邏輯層 Server 之間通信協(xié)議文件的維護成本非常之高诅蝶。有文檔維護界面的還好退个，對于沒有落地文檔的接口，協(xié)議往往都只存在在代碼當中调炬。而當團隊出現(xiàn)人員變動之后语盈，這個代碼的維護難度極大。
同時缰泡， Server 側新增或修改接口字段刀荒，往往 Client 側也要配合修改，很多時候無法保證接口的完全兼容而引發(fā)線上的運營問題棘钞。因此缠借，我們必須要引入一種接口方便維護，同時又容易擴展的二進制協(xié)議宜猜。
除此之外泼返，從開發(fā)效率上而言，原本的協(xié)議開發(fā)總是包含大量的重復的姨拥，但又不得不去做的工作內(nèi)容绅喉。每一次新協(xié)議的開發(fā)，能夠復用的部分非常之少叫乌。而且一個很現(xiàn)實的問題是柴罐，不同 Http 接口的提供方，往往會視自己的心情來定義接口憨奸。常見的例子就是對返回碼的定義革屠，有些人叫ret，有些人叫code膀藐，還有些人就叫r屠阻。就跟到了菜市場，簡直是無所不包额各。
因此這類重復無趣的開發(fā)工作国觉，給客戶端的開發(fā)同學帶來了極大的生理和心理負擔，以至于他們不得不經(jīng)常問 我是誰虾啦，我在哪兒麻诀，我為啥要寫這種代碼 這樣的問題痕寓。基于這種需求蝇闭，我們必須要引入一種 Server 和 Client 端都能夠根據(jù)協(xié)議自動生成接口代碼呻率，保證聯(lián)調(diào)舒爽通暢的解決方案。
再者呻引，Client 對后端服務的發(fā)現(xiàn)和調(diào)用的上報與監(jiān)控礼仗，也是一個老生常談的問題。后端服務如何被發(fā)現(xiàn)逻悠，后端的接口如何被發(fā)現(xiàn)元践，這都是調(diào)用方需要解決的。同時童谒，Client 端非常有必要對后端服務的調(diào)用情況進行上報到中央服務器单旁，中央服務器在根據(jù)收集上來的信息，對后端服務的負載進行動態(tài)的調(diào)整饥伊，保證服務的高可用象浑。要實現(xiàn)這樣的需求，我們必須引入一種集成了監(jiān)控琅豆、主控尋址愉豺、上報通道、負載均衡功能的解決方案趋距。
如果有一種方案粒氧，可以滿足上述的所以需求匆绣，那簡直就是難以置信型宝。兼具了簡單高效、接口維護方便又容易擴展的二進制協(xié)議挺尿、同時滿足server與client端代碼根據(jù)協(xié)議自動生成翼雀，以及集成了尋址饱苟、服務發(fā)現(xiàn)、監(jiān)控狼渊、上報功能箱熬。這么多的優(yōu)勢和特性，非我們今天要介紹的 phptars 莫屬狈邑。
要了解 phptars 的開源方案城须，就要從二進制的協(xié)議說起了：
二進制協(xié)議
HTTP 協(xié)議可能是在應用層上最為廣泛的協(xié)議了。現(xiàn)有 HTTP 的版本主要是1.0和1.1版本米苹。它在 TCP 的基礎上做了十分簡潔的應用層協(xié)議封裝糕伐，純文本的內(nèi)容，以及 header 和 body 的天然隔離蘸嘶。都使得這種協(xié)議的使用十分的方便良瞧。但是不可避免的陪汽，用戶使用的簡單意味著信息的冗余，為了傳輸少量的內(nèi)容褥蚯，往往需要耗費大量的流量挚冤。
另外兩個大家熟知的協(xié)議，就是 JSON 和 XML 了赞庶，這兩位在 WEB 交互常用的協(xié)議中不分上下训挡，可讀性強、容易理解尘执、語言客戶端支持豐富舍哄、協(xié)議表述能力突出宴凉，都是兩者的優(yōu)勢所在誊锭。說真的，我都不知道他們兩個差別何在弥锄，很可能是重復造輪子的產(chǎn)物丧靡。不過不管怎么樣，我們先看看同樣一段信息籽暇，兩者需要的數(shù)據(jù)量温治。
假定有一所學校，兩個學生和一個老師戒悠，如果用 JSON 標識的話熬荆，如下所示：
很簡單的結構，共需要122個字符來表述绸狐。而如果換成 XML ：
則一共需要181個字符卤恳。從信息學的角度而言，信息熵明顯就是太低了寒矿。所以為了實現(xiàn)通信的更高性能和更少帶寬的使用突琳，二進制協(xié)議的引入勢在必行。
說到二進制協(xié)議符相，最赫赫有名的肯定是谷歌退出的protocol buffer了拆融，而今天我們要著重介紹的是騰訊MIG推出的 tars 協(xié)議。從上文中的 JSON 和 XML 中我們發(fā)現(xiàn)他們的靈活性啊终，也就是沒有指定字段的類型镜豹，但是不可避免的，這種靈活帶來了性能的大損失蓝牲。因此 tars 定義了八種基本的數(shù)據(jù)類型趟脂，通過對不同的數(shù)據(jù)類型進行編碼優(yōu)化：
bool、byte搞旭、short散怖、int菇绵、long、float镇眷、double咬最、string
而同時為了滿足業(yè)務需求，擴展出了struct（包含任意字段）欠动、vector（數(shù)組）永乌、map（key-value結構）這三種可以嵌套數(shù)據(jù)，豐富協(xié)議表現(xiàn)力的復雜類型具伍。
按照上文的表現(xiàn)結構翅雏，幾個struct就可以完成。
首先是 student 結構體：
從注釋中可以看到人芽，三個字段需要的字節(jié)數(shù)為14望几，再加上結構體的開始和結構體結束的標識共2個字節(jié)，一共只需要16個字節(jié)而已萤厅。加上另一位老師的信息橄抹，一共不超過30個字節(jié)。相比之下惕味，這僅僅是 JSON 的1/4楼誓，是 XML 協(xié)議標識同樣信息的1/5，高下立判. 巧妙地用協(xié)議強約定換傳輸可讀性名挥，這就是高信息熵的二進制協(xié)議的訣竅疟羹。
PHP擴展-性能利器
有了這么強力的二進制協(xié)議，那么 PHP 必須通過開發(fā)高效的客戶端來充分利用之禀倔。不過榄融，PHP 語言本身被詬病最多的，就是針對 CPU 密集型的運算的低效率蹋艺。由于并不十分高效的 ZEND 虛擬機剃袍、松散的數(shù)據(jù)結構和弱類型的存在，使得打包捎谨、解包這類字符串操作型的效率很低下民效。
基于這個原因，php擴展應運而生涛救。通過引入高性能的 C/C++ 類庫畏邢，使得 PHP 在性能處理方面迎頭趕上。這也就是我們設計 pptars 擴展的初衷检吆。
我們來看看 PHP 語言的結構：
最底層的Server API用來 PHP 與webserver通信舒萎，這個主要是之前與 Apache 配合需要使用的。在其左上的phpcore層蹭沛，是為了提供最基本的文件和網(wǎng)絡操作的能力臂寝。而右上的 ZEND章鲤，則是用來把 PHP 的腳本語言編譯成機器碼的工具。
最上面就是我們的擴展層了咆贬，這層會充分利用 ZEND 的api和phpcore的能力败徊，直接寫出zend能夠高效執(zhí)行和理解的代碼，省去了 PHP 腳本編譯為機器碼的過程掏缎，從而大大的提高執(zhí)行的效率皱蹦。
如果要設計phptars擴展，我們必須要將上文中tars的數(shù)據(jù)結構通過C語言的方式加以表達眷蜈，同時設計出基于這套數(shù)據(jù)結構的編碼器與解碼器沪哺。另一個需要考慮的方面是，必須要使得在 PHP 層面盡可能的簡單酌儒、易用辜妓，這就對我們設計擴展的時候提出了比較高的挑戰(zhàn)。通過參考赫赫有名的 Google 的protobuf的設計思想今豆，我們成功的將tars中的struct嫌拣，進行了 PHP 中的class的表達:
而從圖中可以清晰的看到，結構體SimpleStruct被我們分解成了三個部分：
?tag 部分
成員變量部分
變量描述的 fields
tag部分至關重要呆躲，這部分被我們用來代表 struct 中每個元素的 tag 值。這也是我們實際進行 tars 編碼和解碼的時候捶索，二進制包里面最終包含的內(nèi)容插掂。為什么要有 tag ？這是因為相比于 json 里面對字段的文本性質的描述腥例， tag 本身更節(jié)省空間辅甥。
第二部分則是類的成員變量，這部分成員變量和 tars 的 struct 中的變量一一對應燎竖。這是為了承載對應變量的實際值而存在的璃弄。只有靠他們我們才能對真正的數(shù)據(jù)進行打包和解包。
為了在 tag 和變量之間搭起一座橋梁构回，我們就有了第三個部分夏块。也就是最重要的 fields 部分。這部分是 tag 與其對應的變量屬性的一個映射纤掸。抱哈拿了變量的名稱脐供、變量是否必填以及變量的類型。通過這些信息借跪，一方面我們實現(xiàn)了對 tars 協(xié)議的二進制編碼政己，也實現(xiàn)了解碼時候的映射√统睿可謂一舉兩得歇由。
那么經(jīng)過復雜的擴展設計與實現(xiàn)卵牍，我們有必要將擴展實現(xiàn)的打包解包性能和原生PHP 實現(xiàn)的打包解包性能進行比對。從下面的表格中可以非常明顯的看出擴展實現(xiàn)擁有性能上面的絕對優(yōu)勢：
從這個表格中可以非常清晰的看到沦泌，無論是簡單的tars辽慕，還是復雜的tars，使用擴展進行打包解包都比原生 PHP 的性能提高十倍以上赦肃。當我們遇到復雜的業(yè)務邏輯溅蛉，需要調(diào)用大量的使用 tars 協(xié)議的后臺服務的時候，這種效率的提升會讓我們服務的吞吐量上一個數(shù)量級他宛。
代碼自動生成-效率利器
剛剛提到船侧，除了對打包解包性能的極致追求之外，我們還必須考慮到php使用時的友好性厅各【盗茫基于這一點，非常有必要實現(xiàn)一整套從 tars 到 PHP 文件的自動生成與轉換的工作队塘。
使用協(xié)議的同學袁梗，只需執(zhí)行一個命令，即可將打包解包所必須的文件生成完畢憔古，再經(jīng)過簡單的調(diào)試遮怜，就能完成一次協(xié)議的開發(fā)，從而大大降低了之前人工撰寫的成本鸿市。把人力聚焦在更值得他們做的事情上面锯梁。
轉換為：
要實現(xiàn)這一點，對 tars 文件的處理必不可少焰情。這種轉換與自動生成的工作陌凳，如果要做的足夠健壯，那么一定不能使用生硬的正則匹配内舟。而是必須要從編譯原理的角度去考慮合敦，即是：如果你要做一個 tars 語言的初級編譯器，你會如何去實現(xiàn)验游？
下面給出我們設計的整個工具系統(tǒng)的結構：
具體針對 tars 的語法而言的話充岛，第一點，是對 tars 文件進行正確的分詞批狱，只有把每個有意義的詞或者是符號正確的分開裸准，才能為后續(xù)的生成打下基礎。如結構體中的0 required string name=1赔硫，我們必須區(qū)分出從左至右的每一個字段分別為tag require_type parameter_type parameter_name default_value炒俱，這一步所依賴的最重要的就是構詞的規(guī)則，哪些詞是 tars 語法的關鍵詞，哪些是停止詞权悟，哪些是可以忽略的詞砸王，都需要在規(guī)則中明確下來。
第二點則是對分出來的詞進行語法的分析峦阁，我們必須知道谦铃，哪些詞是參數(shù)類型，哪些詞是可以忽略的榔昔。同時還有很重要的一點是驹闰，現(xiàn)有分出來的詞是否符合特定的語法。比如在分號之后撒会，重復的出現(xiàn) tars 中的 tag 字段嘹朗，這肯定是不合法的。
或者還有出現(xiàn)大括號無法前后對應的情況诵肛，這也是對語法規(guī)則的一種違背屹培。只有這一步保證了語法的正確性，才能進行下一步怔檩，也是最終的一步褪秀，對于語義的分析。
語義分析是需要結合上下文才能正確完成的事情薛训，這與第二點存在一些依賴媒吗，但又不完全相同。我們在判斷某個詞是什么的時候许蓖，不單單需要依賴詞本身的信息和語法規(guī)則帶來的信息蝴猪，還需要依賴詞的上下文的信息。
如果一個數(shù)組出現(xiàn)在頭部膊爪，那么我們認為它是 tag ，而如果一個數(shù)字出現(xiàn)在尾部等號的后面嚎莉，那么我們認為它就是一個默認值米酬。而這種基于對上下文的判斷，必須引入狀態(tài)機來保證流轉的順暢性趋箩。
下面就給出對 tars 中的 struct 的一行數(shù)據(jù)進行狀態(tài)轉換的狀態(tài)機示例：?
正如圖中所示赃额，通過狀態(tài)的流轉，我們能夠順利的完成分詞叫确，以及對詞語具體類型的解釋跳芳。從而將其映射為 php 文件中相應的類、變量竹勉、函數(shù)等等飞盆。可以毫不夸張的說，通過這個工具的優(yōu)化吓歇，原有一次接入 tars 服務的開發(fā)時間孽水，從小時的級別，降低到了分鐘的級別城看，大大提高了起點改造過程中的工作效率女气。
?TAF監(jiān)控上報與自動路由集成
在起點后臺的服務治理完成之后，大部分我們與后臺之間的數(shù)據(jù)交換测柠，已經(jīng)從 http 切換成了基于 tars 協(xié)議的 tcp 網(wǎng)絡傳輸炼鞠。如此多的服務，那就勢必遇到如下的幾個問題：
1. 如何對服務的調(diào)用情況進行監(jiān)控告警
2. 如何管理每個服務的調(diào)用地址和負載均衡
依托于強大的米格監(jiān)控系統(tǒng)轰胁，我們在底層集成了對每個 tars 服務的調(diào)用耗時和成功率的統(tǒng)計谒主。只需選擇不同的業(yè)務，那么當前業(yè)務下的所有調(diào)用的服務和接口软吐，以及他們的頻率瘩将、耗時和成功率都是一目了然。
對于遠程服務的地址管理凹耙，最差的方案就是將其寫入本地文件中姿现。這種方案無法應對快速縮擴容以及服務器下線的需求，會給后續(xù)的運維帶來很大的工作量肖抱。
稍微好一些的方案是本地存儲虛擬IP备典，那么每次只需要調(diào)整虛擬IP，就可以實現(xiàn)服務地址的自動映射和變化意述。但是這意味著對要調(diào)用的每一個后臺服務提佣，都需要存儲其對應的虛擬IP、Host信息荤崇、接口信息等一系列的信息拌屏，同樣維護成本很高。
而更加通用的方案术荤，則是提供服務的統(tǒng)一配置中心倚喂，每次需要調(diào)用后臺服務的時候，就從配置中心根據(jù)唯一的標識拉取出服務最新的地址瓣戚。這樣一方面能夠做到縮擴容對業(yè)務的無感知端圈，另一方面配置中心也能夠通過服務的尋址情況，給每個客戶端分配最適合它的服務機器地址子库，比如機房或者Set就近分配等等舱权。
本地的服務只需要提供兩個能力，第一個是能夠調(diào)用定期的尋址服務仑嗅，并存入本機的存儲中宴倍，保證尋址的速度张症。第二個則是能夠接收配置中心下發(fā)的命令，更新特定服務的地址啊楚。能做到這兩點吠冤，就能夠實現(xiàn)高效的尋址和可靠的尋址了。
正是依托于 phptars 強大的主控和尋址的機制恭理，我們按照如下的架構拯辙，搭建了本機的自動路由和監(jiān)控上報的體系：
在使用中，我們結合實際業(yè)務情況颜价，一方面每分鐘向主控請求一次服務的地址涯保，通過輪詢的方式獲取一個可用的服務地址，再放入本地的高速共享內(nèi)存周伦，方便在這一分鐘之內(nèi)重復的讀取夕春。
另一方面在每次服務調(diào)用的時候，都自動在底層集成對服務調(diào)用情況的耗時专挪、成功率的上報及志。在雙管齊下的作用之下，對遠程服務的調(diào)用不再像過去那樣難以維護寨腔、難以開發(fā)速侈、難以監(jiān)控，而是清晰可見高效的被管理迫卢。
結語
正如上文中所說倚搬，天下武功，唯快不破乾蛤。我們通過引入二進制的 tars 協(xié)議每界，大大壓縮了服務請求的流量。引入對 tars 協(xié)議解析的 php 擴展家卖，提高了打包解包的性能進而提升了單進程的任務處理能力眨层。開發(fā)了狀態(tài)機模型的基于 tars 協(xié)議的代碼自動生成工具，降低了開發(fā)人員的開發(fā)和調(diào)試的成本上荡。
最后谐岁，我們集成了 tars 監(jiān)控上報與自動路由機制，保證服務的高可用和可監(jiān)控榛臼。這一整套的 web 后臺的 phptars 開發(fā)體系，使得我們真正做到了高性能窜司、高效率與高可用沛善。
引用自：
http://www.mobanhu.com/zytg/3050.html
微服務架構到底應該如何選擇？
什么是微服務塞祈？
微服務的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出金刁，他們定義了微服務是由單一應用程序構成的小服務，擁有自己的進程與輕量化處理，服務依業(yè)務功能設計尤蛮，以全自動的方式部署媳友，與其他服務使用 HTTP API 通訊。同時产捞，服務會使用最小規(guī)模的集中管理 （例如 Docker）技術醇锚，服務可以用不同的編程語言與數(shù)據(jù)庫等。 微服務是SOA架構下的最終產(chǎn)物坯临，該架構的設計目標是為了肢解業(yè)務焊唬，使得服務能夠獨立運行。 主要有一下幾個特點
服務拆分粒度更細?微服務可以說是更細維度的服務化看靠，小到一個子模塊赶促，只要該模塊依賴的資源與其他模塊都沒有關系，那么就可以拆分為一個微服務挟炬。
服務獨立部署?每個微服務都嚴格遵循獨立打包部署的準則鸥滨，互不影響。比如一臺物理機上可以部署多個 Docker 實例谤祖，每個 Docker 實例可以部署一個微服務的代碼婿滓。
服務獨立維護?每個微服務都可以交由一個小團隊甚至個人來開發(fā)、測試泊脐、發(fā)布和運維空幻，并對整個生命周期負責。
服務治理能力要求高?因為拆分為微服務之后容客，服務的數(shù)量變多秕铛，因此需要有統(tǒng)一的服務治理平臺，來對各個服務進行管理缩挑。
微服務架構下但两，服務調(diào)用主要依賴下面幾個基本組件：服務描述 注冊中心 服務框架 服務監(jiān)控 服務追蹤 服務治理
開源RPC框架介紹
Dubbo
國內(nèi)最早開源的 RPC 框架，由阿里巴巴公司開發(fā)并于 2011 年末對外開源供置，僅支持 Java 語言谨湘。中間一度沒人維護坑了不少人，17年重啟維護煥發(fā)新春芥丧。架構圖如下
官網(wǎng)：?dubbo.io/
通信框架方面紧阔，Dubbo 默認采用了 Netty 作為通信框架。
通信協(xié)議方面续担，Dubbo 除了支持私有的 Dubbo 協(xié)議外擅耽，還支持 RMI 協(xié)議、Hession 協(xié)議物遇、HTTP 協(xié)議乖仇、Thrift 協(xié)議等憾儒。
序列化格式方面，Dubbo 支持多種序列化格式乃沙，比如 Dubbo起趾、Hession、JSON警儒、Kryo训裆、FST 等。
性能：?dubbo.apache.org/zh-cn/docs/…
Tars
Tars是基于名字服務使用Tars協(xié)議的高性能RPC開發(fā)框架冷蚂，同時配套一體化的服務治理平臺缭保，幫助個人或者企業(yè)快速的以微服務的方式構建自己穩(wěn)定可靠的分布式應用。
Tars是將騰訊內(nèi)部使用的微服務架構TAF（Total Application Framework）多年的實踐成果總結而成的開源項目蝙茶。
官網(wǎng)：github.com/TarsCloud/T…
架構圖如下
開源協(xié)議為：BSD-3-Clause
支持多語言 C++艺骂，Java，Nodejs隆夯，PHP钳恕，Go
gRPC
一開始由 google 開發(fā)，是一款語言中立蹄衷、平臺中立忧额、開源的遠程過程調(diào)用(RPC)系統(tǒng)。
官網(wǎng)：grpc.io
基于HTTP/2?HTTP/2 提供了連接多路復用愧口、雙向流睦番、服務器推送、請求優(yōu)先級耍属、首部壓縮等機制托嚣。可以節(jié)省帶寬厚骗、降低TCP鏈接次數(shù)示启、節(jié)省CPU，幫助移動設備延長電池壽命等领舰。gRPC 的協(xié)議設計上使用了HTTP2 現(xiàn)有的語義夫嗓，請求和響應的數(shù)據(jù)使用HTTP Body 發(fā)送，其他的控制信息則用Header 表示冲秽。
IDL使用ProtoBuf?gRPC使用ProtoBuf來定義服務舍咖，ProtoBuf是由Google開發(fā)的一種數(shù)據(jù)序列化協(xié)議（類似于XML、JSON锉桑、hessian）谎仲。ProtoBuf能夠將數(shù)據(jù)進行序列化，并廣泛應用在數(shù)據(jù)存儲刨仑、通信協(xié)議等方面郑诺。壓縮和傳輸效率高，語法簡單杉武，表達力強辙诞。
多語言支持（C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang轻抱、Java） gRPC支持多種語言飞涂，并能夠基于語言自動生成客戶端和服務端功能庫。目前已提供了C版本grpc祈搜、Java版本grpc-java 和 Go版本grpc-go较店，其它語言的版本正在積極開發(fā)中，其中容燕，grpc支持C梁呈、C++、Node.js蘸秘、Python官卡、Ruby、Objective-C醋虏、PHP和C#等語言寻咒，grpc-java已經(jīng)支持Android開發(fā)。
Motan
Motan 是國內(nèi)另外一個比較有名的開源的 RPC 框架颈嚼，同樣也只支持 Java 語言實現(xiàn)毛秘，它的架構可以用下面這張圖描述。
Motan 與 Dubbo 的架構類似阻课，都需要在 Client 端（服務消費者）和 Server 端（服務提供者）引入 SDK叫挟，其中 Motan 框架主要包含下面幾個功能模塊。
register：用來和注冊中心交互柑肴，包括注冊服務霞揉、訂閱服務、服務變更通知晰骑、服務心跳發(fā)送等功能适秩。Server 端會在系統(tǒng)初始化時通過 register 模塊注冊服務，Client 端會在系統(tǒng)初始化時通過 register 模塊訂閱到具體提供服務的 Server 列表硕舆，當 Server 列表發(fā)生變更時也由 register 模塊通知 Client秽荞。
protocol：用來進行 RPC 服務的描述和 RPC 服務的配置管理，這一層還可以添加不同功能的 filter 用來完成統(tǒng)計抚官、并發(fā)限制等功能扬跋。
serialize：將 RPC 請求中的參數(shù)、結果等對象進行序列化與反序列化凌节，即進行對象與字節(jié)流的互相轉換钦听，默認使用對 Java 更友好的 Hessian 2 進行序列化洒试。
transport：用來進行遠程通信，默認使用 Netty NIO 的 TCP 長鏈接方式朴上。
cluster：Client 端使用的模塊垒棋，cluster 是一組可用的 Server 在邏輯上的封裝，包含若干可以提供 RPC 服務的 Server痪宰，實際請求時會根據(jù)不同的高可用與負載均衡策略選擇一個可用的 Server 發(fā)起遠程調(diào)用叼架。
Spring Cloud
Spring Cloud 是為了解決微服務架構中服務治理而提供的一系列功能的開發(fā)框架，它是完全基于 Spring Boot 進行開發(fā)的衣撬，Spring Cloud 利用 Spring Boot 特性整合了開源行業(yè)中優(yōu)秀的組件乖订，整體對外提供了一套在微服務架構中服務治理的解決方案。它的架構圖可以用下面這張圖來描述具练。
以下為Spring Cloud的核心功能：
分布式/版本化配置
服務注冊和發(fā)現(xiàn)
路由
服務和服務之間的調(diào)用
負載均衡
斷路器
分布式消息傳遞
Spring Cloud對于中小型互聯(lián)網(wǎng)公司來說是一種福音乍构，因為這類公司往往沒有實力或者沒有足夠的資金投入去開發(fā)自己的分布式系統(tǒng)基礎設施，使用Spring Cloud一站式解決方案能在從容應對業(yè)務發(fā)展的同時大大減少開發(fā)成本靠粪。
下圖是RPC框架詳細的比較
如何選擇蜡吧？
一家A輪融資的公司 原來架構是net，想換java架構占键。
公司沒有強大的研發(fā)實力昔善，公司主要是to B業(yè)務，對并發(fā)要求不高畔乙，那可以試試Spring Cloud 架構君仆， Spring Cloud 不僅提供了基本的 RPC 框架功能，還提供了服務注冊組件牲距、配置中心組件返咱、負載均衡組件、斷路器組件牍鞠、分布式消息追蹤組件等一系列組件咖摹，被技術圈的人稱之為“Spring Cloud 全家桶”，而 Dubbo难述、Motan 基本上只提供了最基礎的 RPC 框架的功能萤晴，其他微服務組件都需要自己去實現(xiàn),對于這類研發(fā)能力弱的團隊，SpringCloud 無疑是最合適的胁后，減少了研發(fā)成本店读，社區(qū)熱度高，相關的教程文檔很多攀芯，減少了入門成本屯断；
再比如這家公司不準備切換Java框架還是繼續(xù)使用net架構， 有一定的研發(fā)能力，對并發(fā)要求很高， 那gRPC無疑是最適合的，跨語言支持点晴，高性能；
沒有完美的解決方案敏储，只有最合適的
推薦閱讀
互聯(lián)網(wǎng)公司面試必問的mysql題目(下)
學習Java進階技術干貨、實踐分享朋鞍，職位內(nèi)推，一起聊聊理想妥箕。志同道合的朋友滥酥，歡迎你的加入。
關注下面的標簽畦幢，發(fā)現(xiàn)更多相似文章
