随着计算方法的改变，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例子已经做出了工具并树立了意识，但是它的实践和方向可以帮助开发者从自身的云微服务中收获最多的东西。