修改文章：gRPC简介

修改文章：gRPC简介

content/posts/gRPC简介.md

@@ -31,15 +31,15 @@ draft: false
 
 `TCP`的三个特点是面向连接、可靠、基于字节流（顺便一提，`UDP`的三个特点是无连接、不可靠、面向数据报），但使用纯裸`TCP`容易出现粘包问题等，需要在它的基础上加入一些自定义规则用于区分消息边界。例如常见的可以将消息包装成消息头+消息体的形式：
 
-![](\images\1.jpg)
+![](/images/1.jpg)
 
 这其中消息头可以包含多种信息，例如完整的包长度、消息体是否被压缩过、消息体格式等等，只要通信体系的上下游均约定好特定的消息头，就可以实现互认，这也就是所谓的协议。也正是由此，基于`TCP`衍生出众多协议，其中就包含多种`RPC`协议。
 
 准确来说，`RPC`(远程过程调用，`Remote Procedure Call`)本身并不是一个具体的协议，而是一种调用方式，它可以帮助我们调用远程计算机上某个服务的方法，使得调用远程方法与调用本地方法一样简单。举例而言，如果有两个不同的服务`A`、`B`，它们分别部署在不同的机器上，此时若要在服务`A`中调用服务`B`中的某个方法，就可以使用`RPC`。
 
 `RPC`的原理图如下：
 
-![](\images\2.jpg)
+![](/images/2.jpg)
 
 我们可以将整个框架看作五个主要部分：
 
@@ -111,7 +111,7 @@ draft: false
 
 在使用`XML`、`JSON`进行数据编译时，数据文本格式更容易阅读，但进行数据交换时，设备就需要耗费大量的`CPU`在`I/O`操作上，这样会影响整个传输效率。但`ProtoBuf`不同于它们，它会将字符串进行序列化后再进行传输，即二进制数据。
 
-![](\images\4.png)
+![](/images/4.png)
 
 可以看出二者的内容差异并不大，但是`ProtoBuf`的编码内容只是提供给操作者阅读的，实际传输的并不是以这种文本形式，而是序列化后的二进制数据，字节数会比`JSON`于`XML`的字节数少的多，速率更快。
 
@@ -127,7 +127,7 @@ draft: false
 
 gRPC大致的请求流程如下：
 
-![](\images\3.png)
+![](/images/3.png)
 
 1.客户端中的`gRPC`桩(`gRPC Stub`)调用一个方法`A`，发起`RPC`调用请求。