星空的工作流可以使用同步和消息队列两种模式。相比较两种模式，消息队列模式可靠性更高，支持并发能力更强。但由于消息队列模式依赖Windows Mq消息队列服务，如果服务异常，会导致流程异常或者无法使用消息队列。本文章将介绍如何自行分析排查和修复消息队列服务异常。

1、工作流流程管理中心有一个环境检测工具，可以对工作流依赖的相关配置进行检测。如果有发现消息队列无法连接，可以连上服务器去检查。

2、在“运行”中输入services.msc打开服务，或者从管理工具中打开服务。

3、如果Mq服务未启动，可以尝试启动，如果启动出现异常，进行下一项分析。

4、先确认消息队列服务依赖组件是否有安装，如下红框组件必须确保有安装，如果没有安装，找到产品安装包，运行检测工具重新安装环境。

5、如果VC++ 2010有安装，则进行日志分析。查看K3Cloud/website/app_data/log/当天日期下的日志。先看有没有socket日志，如下

6、如果有K3CloudApp站点无法访问的日志，则需要先确认地址是否正确，如果不正确，例如缺少端口等，则修改Common.config的“ComputeSiteUrl”为正确地址。例如：

7、如果计算服务站点配置没有问题，但是K3CloudApp站点无法访问，则需要检查IIS站点配置。可以分别从以下几个地方检查。

    1）先看看应用程序池是否启动，标识是否为NetworkService。

    2）再检查网站绑定有没有限定Ip或端口。例如有些地址配置的http://localhost/k3cloudapp无法访问，是因为这里限定了Ip，没有允许localhost访问。

    3）前面两个步骤检查没有问题后，可以考虑出杀手锏，清除IIS临时目录，清除临时目录前需要先停止对应虚拟目录的应用程序池，或者杀掉对应w3wp进程。然后再删除如下k3cloudapp目录，确保删除干净。

8、经过以上步骤，如果消息队列服务还是无法启动，再分析以上日志目录中的CloudMQ.log，如有如下错误，则调整Common.config配置如配置截图。

Common.config修改：如果没有该节点，则自行增加 <add key="MQModel" value="CLOUDMQ" />

好了，经过以上步骤，基本可以解决99.9%的消息队列服务异常问题。另外0.1%，可能我也没有碰到过，如果不幸运的踩到这个坑，可以联系我协助分析。谢谢。

最后还有一个提醒：有一些朋友有时更新环境不按套路来，例如标准的环境更新流程是通过制作补丁安装包的方式来更新。但有一些朋友喜欢手动替换组件，手动执行脚本。如果是这种情况，大家一般都知道要去重启IIS，但是往往会忽略重启相关的windows服务。建议这样操作的朋友下次注意，重启IIS后，一定再重启一下K3CloudMQ服务。