Kstry能做什么？如果遇到以下问题：【业务歧义】代码复杂，模型文档更新不及时，让新生和非技术类的同学无法在短时间内了解当前的业务情况。在不知情的情况下，对同一业务的技术和非技术理解存在差异。甚至业务负责人也不能很流畅的描述自己负责的业务【代码凌乱】项目中涉及的领域对象很多，不仅对象之间依赖关系复杂，而且相互混杂，没有明显的界限，而且代码多次迭代后的变化。混乱难维护【低性能】一个业务环节由一系列子任务组成，其中一些需要长时间并行处理，数据之间没有依赖关系，但缺乏精简而无代码并发框架【平台【上】维护平台化产品，为上游众多业务线提供基础服务，但短时间内难以响应各业务方的定制化需求，我不知道如何做好平台与业务、业务与业务的隔离【回溯难点】业务流数据状态难以追踪，仅存在于平台中的偶发问题更难排查在线环境。需要通过简单操作保存重要节点数据的能力。这种能力堪比微调环节后的系统日志打印。【复杂测试】业务场景繁多，测试难以覆盖的复杂环节较多。或者三方数据Mock难度大，测试成本还高，可以试试Kstry框架，因为它有：可视化框架引入业界通用的BPMN流程布局语言，使用事件节点等组件，任务节点和网关节点来描述业务操作和执行。行布局的图形化模型才是代码真正的执行环节。通过所见即所得（图形模型）即所见即所得（代码执行）的方式，在技术和业务之间架起一座共同语言的桥梁，让他们之间的沟通更顺畅服务编排框架划分领域边界，实现业务通过定义服务节点来实现功能。服务节点对应代码中Class的某个方法。承担一个业务动作或领域能力，输入完成任务所需的最小参数集，输出任务完成的结果或处理后的领域对象节点，使用箭头符号的可视化排列方式，保证彼此之间的有序交互，通过并行网关丰富节点间的执行依赖，包括网关、独享网关等。框架支持子流程的定义，可以为子流程设置超时时间。支持指定非严格模式，非严格模式的子流程执行失败后不会影响外围流程的执行自定义操作支持并发无需更改代码，只需要在上面配置open-async=true即可parallelgateway或者includedgateway，然后可以并行化后续的子链路。RBAC（Role-basedaccesscontrol）模式针对的是平台服务。首先，可以定义和编译通用链接模型模型中的某个任务节点，在响应不同的业务场景或需求方的需求时，可以扩展不同的服务能力（例如，业务双方A和B都需要委托服务，那么可以定义一个rake任务节点，然后A业务需要一个比例rake，而B业务需要一个阶梯rake，那么可以在rake任务节点上扩展两种不同的rake能力）得到的能力可以看作是资源。所有的资源都有唯一的资源名称，携带一个包含一定资源名称的权限对象就可以访问相应的资源（资源也可以称为：扩展服务能力）。一批独立的权限对象维护成本高，因此可以将某个业务场景需要的所有权限依次聚合形成一个角色对象。在提供平台能力时，可以根据参数标识确定具体的业务场景或需求方，找到对应的角色，承载该角色执行预设的链路模型，即可完成定制化的业务需求。详见：RBAC模式流程回溯。可以在链接执行后，得到结果或异常前打印流程回溯。节点执行日志或自定义回调方法可用于处理以下问题：查看已运行节点信息，如：执行顺序、节点耗时、入参、出参、异常信息等重要数据自定义处理回溯日志，或者在异常发生时打印详细日志，检查节点执行和参数设置是否符合预期。因为有时候结果不报错，但不代表过程没有问题。如果链接中有自定义角色操作，检查最终角色是否符合预期。简化测试不依赖于业务方的输入，而是通过模拟业务角色的方式。然后请求承载该角色完成个性化服务链路的测试，包括待测试的服务节点或能力扩展点。如何使用Kstry？以下步骤只是简要介绍。详见使用文档Kstry使用文档Kstry使用demo功能测试1.配置导入
