doc[protocol]: 更新文档

protocol/README.md

@@ -71,9 +71,9 @@ cpu： i9900k
 复杂对象，zfoo包体大小2216，kryo包体大小2528，protobuf包体大小5091
 ```
 
-### Ⅵ. 协议规范
+### Ⅵ. 数据类型
 
-- 协议类必须实现com.zfoo.protocol.model.packet.IPacket接口，协议类的的protocolId不能重复
+- 为了代码的优雅，协议类必须实现com.zfoo.protocol.model.packet.IPacket接口，协议类的的protocolId不能重复，但是可以保证不损失性能的情况下支持不继承IPacket的设计
 - 协议类必须有一个标识为：public static final transient short PROTOCOL_ID的"协议序列号"，这个协议号的值必须和IPacket接口返回的值一样
 - 协议类必须是简单的javabean，不能继承任何其它的类，但是可以继承接口
 
@@ -93,17 +93,9 @@ cpu： i9900k
     - 自定义泛型类XXXClass<T>，泛型类在很多框架中都极易出现性能上和解析上的问题，而且并不是所有语言都支持
     - 循环引用，虽然底层支持循环引用，但是考虑到循环引用带来语义上难以理解，容易出现错误，所以就屏蔽了
 
-### Ⅶ. 待解决的问题
+### Ⅶ. 协议规范
 
-- 为了代码的优雅，zfoo protocol要求全部的协议类都要继承IPacket，但是可以保证不损失性能的情况下支持不继承IPacket的设计，这个有待继续讨论。
-
-- 协议类修改
-    - 修改字段名称过后无法解析，内部默认使用字段的名称按照字符串的自然顺序来依次读写的（也可以自定义），所以修改名称会导致读写顺序变化导致出现异常
-    - 减少字段无法解析，没必要一定要删除一个不需要的字段，所以不考虑这种情况
-    - 增加字段，需要加上Compatible，order需要自然增大
-
-```
-设计模式六大原则中的开闭原则是对扩展开放，对修改关闭。协议的设计涉及到功能应该也要遵守这个原则，优先增加新的协议而不是修改现有协议。
-
-协议类修改，可以考虑通过版本号去控制，或者增加新的协议类去解决（组合大于继承，协议类应该对扩展开放，对修改关闭）
-```
+- 如果为了版本兼容，增加字段，需要加上Compatible注解，order需要自然增大，这样就可以保证新老协议可以互相兼容
+- 正式环境为了版本兼容，避免修改字段名称，内部默认使用字段的名称按照字符串的自然顺序来依次读写的（也可以自定义），所以会导致序列化出现异常
+- 正式环境为了版本兼容，避免减少字段，没必要一定要删除一个不需要的字段，所以不考虑支持这种减少字段兼容协议的情况
+- 设计模式六大原则中的开闭原则是对扩展开放，对修改关闭。协议的设计涉及到功能应该也要遵守这个原则，优先增加新的协议而不是修改现有协议