微服务
单体架构
- 一旦某个服务宕机，会引起整个应用不可用，隔离性差
- 只能整体应用进行伸缩，浪费资源，可伸缩性差
- 代码耦合在一起，可维护性差
微服务架构：解决了单体架构的弊端
但同时引入了新的问题
- 代码冗余
- 服务和服务之间存在调用关系
服务拆分后，服务和服务之间发生的是进程和进程之间的调用，服务器和服务器之间的调用
那么就需要发起网络调用，网络调用我们能立马想起的就是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都小，适合网络传输
- 支持跨平台多语言
- 消息格式升级和兼容性还不错
- 序列化反序列化速度都很快