JAR包：如果我依赖你，那劝你别依赖我。一、技术视野1、背景描述在分布式系统搭建的初期，对于组件的选型是需要慎重考虑的，特别是对于同一个场景但是有多个不同组件可选项时，需要经过一定的调研再去确定最终选择，从而尽量避免后期业务发展引起核心组件的替换问题。不同的技术选型，意味着不同的依赖包和版本，作为工程的基础，复杂的系统中管理庞大的依赖，需要具备体系化的思维。2、开源体系从个人习惯上来看，在核心的技术组件选型上，优先考虑从Spring和Apache两个生态中寻找，所以要对这两套开源体系下的组件有广泛的了解，以及相关配套的集成工具，在开发过程中有很多复杂的技术实现都是有对应的封装包来解决，更多的时
JAR包：如果我依赖你，那劝你别依赖我。一、技术视野1、背景描述在分布式系统搭建的初期，对于组件的选型是需要慎重考虑的，特别是对于同一个场景但是有多个不同组件可选项时，需要经过一定的调研再去确定最终选择，从而尽量避免后期业务发展引起核心组件的替换问题。不同的技术选型，意味着不同的依赖包和版本，作为工程的基础，复杂的系统中管理庞大的依赖，需要具备体系化的思维。2、开源体系从个人习惯上来看，在核心的技术组件选型上，优先考虑从Spring和Apache两个生态中寻找，所以要对这两套开源体系下的组件有广泛的了解，以及相关配套的集成工具，在开发过程中有很多复杂的技术实现都是有对应的封装包来解决，更多的时
没有规则，不成方圆；一、背景前段时间，在做项目重构的时候，遇到很多地方需要做很多的条件判断。当然可以用很多的if-else判断去解决，但是当时也不清楚怎么回事，就想玩点别的。于是乎，就去调研了规则引擎。当然，市面上有很多成熟的规则引擎，功能很多，性能很好。但是，就是想玩点不一样的（大家做技术选型别这样，这个是反面教材）。最终一款URule的规则引擎吸引了我，主要还是采用浏览器可直接配置，不需要过多安装，可视化规则也做的不错。经过一系列调研，后面就把它接入了项目中，顺便记录下调研的结果。二、介绍规则引擎其实是一种组件，它可以嵌入到程序当中。将程序复杂的判断规则从业务代码中剥离出来，使得程序只需要
没有规则，不成方圆；一、背景前段时间，在做项目重构的时候，遇到很多地方需要做很多的条件判断。当然可以用很多的if-else判断去解决，但是当时也不清楚怎么回事，就想玩点别的。于是乎，就去调研了规则引擎。当然，市面上有很多成熟的规则引擎，功能很多，性能很好。但是，就是想玩点不一样的（大家做技术选型别这样，这个是反面教材）。最终一款URule的规则引擎吸引了我，主要还是采用浏览器可直接配置，不需要过多安装，可视化规则也做的不错。经过一系列调研，后面就把它接入了项目中，顺便记录下调研的结果。二、介绍规则引擎其实是一种组件，它可以嵌入到程序当中。将程序复杂的判断规则从业务代码中剥离出来，使得程序只需要
目录一、背景简介二、订单业务1、订单体系2、流程管理2.1流程拆分2.2正向流程2.3逆向流程2.4调度与监控3、结构设计三、技术方案1、订单ID2、并行与异步3、超时问题4、分布式事务四、数据方案1、转化分析2、分库分表3、数据同步五、参考源码订单，业务的核心模块；一、背景简介订单业务一直都是系统研发中的核心模块，订单的产生过程，与系统中的很多模块都会高度关联，比如账户体系、支付中心、运营管理等，即便单看订单本身，也足够的复杂；业务在发展的过程中，必然会导致订单量的持续增加，订单自身、数据体量、实现流程，都需要不断的迭代更新，如果在订单流程的研发初期，没有相对全面的考量，那么很有可能导致中后
目录一、背景简介二、订单业务1、订单体系2、流程管理2.1流程拆分2.2正向流程2.3逆向流程2.4调度与监控3、结构设计三、技术方案1、订单ID2、并行与异步3、超时问题4、分布式事务四、数据方案1、转化分析2、分库分表3、数据同步五、参考源码订单，业务的核心模块；一、背景简介订单业务一直都是系统研发中的核心模块，订单的产生过程，与系统中的很多模块都会高度关联，比如账户体系、支付中心、运营管理等，即便单看订单本身，也足够的复杂；业务在发展的过程中，必然会导致订单量的持续增加，订单自身、数据体量、实现流程，都需要不断的迭代更新，如果在订单流程的研发初期，没有相对全面的考量，那么很有可能导致中后
都说认知以外的钱难搞，那认知内的呢？01互联网内卷年代，作为不着调的普通选手；在诸多花里胡哨的黑话中，个人最待见的就是"认知"这个词；认知，有强烈的抽象感；想要深刻理解抽象的概念，可能需要上升到哲学层面，或者所谓的人性层面；很显然，普通玩家达不到那个层次，更多的还是从实践中搭建认知体系；个人理解；认知就是对事物认识的多少和知道的深度层次，即认知范畴内的广度和深度；广度影响思维的开阔性，深度决定思维的正确性；实践出真知；实践是一个复杂的过程，也是结果和经验的持续积累；基于实践周期所得的认知，自然也是曲折和漫长；认知从内在来看：包括经历和实践沉淀的结果和经验，以及形成的思维体系；认知从外在来看：是
都说认知以外的钱难搞，那认知内的呢？01互联网内卷年代，作为不着调的普通选手；在诸多花里胡哨的黑话中，个人最待见的就是"认知"这个词；认知，有强烈的抽象感；想要深刻理解抽象的概念，可能需要上升到哲学层面，或者所谓的人性层面；很显然，普通玩家达不到那个层次，更多的还是从实践中搭建认知体系；个人理解；认知就是对事物认识的多少和知道的深度层次，即认知范畴内的广度和深度；广度影响思维的开阔性，深度决定思维的正确性；实践出真知；实践是一个复杂的过程，也是结果和经验的持续积累；基于实践周期所得的认知，自然也是曲折和漫长；认知从内在来看：包括经历和实践沉淀的结果和经验，以及形成的思维体系；认知从外在来看：是
怎样的架构才能配得上造到飞起的变化？一、软件复杂性1、复杂原因如果软件系统存在持续的迭代周期，那么其中业务、技术、架构的复杂性都会直线拉升，其相应的开发难度也会提高，可以用一句话总结其根本原因：唯一不变的就是变化；业务变化：导致复杂性的根本原因，在多端多版本适配的过程中代码快速膨胀；数据变化：数据随着业务的变化和发展，不断沉淀积累，需要做横向与纵向的管理；技术升级：技术组件可能因为漏洞，或者更好的解决问题，不间断升级版本；人员变动：模块的开发人员一旦出现流动，换人接手会给代码带来风格上的差异；心态起伏：持续应对复杂问题，但平稳的心态很难持续，也是人员流动的一个因素；应对复杂的变化一直都是软件工
怎样的架构才能配得上造到飞起的变化？一、软件复杂性1、复杂原因如果软件系统存在持续的迭代周期，那么其中业务、技术、架构的复杂性都会直线拉升，其相应的开发难度也会提高，可以用一句话总结其根本原因：唯一不变的就是变化；业务变化：导致复杂性的根本原因，在多端多版本适配的过程中代码快速膨胀；数据变化：数据随着业务的变化和发展，不断沉淀积累，需要做横向与纵向的管理；技术升级：技术组件可能因为漏洞，或者更好的解决问题，不间断升级版本；人员变动：模块的开发人员一旦出现流动，换人接手会给代码带来风格上的差异；心态起伏：持续应对复杂问题，但平稳的心态很难持续，也是人员流动的一个因素；应对复杂的变化一直都是软件工
