一个典型的后台软件系统的设计复盘——(三)

2019-10-24 作者:金沙澳门官网网址   |   浏览(118)

武侠小说练功讲究打通任督二脉。程序设计练到一定程度也讲究打通任督二脉。好奇心强的同学可以搜搜“打通任督二脉有什么感觉”。

spring的任督二脉ApplicationContext

最经典的任督二脉莫过于java中spring中的ApplicationContext。用惯spring的都会觉得,这里是这个各种实例的起源。概念解释就不搬砖了,见官网
于是乎,以前创建个jdbc需要 Class.forname() 一大堆反射出工厂类再 getConn() 得到个连接,现在只需要 context.getBean("配置名") 就能得到,还能有datasource各种实现以及高级的事务封装。而实际使用时更方便只需要个 @Autowired 。spring兴起之时大家都是在热议其实现了IoC控制反转原则,现在看来不仅如此,更重要的是,构造了整个bean管理体系BeanFactory,并用ApplicationContext打通了应用的任督二脉。

曾见过一个稍微复杂的应用,Oracle一主一从一物理从,可是稍微用起来就数据库连接数不足。排查原因竟是ApplicationContext新建了三处,也就是说相应的连接池创建了三个。这里延伸出另一个概念,叫容器。官方的说法是,BeanFactory就是一个容器,ApplicationContext则是前者的扩展,也是个容器。在这个容器里,任督二脉是打通的,bean是创建好的、管理好的、相应依赖关系是清晰的。但现在的应用服务器多种多样,比如spring容器、spring boot容器、tomcat容器、dubbo容器,想清楚它们之间是否打通,可以避免一些很幽灵的坑。

scoping和lifecycle-作用范围和生命周期

一个典型的后台软件系统的设计复盘——(三)打通任督二脉-context。应用1能不能通过ApplicationContext访问到应用2的类或对象?正常情况下不可以,这就是作用范围。而生命周期,则是指对象什么时候创建什么时候销毁什么时候变换状态。

对这两个概念更好的理解是数据库事务。比如某用户账上有10元,操作1给他存入20元还没提交,操作2查询他当前账户余额,若两个操作在同个事务则查到结果为30元,若两个操作是不同事务则查到结果为10元,事务隔开了两者的作用范围。而操作1什么时候生效则是生命周期:开启事务-更新余额-提交数据库-成功关闭或失败回滚。

复盘业务场景的任督二脉

一个典型的后台软件系统的设计复盘——(三)打通任督二脉-context。这里的场景是商品-订单-调度任务的打通。首先订单分汇总order和商品项detail,detail记录商品快照和批次也是很常识的。然后detail触发个调度任务job去执行。
一个典型的后台软件系统的设计复盘——(三)打通任督二脉-context。然而job开始结束成功失败都应该回来通知订单啊。job-detail有关联,没毛病。
然后需求变更了,有的job是单个detail,有的job是若干detail。依然可以detail指向job,没毛病。

又需求变更了,完成一个detail会有若干个job。。。第一反应当然是多对多。可是要按订单列出哪批detail做完了,order-detail-job并group by job未免太绕,于是建了一层订单拆分detailGroup。然而,真实的需求是,商品按货架归集,货架1的是若干个detail一起做,货架2的是单个detail,又引入一层实体为detailByShelf。

场景是:对于货架1,detailByShelf近似于detailGroup。对于货架2,detailByShelf用于呈现,按货架列出详情;detailGroup仅有单个detail且用于job。
job要回来更新订单状态,通过detailGroup即可。查询要按货架列出,则查询detailByShelf即可。用detailGroup把job和detail串起来放进job execution context,任督二脉算是打通了。

然而需求并没有就这样停止。job会拆解成多个step,某些step会更新对应的detail。也就是说,step要和detail挂钩。然而特定的step是要更新整个detailGroup的状态的。。。

所以,更精细的设计是:step-step context根据不同类型挂钩不同的订单项-detail或detailGroup。而状态更新通知是:

step状态汇总到job
step状态更新到detailGroup或detail,都汇总到detailGroup
detail汇总到detailByShelf再汇总到order

如何验证这个任督二脉是否完整打通了呢?可以套三个场景。
1.step的状态(比job更精细)能更新到detail的所有层级。
2.某一步step正在执行,可以追踪到整个订单以及其中的哪一项,比如 step - detail/detailGroup - order。
3.按货架列出可以找到当前正在执行的是那一步以后,比如detailByShelf-detail-step-job
再者,哪些job是服务于同个detailGroup,也要能串起来。

所以,整个完整的打通是:
job-detailGroup,若干个调度任务来完成一批商品
step-detail和step-detailGroup,一个步骤操作对应的整批或这批中的一个商品项
至此,整个任督二脉算是打通了,任务可以找到对应订单或商品,订单商品可以找到对应任务和步骤。

 

整个场景非常混淆的两个点是:
1.detailByShelf只是查询场景要用,不能混入context。因为对于货架2,一个job只做一个detail项,detailByShelf根本不能表达相应的关系。
2.step什么时候关联detailGroup?不是整批或单个商品项的区别,而是这个step本身的不同。

 

如果问我,程序打通任督二脉是什么感觉?我会回答,应该是,程序中想要的关联信息都能取到,数据库中想要的信息用几个简单查询就能捞出来 的感觉吧。

本文由金沙澳门官网网址发布于金沙澳门官网网址,转载请注明出处:一个典型的后台软件系统的设计复盘——(三)

关键词:

  • 上一篇:简历
  • 下一篇:没有了