用GPT-4这样的大模型玩狼人杀，人类因为太蠢被投票判死，真正的逆向图灵测试
06-17
1。概述 标准运维V3是一个通过可视化图形界面编排和执行任务流程的系统。
是腾讯蓝鲸产品体系Orchestration SaaS产品中的轻量级调度器。基于腾讯蓝鲸PaaS平台的API网关服务，连接企业内部各个系统的API能力，将多个系统之间切换的工作模式整合到一个流程中，实现一键式自动化调度。
用户编排的流程由标准运维底层使用的bamboo-pipeline流程引擎进行调度和推动。经过多年在各种场景的使用，发动机本身设计上的一些问题也暴露出来。
为了给用户提供更好的服务，让规范运维走得更远。我们决定对底层流程引擎进行重构和升级。
2. 老引擎存在的问题 老版本的bamboo-pipeline引擎在设计和实现上存在以下问题： 序列化粒度：流程执行数据序列化粒度过大，导致额外的IO开销 序列化方式：流程执行数据序列化序列化方式使用pickle，序列化后的数据不可读，导致问题排查困难。流程数据存储方式：流程结构数据和节点数据不分开存储。
当节点输出数据增长时，会导致执行数据膨胀，影响引擎的性能。引擎架构：引擎的控制面和执行面没有分层，导致引擎核心调度逻辑与具体框架的耦合度较高。
2.1.序列化粒度bamboo-pipeline在生成引擎执行数据后会将整个流程对象序列化并存储。数据库中的这种序列化粒度太粗糙，对于小进程（节点数量较少）不会造成特别大的问题。
但当处理大型进程时（节点数量达到数百或数千），问题就会暴露出来。因为引擎推进流程的步骤是：读取当前节点信息，推进并执行节点。
如果遇到需要轮询或者等待回调的节点，就会放弃引擎调度权，发生调度切换。由于流程数据序列化粒度是整个流程，因此第一步需要读取所有流程数据。
即使当前进程只会继续前进一个节点，也需要读取整个进程的数据，这会在引擎进行调度切换时造成很大的开销。 。
2.2.序列化方法bamboo-pipeline使用pickle来序列化流程执行数据，pickle是python内置的二进制序列化方法。协议会随着python的升级而改变。
bamboo-pipeline当时升级到了python2。在python3中，我们处理了由于pickle协议升级以及python内置对象升级导致的旧数据反序列化失败的问题。
而且pickle序列化后的数据是不可读的，这大大增加了故障排除的成本。 2.3.流程数据存储方式：流程执行过程中，节点会产生执行数据，这些数据也需要持久化存储。
竹子管道将执行数据和流程对象一起存储在数据库中。这导致当节点输出数据增长时，进程执行数据随之膨胀，增加了引擎调度切换的开销。
2.4.引擎架构bamboo-pipeline没有对引擎的控制面和执行面进行分层，导致整个流程引擎SDK与具体框架（Django、Celery）强耦合，不利于后续引擎升级和新引擎的开发功能。用户的使用成本也比较高。
3.新引擎的设计为了解决上述问题，我们设计并实现了新版本的引擎——bamboo-engine。目标是：解决竹管道存在的各种问题，增强发动机的鲁棒性和容错能力。
增强引擎可观测性升级允许两套引擎同时存在并运行，为灰度切换和升级提供了可能。针对上一节提到的各种问题，新引擎的解决方案如下3.1。
序列化粒度bamboo-engine采用更细粒度的Serialize方式，将流程中各个节点的数据进行拆分存储。这样保证了引擎能够以最小单元（单节点）进行读取，减少调度切换时不必要的开销，提高引擎调度效率。
3.2.序列化方式bamboo-engine采用JSON格式进行序列化，消除了对pickle的依赖，降低了后续引擎版本升级和故障排除的成本。 3.3.流程数据存储方式bamboo-engine不仅将各个节点的数据进行拆分存储，而且将节点执行的数据单独存储。
保证过程静态数据和动态数据的存储分离。同时，即使节点输出较大的执行数据，也不会影响后续流程的执行效率。
3.4.引擎架构bamboo-engine由两部分组成：引擎和运行时接口。引擎模块负责实现进程的核心调度逻辑，即进程的前进逻辑、各类节点的处理逻辑、进程的调度切换逻辑等。
Runtime接口为引擎提供流程运行时数据存储、流程流程管理、任务调度的实现。两者之间的关系如下图所示： 抽象运行时的好处是，如果系统默认提供的运行时在某些方面不能满足项目的需求，可以基于系统实现一套新的运行时运行时接口，可以直接集成到引擎中。
同时，为了增加系统的可观测性，bamboo-engine 会记录核心指标，并提供采集入口，用于访问蓝鲸监控、Prometheus 等监控系统。 4、新旧发动机对比，操作维护规范。
完成新发动机的升级后，我们进行了对比测试。使用的测试流程如下： 测试环境为 代码语言：txt copy MacBook Pro（16英寸，） 处理器：2.6 GHz 六核 Intel Core i7 内存：32 GB MHz DDR4操作系统：macOS Big Sur 11.2.1Broker：RabbitMQ 3.8 .2engineworker以gevent模式启动。
并发测试进程：在新旧引擎上同时创建并启动测试进程，测量以下指标：进程中所有节点的平均执行时间（等于进程执行时间-调度切换时间）平均进程执行时间 所有进程的总执行时间（最后完成的进程完成时间-最先启动的进程启动时间）测试对比数据如下： Metrics：旧引擎和新引擎进程中所有节点的平均执行时间。 76年代。
37秒。平均流程执行时间。
1秒。 3秒。
所有进程的总执行时间。 s。
引擎内部调度时间。 1 - .76 = 30.34s.3 - .37 = 5.93s 可以看出，新发动机的吞吐量比旧发动机增加了一倍。
同时，引擎内部调度时间也大幅减少。可见，这次升级是有效的、值得的。
新引擎地址：），下载社区版6.0基础包，安装标准运维SaaS，体验一下。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-06
06-17
06-18
06-17
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用