微服务
单体架构
- 一旦某个服务宕机,会引起整个应用不可用,隔离性差
- 只能整体应用进行伸缩,浪费资源,可伸缩性差
- 代码耦合在一起,可维护性差
微服务架构:解决了单体架构的弊端
但同时引入了新的问题
- 代码冗余
- 服务和服务之间存在调用关系
服务拆分后,服务和服务之间发生的是进程和进程之间的调用,服务器和服务器之间的调用
那么就需要发起网络调用,网络调用我们能立马想起的就是HTTP,但是在微服务架构中,http虽然便捷方便,但性能较低,这时候就需要引入RPC(远程过程调用),通过自定义协议发起TCP调用,来加快传输效率
官网:https://grpc.io
中文文档:http://doc.oschina.net/grpc
RPC的全称是Remote Procedure Call,远程过程调用,这是一种协议,是用来屏蔽分布式计算中的各种调用细节,使得你可以像调用本地一样直接调用一个远程的函数
客户端与服务端沟通的过程
1)客户端发送数据(以字节流的方式)编码
2)服务端接受并解析,根据约定知道要执行什么,然后把结果返回给客户解码
RPC:
1、RPC就是将上述过程封装下,使其操作更加优化
2、使用一些大家都认可的协议,使其规范化
3、做成一些框架,直接间接产生利益
而gRPC又是什么呢?用官方的话来说:
A high performance, open source universal RPC framework
gRPC是一个高性能的,开源的通用的RPC框架
在gRPC中,我们称调用方位client,被调用方位server,跟其他的RPC框架一样,gRPC也是基于"服务定义"的思想,简单来讲,就是我们通过某种方式来描述一个服务,这种描述方式是语言无关的,在这个"服务定义"的过程中,我们描述了我们提供的服务名是什么,有哪些方法可以被调用,这些方法有什么样的入参,有什么样的回参
也就是说,在定义好这些服务,这些方法之后,gRPC会屏蔽底层的细节,client只需要直接调用定义好的方法,就能拿到预期的返回结果,对与server端来说,还需要实现我们定义的方法,同样的,gRPC也会帮我们屏蔽底层的细节,我们只需要实现所定义的方法的具体逻辑即可
你可以发现,在上面的描述过程中,所谓的"服务定义",就跟定义接口的语义是很接近的,我更愿意理解为这是一种"约定",双方约定好接口,然后server实现这个接口,client调用这个接口的代理对象,之于其他的细节,交给gRPC。
此外,gRPC还是语言无关的,你可以用C++作为服务端,使用Golang、Java等作为客户端,为了实现这一点,我们在定义服务和在编码和解码的过程中,应该是做到语言无关的。
下面是官网上的图:
因此,gRPC使用了Protocol Buffss,这是谷歌开源的一套成熟的数据结构序列化机制
你可以把他当成一个代码生成工具以及序列化工具,这工具可以把我们定义的方法,转换成特定语言的代码,比如你定义了一种类型的参数,他会帮你转换成func函数,此外,在发送请求和接受响应的时候,这个工具还会完成对应的编码和解码工具,将你即将发送的数据编码成gRPC能够传输的形式,又或者即将接受到的数据解码为编程语言能够理解的数据格式。
序列化:将数据结构或者对象转换成二进制串的过程
反序列化:将在序列化过程中产生的二进制串转换成数据结构或者对象的过程
protobuf是谷歌开源的一种数据格式,适合高性能,对响应速度有要求的数据传输场景,因为protobuf是二进制数据格式,需要编码和解码,数据本身不具有可读性,因此只能反序列化之后得到真正可读的数据。
优势:
- 序列化后的体积相比json和xml都小,适合网络传输
- 支持跨平台多语言
- 消息格式升级和兼容性还不错
- 序列化反序列化速度都很快