- gPRC 介绍
- gPRC 介绍 - 资料收集整理
- gPRC 介绍 - Protocol Buffer 3
- gPRC文档
- gPRC文档 - gRPC官方文档(中文版)
- gPRC文档 - gRPC动机和设计原则
- gPRC文档 - 源码导航
- 基础 - NameResolver
- NameResolver - URI术语
- NameResolver - 类NameResolver
- NameResolver - 类DnsNameResolver
- NameResolver - 类DirectAddressNameResolver
- NameResolver - NameResolver的用法
- 基础 - Metadata
- Channel层
- Channel设计与代码实现 - 类Channel
- Channel设计与代码实现 - 类ManagedChannel
- 类ManagedChannelImpl - 空闲模式
- 类ManagedChannelImpl - InUseStateAggregator
- 类ManagedChannelImpl - Name Resolver
- 类ManagedChannelImpl - Load Balancer
- 类ManagedChannelImpl - Transport
- 类ManagedChannelImpl - Executor
- 类ManagedChannelImpl - 关闭
- Channel层 - Channel Builder设计与代码实现
- Channel Builder设计与代码实现 - 类ManagedChannelBuilder
- Channel Builder设计与代码实现 - 类AbstractManagedChannelImplBuilder
- Channel Builder设计与代码实现 - 类NettyChannelBuilder
- Channel层 - Channel Provider设计与代码实现
- Channel Provider设计与代码实现 - 类ManagedChannelProvider
- Channel Provider设计与代码实现 - 类NettyChannelProvider
- Channel层 - 类CallOptions
- Stub层 - 类DemoServiceBlockingStub
- Stub层 - 类AbstractStub
- 客户端流程
- 状态 - 类Status
- 状态 - 状态码详细定义
- 状态 - 类StatusException
- 状态 - 异常处理的流程分析
- 实践 - 集成Spring Boot
- 实践 - 文档生成
- 文档生成 - 支持proto3
- 文档生成 - build插件
- 文档生成 - 使用模板定制输出
- 实践 - 代理
- 实践 - 超时
gPRC文档 - gRPC动机和设计原则
注: 官网文档 gRPC Motivation and Design Principles, 我原来自己写了一份简单的读书笔记,后来发现有同学全文翻译了这篇文章,就放弃了自己的内容直接转载了.
文档地址
- gRPC Motivation and Design Principles:英文原文
- GRPC的产生动机和设计原则: 此文的中文翻译版本
读后感
注:以下是个人的一点感触
2015年3月的某一天,第一次接触gRPC,当时的第一感觉: 这就是我要的东东!!
上面的这个文档中,在阐述”原则和诉求”时,有几点是特别打动我的:
服务而非对象、消息而非引用
促进微服务的系统间粗粒度消息交互设计理念,同时避免分布式对象的陷阱和分布式计算的谬误。
2015年初,当时正在理解和接受微服务的理念,发现gRPC在理念上特别符合微服务的想法。后来看gRPC文档时看到上面这句,才知道原来gRPC的设计理念本来就是冲着微服务去的……
在这之后的一年中,我心目中完美的服务化框架慢慢的形成了,基石就是:微服务 + gRPC。
普遍并且简单
该基础框架应该在任何流行的开发平台上适用,并且易于被个人在自己的平台上构建。它在CPU和内存有限的设备上也应该切实可行。
“在CPU和内存有限的设备”,对我而言就是移动设备了,尤其特指手机和平板。2015年初在唯品会,遇到手机App端和服务器端通讯的方案选择问题,当时我特别想把手机App端和服务器端这块的通讯机制整合入唯品会的服务化框架,但是因种种原因未能如愿,深以为憾。
当时有一个非常强烈的诉求,就是在如今的移动互联网时代,PC没落手机泛滥,如何可以实施一个服务化框架而无视移动端的需求?
之后就一直在gRPC和Rest之间摇摆,但是我对这两个方案的共同要求,都是可以一套方案打通app到服务器和服务器之间的通讯机制。
2016年,在PPMoney,很有幸,基于gRPC的微服务框架得以开发并实施。
流
存储系统依赖于流和流控来传递大数据集。像语音转文本或股票代码等其它服务,依靠流表达时间相关的消息序列。
虽说目前面对的直接需求中,对流的要求不多,乃至几乎没有。但是我依然看好这个思路,gRPC在框架层次上直接提供对流的支持,想法很好很对路。
元数据交换
常见的横切关注点,如认证或跟踪,依赖数据交换,但这不是服务公共接口中的一部分。部署依赖于他们将这些特性以不同速度演进到服务暴露的个别API的能力。
之前都是想办法自己来生成/传输和利用元数据,如今终于gRPC直接提供。还有什幺好说,用,用,用!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论