架构师之中台思维_系统发展之路_结果和抽象之间平衡的艺术

父文章

   如何成为一名架构师,架构师成长之路_golang架构师成长之路_个人渣记录仅为自己搜索用的博客-CSDN博客

任何系统的发展都是如此.

1. 业务增长

2. 烟囱增长 _ 结果优先 _ 太快去抽象抽象不好

3. 太多的烟囱,

   3.1 抽象复用为平台

   3.2 面对更多新的业务,提供不同的枚举值能力. 平台开始复杂

   3.3 平台本身下游不停地下沉,上浮

4. 更多的业务方接入,抱怨程序传参复杂, 另外不够灵活,新的业务接入需要开发

   4.1 面对不停地下游系统的沉淀,更多的业务接入,减少上游的对接成本, 枚举值笛卡尔积被抽象成业务id,有中台同学配置,提供业务id (bizSceneId或者两码pdCode,eventCode). 提供了策略点平台,还有规则引擎 -> 动态脚本. 支持不同业务不同参数灵活配置.

        写死的数据结构变成了动态的数据结构,通过kV遍历 或者 脚本动态判断. 

平台系统建设所具备的能力_个人渣记录仅为自己搜索用的博客-CSDN博客

状态机/流程引擎/审批流的流程引擎/结合低代码开发的流程引擎 区别 业务系统中使用流程引擎_spring状态机 流程引擎区别_个人渣记录仅为自己搜索用的博客-CSDN博客

   4.2 基于数据结构提供通用的页面- 支付收银台

5. 海量的业务方, 5.a 配置本身就是成本 5.b 还要5个下游一起联调 5.c 配置的脚本各种参数, 严重干扰中台同学, 5.d ext中有什么根本不知道,全部透传. 存在覆盖风险.

        5.1 策略点平台变成中台回调平台,真正中台化, 仅传参唯一id, 中台同学不再识别业务属性,ext变得清爽.

        5.2 出现业务门面facade, 提供产品化运营后台, 支持业务方自由配置,选择一些模版进行配置.

阶段	问题	解决方案	中间件技术