最近有个技术团队的CTO 交流的时候，聊到了逻辑引擎、API服务编排，他很反感逻辑的编排，觉得还不如写代码来得快。
对方是一个小型的交付团队，对方的老板（也稍微懂一些技术，不是很深刻），希望通过快速配置化的方式提升交付效率，降低交付成本，所以当时约了个在线交流，参会的人员除了对方的老板、还有这个CTO 、以及另外一名后端开发人员。
交流的时候发现这个CTO 对配置化有抵触情绪。当然他也提了很多问题，感觉也可能是大家关注的问题，所以我整理出来也给大家分享分享。
交流的主要问题
- 引入配置化（逻辑引擎）技术复杂性增加：
JVS回复：
业务功能之所以复杂，是因为需求千奇百怪，逻辑引擎（服务编排）的本质，是把原子化的能力封装成标准，通过可视化的画布进行拖拽编排，链接，形成有业务价值的功能串
逻辑可以理解为基础的工具，工具一旦稳定了，很少出错，随着交付的同学写代码的量减少了后，bug 数量会减少，测试、运维的同学会减少，特别是业务逻辑是以图形化的方式呈现，至少会比读代码要简单一些，而且系统上支持 把多个节点分组展示，那么业务逻辑会更简单
2.“这个事儿，我开发的速度比配置的速度快多了”
JVS回复：
逻辑= 触发+原子服务+服务编排 ，触发的方式提供了多种场景，我们把很多基础服务抽象成了一些通用的能力
而且组件库可以通过界面化的方式扩展配置，所以对于交付团队而言，随着原子组件的逐步增加，这个会对行业的能力逐步加强。
这样的思路去下结论, 敏捷化交付能力,更多的是把系统往平台化转变,把定制部分公共化,配置数据化
随着原子组件增多，行业内的能力会越来越丰满，开发难度越来越低，而且速度会越来越快。 逻辑引擎是从降低综合开发工作量的角度来看，提升功能的复用度。
3.代码开发线上处理,很多入参/返回、逻辑判断、遍历、赋值、循环等进驻,可视化处理覆盖不了完全的场景。
JVS回复：
- 编排逻辑,一个接口开发，大致会有，接口的定义(入参、返回、验证、默认值、逻辑判断、循环、异常、赋值)等操作、针对服务编排,基本上就是多个服务的逻辑组合赋值、最终返回符合定义的返回结果，如果把这个过程落到功能上，基本要处理的节点就涵盖开始、接口、循环、逻辑判断、延迟、并行/串行、异常捕获、调试等功能,重点其实就在接口处理层级。
4.性能考虑：
JVS回复：
可视化指代的更多是让业务可见，类似于流程图，而且执行的性能和手写的代码运行的效率相差不大，从下图所示
系统提供了逻辑执行的执行监控的多个指标
逻辑引擎在微服务的基础框架上运行，可以对逻辑实现横向扩展，这样对并发效率上也提供了足够的保障。单机500并发压测数据：
5.监控和调试难度：
JVS回复：
逻辑支持动态调试与实时发布,一个逻辑被定义配置好了,需要在执行逻辑的同时根据定义部分动态发布可用的接口,与普通的接口相同,也是需要入参、出参等接口定义部分的内容，支持在线的逻辑实时调试与动态发布，调试过程中能查看到每个环节执行的具体情况，可以查看具体执行结果
6.学习曲线是否较低
JVS回复
凡是一般的后端开发人员，在简单的培训（2-3小时）后，可以便捷高效的使用逻辑编排引擎。并且JVS提供了大量的培训文档与培训的操作手册：
培训视频：
分析
API编排或服务编排在当下快速开发的模式下，它们有助于提高服务的模块化、可重用性和灵活性。然而，开发人员有时会对这些概念产生抵触情绪。以下是可能导致这种抵触情绪的一些原因：
部分开发人员对变革的抵触：
- 开发人员可能对新技术或方法持保守态度，尤其是当他们已经习惯了现有的工作方式时。
- 他们可能担心变革会带来不确定性或额外的压力，对工作的稳定性造成冲击。
- 引入API编排可能需要改变现有的开发、测试和部署流程，虽然简化了，但是传统的研发方式失效，从开发转向交互，对技术人员的需求门槛大大降低。
- 管理团队缺乏有效的开发的ROI的考核，决策者对开发的效能缺乏有效的理解与控制
另外，在交流的过程中，还发现除了逻辑的配置，对规则、ETL 也是有一定述求的，JVS是将逻辑、规则、ETL分别作为三个不同的工具，虽然基础的能力相似，但是业务场景不同，所以从体验的角度来看，使用的人群或有不同，所以将三个工具切分开：
规则引擎：
| ETL：
|
