独立服务应是默认架构选择，及"等待"的常见误解

使用工作流引擎有两种基本方式：作为独立服务运行（自包含应用程序，业务应用与它远程通信）或作为库嵌入服务（跑在业务应用程序进程内部）。作者明确建议独立服务应该是默认选项——这样能把业务服务代码和工作流引擎彻底分开、避免许多问题；作者提到支持嵌入式引擎的案例时，往往要花大量精力才能搞清客户到底是怎么嵌入的、问题从哪产生的。独立服务还带来语言层面的异构能力，配合Docker和云托管服务，现代环境下运转起来非常容易。工作流引擎的内部实现（自己实现调度、线程维护、持久化）是不同产品间最大的差异点——有的用关系型数据库存状态（随流程进展持续更新流程定义和实例的记录），有的用非关系型数据库、偏事件溯源的方案以支撑横向扩展、高吞吐、低时延或实时服务（这种扩展性超出了关系型数据库的能力范围）；使用者虽不必操心具体存储方式，但仍要了解它带来的影响（比如若用关系型数据库，得知道支持哪些数据库产品）。一个容易被误解的术语是”等待”或”长期运行”：这不是说工作流引擎的线程被阻塞、死等某个事件——恰恰相反，工作流引擎把当前状态存进数据库，处理完当前这一步后线程就退出，之后什么都不做；流程实例”逻辑上”仍在等待某个会导致引擎从数据库重新加载状态、恢复流程的事件（可能是用户按钮触发了API调用完成某任务，也可能是调度器因某个计时器到期而唤醒流程实例）——理解这一点，能避免把工作流引擎的”长期运行”错当成”占着一个线程死等”。