主题
近段时间整理可视化编排类的内容比较多,很多时候都是提取概念,逻辑没有自洽,经常除了功能设计和逻辑实现思路之外要充分的考虑别人的灵魂拷问，这个玩意儿有啥用,分享过程以作记录
发现身边事儿、聊点周奇遇，我是沈二，期待奇遇的互联网灵魂~、一起聊天吹水，探索新的可能~wx:breathingss，入圈吧！
谈谈过程
随着前后端分离架构、微服务架构、中台战略、产业互联互通的实施必将产生大量的各种协议的API服务，API将成为企业的数字化资产且API会越来越多， API服务之间的相互调用和依赖情况也随之越来越多和复杂。业务系统与业务系统之间、关联企业之间的API都相应存在大量的API相互调用和逻辑重组需求、 使用传统的编码方式已完全不能满足业务敏捷化交付的特性，简而言之，随着服务粒度的细分和人员的网格化,许多的事情不能简单的用 "这个事儿，我开发比拖拽快多了" 的思路去下结论, 敏捷化交付能力,更多的是把系统往平台化转变,把定制部分公共化,配置数据化。
-
QA 1.类似magic-api那种快速开发框架，不是更香嘛，表层级和代码部分的灵活性更高,为啥不合适?
涉及到一个场景问题,服务编排聚焦的是服务,多服务的接口资产的业务内容,协调的边界更多的是约定好，我要去干个什么事儿,你需要提供什么接口（一般稳定的业务,涉及到外部交互的,都会有通用接口,重新开发的可能性低,再有就是职责边界的问题,满足不了需求，新增接口处理）,所以重点其实在职责边界和粒度问题。
-
QA 2.炒菜前得清楚冰箱里面有啥原料才能决定炒啥菜,同理,一个重要的前提就是接口的资产如何集中和枚举?
这个问题是个绕不开的话题,如果仅仅是单体应用,接口文档在对接过程中就是产生,但跨业务跨团队这种模式下,要想实现一个跨业务定制化编排逻辑接口,已经非功能上的问题,而是此项工作如何去执行的问题，不可能新增一个就要问一圈,这就是个硬伤，同样的，接口swagger的更新和集中、授权又会带来新的问题。 Torna接口文档解决方案，也许是你在前期的整体设计中没考虑到此类情况的补救措施。
QA 3.代码开发线上处理,很多入参/返回、逻辑判断、遍历、中断、赋值等都是很难处理的问题,可视化处理覆盖不了完全的场景，意义在哪里?
区分三个点来说这个问题，可视化、编排逻辑、动态发布，与其说意义在那，不如说其执行的场景边界和功能上限，如果说完全满足开发层级的覆盖要求，那就跟最近 "螺纹钢磨石头" 的行为没啥区别了。
- 可视化 可视化指代的更多是让业务可见，类似于流程图，看了此项就知道这个接口是的大概处理逻辑是怎样的，同时诸如变动性高的接口,完全可以在不发版的情况下,实现诸如活动变更、计费策略、业务逻辑等周期性或者可变性高的接口。
- 编排逻辑,一个接口开发，大致会有，接口的定义(入参、返回、验证、默认值、逻辑判断、循环、异常、赋值)等操作、针对服务编排,基本上就是多个服务的逻辑组合赋值、最终返回符合定义的返回结果，如果把这个过程落到功能上，基本要处理的节点就涵盖开始、接口、循环、逻辑判断、延迟、并行/串行、异常捕获、调试等功能,重点其实就在接口处理层级。
- 动态发布,一个逻辑被定义好了,需要在执行逻辑的同时根据定义部分动态发布可用的接口,与普通的接口相同,也是需要入参、出参等接口定义部分的内容。
说说结果
此项技术路线与之前实施的规则引擎属于不同的技术思路、前后端均是不同的思路，之所以没有采用一套方案是因为场景和具体的交互思路、周期、技术栈均有所不同，规则引擎对运行调试的要求以及跟节点和结束节点均没有强约束、而服务编排对开始和结束是由强约束的。
- 接口列表
- 定义
- 编排
总结
之前对规则、ETL编排、流程、接口编排、爬虫等的思路都有了一些了解,实现的多了发现其实etl编排的过程也不见得像之前想的那么复杂和困难，更多的是经历实际生产场景的锤炼,不断的完善修复，总归是会出现良好的正向结果。