具体阐述windows Azure 中的web role
2017-05-14 21:40
99 查看
Web Role主要是用来处理HTTP或HTTPS请求的,显然这是最为重要的一个角色。目前在Window Azure中的Web Role实例运行在一个包含IIS的虚拟机中。Web Role可以用来构建Web应用和Web服务。开发人员可以使用像ASP.NET、WCF等.NET技术,也可以使用像PHP这样可以通过IIS的FastCGI功能模块支持的非.NET技术来创建Web
Role服务。虽然其它角色如worker Role 也可以通过设置来侦听HTTP和HTTPS请求,但是Web Role是默认支持并且是专门设计来处理这些web请求的。如果一个服务包含多个Web Role,那么它们需要采用不同的HTTP和HTTPS端口。
理解Web Role
从角色定位的角度来看,Web Role主要用来构建Web应用和基于WCF的Web服务。与Worker Role相比,Web Role主要是多了对IIS的支持。Windows Azure会维护和配置包括IIS在内的服务运行环境,开发人员只需要按照Web Role的编程要求构建应用,Windows Azure就能够完成应用所有的自动化部署和配置。
Web Role项目结构是怎样的呢?对于熟悉传统的基于IIS的Web应用编程的开发人员来说,构建Web Role服务将是一个相对简单的工作,因为Web Role服务实现的主要组成部分与传统Web应用非常相似。如果使用Visual Studio的Web Role 模版创建项目,那么这个项目中会自动包含三个与Windows Azure 相关的引用。
1、Microsoft.WindowsAzure.Diagnostics 主要包含诊断和日志相关的类;
2、Microsoft.WindowsAzure,ServiceRuntime 主要包含与角色实例生命周期控制以及配置信息访问相关的编程接口类;
3、Microsoft.WindowsAzure.StorageClient 主要包含使用REST 方式访问 Windows Azure 存储,包括 Blob、Table和Queue等的类。
开发人员自然可以通过 Visual Studio 提供的Web Role 模版创建一个新的Web Role 应用,但如果用户已有一个传统的 Web应用,那么能否把它转换成一个Web Role 应用呢?答案是肯定的。从项目结构上看,这个转换操作相对简单,但是如果需要应用Windows Azure的一些特性,就需要根据它的编程接口进行调整。Windows Azure 角色在状态保存、数据存储等方面有一些特殊要求。
实际上,Windows Azure 项目上主要是包含了服务模型的信息以及项目之间的关联信息,具体的服务逻辑都是由各个角色项目来实现的。从项目依赖关系来看,Windows Azure 项目需要依赖它所包含的那些角色项目。
了解Web Role 运行环境
大部分开发人员都是从Web Role 开始进行 Windows Azure 编程的,因此进一步了解 Web Role 的细节有助于理解 Windows Azure 的计算服务。接下来我们看一下 Web Role 实例具体的运行环境,它包括底层的虚拟机、IIS服务等。
在Windows Azure刚发布时, Web Role 的运行环境对外就像一个黑盒了。因为内部运行环境的细节没有对外公布。Web Role 那时候只支持托管代码,而且只能运行在部分信任模式下;开发人员也没有一个简单的方式来了解 Web Role 实例的具体运行环境的情况。但是微软后来发布了 Windows Azure 的一些新特性,比如代码完全信任设置和管理模式中的远程桌面等,都可以帮助开发人员了解不同角色实例(包括 Web Role)的运行环境。
现在 Windows Azure 的角色可以设置运行在完全信任模式下,比如对于 Web Role,开发人员只需要在相应服务定义文件中进行如下设置即可。
完全信任模式下使几种代码访问场景称为可能。
1、调用非.NET代码。除了托管代码之外,许多开发人员已经写了许多本地代码,尤其在处理一些特殊任务时。完全信任设置使得服务角色可以通过创建新的进程或通过平台调用服务方式调用本地代码。
2、使用一些需要完全信任的.NET库。Windows Azure 原先不能调用那些需要完全信任权限的.NET库,现在就没有这个限制了。
3、通过命名管道进行进程间通信。如果服务创建了不同的进程,现在则可以通过命名管道让它们进行通信。
实际上,让角色可以创建本地进程是 Windows Azure 支持不同语言环境的一个重要前提,后面我们会发现在配置PHP支持时就需要设置完全信任访问权限。另外,需要注意的是,虽然有了完全信任权限,但是角色服务在 Windows Azure 上并不是以管理员身份运行的,因此在有一些资源如注册表等的修改上还是有一些限制的。这是从安全角度出发进行的必要限制。
那如何了解 Web Role 实例运行环境的一些信息呢? 我们知道,在通常的 Windows 环境中可以通过命令行的方式执行一些命令来了解系统环境。完全信任模式可以让开发人员在Web Role 角色中通过System.Diagnostics.Process类生成与一个 cmd.exe 进程,然后把需要执行的命令作为参数传递给它并把命令执行结果返回给客户端。另外,开发人员还可以通过System.Environnment 类和 Microsoft.Win32.Registry 类来得到环境的一些具体信息。
Windows Azure 提供的远程桌面使得开发人员有一个更为直观的方式来了解角色环境。在 Visual Studio 中为服务角色配置远程桌面访问的步骤比较简单,只需要在发布应用时选择配置远程桌面连接如图:
然后在配置窗口中为远程桌面设置相应的用户们和口令即可。在这个过程中 Visual Studio 会自动生成一个证书,并且自动修改相应的服务定义文件和服务配置文件。开发人员可以通过 Windows Azure 管理门户网站把上面步骤中生成的证书上传到对用服务的证书目录中。
在服务定义文件中主要是对<Imports>元素,它描述了需要为角色运行环境增加的导入模块。这是在 Windows Azure SDK 版本 1.3以后增加的一个新功能。 在 Web Role 中与远程桌面连接相关的<Imports>设置主要是对 RemoteAcess模块和RemoteForwarder模块,如下所示。
RemoteAcess表示当前角色支持远程桌面访问,RemoteForwarder表示当前 Web Role 支持RDP访问的转发,因为用户服务中的不同角色不能都对外直接开放RDP访问端口。远程桌面访问的具体配置信息如用户登录信息、证书的职位等被自动定义在服务配置文件中。如下所示。
配置好远程桌面连接之后,开发人员就可以在Windows Azure管理门户网站中直接通过RDP连接相应的角色实例了。开发人员可以具有管理员权限,从而可以通过熟悉的 Windows Server 管理界面来详细了解角色实例的运行环境。比如,可以在资源管理器中看到 Web Role 的目录结构。
Role服务。虽然其它角色如worker Role 也可以通过设置来侦听HTTP和HTTPS请求,但是Web Role是默认支持并且是专门设计来处理这些web请求的。如果一个服务包含多个Web Role,那么它们需要采用不同的HTTP和HTTPS端口。
理解Web Role
从角色定位的角度来看,Web Role主要用来构建Web应用和基于WCF的Web服务。与Worker Role相比,Web Role主要是多了对IIS的支持。Windows Azure会维护和配置包括IIS在内的服务运行环境,开发人员只需要按照Web Role的编程要求构建应用,Windows Azure就能够完成应用所有的自动化部署和配置。
Web Role项目结构是怎样的呢?对于熟悉传统的基于IIS的Web应用编程的开发人员来说,构建Web Role服务将是一个相对简单的工作,因为Web Role服务实现的主要组成部分与传统Web应用非常相似。如果使用Visual Studio的Web Role 模版创建项目,那么这个项目中会自动包含三个与Windows Azure 相关的引用。
1、Microsoft.WindowsAzure.Diagnostics 主要包含诊断和日志相关的类;
2、Microsoft.WindowsAzure,ServiceRuntime 主要包含与角色实例生命周期控制以及配置信息访问相关的编程接口类;
3、Microsoft.WindowsAzure.StorageClient 主要包含使用REST 方式访问 Windows Azure 存储,包括 Blob、Table和Queue等的类。
开发人员自然可以通过 Visual Studio 提供的Web Role 模版创建一个新的Web Role 应用,但如果用户已有一个传统的 Web应用,那么能否把它转换成一个Web Role 应用呢?答案是肯定的。从项目结构上看,这个转换操作相对简单,但是如果需要应用Windows Azure的一些特性,就需要根据它的编程接口进行调整。Windows Azure 角色在状态保存、数据存储等方面有一些特殊要求。
实际上,Windows Azure 项目上主要是包含了服务模型的信息以及项目之间的关联信息,具体的服务逻辑都是由各个角色项目来实现的。从项目依赖关系来看,Windows Azure 项目需要依赖它所包含的那些角色项目。
了解Web Role 运行环境
大部分开发人员都是从Web Role 开始进行 Windows Azure 编程的,因此进一步了解 Web Role 的细节有助于理解 Windows Azure 的计算服务。接下来我们看一下 Web Role 实例具体的运行环境,它包括底层的虚拟机、IIS服务等。
在Windows Azure刚发布时, Web Role 的运行环境对外就像一个黑盒了。因为内部运行环境的细节没有对外公布。Web Role 那时候只支持托管代码,而且只能运行在部分信任模式下;开发人员也没有一个简单的方式来了解 Web Role 实例的具体运行环境的情况。但是微软后来发布了 Windows Azure 的一些新特性,比如代码完全信任设置和管理模式中的远程桌面等,都可以帮助开发人员了解不同角色实例(包括 Web Role)的运行环境。
现在 Windows Azure 的角色可以设置运行在完全信任模式下,比如对于 Web Role,开发人员只需要在相应服务定义文件中进行如下设置即可。
[html] view plain copy print? <WebRole name="WebRole1" endableNativeCodeExecution\"true">
完全信任模式下使几种代码访问场景称为可能。
1、调用非.NET代码。除了托管代码之外,许多开发人员已经写了许多本地代码,尤其在处理一些特殊任务时。完全信任设置使得服务角色可以通过创建新的进程或通过平台调用服务方式调用本地代码。
2、使用一些需要完全信任的.NET库。Windows Azure 原先不能调用那些需要完全信任权限的.NET库,现在就没有这个限制了。
3、通过命名管道进行进程间通信。如果服务创建了不同的进程,现在则可以通过命名管道让它们进行通信。
实际上,让角色可以创建本地进程是 Windows Azure 支持不同语言环境的一个重要前提,后面我们会发现在配置PHP支持时就需要设置完全信任访问权限。另外,需要注意的是,虽然有了完全信任权限,但是角色服务在 Windows Azure 上并不是以管理员身份运行的,因此在有一些资源如注册表等的修改上还是有一些限制的。这是从安全角度出发进行的必要限制。
那如何了解 Web Role 实例运行环境的一些信息呢? 我们知道,在通常的 Windows 环境中可以通过命令行的方式执行一些命令来了解系统环境。完全信任模式可以让开发人员在Web Role 角色中通过System.Diagnostics.Process类生成与一个 cmd.exe 进程,然后把需要执行的命令作为参数传递给它并把命令执行结果返回给客户端。另外,开发人员还可以通过System.Environnment 类和 Microsoft.Win32.Registry 类来得到环境的一些具体信息。
Windows Azure 提供的远程桌面使得开发人员有一个更为直观的方式来了解角色环境。在 Visual Studio 中为服务角色配置远程桌面访问的步骤比较简单,只需要在发布应用时选择配置远程桌面连接如图:
然后在配置窗口中为远程桌面设置相应的用户们和口令即可。在这个过程中 Visual Studio 会自动生成一个证书,并且自动修改相应的服务定义文件和服务配置文件。开发人员可以通过 Windows Azure 管理门户网站把上面步骤中生成的证书上传到对用服务的证书目录中。
在服务定义文件中主要是对<Imports>元素,它描述了需要为角色运行环境增加的导入模块。这是在 Windows Azure SDK 版本 1.3以后增加的一个新功能。 在 Web Role 中与远程桌面连接相关的<Imports>设置主要是对 RemoteAcess模块和RemoteForwarder模块,如下所示。
[html] view plain copy print? <Imports> <ImportmoduleNameImportmoduleName="Diagnostics"/> <ImportmoduleNameImportmoduleName="RemoteAccess"/> <ImportmoduleNameImportmoduleName="RemoteForwarder"/> </Imports>
RemoteAcess表示当前角色支持远程桌面访问,RemoteForwarder表示当前 Web Role 支持RDP访问的转发,因为用户服务中的不同角色不能都对外直接开放RDP访问端口。远程桌面访问的具体配置信息如用户登录信息、证书的职位等被自动定义在服务配置文件中。如下所示。
[html] view plain copy print? <ConfigurationSettings> <Setting name="Microsoft.WindowsAzure.Piugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true"/> <Setting name="Microsoft.WindowsAzure.Piugins.RemoteAccess.Enabled" value="true"/> <Setting name="Microsoft.WindowsAzure.Piugins.RemoteAccess.AccountUsername" value="LoginName"/> ......
配置好远程桌面连接之后,开发人员就可以在Windows Azure管理门户网站中直接通过RDP连接相应的角色实例了。开发人员可以具有管理员权限,从而可以通过熟悉的 Windows Server 管理界面来详细了解角色实例的运行环境。比如,可以在资源管理器中看到 Web Role 的目录结构。
相关文章推荐
- 具体阐述常用的几种文件物理结构及其优缺点
- 将对setjmp与longjmp的具体使用方法和适用的场合,进行一个非常全面的阐述。
- 反渗透设备:反渗透设备工艺流程及用途具体阐述
- 将对setjmp与longjmp的具体使用方法和适用的场合,进行一个非常全面的阐述。
- Windows Azure 市场 — 新的终端用户体验、 新的功能、 新的数据和应用程序服务,依然不变的兴奋体验和附加值!
- Java web的具体更新部署(基于Oracle数据库)
- 阐述独立游戏开发者面临的5大问题
- javascript的window.open()具体解释
- DirectX 3D_基础之粒子系统的组成 绘制粒子系统 粒子随机性 具体的粒子系统
- Java经常使用日期操作具体解释
- 获取字节码的文件路径、获取一个类的具体名称、获取一个类的简单名称、获取一个类的包名
- EF分组后把查询的字段具体映射到指定类里面的写法
- 2013 年 2 月 22 日 Windows Azure 存储中断详细信息
- Java集合框架GS Collections具体解释
- 整型之具体字节数
- linux 统计 具体日期 的文件 内容模板
- Phpcms v9 栏目列表选择性调用数据具体方法
- 具体mongo 中关于java的各个接口实现方法。
- 华为:IP地址匹配 在路由器中,一般来说转发模块采用最大前缀匹配原则进行目的端口查找,具体如下:
- 关于静态与非静态之具体总结