数据依赖微服务待办
1014 18:55 原来有点儿担心让服务器控制的话，解压的时间， 就目前的设计看，解压时间应该可控。
普通对象要不要压缩呢？也可以压？确认一下发送的数据量，如果大就压，发回来的数据也一样，如果大就压。 直接在 client 这里压会不会层级不对？应该还可以，因为 parser 里面是第一层转换条件，然后 client 里面是发送前的判断条件。二者都要满足。
rpccontext 注入 config 但这个 config 不同的协议肯定不一样，咋办。也没关系，对某个组件，对应的 config 一定是想要的那个 config 既然已经组成协议的话。
远程
handlerchain 改写一下，改成迭代
exceptionhandler
通用附件传递中心
invoke-message（add attach from global）
message （add attach 2 global）-invoke-result
插件的热部署效果
权限验证的效果，搞成切面
同样的token不需要重复权限校验
保持 bs 的风格，并兼容已知的 cs 架构
处理已知问题
安全，权限，定位，图表性能，断开
连接过程
切换过程剥离ui和数据
ui数据清空，重新加载ui即可
怎么样描述这些体验
为什么要这么写框架？
灵活性，满足兼容，扩展
序列化
数据发送方式
性能，异步等扩展逻辑
invotionfunc
typestructure extend type
metadata
sevice、method上提
method 改成 endpoint。
attachment 附件信息，换成 attribute 更合适一些。
然后 rpccontext 里面可以是附加信息。
现在的 rpccontext 不能是全局的，全局的侵入式是比较强的。
AsyncCaller。call（context，xxx）
微服务之间的数据依赖问题
切远程的时候，只同步设计器插件，其他的不考虑。而且只切目录，不关插件。
切的时候同步只考虑远程仓库。
理论上两边要保持一致的
pipeline
固定，不能动态加入。
可以提供出来接口，等待调用。
加个名字，比较清楚一些。
streampipe 的资源绑定到 rpcclient context 上。通过 utils，或者直接用 context 绑定？
削减线程池数量
定时清空缓存和持久的缓存。
需要重新缓存。
rpccahe.get（CacheKey）schedule（）
Cacheref.computeifabsent（valueKey，（））
clear（）
缓存在没有失效机制时，没有任何作用。还容易引起误导。
理论上还是有用的，比如插件的更新，就是 n 分钟后同步。
异常时，再重新加载。
不，完全没有任何用，只会导致复杂度高， 缓存应该在组件层， 后台就是对象层， 而不是方法层级。
serverresponse 的处理还是有问题的。
severresult invocation servletresponse rpcresponse
delay 的单测 gzip 加在哪，加在 pipeline 上，还是发送的 client 上？msg 添加 header，然后 client 里面处理。
objectstreamproducer
- consume｛add｝
- consume
- toiterator
pipeline 互相不影响，除非抛出 fatalerror 然后 validate 放 pipeline 里面 client 捕捉 gzipex 然后用其他的 codec 进行错误处理。 用 rpccontext 承接附件对接 workspaceservercontext，防止移除不了，有脏数据