业务需求永远第一
没有和 PM 吵过架的 RD 不是好 RD，那没有被需求整哭过的人生不是完整的人生。
一直以来，PM 和 RD 就是一对欢喜冤家。 “这个需求很简单，就是加个按钮” “你能不能想清楚再提。这个需求能带来多大收益？” “小哥哥，我要改个颜色，马上上线，急” “能不能晚点和其他需求一起上线？” ...
现实中，PM 的需求有时候就是合理的；现实中，有些 RD 的疲于应付就是架构设计不到位；现实中，有时候哭过的 RD 才能成长得更好。
下面我们就来看下这个场景。
典型场景
相信在很多业务下我们需要定义一些规则，比如满足规则 A，则 xx1，满足规则 B 则 xx2。用一个“高端”一点的表达就是一棵决策树，很简单的需求。
图一：规则的决策树表示
基于这种思维方式，在一次活动期间，我们需要对参与活动的人进行风险控制。PM 的需求很简单：两个人是好友，则 3 天内只能使用 1 个优惠，两个人不是好友，则 3 天可以使用 2 个优惠。
用决策树表示则为：
图二：需求Demo
程序员成长之路
01 / 程序员1.0
无知者无畏
涉世未深的程序员，看到这个需求后，心里暗暗的觉得“so easy”，不就是 if/else 轻松解决么。
有经验一点的程序员，心里盘算，PM 是易变的生物，这些“几天几个”肯定要变来变去，得配置化。
因此针对这个需求的 1.0 版本：
图三：基于纯业务开发的系统
看似完美的解决方法，上线后，等待程序员的苦日子就来了。
- 我需要把某棵树的 A 节点和 C 节点重新组织，形成一条行的规则。
- 我需要修改阈值，修改时间范围。
- 我需要根据不同的规则，触发不同的响应。
。。。
拥抱变化，程序员 1.0 开始忙于改配置、测试、上线。随着策略变复杂，需求变化更快，上线出问题也越来越多。程序员 1.0 开始应接不暇了，开始频繁的出错，决策树代码复杂而不可维护了。
我明明很努力，怎么结果就这么不好呢。凌晨下班的1.0，落下了“不甘心的泪”。
02 / 程序员2.0
迭代是互联网的利刃，也是我们程序员持续成长的法宝。
2.0 版本的程序员，吸收了前面的经验教训，在决策树的原理上，复用最大化。我们将决策树的每个节点都按照最小化规则来组织，抽象最小规则元素。
图四：最小规则抽象
特征：按照一定业务逻辑实现的类型。比如是否好友、3天使用优惠数量等等
阈值：配置的触发规则的值
逻辑判断：用于比较特征和阈值之间关系的实现。
对于决策树的分叉，在逻辑上可以抽取成独立的链式关系。即对于图一，我们可以抽象出 ABB1/ABB2/AC 三条规则链，且三条规则链相互独立。
图五：链式规则
对这个链式的规则结果进行统计，将得到和决策树一致的结论，但是节点的存储和组织更加的冗余了。
基于这个认知，我们做了一个规则引擎：
图六：基于最小节点的规则引擎设计
所有的节点都格式化成：特征、阈值、逻辑判断 三要素
所有的决策树打散成独立的链式节点
标准化，表示我们可以搭建一套很完整的产品管理后台，彻底释放RD的生产力。
程序员2.0 松了一口气，总算熬出头了。
03 / 程序员3.0
追求更高、更快、更强。
自研的规则引擎就完事了吗？显然不是，程序员成神的道路没这么简单。
相同的需求，隔壁公司会怎么做？比如美团Maze框架？
基于链式规则不够精简，是否用DAG（有向无环图）方案更科学？ 开源的Drools 有什么优缺点？
实现功能的方案有很多，NX的架构师，不会唯技术论，也不会让自己跟着需求追。
这个时候有一句名言“任何脱离业务场景谈架构，都是耍流氓。”（没错，就是我说的。）
在成大神的道路上，必定充满坎坷。有些人需要3年，有些人需要5年，但人生有多少个5年。我创业做IT教育培训，就是希望能够帮助技术人，做好指路人，用我的经验，将场景与技术结合，让技术人具备更高的架构设计能力，节省最宝贵的时间成本。
下面是我和沈剑一起打磨的课程思想 发、高性能的架构特性，从底层框架到上层业务应用的课程内容设计，涵盖了主流技术框架以及架构师需要具备的多维度视野。
1、全网首推分布式系统全链条技术由点连成线实战课程
从基础组件到业务架构设计、测试 CI/CD 到运维安全，深度剖析分布式系统后端所有技术环节，将涉及知识点连接成"线"，掌握企业及解决方案设计方法；
2、全套基础架构设施建设实践剖析
后端基础架构全套设施深入剖析：开发框架、服务治理、存储系统、基础服务/中间件，体验基础架构从 0 到 1 的建设过程；
3、全新视角，对业务架构逐层剖析，掌握架构设计精髓
对业务架构进行逐层深入剖析，掌握经典三层架构（网关层、业务逻辑层、数据访问层）设计方法;
4、基于业务快速反应的智能运维实践
从反向代理，DNS、CDN 等基础设施，到服务器选型、网络安全防护技术展开，高效利用服务器资源，保证服务系统与数据安全；
