工作流替代后台函数代码的弊端主要包括缺乏相互操作性、缺乏正确性和可靠性的支持、性能问题、缺乏分析、仿真和纠错工具、底层通信平台不完善、以及企业实施的复杂性。
- 缺乏相互操作性:各个工作流管理系统之间并不能真正意义上做到互相兼容,这主要是因为软件开发中缺乏统一的标准。这导致工作流软件之间的互操作性差,影响了系统的整体效率和灵活性。
- 缺乏正确性和可靠性的支持:在工作流实例运行过程中,可能会出现多个活动同时访问共享资源的情况,若这几个活动在数据操作上是相互重叠的,为了保证系统能够正常运行,需要进行并发控制,防止出现“脏数据”等现象。此外,当工作流不正常中断时,如何恢复数据的一致性也是一个需要解决的问题。
- 性能问题:目前的大多数工作流软件不能满足企业对每天处理上千万个,甚至每小时几千个业务的需求,需要拓展。这意味着工作流软件在处理大量数据时可能会遇到性能瓶颈。
- 缺乏分析、仿真和纠错工具:现在的工作流软件还缺乏对工作流进行分析、仿真和纠错的类似工具,这使得在设计和调试工作流时,难以有效地发现和解决问题。
- 底层通信平台不完善:异构系统的通信技术目前还并不成熟,这造成了企业应用工作流管理系统时的额外负担。
- 企业实施的复杂性:工作流应用的开发不仅仅是过程的定义,还需要同事处理其他的许多任务,例如,对外部的应用系统进行封装、建立工作流引擎运行所必须的分布式计算环境、设计开发相应的用户界面等。目前的工作流软件几乎不能为这些任务提供比较有力的支持。
综上所述,虽然工作流管理系统在某些情况下可以替代部分后台函数代码,提高开发效率和系统灵活性,但同时也面临着上述一系列的挑战和限制。
工作流的性能瓶颈太严重了
想要这些东西,就自己组研发团队吧
这是一个很好的问题。 但是也是一个完美主义式的诘问。作为一个 APaaS,它不能和原生技术栈的所有优势来比较。用户得到了零代码实现的价值,必然也会在某些地方有所牺牲。
HAP 的工作流实际上是一个自动化程序执行的编排工具,但它的每一步执行依然是原子化的。因此,正确性和可靠性需要用户有理智的编排,比如防止不可控的并发数据更新。工作流软件不像应用软件,为了提供必要的灵活性和自由度,它并不能保证任意搭建的工作流都能够正确运行。死循环也是可能的(系统有一定的 FailSafe 机制)。
性能问题也是一个折衷,为了保证可靠执行,工作流使用队列机制,这可能导致任务排队。为了弥补这个问题,我们也提供专属算力服务,私有部署用户也可以使用这个工具来改变任务优先执行次序。
有关分析,仿真和纠错,我们在工作流中提供了测试工具,理论上可以帮助用户更轻松地排查错误。
至于不同牌号的工作流软件的互通性,我觉得并不现实。即使有这个需求,也应该通过 API 方式来实现。明道云的封装业务流程可以打开平台 API 能力,从而在我们这一侧提供好 Interoperatability.