隨著計(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ù)中收獲最多的東西。