清晨7时40分左右，继续上次构思的总体设计，准备着手代码实现。在此基础和目的上，以先后顺序记录整个思考和实现过程。
1，开始构思整体的目录结构，初步构思为总目录prpc，下分别创建proxy，stub，connetion目录，加prpc.py文件，思路为各个目录代表了各个组件，各个组件之内可能有各自的配置和其他工具py之类的，彼此相互独立，所以将目录分开
2，删除了proxy，stub，connection目录，新增proxy，stub，connection后缀为py的文件，初步考虑，代码量和项目目的需求量的原因，觉得拓展过多的不必要的功能实际上是没有必要的，时间和精力都不允许
3，编写prpc.py，通过在方法上加标签，起到拦截方法执行，从而将方法加入代理类，期间查询了@标签的用法，以及其拦截实现中参数传递和方法返回的机制
4，在prpc.py中引入proxy模组，在proxy模组中新增proxy方法（后改为invoke方法，想法的来源是java，虽然并不知道有什么特殊含义），proxy名为代理，但在代码实现过程中，他并未起到代理的作用，invoke方法，实际上只是在获取方法参数和封装请求的context，然后直接返回（可能是对代理的理解不透彻，也可能是因为并没有那个需求，实际上python的语法跟java还是差距很大）
5，proxy模组invoke方法返回是封装的请求context，直接返回到了prpc模组，prpc引入stub模组，执行invoke方法，这里开始有另外一种想法，就是整个调用过程不是这样分步骤的，而是链路方式的，想法是，怎么去的就原路返回，这样的好处就是不必要把请求和响应分离，原路返回的好处就在于请求信息的封装可以展示在同一个方法下面，甚至可以使用同一个方法，减少代码量，并且增加代码的连贯性，但后来还是采用了，直接返回处理结果后，供下一个过程调用，这样做的目的是，为了在prpc模组下实现整个过程的总控。
6，stub组件invoke的方法，功能相对来说，比proxy明确的多，发现远程服务，对比，配置远程服务信息，返回
7，stub返回远程调用信息后，prpc引入connction模组，这个模组的设计主要是为了建立连接，并发送消息，同时外加了组装报文的作用，刚开始是如何组包的问题，加入了不同的报文转换方式，json，bytes，base64，str这几种方式，同时在思考发送信息过后响应超时或者报文失败的因素影响，增加了一个些控制字段，标示表文类型的字段（message_type，request，response，ack，error，repeat），这些报文类型，主要是让服务端识别请求端想要的响应内容，比如repeat指的是，在响应接收失败，或者超时或者丢包的情况，可以要求服务器重发响应信息，这个功能看起来还是挺不错，但也增加了工作量
8，同时也开始思考，这些控制信息应该放在什么地方配置，思考的结果是，放在connection下，作为一种可变配置，通过stub的invoke_type字段来控制是否支持重传。
9，然后就是接收到的报文验证和解包问题，设计了报文头，在不用转换的情况，获取主要信息来验证报文和确认请求类型。
10，响应回来的处理逻辑，相对来说比较简单（主要是太累了，难得想），一个大问题就是变量命名出现了脑洞不够的情况，有些东西很明显重复或者词不达意，哎。
11，动次打次，动次打次，动次打次，打击乐打击中。。。哈哈哈哈哈
网友评论