新人同学熟悉一个新系统 接手新业务对应的另外一篇文章，重构系统 ,还不是很系统
相关文章
代码阐释系统 从数据分析角度理解一个新系统_个人渣记录仅为自己搜索用的博客-CSDN博客
目录
宏观理解 - 远远不够- (权限,人才是终极,3个月内,任意链路,主要是我们的边界, 依赖哪些系统,是否需要我们自己配置,例如算法常驻部署,多机房考虑等.)
接手依赖于中台系统的挑战
看上去边界的入参和出参都很简单, 但是大量复杂的逻辑存在与下游依赖的各个系统的配置中.
对接一个新业务, 你得了解这些系统的配置对应的能力. 不然你无法接业务 ,或者说经常以为是个简单的配置对接, 但是依赖下游的n多人力无法拉齐.
架构师之中台思维_系统发展之路_结果和抽象之间平衡的艺术_个人渣记录仅为自己搜索用的博客-CSDN博客
思想/方法论 业务链路和稳定性两块
首先是先整理总结最后抽象复用, 大道至简. 抽象出各行各业都能通用的方法论.
抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。 具体地说，抽象就是人们在实践的基础上，对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作，形成概念、判断、推理等思维形式，以反映事物的本质和规律的方法。
实物抽象: 大脑通过各种感觉器官来量化,然后再各个区间范围内定义物体. 下次看到类似的东西就会根据输入. 视觉 来决定是什么.
文字抽象: 人类基于实物/感觉 描述了很多的文字符合/声音符号 来固化描述概念. 慢慢聚合起来就是文字抽象. 然后基于文字上的输入,思考,表达.
工作中的抽象: 都是基于以上的能力. 去总结新的概念. 总结和复用.
广义的抽象包括任何总结思考. 有抽象总结后就可以复用迁移. 狭义的抽象仅包括两个类似的东西抽出相同的东西, 前提必须要两个
动静法; 归纳总结/演绎; 时间法: 过去/现在/未来
动静:
动: 先自顶到下, 先流程,找到入口,典型流程熟悉系统能力. [备注] 读流程勿忘. 读能补全你的表设计,让设计更完备. 辅助工具: 用例图,流程图(含读),角色图. 动分两个层次: 人视角流程图, 系统视角时序图. 先大再小. 最终细节要搞清楚 1.接口的唯一性id是什么. 靠接口文档或者口口相传,靠数据库唯一id,靠代码控制. 2. 幂等唯一. 3. 状态机对应的流程是什么,入口在哪里.(状态机系统) 异常: 4.各种异常分布式一致性问题,核对 5. 并发, 每个节点, 多个人是否能同时操作 ,并发读写? 安全: 攻击.
进阶: 先自顶到下,然后自下到顶视角整理. 动业务链,和成本结合价值链, 和人结合即部门链. 包括我们依赖的技术和产品, 别人依赖我们的技术.
链路的熟悉 - 特别是非标链路的熟悉 - 没有标准化监控. 旁路系统的权限申请,别出问题的时候找不到人权限申请.
静: 就是整理出 写/读的功能集合. 产品功能架构 -> 系统架构 从人出发. 不同的业务要有接口人. 业务和接口人分别是谁, 有没有认识, 见过面,吃过饭, 人才是核心.
归纳总结/演绎
归纳总结(注意层次)
现有功能整理,归纳.(总结现有产品大图,动词物化) 现有系统链路整理(系统架构图) 各种系统问题整理,归纳起来(总结未来的重构大图). 各种产品问题,需求整理总结(总结未来价值大图).
总结还要抽离层次. 归纳,下沉,上浮,平行. 其实就是脑图的思考方式. 节点太多了,就分类. 节点描述太模糊了,就拆分,下沉. 节点太深了,就上浮. 层次很多. 支付系统里有 资产(账,银行卡核心), 资产交换核心. 金融网络, 清算中心,对账中心 支付决策. 收银台. 收单系统. 账单系统. 网络. 应用层,网络层 传输层, 数据链路层 物理层
维度
总结有通用的维度,时间/人的角色/地点, 人的感官: 情绪/味觉/触觉(温度,湿度)/听觉 . 动/静 过去/现在/未来
演绎
动态化的思考未来可能的情况. 大的方面 各种系统问题整理,归纳起来(总结未来的重构大图). 各种产品问题,需求整理总结(总结未来价值大图). 小的方面 写需求时需要演绎, 多人并发操作,一写多读. 演绎要抓维度. 不同的角色/并发/通用的维度. 类似/相同的
第一性原理
从最初目的和材料出发思考问题. 推翻原有的体系,弯道超车. 越底层核心(例如能源) 越吸引人(例如ar)的替代越有用.
宏观理解 - 远远不够- (权限,人才是终极,3个月内,任意链路,主要是我们的边界, 依赖哪些系统,是否需要我们自己配置,例如算法常驻部署,多机房考虑等.)
1. 系统角色，系统边界图。核心流程拓扑图。核心用例把握。
2. 内部模块图。
3. 整体架构图，含支撑工具，中间件（所有依赖的系统）
3. 模块流程拓扑图，复杂版，含各个线路。
4. 线上部署机房图。
5. 各系统的机器逻辑图。
但上面这些其实没有意义,因为业务是从流程开始的.
业务细节
通过数据分析了解系统: 很重要的一点,获取DB blink的增/改diff (避免status值的变动)和traceId ,放在sql的注释里. 然后获取到结合入口日志/边界日志分析,status的哪些入口改. 这个入口这个status,影响了哪些下游. (实在没有 自己打印日志,只是代码里不变更的就不要传到sql里,搞个mq,自己异步查询数据库,然后diff打印日志. )
6. 真正的落地，代码和用例结合。特别是关注type值。
7. 熟悉表结构，主键,联合主键, type值，status值
|
类型
|
接口名
|
核心type值
|
调用方
|
场景描述
|
涉及到的表，存储
7.2 画领域结构体.(逻辑相关) (如果没有直接存储,可能需要通过DO和配置转换成对应的领域实体) 详见 fei334243 ddd
8. 作为平台的话(因为太底层,有时候接口间关系搞不明白),用户交互和接口的关联关系理解明白.
- 接口和实际行为对应学习，模拟端上操作，然后看结果。
- 入参的唯一id,唯一键列表. 如果表上没有,这个需要问
- 内部生成的唯一id,唯一键列表, 看表.
- 出口调用外部api的请求日志. 和返回值
- 请求唯一值,唯一键列表. 这个需要问
- 返回唯一值,唯一键列表. 这个需要问
这里有点需要注意: 下游回调,不同状态的下游唯一id可能和同步请求返回的唯一id不同. 需要通过业务方的唯一id进行匹配.
进阶- 稳定性
进阶 - 改造
12. 系统的优化改造：
1. 基础日志改造
2. 更新接口改造。 status的值得封装。不要直接业务上大方法上直接传入一个bean进来。
1. 业务成功率统计(业务层面的拦截器,识别不同的Bean)
2. 接口成功率统计(不同的result,需要filter或者拦截器)
3. 临时状态核对.
4. error日志结构化
5. ab test的统一动态key开关, B流程日志的动态key,统一日汇总, 周汇总, 月汇总.
6. 自核对
13. status的utils 状态机，type的接口化改造。
14. 各中间件的边界日志，整理到对应的文件中。方便后续制定方位排查。边界可维护. 一般都有中间件日志.
15. 单测框架改造。 继承, 自动化mock, 设定 depDate(depClientMethodData,depDbData) expectData{ ExpectDb , ExpectClientParam,expectResponse}
16. 业务域的抽象。
17. 消息的同步, 必须要有ack和同步机制. 端宕机后全量数据恢复和增量数据修正.每个消息操作都要有个自增id (根据时间行不行,同一个conf落一台redis,add的同时返回redis 自增id, 自增id的好处是,对增量消息,端上不会先执行后面的消息,不能隔数更新.)
206
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
