gRPC动机和设计原则

注: 官网文档 gRPC Motivation and Design Principles, 我原来自己写了一份简单的读书笔记，后来发现有同学全文翻译了这篇文章，就放弃了自己的内容直接转载了.

文档地址

读后感

注：以下是个人的一点感触

2015年3月的某一天，第一次接触gRPC，当时的第一感觉： 这就是我要的东东！！

上面的这个文档中，在阐述”原则和诉求”时，有几点是特别打动我的：

服务而非对象、消息而非引用

促进微服务的系统间粗粒度消息交互设计理念，同时避免分布式对象的陷阱和分布式计算的谬误。

2015年初，当时正在理解和接受微服务的理念，发现gRPC在理念上特别符合微服务的想法。后来看gRPC文档时看到上面这句，才知道原来gRPC的设计理念本来就是冲着微服务去的……

在这之后的一年中，我心目中完美的服务化框架慢慢的形成了，基石就是：微服务 + gRPC。

普遍并且简单

该基础框架应该在任何流行的开发平台上适用，并且易于被个人在自己的平台上构建。它在CPU和内存有限的设备上也应该切实可行。

“在CPU和内存有限的设备”,对我而言就是移动设备了，尤其特指手机和平板。2015年初在唯品会，遇到手机App端和服务器端通讯的方案选择问题，当时我特别想把手机App端和服务器端这块的通讯机制整合入唯品会的服务化框架，但是因种种原因未能如愿，深以为憾。

当时有一个非常强烈的诉求，就是在如今的移动互联网时代，PC没落手机泛滥，如何可以实施一个服务化框架而无视移动端的需求？

之后就一直在gRPC和Rest之间摇摆，但是我对这两个方案的共同要求，都是可以一套方案打通app到服务器和服务器之间的通讯机制。

2016年，在PPMoney，很有幸，基于gRPC的微服务框架得以开发并实施。

流

存储系统依赖于流和流控来传递大数据集。像语音转文本或股票代码等其它服务，依靠流表达时间相关的消息序列。

虽说目前面对的直接需求中，对流的要求不多，乃至几乎没有。但是我依然看好这个思路，gRPC在框架层次上直接提供对流的支持，想法很好很对路。

元数据交换

常见的横切关注点，如认证或跟踪，依赖数据交换，但这不是服务公共接口中的一部分。部署依赖于他们将这些特性以不同速度演进到服务暴露的个别API的能力。

之前都是想办法自己来生成/传输和利用元数据，如今终于gRPC直接提供。还有什么好说，用，用，用！