《》

　　本文是对内容的补充。

 

　　我们知道，在Windows Azure PaaS，有一个非常重要的概念，就是Web Role和Worker Role。

　　在创建Azure Cloud Service的时候，会提示如下的选项：

　　

 

　　-Web Role是响应客户端的HTTP请求

　　-Worker Role则是在后台执行的应用程序，概念上类似于Windows Service。

　　-Web Role可以通过Azure Storage中的Queue，向Worker Role发送队列消息 (Queue.AddMessage())，以便让Worker Role在后端执行自己需要的逻辑。

　　

　　注意：上图中Worker Role分为三类。本章会介绍PaaS Worker Role。

 

　　有关Cache Worker Role的详细信息，请参考：

      

      

 

　　有关Worker Role with Service Bus Queue，请参考:

　　

      

　　

 

　　为什么微软要有Web Role/Worker Role？它的好处在哪里？在这里我举个例子您就能明白，比如我们有一个信息管理系统，需要上传Excel文档来进行解析和处理，从软件设计的角度来说有2种方法来解决

　　(1)在ASP.NET应用程序里新建个upload control,在upload control里面写函数：一旦Excel文件上传完毕，则在.cs文件执行对于Excel的处理工作。

　　但这样会有一个缺点，如果Excel文件里包含的内容非常大的话，需要时间来处理这些内容，所以前台的ASP.NET的页面会停滞或者无响应。虽然我们也可以通过增加progressbar或者loading图片来增强用户的体验，但是从软件设计上来说不是最好的。

　　(2)前端还是用原来的处理方式，使用upload control。服务器端增加一个Windows Service，时序的查询某一个文件夹，一旦发现前端页面上传了一个Excel文件，则Windows Service执行处理Excel的工作。这样前端的页面会及时的响应并且得到更好的用户体验。

　　但是这还是有一个缺陷，前端的页面和windows service是一对一的关系，如果附件上传的数量很大的话会出现Windows Service来不及处理的情况。

　　(3)有了Worker Role，我们可以让一个ASP.NET页面后端有多个Worker Role来进行分布式的计算，是一对多的关系，能够有效的利用云上的计算资源，Worker Role可以处理高负载的数据访问。

 

 

　　这样的架构好处有两点：

　　1.异步处理，Web Role只响应客户端的HTTP请求，进行快速的响应。而Worker Role在后端处理Web Role发送过来的消息(Queue)，两者是松耦合的。

　　在传统的Web应用中，如果我们把复杂的处理逻辑写在ASPX页面，则ASPX页面可能会停滞，造成的用户体验不好。Windows Azure PaaS使用Web Role和Worker Role，Web Role只关注于响应客户端的HTTP请求；而Worker Role可以在后端处理业务逻辑，进行异步处理。

 

　　2.Web Role和Worker Role的关系是多对多的，比如我可以在Web Role的配置中，设置Instance count为10。如下图：

　　

　　在Worker Role的配置中，设置Instance count为3

　　

 

　　这种架构就好比一个餐厅，里面有10个服务员(Web Role)和3个厨师(Worker Role)。

-          服务员(Web Role)只负责招待客人(响应客户端请求)，并将客人的点菜信息通过队列消息交给厨房(Queue.AddMessage())

-          厨师(Worker Role)读取点菜信息(Queue.GetMessage)，随后负责烧菜做饭(进行后端逻辑)，当饭菜准备完毕后，则删除点菜信息。

-          如果前端压力过大(客户端请求过多)，则Web Role可以横向扩展

-          如果后端压力过大(后端逻辑处理过多)，则Worker Role也可以横向扩展

-          这种松耦合，多对多的关系非常适合企业级应用架构

　　

　　可以看到，Web Role和Worker Role的进行通信的重要途径是通过Queue，了解Queue对于Azure PaaS架构设计非常重要。