工作流引擎在视频网站架构中的应用

如果对工作流引擎没有了解过的同学可以先看前一篇文章：
土制状态机在工作流引擎中的应用
http://ahuaxuan.iteye.com/blog/505124

/**
* @author: ahuaxuan(张荣华)
* @date: 2009-11-23
*/
[size=medium]
       在一个视频网站中，用户从上传一个视频，一直到视频能够正确的被其他用户下载观看，其中经历了一个很长的流程。


下面ahuaxuan来画一张图来表示这个简要的流程，但是实际上不同视频网站由于其架构的不同，可能也会导致流程图中有些环节的增加或者减少。




从上面这张图上，我们可以看到的是一个简要的视频处理流程，而这个流程理论上来将并不是一成不变的，它会随着业务的变更而变更。如何更好的打造出一个视频处理系统应该是每个视频网站都比较关注的话题。


如何能够快速的变更流程，如何灵活的做到这一点，而无需大量的修改代码或者重新开发一个项目来替代老的项目呢？

其实工作流引擎在这个领域更为合适，一个轻量级的工作流引擎即可以满足这样的需求，大部分人对工作流的认识或者经验都停留在一些OA, ERP, PLM系统上，对于无人参与的工作流系统可能并没有相关的经验，关于这个话题，下面ahuaxuan来作一个较为详细的说明(我们将基于工作流引擎的视频处理系统称为VideoProcessSystem)。

在视频处理的流程中，转码和CDN发布尤为重要，而对于转码服务器来说都是一个个群组，而CDN发布则有不同的方式，有推或者拉两种模型，推模型有专门的CDN发布程序来将转码之后的视频主动的发布到各CDN节点上去。而拉模型中，CDN节点将来主动下载需要发布的视频，而在这之前，它首先要得到需要发布的视频的地址。

这意味着我们VideoProcessSystem将会有很多的client, 而且这些client有不同的类型。
上面这句话其实还有另外一层的含义，它可以抽象另外一个模型－－－－》user role.
不同的转码服务器或者发布服务器其实就是VideoProcessSystem的user,而转码服务器则是它们的角色，发布服务器则是另外一种角色。这意味着工作流引擎的用户都是机器，而根据机器工作的类型，我们可以给其分配角色

在一个视频处理的流程中，不同的role的user会在不同处理流程的不同阶段对视频进行处理。而由于工作流引擎的存在，每个步骤都变得相对独立.

举例来说:
1. 当用户上传一个视频之后，其实就在VideoProcessSystem启动了一个视频处理流程，流程启动之后得第一个节点(state, step)应该应该是选择一个转码服务器（可能根据cpu, memory得历史负载选择一个），然后这个被选中得服务器会访问VideoProcessSystem，拿到属于自己的这个节点(state, step)信息，其中包含视频的下载地址。


转码服务器得到地址之后开始下载源视频，下载成功之后校验视频的checksum，正确之后开始转码。

转码成功之后回报给VideoProcessSystem, VideoProcessSystem会为这个视频创建CDN发布的节点（state, step）

............

就这上面短短的三步中，其实就已经包含了很多内容，为什么呢，比如说下载视频，可能发生源视频下载url不正确的错误(404)，也可能发生缴验码不正确的情况，或者转码的时候进程崩溃等等，总而言之，有可能发生一堆错误，那么如何处理这些错误就变成了VideoProcessSystem的重中之重，不过得益于我们的工作流引擎，我们在遇到这些错误的时候可以更灵活的处理它们，比如转码服务器遇到checksum的错误，则可以汇报给VideoProcessSystem， VideoProcessSystem会通过流程的定义来决策下一节点(state, step), 比如说可以告诉客户端重新下载，重新下载之后还不正确就通知流程创建着，或者跳转到结束或者挂起节点(state, step)。

我们来看一个基于osworkflow的VideoProcessSystem的流程处理片段：

<action id="13" name="failure">
					<!-- 
					What's the failure reason here?
					1. how to do if the target URL is error
					2. how to do if the checksum is not match
					 -->
					<restrict-to>
						<conditions type="AND">
							<condition type="class">
								<arg name="class.name">com.opensymphony.workflow.util.StatusCondition</arg>
								<arg name="status">Underway</arg>
							</condition>
						</conditions>
					</restrict-to>
					<results>
						<!-- 
						Pls think the different result here. Why?
						Different reason, different next step!
						 -->
						<result old-status="Finished" status="Queued" step="1" owner="${mostRecentOwner}">
							<conditions type="AND">
								<condition type="beanshell">
									<arg name="script">
									propertySet.getString("checksum error").equals("test")
									</arg>
								</condition>
							</conditions>
							<!-- TODO this post functions is very important because if the checksum is error, 
							the function should reset the task, which is associated with this step, here the step is existed, no problem-->
							<post-functions>
								<function type="beanshell">
									<arg name="script">
                                        System.out.println("reset the task");
                                    </arg>
								</function>
							</post-functions>
						</result>
						<result old-status="Finished" status="Queued" step="1" owner="${mostRecentOwner}">
							<conditions type="AND">
								<condition type="beanshell">
									<arg name="script">
									propertySet.getString("url error").equals("url error")
									</arg>
								</condition>
							</conditions>
							<!-- TODO if the download error error, the step should go, but where to go??  
							End the step and notify the client, or something else-->
							<post-functions>
								<function type="beanshell">
									<arg name="script">
                                        System.out.println("url error, ask the client to get new url, how the step go?????????????????????");
                                    </arg>
								</function>
							</post-functions>
						</result>
						<unconditional-result old-status="Finished" status="Queued" step="1"/>
					</results>
					<post-functions>
						<function type="beanshell">
							<arg name="script">
								System.out.println("if download failure, the logger should log the reason here, log to DB, or somewhere");
                            </arg>
						</function>
					</post-functions>
				</action>

这意味着有了工作流引擎，整个VideoProcessSystem将会变得非常的灵活，我们不需要硬编码整个流程，不需要硬编码某个错误处理。

当然其实我撒谎了，其实上面说道无人参与的视频处理流程这个言论是不正确的，因为我们还有审片，见下图：


在视频网站中， 视频的发布离不开审片，而审片目前都是靠人来完成的。那么也就是说转码之后，其实我们并不是要将视频发布到CDN,而是先将视频交给审片组审查，那么这里通过之后才能发布，不通过则不能发布。虽然ahuaxuan到最后才提出这一点，但是这并不能难倒我们VideoProcessSystem的，我们之需要再定义一个节点(state, step),然后将这个节点的操作者将会是human,审片的xdjm们同意就点击approve, 不同意就reject,然后流程就能按照我们定义的方式转化，比如说reject之后这个流程就跳到一个有害视频处理的节点，approve就产生CDN发布的节点(state, step)

于是，VideoProcessSystem就变成了一个客户端是人机混合的基于工作流引擎的视频处理系统。

在拥有了这么一个灵活的，基于配置的视频处理系统之后，接下来做什么？ 当然是继续优化其他的架构。
[/size]

评论

2 楼 jeftom 2012-06-11  

楼主是土豆的么？

1 楼 化蝶自在飞 2010-05-22  

转换格式应该放最后吧? 太深奥,看不懂 ^