刚刚好最近在做系统，出了很多问题。这下子才理解，业务面试为什么要天天问aop，问消息中间件，分布式事务，数据库了。
case 1:
非业务逻辑的代码处理。比如日志记录，权限控制，埋点上报等。
很多人秉承"高内聚，低耦合"的思想，会写一个单例类，封装各种各样的函数。然后在需要的地方去调用。
这个处理方式看似没有问题，实际上，挫的不行。
一个新接口，上来先把各个非业务逻辑的类方法调用一遍。然后再往里面填业务逻辑。
这种方式在项目初期，或者在外部依赖不够多的时候代码看着还比较优雅。但是只要流程变长，一个接口的代码段马上就变成shit山。
即使把代码排列段整整齐齐，看着整洁。但是那绝对不是个优雅的设计。
非业务逻辑，比如参数校验，日志记录，函数性能埋点分析等等应该剥离出去。使用aop或者python的装饰器之类的。
让接口干干净净，专注业务逻辑。
case 2:
我在做一个运维系统，一个运维动作，会涉及多个系统之前相互配合，需要保持数据一致性。
刚刚开始，我考虑用责任链的设计模式，试图让代码看起来比较"好看"，不用堆砌太多系统之间的调用流程。
抽象Ａ，B，C等系统，然后再用责任链串一串。代码看着肯定干净清晰很多。
问题来了为什么这里不用责任链设计模式？
责任链模式，也可以抽象简化不少业务逻辑。一个系统一个系统等调用组装，用责任链串成串，代码看起来也是干干净净。
但是一旦异常发生，数据不一致，重试或者回滚产生各种副作用。马上就感觉着系统就是坨shit。就算摆的整整齐齐，装饰的花里胡哨，也还是shit。
Ａ系统处理完，丢给B系统处理，再丢给C系统etc.但是这种和几百个if else排列的整整齐齐的垃圾代码没有什么本质性的差异。
仔细分析系统和业务，我着手的平台，有以下一些要求。
1.多个系统之间数据需要保持一致，要么成功，要么回滚。
2.工作流程长，一次执行可能需要几分钟甚至几小时。
3.需要注意幂等问题，避免中间过程失败重试导致副作用。
4.因为流程长，需要查询任务执行进度。
这个就是一个非常典型的分布式事务saga模型。对于公司搬砖人来说，重要的是设计思路，太多开箱即用的工具和客服同学协助使用。思路清晰后，实现套demo即可。
有人去厕所带薪拉shit，而有的人偏偏要到git上……
全部评论
(0) 回帖