微服務(wù)模塊化編程接口之反思

責(zé)任編輯:editor006

作者:Tom Nolle

2015-09-28 14:20:24

摘自:TechTarget中國

隨著計(jì)算方法的改變,IT需要反思模塊化編程。傳統(tǒng)模塊化編程被視為應(yīng)用的功能元素的創(chuàng)建“過程”,因此過程調(diào)用就成為了連接它們進(jìn)入單一結(jié)構(gòu)的機(jī)制。

隨著計(jì)算方法的改變,IT需要反思模塊化編程。Tom Nolle檢查了Google的gRPC以便確定它是否有益。

傳統(tǒng)模塊化編程被視為應(yīng)用的功能元素的創(chuàng)建“過程”,因此過程調(diào)用就成為了連接它們進(jìn)入單一結(jié)構(gòu)的機(jī)制。一旦有必要把組件跨網(wǎng)絡(luò)隔離開來時(shí),合理的步驟就是遠(yuǎn)程過程調(diào)用(RPC)。把API跟微服務(wù)關(guān)聯(lián)起來是合理的,我們應(yīng)該看看另一種解決方案:Google的gRPC。

基于RPC的API跟那些基于Web事務(wù)的前端過程多少有點(diǎn)不同。這些API,可以是簡單的RES/HTTP或者JSON接口,往往將有限的信息元素通過顯示表格傳遞出去。即便是像M2M這樣的應(yīng)用或則手機(jī)、平板信用卡處理也可以從二進(jìn)制數(shù)據(jù)交換中受益,而二進(jìn)制數(shù)據(jù)是服務(wù)器對(duì)服務(wù)器連接(包括微服務(wù)與其“存儲(chǔ)前端(store front)”的連接)的標(biāo)準(zhǔn),。RPC API往往會(huì)傳遞二進(jìn)制數(shù)據(jù)和復(fù)雜結(jié)構(gòu),若干業(yè)界玩家開始致力于一個(gè)兼容HTTP的RPC模型。然而,Google的gRPC似乎成為了新興標(biāo)準(zhǔn)。

遠(yuǎn)程過程調(diào)用幾乎一直是微事務(wù)的一種。這種情況下,過程會(huì)帶有特定的一組參數(shù),會(huì)返回特定結(jié)果。Google的gRPC利用了部分開發(fā)者比較熟悉的一個(gè)概念:協(xié)議緩沖。這個(gè)術(shù)語描述了同時(shí)就數(shù)據(jù)結(jié)構(gòu)和內(nèi)容進(jìn)行通信的一種跨網(wǎng)絡(luò)連接的快捷方式。“序列化”這個(gè)詞會(huì)經(jīng)常用到;其意思是協(xié)議緩沖會(huì)把二進(jìn)制數(shù)據(jù)當(dāng)作一種結(jié)構(gòu),然后把它轉(zhuǎn)化為一系列的字位流,這種流會(huì)在另一端重組為結(jié)構(gòu)。XML提供了類似的部分能力,但是協(xié)議緩沖卻比XML要快100倍,且流的編碼和解碼實(shí)現(xiàn)往往只需要1/10。

對(duì)于開發(fā)者來說,gRPC關(guān)鍵的是讓他們可以編寫這樣的應(yīng)用或組件,使得所有的代碼看起來好像都是一個(gè)地方一樣—即一體式的開發(fā)。開發(fā)者還可以根據(jù)需要把一部分功能從主組件中抽離出來,讓背后的gRPC stub表示現(xiàn)在是遠(yuǎn)程的部分。網(wǎng)絡(luò)連接和協(xié)議緩沖然后會(huì)將對(duì)該功能的請(qǐng)求通過網(wǎng)絡(luò)傳送給它,不管這個(gè)功能是在哪里的,再返回響應(yīng)。而應(yīng)用的其他部分仍然看到的是熟悉的本地組件—只不過現(xiàn)在是gRPC stub。

對(duì)于要開發(fā)面向網(wǎng)絡(luò)連接的應(yīng)用來說,gRPC仍然有好處。它的機(jī)制是獨(dú)立于語言的,且gRPC stub以及服務(wù)器邏輯庫所有流行編程語言都能訪問。單個(gè)應(yīng)用可以用一組語言來開發(fā),而gRPC充當(dāng)了粘合劑的作用,把不同的部分揉成一個(gè)應(yīng)用。

基本上看采用gRPC是很容易的;寫服務(wù)器或客戶端組件的時(shí)候把gRPC元素吸收進(jìn)來就行了,而API則按照查詢-響應(yīng)的模式組織就行了。與面向Web的get/post功能相比,這一過程更類似于傳統(tǒng)的模塊化編程,但是它又更加靈活,很適應(yīng)微服務(wù)的模式(gRPC的“客戶端”是主要的店面組件,而“服務(wù)器”就是微服務(wù))。前者獲得gRPC stub,后者獲得遠(yuǎn)程實(shí)現(xiàn)。

Google等做微服務(wù)的經(jīng)驗(yàn)(這種經(jīng)驗(yàn)讓gRPC及其標(biāo)準(zhǔn)化行動(dòng)不斷壯大)說明了微服務(wù)會(huì)從被設(shè)計(jì)為由模塊化過程構(gòu)成的同構(gòu)應(yīng)用中受益。這跟一般需要事先考慮邏輯組件化,API是針對(duì)工作流的特定模塊配對(duì)的多組件、網(wǎng)絡(luò)耦合設(shè)計(jì)做法是不一樣的。在微服務(wù)中應(yīng)用這個(gè)是困難的,因?yàn)榭赡軙?huì)很難構(gòu)思最合適的微服務(wù)結(jié)構(gòu)。

有了gRPC,如果認(rèn)為剝離對(duì)于改進(jìn)可用性或性能有幫助的話,開發(fā)者可以把微服務(wù)從應(yīng)用或組件中剝離出來,或者分配一個(gè)模塊給一個(gè)使用不同語言的不同的編程團(tuán)隊(duì)—如果需要加快實(shí)現(xiàn)速度的話。預(yù)留這一能力對(duì)于微服務(wù)的過渡非常重要,準(zhǔn)備好后只需幾步就能確保過渡完成。

首先,要記住gRPC是從RPC演變過來的,這意味著功能預(yù)期是本地的時(shí)候可以用它。如果遠(yuǎn)程連接組件的特定結(jié)構(gòu)設(shè)計(jì)進(jìn)應(yīng)用當(dāng)中時(shí),可能就會(huì)限制了微服務(wù)使用的靈活性。應(yīng)用設(shè)計(jì)要簡化,把它們當(dāng)作一組本地過程的集合來考慮,如果復(fù)雜性太高無法這么處理,則把應(yīng)用按照工作流(前端、編輯/處理,更新)分離出來,這樣轉(zhuǎn)成微服務(wù)會(huì)容易些。

其次,一切微服務(wù)都會(huì)有一個(gè)store-front或strip-mall結(jié)構(gòu),保證這個(gè)結(jié)構(gòu)不能太深這一點(diǎn)至關(guān)重要,因?yàn)槲⒎?wù)會(huì)通過gRPC調(diào)用其他微服務(wù)。這類工作流級(jí)聯(lián)幾乎總是會(huì)產(chǎn)生性能問題,并且使得應(yīng)用更容易受到網(wǎng)絡(luò)故障的影響。

第三點(diǎn),盡管gRPC很高效,但也不是一點(diǎn)負(fù)載都沒有。即便通信連接是本地的、快速的,許多的消息序列化也會(huì)影響到應(yīng)用性能。有了gRPC機(jī)制之后,把本地過程轉(zhuǎn)為遠(yuǎn)程會(huì)容易些,很容易就會(huì)把組件化應(yīng)用編程獨(dú)立服務(wù)的做法做得過火。

微服務(wù)創(chuàng)建了應(yīng)用的服務(wù)器端或“內(nèi)部”工作流—這種工作流最好是結(jié)合不同或不那么多的Web連接式的API模式一起用。Google的gRPC例子已經(jīng)做出了工具并樹立了意識(shí),但是它的實(shí)踐和方向可以幫助開發(fā)者從自身的云微服務(wù)中收獲最多的東西。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號(hào)-6京公網(wǎng)安備 11010502049343號(hào)