|
編者按：高可用架構(gòu)分享及傳播在架構(gòu)領(lǐng)域具有典型意義的文章,，本文由張雷在高可用架構(gòu)群分享。轉(zhuǎn)載請(qǐng)注明來(lái)自高可用架構(gòu)公眾號(hào)「ArchNotes」,。
隨著微博容器化部署以及混合云平臺(tái)的高速發(fā)展，RPC 在微服務(wù)化的進(jìn)程中越來(lái)越重要,，對(duì) RPC 的需求也產(chǎn)生了一些變化,。今天主要介紹一下微博 RPC 框架 Motan，以及為了更好的適應(yīng)混合云部署所做的一些改進(jìn),。 RPC 框架的發(fā)展與現(xiàn)狀RPC（Remote Procedure Call）是一種遠(yuǎn)程調(diào)用協(xié)議,，簡(jiǎn)單地說(shuō)就是能使應(yīng)用像調(diào)用本地方法一樣的調(diào)用遠(yuǎn)程的過(guò)程或服務(wù)，可以應(yīng)用在分布式服務(wù),、分布式計(jì)算,、遠(yuǎn)程服務(wù)調(diào)用等許多場(chǎng)景。說(shuō)起 RPC 大家并不陌生,，業(yè)界有很多開(kāi)源的優(yōu)秀 RPC 框架,，例如 Dubbo、Thrift,、gRPC,、Hprose 等等。下面先簡(jiǎn)單介紹一下 RPC 與常用遠(yuǎn)程調(diào)用方式的特點(diǎn),，以及一些優(yōu)秀的開(kāi)源 RPC 框架,。 RPC 與其它遠(yuǎn)程調(diào)用方式比較 RPC 與 HTTP、RMI,、Web Service 都能完成遠(yuǎn)程調(diào)用,，但是實(shí)現(xiàn)方式和側(cè)重點(diǎn)各有不同。 HTTP HTTP（HyperText Transfer Protocol）是應(yīng)用層通信協(xié)議,，使用標(biāo)準(zhǔn)語(yǔ)義訪問(wèn)指定資源（圖片,、接口等），網(wǎng)絡(luò)中的中轉(zhuǎn)服務(wù)器能識(shí)別協(xié)議內(nèi)容,。HTTP 協(xié)議是一種資源訪問(wèn)協(xié)議,，通過(guò) HTTP 協(xié)議可以完成遠(yuǎn)程請(qǐng)求并返回請(qǐng)求結(jié)果。
HTTP 的優(yōu)點(diǎn)是簡(jiǎn)單,、易用,、可理解性強(qiáng)且語(yǔ)言無(wú)關(guān)，在遠(yuǎn)程服務(wù)調(diào)用中包括微博有著廣泛應(yīng)用,。HTTP 的缺點(diǎn)是協(xié)議頭較重,，一般請(qǐng)求到具體服務(wù)器的鏈路較長(zhǎng),，可能會(huì)有 DNS 解析、Nginx 代理等,。 RPC 是一種協(xié)議規(guī)范,，可以把 HTTP 看作是一種 RPC 的實(shí)現(xiàn)，也可以把 HTTP 作為 RPC 的傳輸協(xié)議來(lái)應(yīng)用,。RPC 服務(wù)的自動(dòng)化程度比較高,，能夠?qū)崿F(xiàn)強(qiáng)大的服務(wù)治理功能，和語(yǔ)言結(jié)合更友好,，性能也十分優(yōu)秀,。與 HTTP 相比，RPC 的缺點(diǎn)就是相對(duì)復(fù)雜,，學(xué)習(xí)成本稍高,。 RMI RMI（Remote Method Invocation）是指 Java 語(yǔ)言中的遠(yuǎn)程方法調(diào)用，RMI 中的每個(gè)方法都具有方法簽名,，RMI 客戶端和服務(wù)器端通過(guò)方法簽名進(jìn)行遠(yuǎn)程方法調(diào)用,。RMI 只能在 Java 語(yǔ)言中使用，可以把 RMI 看作面向?qū)ο蟮?Java RPC,。 Web Service Web Service 是一種基于 Web 進(jìn)行服務(wù)發(fā)布,、查詢、調(diào)用的架構(gòu)方式,，重點(diǎn)在于服務(wù)的管理與使用,。Web Service 一般通過(guò) WSDL 描述服務(wù)，使用 SOAP通過(guò) HTTP 調(diào)用服務(wù),。 RPC 是一種遠(yuǎn)程訪問(wèn)協(xié)議,，而 Web Service 是一種體系結(jié)構(gòu)，Web Service 也可以通過(guò) RPC 來(lái)進(jìn)行服務(wù)調(diào)用,，因此 Web Service 更適合同一個(gè) RPC 框架進(jìn)行比較,。當(dāng) RPC 框架提供了服務(wù)的發(fā)現(xiàn)與管理，并使用 HTTP 作為傳輸協(xié)議時(shí),，其實(shí)就是 Web Service,。 相對(duì) Web Service,，RPC 框架可以對(duì)服務(wù)進(jìn)行更細(xì)粒度的治理,，包括流量控制、SLA 管理等,，在微服務(wù)化,、分布式計(jì)算方面有更大的優(yōu)勢(shì)。 RPC 框架介紹 RPC 協(xié)議只規(guī)定了 Client 與 Server 之間的點(diǎn)對(duì)點(diǎn)調(diào)用流程,，包括 stub,、通信協(xié)議,、RPC 消息解析等部分，在實(shí)際應(yīng)用中,，還需要考慮服務(wù)的高可用,、負(fù)載均衡等問(wèn)題，所以這里的 RPC 框架指的是能夠完成 RPC 調(diào)用的解決方案,，除了點(diǎn)對(duì)點(diǎn)的 RPC 協(xié)議的具體實(shí)現(xiàn)外,，還可以包括服務(wù)的發(fā)現(xiàn)與注銷、提供服務(wù)的多臺(tái) Server 的負(fù)載均衡,、服務(wù)的高可用等更多的功能,。目前的 RPC 框架大致有兩種不同的側(cè)重方向，一種偏重于服務(wù)治理,，另一種偏重于跨語(yǔ)言調(diào)用,。 服務(wù)治理型 RPC 框架 服務(wù)治理型的 RPC 框架有 Dubbo、DubboX 等,，Dubbo 是阿里開(kāi)源的分布式服務(wù)框架,，能夠?qū)崿F(xiàn)高性能 RPC 調(diào)用，并且提供了豐富的管理功能,，是十分優(yōu)秀的 RPC 框架,。DubboX 是基于 Dubbo 框架開(kāi)發(fā)的 RPC 框架，支持 REST 風(fēng)格遠(yuǎn)程調(diào)用,，并增加了一些新的 feature,。 這類的 RPC 框架的特點(diǎn)是功能豐富，提供高性能的遠(yuǎn)程調(diào)用以及服務(wù)發(fā)現(xiàn)及治理功能,，適用于大型服務(wù)的微服務(wù)化拆分以及管理,，對(duì)于特定語(yǔ)言（Java）的項(xiàng)目可以十分友好的透明化接入。但缺點(diǎn)是語(yǔ)言耦合度較高,，跨語(yǔ)言支持難度較大,。 跨語(yǔ)言調(diào)用型 跨語(yǔ)言調(diào)用型的 RPC 框架有 Thrift、gRPC,、Hessian,、Hprose 等，這一類的 RPC 框架重點(diǎn)關(guān)注于服務(wù)的跨語(yǔ)言調(diào)用,，能夠支持大部分的語(yǔ)言進(jìn)行語(yǔ)言無(wú)關(guān)的調(diào)用,，非常適合于為不同語(yǔ)言提供通用遠(yuǎn)程服務(wù)的場(chǎng)景。但這類框架沒(méi)有服務(wù)發(fā)現(xiàn)相關(guān)機(jī)制,，實(shí)際使用時(shí)一般需要代理層進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)和負(fù)載均衡策略控制,。 微博的 RPC 框架 Motan 屬于服務(wù)治理類型，是一個(gè)基于 Java 開(kāi)發(fā)的高性能的輕量級(jí) RPC 框架,，Motan 提供了實(shí)用的服務(wù)治理功能和優(yōu)秀的 RPC 協(xié)議擴(kuò)展能力,。 Motan 提供的主要功能包括：
Motan 可以支持不同的 RPC 協(xié)議、傳輸協(xié)議,。Motan 能夠無(wú)縫支持 Spring 配置方式使用 RPC 服務(wù),，通過(guò)簡(jiǎn)單、靈活的配置就可以提供或使用 RPC 服務(wù),。通過(guò)使用 Motan 框架,，可以十分方便的進(jìn)行服務(wù)拆分、分布式服務(wù)部署,。 與同類型的 Dubbo 相比,，Motan 在功能方面并沒(méi)有那么全面，也沒(méi)有實(shí)現(xiàn)特別多的擴(kuò)展,，但 Motan 是一個(gè)小而精的 RPC 框架,，它的特點(diǎn)是簡(jiǎn)單、易用,，是一個(gè)不斷向著實(shí)用,、易用方向發(fā)展的 RPC 服務(wù)框架。 Motan RPC 框架介紹Motan 的交互流程Motan 中有服務(wù)提供方 RPC Server,，服務(wù)調(diào)用方 RPC Client 和服務(wù)注冊(cè)中心 Registry 三個(gè)角色,。
交互關(guān)系如下圖： Motan 可以支持不同的注冊(cè)中心,，如 ZK,、Consul,，目前使用的注冊(cè)中心是平臺(tái)開(kāi)發(fā)的 Vintage,，Vintage 是一個(gè)基于 Redis 的輕量級(jí) KV 存儲(chǔ)系統(tǒng)，能夠提供命名空間服務(wù),、服務(wù)注冊(cè),、服務(wù)訂閱等功能。 Motan 框架 Motan 中主要有 register,、transport,、serialize、protocol 幾個(gè)功能模塊,，各個(gè)功能模塊都支持通過(guò) SPI 進(jìn)行擴(kuò)展,，各模塊的交互如下圖所示： Register：用來(lái)和注冊(cè)中心進(jìn)行交互，包括注冊(cè)服務(wù),、訂閱服務(wù),、服務(wù)變更通知、服務(wù)心跳發(fā)送等功能,。Server 端會(huì)在系統(tǒng)初始化時(shí)通過(guò) register 模塊注冊(cè)服務(wù),，Client 端在系統(tǒng)初始化時(shí)會(huì)通過(guò) register 模塊訂閱到具體提供服務(wù)的 Server 列表，當(dāng) Server 列表發(fā)生變更時(shí)也由 register 模塊通知 Client,。 Protocol：用來(lái)進(jìn)行 RPC 服務(wù)的描述和 RPC 服務(wù)的配置管理,，這一層還可以添加不同功能的 filter 用來(lái)完成統(tǒng)計(jì)、并發(fā)限制等功能,。 Serialize：將 RPC 請(qǐng)求中的參數(shù),、結(jié)果等對(duì)象進(jìn)行序列化與反序列化，即進(jìn)行對(duì)象與字節(jié)流的互相轉(zhuǎn)換,；默認(rèn)使用對(duì) Java 更友好的 hessian2 進(jìn)行序列化,。 Transport：用來(lái)進(jìn)行遠(yuǎn)程通信，默認(rèn)使用 Netty nio 的 TCP 長(zhǎng)鏈接方式,。 Cluster: Client 端使用的模塊,，cluster 是一組可用的 Server 在邏輯上的封裝，包含若干可以提供 RPC 服務(wù)的 Server,，實(shí)際請(qǐng)求時(shí)會(huì)根據(jù)不同的高可用與負(fù)載均衡策略選擇一個(gè)可用的 Server 發(fā)起遠(yuǎn)程調(diào)用,。 在進(jìn)行 RPC 請(qǐng)求時(shí)，Client 通過(guò)代理機(jī)制調(diào)用 cluster 模塊,，cluster 根據(jù)配置的 HA 和 LoadBalance 選出一個(gè)可用的 Server,，通過(guò) serialize 模塊把 RPC 請(qǐng)求轉(zhuǎn)換為字節(jié)流，然后通過(guò) transport 模塊發(fā)送到 Server 端,。 Server 端的 transport 模塊收到數(shù)據(jù)后,，通過(guò) serialize 模塊還原成 RPC 請(qǐng)求，并通過(guò) protocol 層配置的參數(shù)找到具體提供服務(wù)的實(shí)現(xiàn)類,，通過(guò)反射進(jìn)行調(diào)用,。調(diào)用后的結(jié)果在通過(guò)類似的方式返回到 Client 端,，完成一次 RPC 請(qǐng)求。 Motan RPC 在混合云中新的需求和挑戰(zhàn)在混合云平臺(tái)建設(shè)過(guò)程中,，RPC 服務(wù)需要適應(yīng)云端部署,，在實(shí)際部署當(dāng)中對(duì) RPC 提出了一些新的要求?；旌显破脚_(tái)包括私有云與公有云兩部分,，其中私有云在本地機(jī)房，為了保證云與云之間通信的穩(wěn)定,，使用了專線的方式鏈接私有云與公有云,。RPC 服務(wù)在云端擴(kuò)容大致有如下三種情況：
在實(shí)際擴(kuò)容中會(huì)我們會(huì)盡量使用第三種方式進(jìn)行就近訪問(wèn)，但是有些情況下不可避免會(huì)產(chǎn)生第一二種情況,，例如需要單獨(dú)擴(kuò)容 RPC 服務(wù),，或者某些 RPC 服務(wù)依賴的資源暫時(shí)無(wú)法在公有云部署等。 在第一,、二種情況下,，會(huì)產(chǎn)生跨專線調(diào)用（圖中藍(lán)色虛線），為了能夠靈活控制 RPC 調(diào)用,，需要 RPC 支持跨機(jī)房調(diào)用的能力,，并且能夠控制跨機(jī)房調(diào)用的比例。 另外,，以前 RPC 都是通過(guò) group 配置來(lái)實(shí)現(xiàn)同機(jī)房調(diào)用,，實(shí)際使用當(dāng)中并不需要特別關(guān)注帶寬占用情況，但是在混合云環(huán)境中,，跨機(jī)房調(diào)用會(huì)占用專線帶寬,，因此，RPC 占用的帶寬也需要盡量節(jié)約,。 我們做了如下改進(jìn)： 流量壓縮 在微博中有兩種典型的 RPC 使用場(chǎng)景：一種是請(qǐng)求的參數(shù)和返回值都非常小,，但是請(qǐng)求量大，QPS 高,。例如微博的未讀數(shù) unread 服務(wù),。另一種場(chǎng)景是 QPS 不高，但每次返回值較大,。 針第一種場(chǎng)景,，我們對(duì)協(xié)議自身信息進(jìn)行了壓縮。Motan 的請(qǐng)求信息大致包括 4 個(gè)部分 header 信息,、Service 及請(qǐng)求方法描述,、參數(shù)值、附加信息。
一般情況下 Service 和方法描述,、附加信息等就有 200 多個(gè)字節(jié)，這樣在發(fā)送一個(gè)只有 long 型參數(shù)等請(qǐng)求時(shí),，協(xié)議的有效載荷就比較低,。壓縮的思路是使?方法簽名代替方法描述信息，并緩存?zhèn)鬏斨泄潭ǖ母郊有畔ⅰ?/p> RPC Server 提供的接口和方法是有限的,，只要能標(biāo)示出想要調(diào)用的方法及版本,，就不需要攜帶完整的方法信息。Server 端和 Client 端都把接口名,、方法名,、參數(shù)描述、版本信息生成 16 字節(jié)的簽名并把對(duì)應(yīng)關(guān)系進(jìn)行緩存,，這樣在每次請(qǐng)求時(shí)只需要攜帶 16 字節(jié)的簽名就能找到具體的調(diào)用方法,。 方法簽名需要在一個(gè) Server 內(nèi)唯一，所以不需要考慮全局碰撞,，只要對(duì)應(yīng) Server 中的方法簽名不產(chǎn)生碰撞沖突就可以,。按單個(gè) Server 中包含 10W 個(gè)方法估算，16 字節(jié)簽名產(chǎn)生沖突的概率?約為 1 / 2 * 10W * (10W - 1) * 1 / (2 ^ 128) 約為 1 / 2 ^ 99,，碰撞的概率可以忽略不計(jì),。當(dāng) Server 端新增方法出現(xiàn)碰撞時(shí)，可以通過(guò)修改?法名避免沖突,。 請(qǐng)求中的附加信息用來(lái)統(tǒng)計(jì)調(diào)用情況,，每個(gè) Client 在運(yùn)行中附加信息大部分是不會(huì)變動(dòng)的，因此如果 Server 端能夠緩存這些信息也就不需要每次請(qǐng)求都攜帶了,。 在 Client 首次調(diào)用服務(wù)時(shí),，會(huì)把固定的附加信息和對(duì)應(yīng)的附加信息簽名一起發(fā)送給 Server 端，Server 端收到請(qǐng)求后會(huì)以 IP 為維度緩存附加信息和簽名，然后返回值中會(huì)回傳對(duì)應(yīng)簽名作為應(yīng)答,。Client 收到應(yīng)答信息后再次請(qǐng)求時(shí)就只需傳遞簽名了,。當(dāng) Server 端因?yàn)橹貑⒌仍騺G失簽名對(duì)應(yīng)信息后，如果收到未知的簽名信息會(huì)要求 Client 下次請(qǐng)求攜帶完整附加信息,，這樣就能夠再次緩存對(duì)應(yīng)信息,。 對(duì)協(xié)議信息進(jìn)行壓縮后，一次只有一個(gè) long 參數(shù)的 RPC 請(qǐng)求從 280 字節(jié)減少到了 94 個(gè)字節(jié),。在實(shí)測(cè)場(chǎng)景下平均每個(gè)請(qǐng)求壓縮了 60%,，在 QPS 較高的場(chǎng)景中上行帶寬明顯減少。 針對(duì)另一種返回值較大的場(chǎng)景,，我們嘗試了不同的序列化協(xié)議,，如使用 Protocol Buffers 代替 hessian2，實(shí)際測(cè)試約減小 10％～15%,，效果不算理想,，當(dāng)使用 QuickLZ 或 GZIP 進(jìn)行壓縮后，根據(jù)原始大小不同壓縮后大約可以減少 30%～70％,，缺點(diǎn)就是 CPU 負(fù)載會(huì)有所增加,。 最后我們?cè)黾恿藟嚎s功能，業(yè)務(wù)方可以根據(jù)業(yè)務(wù)特點(diǎn)配置是否啟用壓縮以及啟用壓縮的最小閾值,。為了盡量減少第三方包依賴,，默認(rèn)使用 GZIP 進(jìn)行壓縮。實(shí)際測(cè)試在返回值 2KB～20KB 時(shí)壓縮會(huì)有比較好的效果,，大于 50KB 壓縮平均耗時(shí)就會(huì)比較高,。 壓縮統(tǒng)計(jì)數(shù)據(jù)如下： 動(dòng)態(tài)流量調(diào)整 Motan 中的 Service（即接口類）以 group 為單位劃分，group 一般由機(jī)房＋業(yè)務(wù)線組成,，一個(gè) group 下可以有多個(gè) Service,。例如 group 為 yf-user 表示永豐機(jī)房的 user RPC 服務(wù)，yf-user 的 Client 只會(huì)訂閱 yf-user 的 Server,，通過(guò) group 實(shí)現(xiàn)同機(jī)房就近訪問(wèn),。 要想控制 Client 的跨機(jī)房調(diào)用，實(shí)際上就是允許 Client 以一定比例進(jìn)行跨 group 調(diào)用,。因此從注冊(cè)中心或 Client 端自身都可以實(shí)現(xiàn)這個(gè)功能,，為了 Motan 框架在使用不同注冊(cè)中心時(shí)都能擁有流量控制的功能，我們選擇了在 Client 端實(shí)現(xiàn),。 我們?cè)O(shè)計(jì)了一套指令系統(tǒng),，這樣方便后續(xù)擴(kuò)展更多的管理功能，指令使用 JSON 格式保存在注冊(cè)中心,，當(dāng) Client 在訂閱 RPC 服務(wù)時(shí)同時(shí)也訂閱對(duì)應(yīng)的指令,。指令以 group 為單位存儲(chǔ),，即相同 group 的 Client 會(huì)接收到相同的指令。當(dāng)從管理后臺(tái)發(fā)布一條指令后,，對(duì)應(yīng)的 Client 會(huì)收到指令,，并且解析執(zhí)行指令。 單條指令的樣例如下： { ' index ' : 1, ' version ' : '1.0', ' dc ' : ' yf ', ' pattern ' : ' * ', ' mergeGroups ' : [ ' openapi-tc-test-RPC : 12 ', ' openapi-yf-test-RPC : 1 ' ] , ' routeRules ' : [], ' remark ' : ' 切換 50% 流量到另外一個(gè)機(jī)房 ' } 其中 mergeGroups 屬性用來(lái)實(shí)現(xiàn)跨機(jī)房調(diào)用設(shè)置,，可以設(shè)置多個(gè)機(jī)房以及各機(jī)房調(diào)用的權(quán)重,。跨機(jī)房調(diào)用過(guò)程如下圖所示： group1 和 group2 分別屬于兩個(gè)不同的機(jī)房,，提供相同的 Service,，Client1 和 Server1 屬于 group1，Client2 和 Server2 屬于 group2,。 正常情況下 Client 對(duì)Server 的調(diào)用是同 group 調(diào)用,，如圖中藍(lán)色箭頭所示,。 當(dāng) group1 的 Server 壓力突增時(shí),，通過(guò)管理后臺(tái) manager 在 registry 設(shè)置 group1 的 mergeGroup 指令為 ' mergeGroups ' : [ ' group1 : 5 ', ' group2 : 1 ' ] 這時(shí) group1 的 Client1 會(huì)收到指令并解析，根據(jù)指令 Client1 會(huì)同時(shí)訂閱 group1 和 group2,，并按 5 : 1 的比例同時(shí)訪問(wèn) group1 的 Server1 和 group2 的 Server2,，如圖中紅色虛線表示。 Client2 由于不屬于 group1,，所以并不會(huì)接收到這條指令,，仍然只訪問(wèn) Server2。 指令控制的粒度可以到接口類級(jí)別,，通過(guò) pattern 字段來(lái)進(jìn)行設(shè)置,。通過(guò)設(shè)置 group 的權(quán)重來(lái)控制流量切換的比例，最小比例可以到 1%,。 指令中的 routeRules 字段可以實(shí)現(xiàn)路由功能,，來(lái)精確控制調(diào)用，或者用來(lái)實(shí)現(xiàn)預(yù)覽等功能,。如： { ' index ' : 3, ' version ' : ' 1.0 ', ' dc ' : ' yf ', ' pattern ': ' com.weibo.xxxx.Preview ', ' mergeGroups ' : [], ' routeRules ' : [ ' * to !10.75.0.1 ' ], ' remark ' : ' 預(yù)覽某臺(tái)機(jī)器,，關(guān)閉其線上流量 ' } routeRules 中的每條 rule 表示 from to 的關(guān)系， ' * to !10.75.0.1 ” 這條 rule 表示禁止訪問(wèn)預(yù)覽機(jī) 10.75.0.1,。 rule 規(guī)則支持通配符,，如 “ 10.75.0.＊ to 10.75.0.1 ” 表示 10.75.0 段的所有 Client 只能請(qǐng)求 10.75.0.1 這臺(tái) Server。 其他優(yōu)化 在 RPC 調(diào)用中還有一些小的細(xì)節(jié),，例如,，Server 端業(yè)務(wù)異常時(shí)會(huì)把異常棧序列化并傳遞到 Client，一個(gè)異常?？赡軙?huì)有 1- 2k 的大小,，如果 RPC 調(diào)用中異常大量增加，也會(huì)占用不小帶寬?？紤]到大部分場(chǎng)景 Client 端只關(guān)心異常原因,，并不關(guān)心異常棧內(nèi)容，我們對(duì)業(yè)務(wù)異常時(shí)的異常棧進(jìn)行了替換,，避免傳輸不必要的棧信息,。 此外還對(duì) RPC 服務(wù)的注冊(cè)與注銷機(jī)制進(jìn)行了一些調(diào)整，并支持了使用 consul 作為注冊(cè)中心,。使 RPC 服務(wù)在混合云的部署能夠更加靈活,。 后記Motan RPC 框架在微博平臺(tái)的各個(gè)業(yè)務(wù)中發(fā)揮著重要作用，通過(guò)在微博將近三年的線上運(yùn)行考驗(yàn),，正在變的越來(lái)越優(yōu)秀,，功能也更加完善。Motan 的設(shè)計(jì)理念是簡(jiǎn)單,、易用,，前輩大師們?cè)谠O(shè)計(jì) Motan 框架時(shí)就朝著這個(gè)方向努力，后續(xù)也將向這個(gè)方向繼續(xù)發(fā)展,。 如何打造更為易用的高性能 RPC 框架,？我覺(jué)得除了與時(shí)俱進(jìn)的實(shí)現(xiàn)新的需求，更需要從細(xì)節(jié)上考慮框架的易用性,，例如新功能的無(wú)縫升級(jí),、盡量降低業(yè)務(wù)方的接入成本、增加必要的切換開(kāi)關(guān)提高靈活性,，后臺(tái)指令預(yù)覽防止誤操作等,，從每個(gè)細(xì)節(jié)完善 Motan 框架。 近期我們打算對(duì) Motan 框架進(jìn)行全面梳理,，去掉特定的依賴,，使用更通用的方式來(lái)實(shí)現(xiàn)，并完善配套的文檔,。開(kāi)源,，是 Motan 設(shè)計(jì)之初的方向之一，我們要把 Motan 打造成一個(gè)更易用的高性能 RPC 開(kāi)源框架,。歡迎大家一起參與,。 Q & A1、Motan 是否開(kāi)源,？現(xiàn)在能下載代碼不,？ 我們正在進(jìn)行梳理，近期準(zhǔn)備開(kāi)源核心部分,。 2,、支持 PHP 等跨語(yǔ)言調(diào)用嗎,？ 目前 Motan 還不支持 PHP 等其他語(yǔ)言調(diào)用，我們正在進(jìn)行這方面工作,，已經(jīng)在小范圍測(cè)試,。 3、圖里的耗時(shí)是壓縮耗時(shí)么,？ 圖里的耗時(shí)是單次壓縮耗時(shí)均值,。 4、從零開(kāi)始實(shí)現(xiàn)一個(gè) RPC,，一般需要考慮實(shí)現(xiàn)哪些東西,，大致思路是什么？ 簡(jiǎn)單的 RPC 調(diào)用只需要考慮協(xié)議（方法描述）,、序列化（參數(shù)值傳遞）,、傳輸（TCP、HTTP 等） 5,、Motan 支持異步調(diào)用嗎,？如何實(shí)現(xiàn)？Load balance 支持哪些策略,？是否支持自定義策略,？ Motan 的請(qǐng)求在傳輸層面都是異步調(diào)用的,，但是在使用本地引用時(shí)不能顯示異步執(zhí)行,。Load balance 策略支持低并發(fā)優(yōu)先、一致性 hash,、隨機(jī),、輪詢。支持通過(guò) SPI 機(jī)制擴(kuò)展其他策略,。 6,、感覺(jué)和 Dubbo 好像好像，里面的序列化協(xié)議,，通信協(xié)議,，框架模塊定義，架構(gòu)分層,，服務(wù)分組都一樣一樣的,，命令行改配置好像也不方便，Dubbo 的管理界面很方便,，相比 Dubbo 具體怎么輕量,？Dubbo 用起來(lái)好像也只要一個(gè)注冊(cè)中心就可以了。 與 Dubbo 的分層來(lái)對(duì)比,，Motan 的模塊層次要更簡(jiǎn)單一些,，沒(méi)有 exchange 和 directory 等,，Motan 提供了一些 SLA 策略，例如并發(fā)限制等,。 7,、如果設(shè)計(jì)監(jiān)控的話一般涉及到那些指標(biāo)，如何快速發(fā)現(xiàn)服務(wù)出現(xiàn)問(wèn)題,？ 一般通過(guò)監(jiān)控統(tǒng)計(jì)日志中的耗時(shí),、框架異常、業(yè)務(wù)異常數(shù)量,，來(lái)發(fā)現(xiàn)服務(wù)問(wèn)題 RPC 的調(diào)用情況是在內(nèi)存中通過(guò) Metric 進(jìn)行統(tǒng)計(jì)的,，然后統(tǒng)一輸出到統(tǒng)計(jì)日志中。 8,、重新實(shí)現(xiàn)了一套 Dubbo 是出于什么樣的考慮,，或者說(shuō)業(yè)務(wù)上 Dubbo 無(wú)法解決哪方面的需求？ Dubbo 功能上比較豐富,，但當(dāng)時(shí)我們想要一個(gè)比較輕量的 RPC 框架,，方便我們做一些適合自己業(yè)務(wù)場(chǎng)景的改造和功能 feature，以達(dá)到內(nèi)部業(yè)務(wù)平滑改造和遷移的目的,。這種情況下,，在 dubbo 上改的成本可能比重新寫(xiě)一套更高。最終我們決定開(kāi)發(fā) motan RPC,。從另外角度,，選擇復(fù)用和選擇自行開(kāi)發(fā)需要看團(tuán)隊(duì)的研發(fā)能力與資源，我們當(dāng)時(shí)剛好有合適的工程師有興趣來(lái)做這個(gè),。 9,、Motan 支持功能擴(kuò)展嗎,？ 支持通過(guò) SPI 方式進(jìn)行擴(kuò)展 10、Registry 如何保證高可用？Server 與 Registry 是雙向心跳還是單向,？或者說(shuō)如何保證 Server 上下線狀態(tài)及時(shí)感知,？ Registry 自身需要較強(qiáng)的容災(zāi)來(lái)保證高可用,，例如 ZK,、Consul 都支持很強(qiáng)的容災(zāi)。另外,，當(dāng) Registry 不幸各個(gè)節(jié)點(diǎn)都掛掉的話,，會(huì)影響服務(wù)的發(fā)布與注銷，不會(huì)影響 Client 的正常調(diào)用,。Server 與 Registry 是單向心跳,。Server 上下線 Client感知有可能會(huì)有延遲，一般都是秒級(jí),。 12,、一致性hash的負(fù)載策略能具體講一下嗎,？ 根據(jù)請(qǐng)求 Request 參數(shù)計(jì)算出一個(gè) hashcode，按 hashcode 每次請(qǐng)求同一個(gè) server,。一致性 hash 的策略主要用于有狀態(tài)的RPC服務(wù)場(chǎng)景,，比如有session的IM服務(wù)等。 微博技術(shù)團(tuán)隊(duì)在高可用架構(gòu)分享的部分文章 高可用架構(gòu)新年聚會(huì)暨架構(gòu)開(kāi)源研討會(huì)的部分報(bào)道及演講 本文策劃李慶豐,，編輯王杰，審校 Tim Yang,，想討論 RPC 及微服務(wù)架構(gòu),，請(qǐng)關(guān)注公眾號(hào)獲取進(jìn)群機(jī)會(huì)。轉(zhuǎn)載請(qǐng)注明來(lái)自高可用架構(gòu) 「ArchNotes」微信公眾號(hào)及包含以下二維碼,。
|
|
|
來(lái)自： ycwu314 > 《架構(gòu)設(shè)計(jì)》
