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直接提供。还有什么好说,用,用,用!