最近经常听到的一个缩写：grpc，但是这个次对于一个前端或者没太接触过微服务的同学来说，可能还是比较陌生。 在这分享一下作者对 grpc 从一无所知到逐渐有点印象的过程。
什么是 grpc
Google 家的 PRC 框架，RPC(Remote Procedure Call),即远程过程调用。程序可以像调用本地函数一样调用另一个服务上的函数。但这不是重点。
疑惑
通过描述，从前端开发者的视角看来，调用 REST 风格的 API 也能实现同样的功能，为什么还要使用 RPC 来实现呢？
解惑
通过查阅资料发现，从阅读角度看，RPC 可以理解为是不同于 REST 的另一种风格，但两者也有近似之处。 笔者平时开发时，会事先约定好接口文档，然后再将 Swagger 转换成 Typescript API。grpc 会有 proto 文件(注意：这里的 proto 是 protocol 协议的简写，并不是 proto 原始、原型的意思。前端小伙伴因为熟悉 js 中的 prototype，很容易误解 grpc 中的 proto，导致理解上的蒙圈)，实现的大致功能是函数的定义，传参和返回值这些功能。使用的时候会根据 proto 文件的定义，转换成不同语言使用的函数。
姑且粗浅的理解为接口定义。一个是 Swagger，一个是 proto。
One More Thing
阅读了一些参考资料，发现微服务偏向使用 grpc 而不是 REST，主要是考虑到更好的性能（gprc 用二进制，REST 一般使用 JSON）和数据的流式处理。 流式处理使得不需要像 JSON 一样先拿到所有数据才能进行下一步，而是只获得一部分即可先行继续。对于流式处理，还没有太多的理解。暂时只能点到为止。
以上