前文书说到目前微软的Bot机器人分为五类，也从以前的Bot Framework迁往Azure的Bot Service。利用QnA Maker，我们已经快速的做了一个对话机器人。那么，怎么让这个对话机器人面向大众提供服务呢？目前的架构而言，自己开发代码连到QnA Maker机器人是一种做法，而使用Azure的Bot Service让机器人更加容易部署，更加聪明也是一种做法。接下来就会看看怎么在Azure里部署一个机器人。
在Azure的订阅里，从“AI+Cognitive Services”中直接新建一个“Web App Bot”。和之前定义的一样，有五类机器人可选，并可以选择使用 C# 还是 Node.js 来实现。Bot Service是泡在 IIS 的 Web 服务上的，所以创建Bot的时候，就会创建Web Bot App服务、Bot使用的应用服务和对应的应用服务计划。Bot可以选择F0的计划，这样测试的时候不用花钱。应用服务计划在随Bot创建的时候，会自动选择S1的标准计划，这个计划是要收费的，所以我赶紧把应用服务计划改成F1免费的。如果使用模板部署，可以直接修改模板文件。
顺便提一下，因为应用服务可以按照需要进行伸缩，所以选择合适的应用服务计划是很好的做法。
坐和放宽，不一会Bot服务就制备好了，因为选择的是QnA的机器人，所以到应用配置中，输入我们之前创建的QnA Maker的订阅ID和KB的ID。
默认Bot服务就会开启Web Chat的信道，信道的概念暂且不提，以后再写。接下来，我就兴冲冲的打开Bot机器人，选择“Test in Web Chat”来测试我的机器人，可是，等了半天，对话窗口一直打不开。好失望……仔细检查，应用服务记录了500的HTTP错误。
我回到Docs站点，查看微软的文档，示例选择的是Basic机器人，难道跟机器人类型有关？这不科学啊。不过可以创建一个Basic的来试试。
看上去貌似是正常的，问题在哪呢？翻来翻去，发现有个在线代码编辑器，可以直接在线查看代码。立马打开两边的代码进行比较。
这是Basic机器人的，可以看到你说啥它就回复啥。
这是QnA机器人，可以看到使用环境传入的订阅ID和KB的ID连接QnA Maker的服务。代码没毛病啊，要是有问题，还能放到Azure里？反正是Node.js，我就在编辑器里运行呗。查看一下输出，还真有不少报错，提示依赖包没找到……
Node.js的代码不会写，包我还不会安装么。看看都有啥包。
确实比Basic机器人依赖的包多啊。怎么加这些包呢？又不是一台IaaS的虚拟机，可以远程上去装。看了看，在线编辑器居然提供了Console~ 赶紧试试npm install，没毛病~
赶紧把依赖的包全部都装上，再次运行代码。这次没报错了，回到Azure的Portal，继续测试Web Chat。
这次终于能跑了。不过还有两个问题：
1、发送问题跟获得回答的时间挺长，我估计跟我全部选择免费服务计划有关，慢一点忍了。
2、在这个QnA Maker服务里，我同时添加了URL和上传了KB文件（txt），但是只有内置的和URL的KB能够响应。即使我把URL的KB删除了，KB文件依然没有生效。报了一个事件给QnAmaker.ai的反馈。
原文地址：http://blog.51cto.com/haohu/2065177