@@ -220,7 +220,7 @@ SPI (Service Provider Interface)
2202203 . 接口位于独立的包中
221221
222222
223- ### 1、 接口位于【调用方】所在的包中
223+ ### 1. 接口位于【调用方】所在的包中
224224对于类似这种情况下接口，我们将其称为 SPI, SPI的规则如下：
225225
226226- 概念上更依赖调用方。
@@ -234,13 +234,13 @@ SPI (Service Provider Interface)
234234- 日志 Log
235235- dubbo扩展点开发
236236
237- ### 2、 接口位于【实现方】所在的包中
237+ ### 2. 接口位于【实现方】所在的包中
238238对于类似这种情况下的接口，我们将其称作为API，API的规则如下：
239239
240240- 概念上更接近实现方。
241241- 组织上位于实现方所在的包中。
242242
243- ### 3、 接口位于独立的包中
243+ ### 3. 接口位于独立的包中
244244如果一个“接口”在一个上下文是API，在另一个上下文是SPI，那么你就可以这么组织
245245
246246![ ] ( https://github.com/zaiyunduan123/Java-Interview/blob/master/image/dubbo-3.png )
@@ -1292,13 +1292,13 @@ dubbo 是基于netty NIO的非阻塞 并行调用通信。 （阻塞 非阻塞
12921292dubbo从头到脚都是异步的
12931293dubbo 的通信方式 有3类类型：
12941294
1295- ### 1、 异步，无返回值
1295+ ### 1. 异步，无返回值
12961296这种请求最简单，consumer 把请求信息发送给 provider 就行了。只是需要在 consumer 端把请求方式配置成异步请求就好了。如下：
12971297```
12981298<dubbo:method name="sayHello" return="false"></dubbo:method>
12991299```
13001300
1301- ### 2、 异步，有返回值
1301+ ### 2. 异步，有返回值
13021302
13031303这种情况下consumer首先把请求信息发送给provider，这个时候在consumer端不仅把请求方式配置成异步，并且需要RpcContext这个ThreadLocal对象获取到Future对象，然后通过Future#get( )阻塞式获取provider的相应，那么这个Future是如何添加到RpcContext中呢？
13041304
@@ -1335,7 +1335,7 @@ hello=temp.get();
13351335
13361336
13371337
1338- ### 3、 异步，变同步（默认的通信方式）
1338+ ### 3. 异步，变同步（默认的通信方式）
13391339
13401340异步变同步其实原理和异步请求的通过 Future#get 等待 provider 响应返回一样，只不过异步有返回值是显示调用而默认是 dubbo 内部把这步完成了。
13411341
@@ -1492,7 +1492,7 @@ dubbo 使用长度为 16 的 byte 数组作为协议头。1 个 byte 对应 8
14921492- 96 ~ 127： data length，请求或响应数据体的数据长度也就是消息头+请求数据的长度。用于处理 dubbo 通信的粘包与拆包问题。
14931493
14941494
1495- ### 1、 consumer请求编码
1495+ ### 1. consumer请求编码
14961496consumer 在请求 provider 的时候需要把 Request 对象转化成 byte 数组，所以它是一个需要编码的过程。
14971497```
14981498----------1------consumer请求编码----------------------
@@ -1502,7 +1502,7 @@ consumer 在请求 provider 的时候需要把 Request 对象转化成 byte 数
15021502 -->ExchangeCodec.encodeRequest
15031503 -->DubboCodec.encodeRequestData
15041504```
1505- ### 2、 provider 请求解码
1505+ ### 2. provider 请求解码
15061506provider 在接收 consumer 请求的时候需要把 byte 数组转化成 Request 对象，所以它是一个需要解码的过程。
15071507```
15081508----------2------provider 请求解码----------------------
@@ -1512,7 +1512,7 @@ provider 在接收 consumer 请求的时候需要把 byte 数组转化成 Reques
15121512 -->ExchangeCodec.decodeBody
15131513```
15141514
1515- ### 3、 provider响应结果编码
1515+ ### 3. provider响应结果编码
15161516provider 在处理完成 consumer 请求需要响应结果的时候需要把 Response 对象转化成 byte 数组，所以它是一个需要编码的过程。
15171517```
15181518----------3------provider响应结果编码----------------------
@@ -1523,7 +1523,7 @@ provider 在处理完成 consumer 请求需要响应结果的时候需要把 Res
15231523 -->DubboCodec.encodeResponseData//先写入一个字节 这个字节可能是RESPONSE_NULL_VALUE RESPONSE_VALUE RESPONSE_WITH_EXCEPTION
15241524```
15251525
1526- ### 4、 consumer响应结果解码
1526+ ### 4. consumer响应结果解码
15271527consumer 在接收 provider 响应的时候需要把 byte 数组转化成 Response 对象，所以它是一个需要解码的过程。
15281528```
15291529----------4------consumer响应结果解码----------------------
0 commit comments