第四月:业务周、还是业务周、技术+熬夜周、测试周

第13周

转眼也已经实习三个月了,
第一个月的前端技术,第二个月的java技术栈学习,以及第三个月的业务开发。

本周完成工作:

本周主要进行了业务开发:

  1. 完成:三大模块共计7个页面的controller层测试用例编写,都达到了100%覆盖
  2. 完成:两个模块共计四个页面的文档撰写和代码迁移
  3. 学习了学森同学基于Mock注解的测试用例使用。

本周工作总结:

本周主要还是进行业务开发和测试,在文档撰写过程中加深了业务owner的思路,每个小模块的文档都应该体现出它每个字段的含义,在哪个上游被调用,以及对那些业务领域产生了影响。这就要我们跳出单个小模块去熟悉整合业务体系。
同时,在于同学探讨的过程中还加深了日志和异常的使用,并重新看了阿里开发手册中相应的规范。


第14周

本周完成工作:

  1. 完成四大模块的代码优化以及一个页面的重构
  2. 完成对项目线程池的优化以及从Actuator metrics验证配置

本周工作总结:

  1. 本周学到了在业务中要学会运用面向对象的设计思想,一般的业务普遍用到的还是面向过程,这样很难成长。
  2. 同时也明白了重构的意义,重构,不仅仅是代码迁移,然后优化一下代码和数据库查询时间。它重点在于对整个框架的细粒度控制,以及对整个业务体系的服务划分。
  3. 学习了关于线程池大小以及队列设置还有自定义拒绝策略,但仍存在问题,基于重写RejectedExecutionHandler接口的自定义拒绝策略,在项目中无法被Tomcat线程池引用,但测试中可以在新建的线程池被引用。

前四天基本都是业务相关的重构,基本对重构用到的技术都十分熟练了。对涉及到的业务理解也都基本打通了。就是提前做好了自己的业务开发也还是被分配了类似的任务,本来打算腾出时间给自己学习的。
所以以后要学聪明点,能在规定时间内做好就行,差不多卡到提前一点点,穿插时间稍微学点其他的。不过那也得让我撑过技术周再说了。

这周的线程池配置还是学到了一些东西,但是Tomcat线程池自定义的拒绝策略还是搞不定。主要是全网都找不到就很难受。也是这周五才感受到了无能狂怒的痛。

下周工作计划:

重点完成soa服务化以及技术周流量监控这一模块的学习。
调用链监控是基于日志来的 ,soa 如果没有任何日志 。调用链上只有框架的那一条 。监控层面上是很弱的 。我希望能够知道 who call me , call 了多少次 , 平均时间 ,max时间 。服务耗时在这哪一个阶段 ,以及线程池情况 。 当前promethues 是有部分metric , 比如 java 线程池 , tomcat 线程池 。


第15周

本周完成工作:

完善了上周业务的测试后便开始了技术周:

  1. 完善业余接口测试
  2. 学习了两种接入Prometheus的方案(直接Prometheus通过pull拉取,以及先推送到pushgateway再从中拉取)并完成了接入项目的详细设计文档
  3. 完成了j241引入Prometheus的代码编写

本周工作总结:

本周学到流量监控相关的技术体系,也让我更加理解了“数据”对于业务的价值,同时也学到了一点关于运维相关的知识体系。(满满的官话)


这周经常熬夜导致周末也很难顶,基本没有状态去写博客,现在已经晚上九点多了。
先讲讲其他的吧,这周技术栈搞基于Prometheus的流量监控,这块其实和运维是相挂钩的。
最开始看都是晨哥给的三个Class文件,等做完笔记才知道原来公司用的不是同一套方法。
而且差别很大,也是最后一天才决定推翻重做的。搞定调出不难,但是掌握整个体系运转和跳出一开始方案一的思维误区还是蛮难的。


第16周

本周完成工作:

完成SOA的迁移和测试


感觉开头留给自己的时间还算比较充裕,可以打好基础,后半段时间提升虽然挺快的但是有点基础不稳。
这一次没有争取成为第一个业务owner也是因为对自己基础的一个不自信吧,但是既然选择了暂不接手那就多花点时间来巩固自己的技术。

有不足也有进步吧,这周开始回归运动了也尽量早睡早起,也有了更多的尝试(比如喂猫撸猫)
就是这周太冷了经常犯困简直想直接冬眠了

下周开始制定一些计划把之前落下的东西补齐,
午睡前看一点《成神之路》的知识点,晚上回来到九点前都属于学习时间(虽然吃完忙完也已经很晚了),尽量争取十点半上床吧。


设计先行,先设计(多种方案)再技术评审,最后开发验证自己的设计。
在业务中要学会运用面向对象的设计思想,一般的业务普遍用到的还是面向过程,这样很难成长。


明净系统本质上就是规则以及其产生的结果的集合体,里面包括了在线和离线(人工)校验,但是都离不开规则判定这一事件。
这块在大公司中尤为重视,因为这代表了一家公司的底线。
所有的规则判断,统称为风控引擎。主要是对不同类别的实时事件做处理。
这些不同类别的实时事件会经历于一个类似规则树的存在,通过规则判定,会得到一个行为作为响应,这个行为有可能是封号,添加黑名单,人机验证,账户认证等等。
当前系统是把各种事件规则树融合在一起,然后对所有的规则事件做一个开关,不同渠道触发的事件自带一个规则开关,符合这些的就开启验证。
这样子的好处可能就是不同渠道触发的校验事件可能存在一些重复项,而且配置规则很省事。缺点就是需要改动其中某条规则时,必须要知道那些渠道的校验开启了该规则的开关。

但是更趋向于,不同渠道的校验规则就封装在对应的规则树对象中,通过事件来选择规则树,而非开关去从所有规则中筛选。
如果大的风控,涉及到禁言、封号两个校验操作,那么只需要引入这两者的规则树即可,虽然对象中可能存在一些重复的规则属性,但是好处却是显而易见的。
起码它清晰的呈现了风控引擎的调用,并且使得整个过程更偏向于面向对象,而非面向方法。
但这也要求必须每个人都吃透整个架构的规则,同时还需要统一规范,把一个模块做成demo再一起完善剩下的。


重构,不仅仅是代码迁移,然后优化一下代码和数据库查询时间。
重点在于对整个框架的细粒度控制,以及对整个业务体系的服务划分。
细粒度资源控制(cpu,线程 ,内存 ,io ):减少部署实例、降低无用的消耗资源(表锁转行锁、删除无用表、后台管理系统不需要用到很多redis锁,不要为了技术而技术)
服务划分:区分各自服务领域的开发,降低代码冗余。(如封号模块就只专注于对传进来的用户列表进行封号相关操作,那些判断是不是游客是不是传空,是别的领域以及前端该干的事。)
良好的服务划分可以提高内聚性,使得各自领域内更细致的日志监控、流量监控成为可能。也能使开发人员更加专注,提升了稳定性和易维护行。


定期回看一下自己写的博客和代码,如果你觉得写的很浅或者代码跟屎一样,那就说明你在进步了。


种了一朵玫瑰,可惜没能熬过这个冬天。

Last modification:March 14th, 2021 at 04:38 pm
喵ฅฅ