20210522大检查计划 - ziyouzy/2021blog GitHub Wiki

river-node节点只会去产生Errors和Events这两种数据，同时可以“负责某个”数据的传递工作
river会去产生Errors和Events这两种数据同时也会基于river-node“实现某个”数据的传递工作
无论river-node还是river，最重要的都是需要去重点关注那些将来会负责接收Errors或Events的业务逻辑，你需要确保他们不会发生逆流
其他的也不用太神经过敏

检查顺序：
1.所有的rn（done）：

总结，所有river-node所产生的event和error，在主系统中的处理方式需遵循如下原则：  
1.所产生的Errors和所产生的Events均禁止被发送给客户端  
2.整体系统可基于river-node的Errors采取后续策略(如p.warpError_Panich；BAITSFILTER_LENAUTHFAIL->river success)  
3.整体系统不可基于river-node的event采取后续策略  
4.所有river-node的event唯一的后续策略只有记录日志  
这么规定另一个好处是可以让eebox中的eventbox变得简单  

2.所有的readriver

1.所产生的Errors禁止发送给客户端，所产生的Events可以发送给客户端  
2.整体系统可基于river的Errors采取后续策略(如p.warpError_Panich)  
3.整体系统不可基于river-node的event采取后续策略  
4.所有river-node的event唯一的后续策略不再只有记录日志，还可以遵循1所述发送至客户端  
(event可以被发送给客户端由于是基于sub机制，因此也就是说可以发送给所有的writer，如TCPUSRIO808RECEIVER_RUN）  

3.所有的writeriver

1.由于需要用此模块实现“event流动至客户端”这一功能(接收来自eventBox的数据)，因此在流动过程中严禁逆流回eventBox  
2.但是可以讲event转化为error并流入ErrorBox  
3.严禁用任何writer属性的river“流动处理Error”  

2与3的宏观总结：

1.**Errors:记录日志**  
2.**Errors:整体系统可基于Errors采取后续策略(如p.warpError_Panich)**  
3.**Errors:禁止发送至前端** 

4.**Events:记录日志**   
5.**Events:整体系统禁止基于Events采取后续策略（基于"Plan for failure,not success"原则）  
6.**Events:可发送至前端**（可以将eventBox与writeriver(由于是基于广播机制，其实等同于于任何writeriver）进行“数据流动对接”)  

4.tcpmanul(从这里开始变得繁杂，会拥有ps之类的东西了)
5.modbusbox
6.不用检查eebox，而是直接重构
7.service