美文网首页
prpc开发日志-2021年3月20日

prpc开发日志-2021年3月20日

作者: 扫地专业高级研究生 | 来源:发表于2021-03-20 22:38 被阅读0次

    清晨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,动次打次,动次打次,动次打次,打击乐打击中。。。哈哈哈哈哈

    相关文章

      网友评论

          本文标题:prpc开发日志-2021年3月20日

          本文链接:https://www.haomeiwen.com/subject/ordgcltx.html