目前市面上可能兼容 gRPC 接口的接口调试与管理工具非常无限，而 gRPC 现已广泛应用于微服务架构中，并且能够预感的是，它会变得越来越风行。
作为业界当先的接口管理工具，Apifox 现已上线 gRPC 接口调试能力，全面兼容以下四种调用类型：
- Unary：一元调用
- Server Streaming：服务端流
- Client Streming：客户端流
- Bidirectional Streaming：双向流
兴许你对 gRPC 接口还不太熟悉，那么咱们无妨先来简略理解一下！
什么是 gRPC？
gRPC 是一个由谷歌开发的古代开源高性能 RPC 近程过程调用 （Remote Procedure Calls） 框架，具备良好的兼容性，可在多个开发环境下运行。
gRPC 的利用场景
相较于目前支流的 HTTP API 接口，gRPC 接口采纳了 当先的 HTTP/2 底层架构设计作为底层传输协定，可能在大规模数据传输场景（例如视频流传输）和大量服务互相调用的微服务架构场景下大展身手。
数据交换采纳轻量化的 Protobuf 序列化协定，使得它可能在资源受限场景（常见于手机等挪动端设施）提供更快的数据处理速度的同时，缩小网络传输的数据量并节俭网络带宽，从而降低功耗并晋升电池寿命。
在正式开始介绍 gRPC 之前，咱们无妨先弄清楚到底什么是 RPC 以及它的作用，这对于后续的了解非常有帮忙。
什么是 RPC？
RPC 协定是一种 近程过程调用的实现形式。假如当初有两台服务器 A 和 B。部署在 A 服务器上的服务，想调用正在 B 服务器上运行的另一个过程。但因为单方服务并不在一个内存空间而导致无奈间接调用，那么就必须通过网络通讯来达到调用成果。
要建设网络通讯无非是在传输层发动 TCP 连贯。TCP 的握手机制确保了数据包能牢靠地传输给对方，并且它具备以下三个特点：面向连贯、牢靠、基于字节流 。后面两种个性都能够胜任这个场景，但唯独在 基于字节流 这一点恐怕值得商讨。为什么？
因为 它没有边界。字节流实质上是在传输层双向通道中流淌的数据，也就是计算机可能了解的二进制 0 1 数据。所以当发送端应用 TCP 发送“南京市”+“长江大桥”字符时，接收端有可能收到的就是“南京市长”+“江大桥”，也有可能是“南京市长江大桥”等。
过于简略的 TCP 连贯过程无奈保障信息的唯一性和确定性，因而才须要在数据中定义 音讯头、音讯体 ，并且发送方与接管方独特认可这套沟通形式，由此衍生出了 HTTP 协定和 RPC 调用等计划， 它们实质上都是对数据的传递和调用形式作出了规范化定义，避免出现信息失真。
例如当初有一个购物网站，存在 订单服务 与用户服务（例如账号治理） 两项微服务。订单服务须要查问到用户服务下的一些数据，然而两者相隔离。此时订单服务就必须通过近程调用的形式获取数据。
下图的示例中，服务端（用户服务） 仅需暴露出一个可能调用数据库的 getConsumerByld() 函数，客户端（订单服务） 应用 RPC 便可能像在本地中间接调用 getConsumerByld() 函数并获取到所需的响应后果。RPC 胜利暗藏了外部通信的复杂性，为单方提供了稳固对立的接口，使得开发者只须要关注业务逻辑，而无需关注底层网络通信细节。
而 gRPC 实质上就是一种由 谷歌公布并开源的 RPC 框架。
gRPC 的劣势有哪些?
先进的传输协定
HTTP/2 在 2015 年稍早于 gRPC 公布，因而 gRPC 很天然的将这一先进的传输协定作为底层根底，从而使得它具备更高效的传输性能，并且还可能反对流式调用，为许多实时数据传输场景（例如股票数据、语音通信、游戏场景）提供反对，人造当先许多在千禧年之际公布的古早 RPC 框架。发动连贯时会建设连接池，面对多条连贯时可能显著晋升网络申请性能。
迷信的设计理念
同时 gRPC 采纳了体积更小的 Protobuf 序列化协定保留构造体数据。Protocol Buffers 是一种跨语言、跨平台的数据结构序列化协定。相比 JSON 或 XML 协定，它更加轻量级，因而在传输数据时更加高效。
同时这也决定了 gRPC 接口必然遵循 API First 理念，因为在开发工作开始前就须要在文件中定义服务接口，蕴含客户端如何应用服务、调用时所需传递的参数。gRPC 接口能够依据已定义的 .proto 文件主动生成客户端和服务端的通信形式，大大简化了开发过程。
良好的兼容性
gRPC 不依赖于任何特定的技术或语言栈，因而能够被宽泛地利用到不同的开发环境之中。它反对多种编程语言，包含 Java、C++、Python、Go 等古代风行的编程语言。它能够在轻松地不同语言之间进行通信，这为多语言的微服务架构提供了无力反对。
尽管 gRPC 有着许多劣势，然而大部分内部使用者对于 HTTP 接口更加相熟（这也导致了 gRPC 的生态凋敝度并不如 REST/HTTP 协定），因而 gRPC 次要的利用场景是团队外部微服务间的通信与连贯，并不适宜将服务公开至内部应用 。并且若想要胜利调用 gRPC，还可能波及到外部零碎的参数传递过程。另一个比拟大的毛病便是 浏览器并不反对 gRPC 服务调用，须要借助扩大或业余的接口调用工具（比如说 Apifox）能力进行接口合作。
Apifox gRPC 接口调试性能
Apifox 目前已上线 gRPC 接口调试性能，咱们将通过一个示例场景简要演示如何在 Apifox 中新建 gRPC 我的项目并针对接口发动调试。
留神：gRPC 接口治理性能要求 Apifox 版本号 大于等于 2.3.0。
在 Apifox 中点击「新建我的项目」按钮，抉择 gRPC 类型，填写项目名称后轻点「新建」按钮。
导入定义 gRPC 接口所应用的服务、办法和音讯的 .proto 文件。你能够将文件拖拽至其中或应用文件在线 URL 实现导入。
Apifox 将基于 .proto 文件内容生成对应的接口信息。示例接口中自带了一元调用、服务端流、客户端流和双向流四种调用办法。
发动一元调用
一元调用指的是在一个申请中发送一个音讯，并接管一个音讯作为响应。相较于 JSON，gRPC 应用 Protocol Buffers（ProtoBuf）作为默认的序列化框架，能够更加紧凑地表述数据，晋升传输速度。且 gRPC 应用 HTTP/2 作为底层传输协定，间接利用 HPACK 压缩算法对 Header 中的信息进行解决，在网络传输中缩小了头部的大小，从而节俭了带宽资源。这对于传输小型数据或须要实时响应的场景非常敌对。\
抉择 SayHello 办法，在接口地址中填写 grpcb.in:9000。而后点击「主动生成」按钮生成申请体，轻点「调用」即可查看返回响应。
在 Apifox 中，你能够十分便捷地将接口地址提取至「环境」，以便团队内的其它成员或我的项目中的其它接口发动调用申请。
发动流式调用
服务端流、客户端流和双向流都被被称为流式调用。它容许客户端和服务器之间建设一个长久的双工流式连贯，并通过流式传输来进行数据的读取和写入。流式调用的次要特点是能够在一个连贯上发送和接管多个音讯，反对继续交互和大规模数据传输，罕用于交易所股票数据、视频语音通信与在线游戏场景。
服务端流
正如同它在图标中所示意的意思一样，服务端流示意：一次发送，返回多个响应数据。例如订阅一分钟之内的所有股票的成交价格数据。
客户端流
在这种模式下，客户端能够间断地发送多个申请音讯给服务器，而不须要期待服务器的立刻响应。发动调用后，你能够继续在 Message 中继续填写申请信息，而后点击“发送”按钮。服务器在解决完所有申请后，发送一个独自的响应音讯给客户端。
双向流
双向流容许客户端和服务器之间建设长久的双向通信，并能够同时传输多个音讯。常见于在线游戏与实时视频通话软件，实用于实时通信和大规模数据传输场景。发动调用后客户端与服务端之间将持续保持会话，发送不同的申请内容后实时取得响应。
gRPC 接口合作
Apifox 可能基于 .proto 文件渲染出更适宜人类浏览的 gRPC 接口文档，使得接口更容易在团队中进行合作。你能够点击接口右侧的菜单按钮获取合作链接，将它分享给其它团队成员对齐接口的调试办法。
Apifox 的 gRPC 接口调试性能正 处于 Beta 公开测试阶段，目前的性能只是咱们迈出的第一步，后续也会继续迭代更新。Apifox 作为 API 一体化合作平台，心愿为不同的 API 技术提供同样优良的体验。