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

傳統模塊化編程被視為應用的功能元素的創建“過程”，因此過程調用就成為了連接它們進入單一結構的機制。一旦有必要把組件跨網絡隔離開來時，合理的步驟就是遠程過程調用（RPC）。把API跟微服務關聯起來是合理的，我們應該看看另一種解決方案：Google的gRPC。

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

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

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

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

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

Google等做微服務的經驗（這種經驗讓gRPC及其標準化行動不斷壯大）說明了微服務會從被設計為由模塊化過程構成的同構應用中受益。這跟一般需要事先考慮邏輯組件化，API是針對工作流的特定模塊配對的多組件、網絡耦合設計做法是不一樣的。在微服務中應用這個是困難的，因為可能會很難構思最合適的微服務結構。

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

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

其次，一切微服務都會有一個store-front或strip-mall結構，保證這個結構不能太深這一點至關重要，因為微服務會通過gRPC調用其他微服務。這類工作流級聯幾乎總是會產生性能問題，并且使得應用更容易受到網絡故障的影響。

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

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