gRPC,云原生应用开发的水煤电

共 1784字,需浏览 4分钟

 ·

2021-03-01 10:42


微服务和云原生架构越来越火热的今天,服务之间通信的能力越来越显得重要。这其中最常见 HTTP(RESTFul) 和 RPC 这两种通信风格。

比如 Spring Cloud 技术栈常见的服务间调用是通过 HTTP(RESTFul)风格,另外的一些 Java 技术栈中也常见通过  RPC 进行服务间调用的,比如常用到的 Dubbo。


RPC 是什么?做 Java 服务开发的同学可能都能说几句。因为这几年 Dubbo 的普及,大家对 「注册中心」, 「Provider」 和 「Consumer」 这几个词都耳熟能详。

那说到底, RPC 是要干啥?

不是两个服务之间互相调用吗?

RPC 全称是 Remote Procedure Call,  也称为远程过程调用,通过 RPC 我们可以像调用本地方法一样远程调用某个方法。这个「远程的方法」可能部署在不同的机器,使用不同的开发语言开发等等。

确切的说,RPC 是解决进程间通信的技术。部署在同一台机器上的多个进程,实际是远程的一种情况。Dubbo 在 Java 应用中的使用,对于 RPC 来说,是两方使用相同的编程实现的一种情况。

例如对于早期,进程间通信,不同应用之间有一些 Old Fashion 的RPC,有的可能只是听说过。像 CORBA (Common Object Request Broker Archiecture),Java 会使用 Java 远程方法调用 RMI (Remote Method Invocation),如果做过 JEE 应用服务器之类的开发,应该会有所接触。

再之后,过渡到像 SOAP, REST 这些。RPC 框架的话就出现了 Dubbo, gRPC, Thrift 等等。

而随着 Docker 和 K8S 的云原生时代到来, gRPC 基本成为底层的通信层。

我自己之前一直使用的都是 Java 的 RPC,最近看了一本关于 gRPC 的书籍 『gRPC 与云原生应用开发』,对 gRPC 中的一些设计感觉还是挺新鲜的。



比如 gRPC 在 HTTP/2 之上实现了 protocol buffers,处理进程间通信很快。对于通信模式来说,除了传统的请求响应模式(Unary RPC)之外,还支持基于 Stream 的通信方式,单向Stream, 双向Stream。

在看服务端的这种流的 RPC 的时候,感受和当时看 Spring 5 的 WebFlux/Mono 这种响应式的风格,以及更早的 Servlet 3.0 中的异步Servlet 一样,眼前一亮。

书里除了通信模式,对于 gRPC的底层原理,比如消息分帧,基于 HTTP/2 如何做请求和响应等这些底层的执行和实现有所介绍,如果平时仅限使用框架,那这些对一般 RPC的原介绍,能使你能RPC 框架的设计等有所了解,使用起 gRPC 来也能心中有数。


书中的案例基本通过Go 和 Java 两种实现,演示从基础服务的定义、创建,到构建和运行的过程,对应 GitHub 中还有 Node, Python 等其它语言的实现。

还有对于 gRPC 中如何使用和实现拦截器,多路复用,负载均衡等高级特性,以及如何和 Docker、 K8S 协作的介绍。


相比 Dubbo 这种包含服务治理功能的 RPC 框架,如果按传统的方式使用 gRPC,感觉可能需要考虑和了解的其它内容比较多,例如负载均衡,注册中心等,这是因为在云原生应用开发中, gRPC 把这些功能都交给了容器编排和服务网格等更高层次的抽象。


标题中虽略显浮夸,不过像 gRPC 这样的框架,可以在云原生时代实现跨语言,跨系统的服务调用,其它的能力交给上层抽象,就像水煤电,具体要怎么用,交给使用的锅炉和水箱这些工具和终端。:-)





感谢图灵出版社支持,本次『gRPC 与云原生应用开发』赠书三本。

截止2.28 20:00,留言点赞前三名获得。

留言说说 RPC 也好,云原生应用开发,进程间通信或者类似开发相关的话题皆可。

浏览 36
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报