搜索歷史

熱搜詞

原創(chuàng)

活動

創(chuàng)新2.0

I T

產(chǎn)業(yè)

當(dāng)前位置：首頁 >互聯(lián)網(wǎng)?IT > 服務(wù)器 > 微服務(wù) > 正文

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

來源：TechTarget中國：Tom Nolle 2015-09-29 10:57:59

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

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

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

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

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

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

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

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

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

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

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

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

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

編輯：閆春春

關(guān)鍵字：微服務(wù)