[VS2010] Visual Studio 2010 与 Windows Azure: 准备篇 (3) - 认识 Development Fabric 与 Development Storage

[VS2010] Visual Studio 2010 与 Windows Azure 准备篇 (3) : 认识 Development Fabric 与 Development Storage

不论是用 Visual Studio Tools for Windows Azure，或是直接安装 Windows Azure SDK，都可以在电脑中找到两个奇怪的东西，一个是 Development Fabric，一个是 Development Storage，这两个是用来做为模拟 Windows Azure 实际运行环境的服务程序，在本机上开发 Windows Azure 应用程序时，若要侦错就不能没有它，否则还要跑 Windows Azure 网站上传后再测试，那可是很累人的，而且调试器跨网络的话性能会差很大，有个本地端的模拟工具对开发人员来说方便很多，至少在测试时省下的时间会比没有多太多了。

Development Fabric 的功用是模拟部署，执行以及在程序中实践的记录与诊断 (Logging and Diagnostics) 的功能，Development Fabric 本身就是一个 Windows Azure Fabric (云端中的 Windows Azure 执行代理程序) 的本机版本，上面搭载的是 Windows Azure Guest OS，也就是应用程序实际执行的操作系统环境，于 Windows Azure SDK 1.1 (二月份的版本) 中，可以借由设定服务组态档 (Service Configuration File) 来设定应用程序要使用哪一个 Windows Guest OS 版本，默认当然都是使用最新的版本，Development Fabric 允许开发人员设定使用不同的 Windows Guest OS，但是该功能只适用于以旧版 SDK 开发的应用程序，新的版本还是以最新的 Windows Guest OS 为宜。

Development Fabric 在 Visual Studio 启动云端应用程序时，它是在背景执行的一个服务，只会在工作列上显示一个图示：

如果要特别显示它的使用者界面，则要由那个图示的快显功能表中选择 [Show Development Fabric UI]：

选取之后，Development Fabric 的使用者界面才会出现：

这个使用者界面可以做的事有：

1. 监控应用程序的执行状况。

2. 若应用程序会输出 Log 记录，则可以在这里看到，这对 Worker Role 或 WCF Service 型的应用程序会很有帮助。

3. 测试服务停止与启动时的反应 (OnStart() 与 OnEnd() 事件常式的处理反应)。

前面也已经说到，Development Fabric 是一个模拟的环境，就像是 ASP.NET Development Server 之于 IIS 一样，它和正式的 Windows Azure 环境会有部分差异，有些差异则是开发人员必须要注意的：

1. 调试器不能挂到正式的 Windows Azure 环境，任何调试用的消息都要用 log 来输出。
2. Development Fabric 中运行的 Windows Azure 应用程序可以存取本机的系统资讯，如 GAC/Registry/Machine Configuration 与本机系统资源等等，但这些东西在正式的 Windows Azure 环境中没有。
3. Development Fabric 可以直接将记录资讯输出到 UI 中，如同使用 Windows Azure Diagnostics 抓取的一样，但在正式的 Windows Azure 环境中，只能用 Windows Azure Diagnostics API 将消息存到 Table Storage。
4. 在正式的 Windows Azure 环境中，开发人员可以利用服务组态档在不重新部署应用程序的情况下设定执行的 role instance 数量，但在 Development Fabric 中这个功能不支持，只能重新部署。
5. Development Fabric 无法完全模拟 Windows Azure Load Balancer (负载平衡器) 的所有行为。

另外一个模拟环境是 Development Storage，它则是模拟在云端中的 Windows Azure Storage Services，包括 BLOB, Table 以及 Queue Service 都由它来模拟，因此它会需要一个保存的地方。依照默认，Development Storage 会存取本机的 SQL Server Express  (./SQLEXPRESS) 以建立一个它专属的数据库，因此若电脑中没有安装 SQL Server Express，在启动 Development Storage Service 时会出现下列的消息：

那么如果本机上有 SQL Server 但不是 SQL Server Express 怎么办？不用担心，Windows Azure SDK 有提供一个工具：DSInit.exe (Development Storage Initialization Tool，这个工具存放在 %PROGRAM_FILES%Windows Azure SDKv1.1bindevstore 目录中，你也可以由 Windows Azure SDK 所建立的 “Windows Azure SDK Command Prompt” 来执行它)，它可以允许开发人员自行设定 Development Storage 要使用的 SQL Server 执行个体，因此如果要设定 SQL Server 的默认执行个体，可以下这样的命令：

dsinit /sqlinstance:.

这样 DSInit 就会连结到 SQL Server 默认的执行个体，而看到的消息就是这样：

此时就可以由 SQL Server Management Studio 来看由 Development Storage 所建立的数据库，名称是固定的 DevelopmentStorage20090919，表格配置则是：

它也安装了一些辅助的预存进程以及函数：

有了 Development Storage 服务，开发人员也才能在本机使用 Microsoft.WindowsAzure.StorageClient 来开发应用 Windows Azure Storage 的应用程序。而 Development Storage 本身也有一个使用者界面，用来设定要执行哪些 Storage Service：

Development Storage 所开放的 Storage Service 终端点，都是以本机 URL 用不同的 Port 所切分，和 Windows Azure Storage 实际开放的 URL 是不一样的，开发人员在利用本机发展完应用程序后要记得做转换 URL 的动作，否则在云端上会失效。另外，Development Storage 本身有提供一个存取的 Key:

Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

以模拟实际在 Windows Azure Storage 存取服务时要提供 Account name 以及 Account key 一样，这也是开发人员需要在部署到云端前要做的更换工作。

Development Storage 与 Windows Azure Storage 的差异有：

1. Development Storage 和正式的 Windows Azure Storage 的服务 URL 不相同，正式的 Windows Azure Storage 的 URL 是：

 
 
  
  ://
  
  
   
   .
   
   
    
    .core.windows.net/
    
    
     
     
（service-name 是下列三种值之一：blob, table 与 queue）
    
    
   
   
  
  
 
 

2. Development Storage 没有 Scale 能力，也无法支持大量的同时使用者。
3. Development Storage 使用固定的 Account name 与 Account key，如上所述。
4. 本机的 BLOB Service 大小最高 2GB。
5. 在 Development Storage 的 Table Service 中的日期范围，与 SQL Server 2005 所支持的日期范围相同。
6. 在 Development Storage 的 Table Service 可以支持 partition key 与 row key 的属性值要小于 900 bytes，而 account name, table name 与 key property name 三者加总的长度也不能超过 900 bytes。
7. 在 Development Storage 的 Table Service，每一列的长度不可以超过 1MB。
8. 在 Windows Azure Storage 中，每个 entity transaction group 的批次大小最大是 4MB，但在 Development Storage 中不会检查这件事。
9. 在 Development Storage 的 Table Service 若查询表格中不存在的字段，会回传错误，但在正式的 Windows Azure Storage 不会回传错误。
10. 在 Development Storage 的 Table Service 中，以 Edm.Guid 与 Edm.Binary 为类型的属性，只支持 eq (=) 和 ne (!=) 运算。

多了解 Development Fabric 与 Development Storage 本身以及它们与正式环境间的差异，可以有效的消除一些因两者差异而造成的设计瑕疪或问题。

参考数据：

About Development Fabric: http://msdn.microsoft.com/en-us/library/dd179455.aspx
About Development Storage: http://msdn.microsoft.com/en-us/library/dd179339.aspx

原文:大专栏  [VS2010] Visual Studio 2010 与 Windows Azure: 准备篇 (3) - 认识 Development Fabric 与 Development Storage