document:更新readme描述，添加下一阶段的计划

Author: Casper-Mars

README.md

@@ -5,48 +5,60 @@
 >
 > [nifty]: https://github.com/facebookarchive/nifty.git
 > [origin]: https://github.com/Casper-Mars/springboot-starter-thrift
-> 
+>
 
 ---
+
 ## 开发阶段
 
 ### 第一阶段（已完成）
+
 配合spring，实现自动装配出thrift的server
 
 * 使用自定义的注解
 * 在spring容器初始化后，获取全部的thrift server实现类。
 * 构建服务类统一代理实现的thrift server类，并最终注入到ioc容器中
 
 ### 第二阶段（已完成）
+
 配合spring，实现自动装配出thrift的客户端
 
 * 使用自定义的注解，标记客户端使用的熔断类
 * 使用cglib动态代理，在thrift调用中出现服务熔断，则调用本地实现类
 * 手动注册客户端bean
 
 ### 第三阶段（已完成）
+
 添加对spring cloud的支持。
 
 * 改造eureka客户端的注册流程。在服务端启动后，如果有配置eureka，则在eureka客户端注册的服务信息中添加thrift服务信息，包括服务名称和端口
 * 改造eureka客户端的获取服务信息流程。在客户端启动后，如果有配置成从eureka获取服务信息，则从eureka注册中心获取服务的信息并提取其中的metaData，解析metaData获取thrift服务信息。
 * 注册监听器，监听eureka客户端的服务列表更新。获取最新的服务列表后更新本地的thrift服务信息
 
 ### 第四阶段（已完成）
+
 融合server和client。实现server和client并存，赋予微服务服务能力的同时也有客户端功能。
 
 ### 第五阶段（已完成）
+
 分离客户端和eurake客户端，把纯封装thrift的抽出成client-core，再定义eurake客户端实现eurake-thrift-client。eurake-thrift-client只需提供eurake相关的bean并引入client-core依赖组装而成。分离的目的为了未来更好地扩展出其他版本的服务注册中心的客户端
 同理分离服务端
 
 ### 第六阶段（已完成）
+
 修改客户端处理服务的逻辑。原来的扫描全部的服务并建立代理bean的方式有缺陷。在微服务不需要大部分的服务时，只会消耗系统资源去维护服务列表（包括列表刷新和底层socket的操作）。
 因此，现在改成按需建立代理bean，只有被ThriftClient注解注释的才会被认为是需要的服务而创建代理bean。同时被注解注释的类会作为熔断回调类在服务down的时候调用。
 
 ### 第七阶段（待实现）
+
 修改客户端的socket管理。目前的管理方式没有处理服务端掉线的问题。尝试使用netty做底层通讯框架，方便管理socket和处理各种事件。设置掉线重连机制。
 
+### 第八阶段（待实现）
+
+thrift耦合了netty后，底层的实际通讯逻辑经由netty实现。把耦合后的thrift和netty从spring的逻辑中抽离出来，形成新的模块，spring只是负责管理依赖和注入依赖，thrift负责管理rpc的协议和调用，netty负责管理底层的网络通讯
 
 ---
+
 ## 技术要点
 
 ### springboot starter
@@ -71,6 +83,7 @@
 客户端和服务端都需要用到spring的ioc容器。因此，免不了和ioc注入打交道，实现自定义的注入逻辑。需要了解ioc注入的生命周期、注入的切入点和触发点。
 
 ---
+
 ## 问题
 
 ### 客户端请求包混乱问题(close)
@@ -95,14 +108,17 @@
 * 副作用：每次的请求都需要反射生成thrift的客户端，需要额外的开销
 
 ### netty化后的客户端(close)
+
 * 问题：在多线程的情况下，底层创建channel的逻辑没有加锁，导致高并发的情况下会出现多个相同目标主机的链接的channel。
 * 解决方案：加上锁
 
 ### thrift请求数据构造(close)
+
 * 问题：不清除thrift是怎样构造请求的，在获取seqId的时候，不同的请求得到的结果是一样的。因此推测seqId是对于同一个请求而言才有意义。
 * 解决方案：再把thrift协议封装一次，每个channel为所发送的thrift请求添加唯一的id，接收的时候按照id进行响应
 
-### 多线程高并发下会出现某些请求失败的问题
+### 多线程高并发下会出现某些请求失败的问题(close)
+
 * 问题：在多个线程同时调用同一个channel发送请求时，会出现某些请求失败，一直得不到服务端的响应。通过抓包排查发现，请求的数据包确实是通过网卡发送出去了，而服务器的网卡也接收到了，但是服务进程却没有接收到数据包。
 通过对比单线程循环发送请求的tcp数据包顺序和多线程并发发送的顺序，发现循环发送的情况数据包是按照：发->收->确认的顺序。而多线程的情况下是多个线程的数据包按照先后次序依次发送，并没有等服务端的响应，随后服务端的响应也只是其中某几个请求。
 通过对比，分析得出推论：在多线程的情况下，可能是缺少了确认的数据包，导致通讯不完整，只有某些包是有确认数据包的，所以只有某些请求响应了
@@ -114,9 +130,8 @@
 
 * 问题：在多线程访问下，会有一定几率出现内存泄漏的异常
 
-
-
 ---
+
 ## 开发指南
 
 ### 架构
@@ -127,11 +142,10 @@
 
 > ![avatar][client-core-image]
 
-* client-core 
+* client-core
 
 > 只是核心的部分，实现了扫描客户端并动态代理的功能。细节上着重体现在注入和维护两方面。
 
-
 * client-eureka
 
 > 实现了服务提供的功能，并实时刷新服务。![avatar][client-eureka-image]
@@ -148,17 +162,12 @@
 ### 客户端变更
 
 * 2020-06-24
+
 ```
+
 原来的客户端是使用原生的thrift客户端进行rpc通讯的。当搭配eureka使用的时候，需要对eureka监听到的服务刷新事件进行处理。底层需要维护一套在线可用的transport列表
 经过netty化后的客户端，可以减少维护成本，服务的可用只需根据netty的链接状态即可维护，此时的eureka更多的只是作为一个服务信息增量提供的中间件。
 
 ```
 
-
-[client-core-image]:./info/client-core.png
-[client-eureka-image]:./info/client-eureka.png
-
-
-
-
-
+[client-core-image]:./info/client-core.png