【IT168 技术文档】简单的说，一个Web Role是一个能够通过HTTP/HTTS访问的Web应用，而Worker role 则是一个无法通过HTTP/HTTPS访问的后台处理应用。一般根据Azure的定义一个Azure服务至少有一个Web Role，而Worker Role则是可选的，不一定要有。 你也可以理解成Web Role是前台应用，比如一个你熟悉的网上商店，Web Role负责展示商店的商品，进行商品的搜索，以及接受用户的订购申请。

  第一篇：Azure Services探索:存储之本地存储 

  第三篇：Azure Services探索:存储之Blobs存储

  第四篇：Azure Services探索:存储之表(Table)存储

  而订购申请产生后，是否被接受和处理了，则是由Worker Role这样的后台应用在进行处理，比如检查库存是否有货，用户的信用情况，货物发送到物流公司的状态更新。

  就像下面这幅图显示的,WebRole是负责卖咖啡的，而Worker Role就是那个负责制造咖啡的。在Windows Azure的设想里，其实这个卖咖啡的和这个制造咖啡的可以是处于不同生产环节上的两个厂商，他们分别将其应用托管到Windows Azure上，对于这连个应用之间的协作和消息通讯，Windows Azure可以提供一个很好的解决方案。

  比如.NET Services 中的Service Bus 和 Workflow Service，这是针对两个独立的应用(可能是坐落在不同云朵上的两个云应用)之间，对于我们单独的一个咖啡应用之间，卖咖啡的和做咖啡之间的消息传递就可以考虑使用队列服务或队列存储，这是一个非常典型的生产者-消费者的模型。

  也就是相对复杂一些的应用场景，我们一个单独Azure服务会同时需要Web 角色和Worker角色，甚至可能是一个Web角色，多个后台Worker角色，队列存储其实解决的就是前台角色和后台Worker角色消息共享和传递的问题。解决消息共享，管理消息的就是消息存储负责的，至于消息传递，消息的可靠性，则是由消息服务来负责的。

  除了一个Azure服务的内部各个组件和角色之间通讯外，还有应用组合的场景中也可以考虑使用Azure的队列存储和服务。比如下面的这个例子：

Pictures source: http://blog.smarx.com/posts/windows-azure-worker-role-to-deal-with-spam

  Steve Marx举的这个例子场景就是，他现在想做一个云计算版本的Weblog应用，但他也需要解决垃圾评论的问题。而TypePad AntiSpam对于垃圾评论已经实现了一个很好的解决方案，而且TypePad AntiSpam也提供了一个公开的API和接口，那么Steve Marx的Weblog应用就完全可以将TypePad的垃圾评论能力聚合到自己的Weblog应用中。

  大致的流程如下：

  1. 某个读者访问Steve Marx的云版Weblog应用(Web Role)，并且写了自己的评论。

  2. Web Role 先将读者的评论保存在Azure 的表存储中，将其状态设置为审核中不显示。

  3. 然后Web Role 再通过Azure队列，放一个消息，告知一个编号的评论需要审批，看是否是恶意或垃圾评论

  4. Worker Role一般在Web Role启动后不久也会开始工作，它检查队列里的消息，一旦检查到了，它便可以通过消息里的编号，去Azure 的表存储中找到具体的评论信息，用户信息以及用户是针对哪篇文章发表的评论。

  5. 之后Worker Role 带着这些信息(TypePad AntiSpam服务需要的信息)，调用TypePad的垃圾评论检测服务的接口，从而确定这个用户的这个评论的有效性。

  6. 获得TypePad AntiSpam返回的结果，Worker Role更新Azure 的表存储中这个评论的状态，比如设置成，审核通过可显示，或审核未通过不显示。

  了解了设计层面和使用的场景，技术和代码层面就比较简单了。我修改了上篇文章的项目设计一个简单的场景来模拟，并探索Azure 队列的功能。

  应用界面如下：

  前台的Send，负责产生需求和输入，并将其放到队列中，Refresh则读取队列，看看队列中有哪些需求和输入没有处理，后台的Worker Role则读取队列中的消息，并且将其处理(从队列中删除)