需求拆分 概要设计 详细设计(系分)流程总览 - 异常,非功能性分析

目录

第一步, 了解流程.  (前两年)   

第二步, 垂直切割 (第三年,初步的模块划分,第四年,内部模块划分)

第三步,每个流程整理领域对象和设计.

3.1  方案讨论阶段, 无字段. 流程, 模块划分、选择的技术路线 , 关键技术难点等。 

3.2  方案概要设计, 有字段, 流程图, 边界交互的字段. 上游接口,下游接口字段, db字段.

3.3 详细设计 ( 系分) ,含

3.4 存储泛化支撑.

3.5  用上诉方式,去理解中间件源代码,业务代码均可.

多个需求后

第三步, 水平切割/ 通过type 抽象父子类. 本质上是把相同的字段下沉到一个地方操作.  并提供 queryBean , saveBean的操作. 

第四步 复杂系统的进一步设计和治理

     4.1   门面系统的诞生

     4.2   根因定位系统 / 业务异常治理.

---

代码结构-可维护性代码_代码的可维护性_个人渣记录仅为自己搜索用的博客-CSDN博客

转 - C4 模型 - 可视化架构设计_idea用plantuml画c4图_个人渣记录仅为自己搜索用的博客-CSDN博客

几句话 - 之前的快速记录 架构系统设计能力,模块设计能力_个人渣记录仅为自己搜索用的博客-CSDN博客

思考一个业务系统，物，行为都可以设计 为实体。最重要的是从人角度出发，

第一步, 了解流程.  (前两年)   

        用户使用体感如何, 是否会冒风险,使用的时候是否担心受怕,例如scheme校验,限流都需要log模式, 是否能真的解决问题.
        

    1. 流程理解(用例者,入口,并行流转.) 状态非常关键

    2. 状态机,流程引擎理解. +行为理解(有些流程是并行的,有些是串行的)

    3. 异常case理解

    流程引擎图(节点,流程,行为,用例者)流转.

第二步, 垂直切割 (第三年,初步的模块划分,第四年,内部模块划分)

   2.1 理清边界主体. 上游边界的主体,下游边界的主体不在这里切割. 分别治理. 例如 支付宝的保险,理财,淘宝. 下游边界主体是支付的银行机构, 网联,银联 

      调用分为那几步.,每一步都可以变成一个类(类比方法的好处是独立文件,更直观, 更容易搜索和记忆,便于以后维护)
      每个调用和调用后的处理都可以分为两个类.  比如支付里的. 支付和支付回调. 支付和支付成功入账处理.  字段虽然一样, 但处理的逻辑不同. 相同的字段就是下沉. 例如 支付和提现.

第三步,每个流程整理领域对象和设计.

举例: O2O项目,有接单,抢单,结束服务,支付,分润,入账,.

3.1  方案讨论阶段, 无字段. 流程, 模块划分、选择的技术路线 , 关键技术难点等。 

                    用户使用体感如何, 是否会冒风险,使用的时候是否担心受怕,例如scheme校验,限流都需要log模式, 是否能真的解决问题.

    状态设计
     智能会议室遥控器 一个较复杂的需求,概要设计简析_个人渣记录仅为自己搜索用的博客-CSDN博客

3.2  方案概要设计, 有字段, 流程图, 边界交互的字段. 上游接口,下游接口字段, db字段.

软件概要设计如何写（文档恐惧症的程序猿必读）_系统软件设计怎么写_燕山暮雪的博客-CSDN博客

   
通知接口+主动领域查询 [面向领域,对象] .. 重要案例就是支付模块的account子模块. 流水业务和充值业务的错误拆分. (理论上尽可能的通知+查询,spring的消息中间件,保证本机内流转,解耦,避免mq跨机器流转.) [面向过程]

   内部代码层面也有这种通知写法 设计- 双向依赖关系的理解_个人渣记录仅为自己搜索用的博客-CSDN博客

3.3 详细设计 ( 系分) ,含

系分模板

技术review 评审模板

       1.  内部设计,

                领域type的分割, 对于service. 各个类有的方法和抽象方法.

                内部用的的类重点关注数据结构, map, list 也算.

                重要复杂逻辑的伪代码, 递归等. 写着写着就会反向输出type的分割.  例如if中有两个 type.equals ,就基本上有个父类可以抽了.

                老代码的改动点.
       2.  异常设计: 
                2.1 幂等调用(事务下游调用失败再调用,  上游调用失败再调用, 主要也是因为不再一个事务里, ),  并发竞争,   
                2.2 上游周知: 接口约定之 success 重试(接口调用成功和业务成功,http调用有httpCode 200 ),   特殊code处理, 幂等code
                        这个也是异常case的点.
       3.  兼容性考虑:  关注边界. 字段本身变更:   3.1 字段格式的变更,类型等  3.2 字段的不写入. 等价删除.  3.3 新增了字段, 但因此变更了内部代码的字段取值来源,  往往来自与字段的复制 - 同步 (新)

                方法: 需要依赖脑图绘制xml数据流图. 新老系统作为节点交叉执行.
       4.  稳定性设计:  大流量, 大io. 资源边界导致上游重试雪崩限流. 特殊case: 大io小频率. 只能通过orderId+业务限流. 4.1 下游多个业务方的治理 例如机构的管理, 能力评估,切流, 断流处理. 可能需要专门搞个后台系统运维,入住等程序.
       5.  成本设计: 

3.4 存储泛化支撑.

  比如流水模块,只预存储基本信息. 泛化json信息.不关心业务. 

   理论上这样的系统不存在. 任何的系统的诞生都要有存储+ 基于存储的读以及相关逻辑. . 不然就没有太多的价值. 

     例如算法工程平台, 最核心的还是 方案的管理, 

       1. 设计到方案的接受,

        2. 定时读取, 生/失效时间的管理. 即

                2.1 读取并提前灰度,攒流量, 基于流量计算出新模型参数. 用于线上的sdk直接运行.

                2.2.灰度到生效时间后并上线.

3.5  用上诉方式,去理解中间件源代码,业务代码均可.

细节:

    1. 有些业务必须原子操作,采用事物.或者采用幂等重试的思路. 幂等两种, 幂等插入法, 幂等状态检查法. 都需要事务封装. 

        2. 锁和并发. 

        3. mysql limit

        4. 分布式锁的finally unlock的 是否本线程加锁的判断.

        5. join 框架的实现. 这个没有去思考执行过程,只有输入输出,没有过程,过程是要自己想的,这个比较难.输入是图,输出是数据. 实体是混沌中整理出来的.按此思路重新梳理一遍.

        6. 数据结构,考虑性能,读写,随机读, 写多读少等等情况下的数据结构选择. 这个是技术专家方便. 行储存和列存储的选择. 分词, 时时索引的方案选择. 这个是技术方案.

        7. tcp nio 网络层面的考量.交互

多个需求后

系统升级之路_个人渣记录仅为自己搜索用的博客-CSDN博客

第三步, 水平切割/ 通过type 抽象父子类. 本质上是把相同的字段下沉到一个地方操作.  并提供 queryBean , saveBean的操作. 

    不同业务类似流程的抽象/复用,  导致了支撑模块的诞生和下沉, 即水平切割. 例如支付,账号系统,分租户业务.  还有就是门面系统的诞生.  存储不可扩容, 承担了最大的稳定性维护工作.

      如果是一个系统内, 那就不用queryBean了, 而是直接从父类里 getField 反正本身也是一个人在维护.

       每个if分支一个类. 本质上通过type来编译化领域划分. 复杂逻辑易于后期维护和扩展.

第四步 复杂系统的进一步设计和治理

     4.1   门面系统的诞生

            当下游的系统越拆越多时, 门面系统就诞生了.

     4.2   根因定位系统 / 业务异常治理.

           https://blog.csdn.net/fei33423/article/details/125624659

            异步多阶段, 同步的根因定位.

            但是有些是从入口是根因需要特殊技术手段
             疑难案例1: 例如 用户有三张银行卡, 其中有一张因为某个原因渠道可用性解析失败, 整理是成功的, 但链路里部分出现了非强依赖error. 但实际上用户是无法支付. 需逐个采集这种异常日志.

             技术化方案: 在入口处打标,上下文传递. 把核心业务的流量相关的error信息都整理出来. 逐个分析. 特别是list这种的. 也就是该业务标识链路下出现rpc中项链的是同一个接口或者db接口的情况. 又自动打上标记, 这种链路不管是否对业务有影响都需要重点关注, 梳理. 

              业务化方案: 从客诉的角度整理, 归纳治理.