《Windows Azure Platform 系列文章目录》
对于传统的自建数据中心，从底层的Network，Storage，Servers，Virtualization，中间层的OS，Middleware，Runtime，最上层的Application，Data，都需要企业进行管理。这就好比农村自建房。
对于公有云平台，一般分为三种类型: IaaS, PaaS和SaaS。
Microsoft Azure平台属于IaaS和PaaS范畴。
1. IaaS
对于用户来说，底层的Network, Storage, Server, Virtualization微软Azure都已经准备就绪了。用户只需要把应用部署到Azure IaaS即可，日常只需要管理中间层的OS，Middleware，Runtime和最上层的Application，Data。
Azure支持的操作系统为
- Windows : Server 2008 R2, Server 2012, Server 2012 R2
- SQL Server：SQL Server 2008 R2, SQL Server 2012 SP1, SQL Server 2014 RTM (Web, Standard, Enterprise)
- Linux:
Ubuntu (12.04 LTS, 12.10, 13.10, 14.04 LTS),
CentOS (6.5),
SUSE (SUSE Linux Enterprise Server 11 SP3)
对于IaaS来说，OS以上部分的管理和维护都需要用户来管理。这样的缺点是:比如说用户现在使用Windows Server 2012 R2，将来微软release了Windows Server 2012 R2 SP1，需要用户进行手动升级。
2. PaaS
在PaaS里，OS，Middleware，Runtime都是由Microsoft Azure来管理。PaaS强调的是提供平台能力，而不需要关心OS，Middleware，Runtime。即客户只需要告诉Microsoft Azure提供运行Application的能力，无论是.NET的能力，Java的能力，PHP的能力等等。企业可以非常方便的将应用程序部署到Microsoft Azure。
微软提供Azure SDK包含的开发平台：
- .NET
- Java
- PHP
- Node.js
- Python
- Ruby
从迁移难度来说，从IDC机房迁移到Azure PaaS难度要比IaaS大，因为PaaS需要进行一定的代码修改。
我个人的建议是先让用户将本地的应用迁移到Azure的IaaS平台，享受云计算带来的便利性和可靠性；然后在IaaS平稳运行的前提下，将部分应用迁移至PaaS平台。
3. SaaS
Microsoft Azure不是SaaS平台。
SaaS是提供给用户完整的软件解决方案，开箱即用的。最终用户无需了解该软件解决方案背后是部署在哪家云计算供应商，背后的平台是使用IaaS还是PaaS服务。
微软的Office 365就是非常典型的SaaS服务。类似的像Salesforce.com这样的解决方案也是提供SaaS服务。
对于那些ISV厂商来说，传统交付软件的方式是需要经过以下几步：
- 在客户现场首先部署硬件服务，包括安装服务器，网络，防火墙，电源等
- 安装软件，包括操作系统，数据库软件，运行时软件
- 安装应用软件
可以看到，这样的软件交付流程，其实包括了硬件的交付和软件的交付。对于ISV厂商来说，不仅仅需要维护软件的可用性，而且需要维护底层的硬件服务器。
ISV厂商采用了微软的Microsoft Azure公有云服务之后，可以采用
- IaaS，将底层的Network, Storage, Server, Virtualization全部交付给Microsoft Azure
- PaaS，将底层的Network, Storage, Server, Virtualization和中间层的OS，Middleware，Runtime交付给Microsoft Azure
ISV厂商只要专注于软件的开发和升级就可以。其他硬件服务器的运维等等工作，都交付给微软Azure来处理就可以了。
通过这样对应用程序的改造和升级，那些传统的ISV厂商就可以利用微软的公有云服务，提供给自己的客户SaaS的服务。
Microsoft Azure所提供的服务
注意：本篇仅介绍Azure China提供的服务。Azure平台是一个更新的平台，每个月都会有新的feature release，笔者尽最大可能更新文档，但本文不代表Azure 平台提供的最终服务内容。
按照Microsoft Azure的业务价值和典型的业务场景，Microsoft Azure的各个服务组件分类如下：
服务类型 |
计算服务 |
数据服务 |
应用服务 |
网络 |
服务详细 |
l 虚拟机 l Web Site(预览) l 云服务 |
l SQL Database l 存储 |
l 服务总线 l Notification Hubs l Active Directory l CDN(预览) l Scheduler |
l 虚拟网络 |
注：以上内容会随着Microsoft Azure平台变化而增加，想了解Azure提供的所有服务，请参考www.windowsazure.cn。
基于以上这些服务组件，用户可以灵活的构建自己的IT架构和应用环境。
一. 存储服务
Azure存储服务是云端的文件存储服务，简单理解是用户可以将本地的文件、图片、照片等二进制文件保存在云端的存储服务中。
在传统的IDC数据中心，存储是某个机器名、或者保存在某个服务器的某个磁盘下，或者是某个存储的网络位置。
在Azure存储服务，其实是一个http / https的网络路径，可以进行权限控制。Azure存储服务并不依赖于任何一个IP地址或者是网络路径。
存储服务本身支持99.9%的SLA，它提供三种高可用:
1)本地数据中心的三重冗余 (Local Redundant Storage, LRS)。比如客户可以选择将存储服务在同一个数据中心做三重冗余，比如在上海的数据中心做三重冗余。任意一个保存在上海存储服务的文件，都有一个主备份和一个子备份。
比如客户上传了10 GB电影，其实Azure存储服务在同一个数据中心保存了30GB。但是Azure收费只会收取用户实际上传的10GB费用。
对于LRS，事务在同一个数据中心的三重冗余是同步执行的。
2)跨数据中心的三重冗余 (Geo Redundant Storage, GRS)
细心的用户会发现，微软在国外和国内的数据中心建设都是成对的，比如北京数据中心和上海数据中心。这是因为微软充分考虑了异地冗余的能力。在北京和上海数据中心之间会有专线连接，这个专线是内网数据中心之前数据同步专用的。
比如用户在上海数据中心(主要位置)创建了存储账号，并且开启了跨数据中心同步的能力。当用户往上海数据中心上传10GB电影，该电影文件不仅在上海数据中心做了三重冗余，在北京的数据中心(辅助位置)也会做三重冗余，文件一共做了六重冗余。举个例子，即使上海数据中心因为地震、战争、洪水完全被摧毁了，用户的数据还是安全的保存在北京的数据中心，文件真正做到了万无一失。
对于主要位置的数据中心来说，事务是异步从主要位置发送到辅助位置的。
下表显示了当前的主要位置和辅助位置的信息:
主要位置 |
辅助位置 |
中国东部 |
中国北部 |
中国北部 |
中国东部 |
GRS的RPO 和RTO是多少?
恢复点目标 (RPO)：在 GRS 和 RA-GRS中，存储服务将数据从主要位置异步跨地域复制到辅助位置。发生重大区域性灾难，需要进行故障转移时，未进行跨地域冗余复制的最新增量变化可能会丢失。这种潜在数据丢失的分钟数称为 RPO（即数据可以恢复到的时间点）。我们的 RPO通常不会超过 15分钟，不过目前尚无 SLA涉及跨地域冗余复制需要多长时间。
恢复时间目标 (RTO)：另一个需要了解的指标是 RTO。这指的是进行故障转移以及执行故障转移后使存储帐户恢复联机所需的时间。进行故障转移所用的时间包括：
(A)调查并确定能否在主要位置恢复数据或是否应该进行故障转移所需要的时间
(B)通过更改 DNS条目实现帐户故障转移的时间
我们非常重视保护您的数据，所以如果有任何恢复数据的可能，我们将暂缓故障转移，并尽量恢复主要位置的数据。将来我们计划提供一个 API，使客户可以在帐户级别触发故障转移，从而使他们能够自己控制 RTO，但目前尚不可用。
3)读取访问地域冗余 (Read Access – Geo Redundant Storage, RA-GRS)
简单的来说，如果用户在上海数据中心(主要位置)创建了存储账号，并且开启了RA-GRS，事务就会异步的复制到北京的数据中心。RA-GRS提供了对复制到北京数据中心(辅助位置)的”只读”访问权，实现对存储账户的更高读取可用性。
这样用户可以指定对于Azure Storage的访问是指向上海数据中心(主要位置，还是北京数据中心(辅助位置)，提高读取的高可用性。
启用该功能后，在主要区域无法读取数据时，可使用辅助位置读取更高可用性。该功能为”选择使用”，要求存储账户进行跨地域冗余复制。
举个例子，假设我在上海数据中心(主要位置)创建了Azure Storage，Storage Name为leizhangstorage，并且开启了读取访问地域冗余 (Read Access – Geo Redundant Storage, RA-GRS)。
(A)我就可以通过http://leizhangstorage.blob.core.chinacloudapi.cn 访问主要位置的Azure Storage Account。
(B)然后还可以通过http://leizhangstorage-secondary.blob.core.chinacloudapi.cn 访问次要位置的Azure Storage Account
(C)在发生上海数据中心(主要位置)无法读取数据的时候，可以使用辅助位置的数据读取来提供高可用性。
参考资料:
http://blog.csdn.net/azurechina/article/details/22749157
Azure存储服务提供三种不同类型的存储服务: Blob, Table, Queue。
1. Blob
Blob就是保存大型二进制对象，比如用来存储文件、图片、文档等二进制格式的文件。
Blob分为两种类型：
(1)Block Blob
这种类型适合存储二进制文件，支持断点续传，可以最大以4M为一个区块单位，单一文件最大可以存储200GB，且区块不会连续存储，可能会在不同的存储服务器分块存放。为了适应文件的上传和下载而专门进行了优化。
Block可以通过2种方式创建。不超过64MB的Block Blobs可以通过调用PutBlob操作进行上传。大于64M的Block Blobs必须分块上传，且每块的大小不能超过4MB。
(2)Page Blob
这类存储优化了随机访问。它会在存储区中划分一个连续的区域供应用程序存放数据，可以用来存放VHD，单一文件最大可以存储1TB。
Blob服务由Blob本身以及其收纳容器(Container)构成，容器可以视为一般本机上的文件夹。
你可以通过REST API来访问Blob
http://<accountname>.blob.core.chinacloudapi.cn/<containername>/<blobname>
accountname表示哪个Azure存储账号下的资源，是全局唯一的。
blob.core.chinacloudapi.cn表示azure china blob存储资源，是固定的。
containername表示容器的名字，可以认为是访问某一文件夹下的资源
blobname表示我要访问的资源名称，你可以认为是一个mp3文件，或者是一个jpg文件。
举例说明：
我保存在leizhangstorage存储账号下，containername为photo，blobname为myphoto.jpg。则这个URL地址为：
http://leizhangstorage.blob.core.chinacloudapi.cn/photo/myphoto.jpg
我保存在leizhangstorage存储账号下，containername为vhd，blobname为myvm.vhd。则这个URL地址为：
http://leizhangstorage.blob.core.chinacloudapi.cn/vhd/myvm.vhd
注意Container的命名规则
- containername只能是一级目录，没有办法在containername下再设置下一级别containername
- 必须以英文或数字开头，且名称内只能有英文、数字及dash(-)
- 不能以dash(-)开头或结尾，dash(-)不能连续出现
- 所有的英文的字符必须是小写
- 长度为3-63之间
Blob的命名规则
- 除了url的保留字符以外，其他的字符组合都可以使用
- 长度为1-1024个字符
- 尽量避免以dot(.)或者是forward slash(/)结尾。否则会造成Blob Service误判。
2.Table
这里的Azure Storage Table是非关系型数据表，不能与SQL Server的Table相混淆。用户可以近似认为Azure Storage Table是NoSQL。
Azure Table中的每一行记录就是一个Entity，单个Entity的最大容量是1M。
Azure Table中表的所有记录最大容量是200TB，每个Azure Table都必须有Partition Key和Row Key。Azure Table属性最多有255个。
Partition Key的值可以设置记录的物理位置。
在Azure Table中的2条数据，如果Partition Key值相同，则表示这2条数据存储的物理位置是相同的；
如果Partition Key不同，则表示这2条数据可能存储在同一台物理介质上，或者不同的2台物理介质上。如下图:
Table使用的场景，比较适合于日志文件存储，或者是需要非关系型数据库的场景。
3.Queue
Queue，队列，是一种先到先服务(First-Come, First-Serve)，或者称为FIFO(先入先出)的存储服务。队列可以是字符串或者是最长64KB的二进制数据。
在Azure PaaS中有一个非常重要的概念叫Web Role/Worker Role。Queue作为Web Role/Worker Role沟通的重要的桥梁。
有关Azure PaaS平台的Web Role/Worker Role的内容，笔者会在接下来一章进行详细的介绍。
存储服务的性能指标
用户在选择使用Azure存储服务之前需要关心的一个方面是它的性能指标，也就是说，该存储服务是否能够满足用户日常的使用需求，同时是否能够满足用户访问峰值的情况。以下是一个存储账号的最大性能指标。
(1)一个存储账号的最大数据存储量是100TB
(2)一个存储账号最大的Transaction是每秒处理5000次(包括Blob，Queue和Table)
(3)一个存储账号最大的带宽是每秒钟传输3GB数据
以上性能指标是当前Microsoft Azure存储服务所能提供的最大性能指标，所以在应用程序运行过程中，用户实际上能获得的性能指标会低于该指标。
Windows Azure使用数据划分来提高数据访问性能和弹性伸缩。所以用户也应该尽量使用数据划分来把数据分散存储到多个服务器上以获得尽可能高的数据访问性能。每个数据划分的最大性能指标如下：
(1)对于单个Blob，每秒钟可以传输60MB数据
(2)对于单个Table Partition Key，每秒钟可以处理500个实体记录
注意，这只是单个Table Partition Key的性能指标，不是单个Azure Table。因此如果一个Azure Table能够有好的Partition设计，可以提高性能。
(3)对于消息队列，每秒钟可以处理500个消息
如果应用程序已经达到单个存储账号的最大性能指标，则可以考虑以下策略来进一步提高性能。
(1)对于Blob，可以考虑使用CDN来将经常访问的数据缓存到离用户最近的Edge Server来减少数据传输的时间。
(2)对于Table，可以考虑设计Partition Key，尽量把数据分散存储到多个地方
(3)对于Queue，可以考虑把多个消息集中到一个消息中或使用多个消息队列
存储服务安全性
Windows Azure存储服务会分配给用户两个访问密钥：主访问密钥和辅助访问密钥。
该访问密钥是256个字节的字符串，用户使用该访问密钥来验证每一个对Windows Azure存储服务的数据访问请求。
它的工作流程如下：
(1)用户首先构建数据访问请求，该数据访问请求可以是读Blob、写Entity到Table中或者使用Queue
(2)用户使用访问密钥通过加密算法对数据访问请求进行数字签名
(3)该数字签名包含在数据访问请求的标头部分(HTML Header)，然后数据访问请求发送到Windows Azure存储服务
需要注意的是，我们在申请存储账号时系统生成了两个访问密钥：一个是主访问密钥，另一个是辅访问密钥。两个访问密钥的功能相同都可以访问数据。之所以有两个是为了方便用户切换访问密钥。比如，在通常情况下用户使用主访问密钥，如果一旦主访问密钥被泄露，用户可以把主访问密钥在最短的时间内失效(重新生成一个新的主访问密钥)，然后切换到使用辅访问密钥。用户不需要为此修改代码，而只需要更改服务配置文件即可，同时更新服务配置文件也没有宕机时间。此外，另外一种有效的做法是应用程序代码可以先使用主访问密钥来访问数据，如果验证失败，代码自动使用辅访问密钥，这样用户在切换访问密钥时就不会有宕机时间了。
为了进一步提高对Blob数据访问控制的灵活度，Windows Azure数据存储服务还提供了另外一种叫做Shared Access Signature的数据访问控制方式。使用Shared Access Signature，管理员可以为其他用户生成一个临时的数据访问请求，该临时数据访问请求包含有效的数字签名，所以它可以通过数据验证。该临时数据访问请求也包含该用户可以访问哪些数据和操作权限等信息，而且该临时数据访问请求只会在指定时间内有效。这样管理员既可以允许其他用户访问数据，又不会泄露访问密钥。
需要注意的是，我们在申请存储账号时系统生成了两个访问密钥：一个是主访问密钥，另一个是辅访问密钥。两个访问密钥的功能相同都可以访问数据。之所以有两个是为了方便用户切换访问密钥。比如，在通常情况下用户使用主访问密钥，如果一旦主访问密钥被泄露，用户可以把主访问密钥在最短的时间内失效(重新生成一个新的主访问密钥)，然后切换到使用辅访问密钥。用户不需要为此修改代码，而只需要更改服务配置文件即可，同时更新服务配置文件也没有宕机时间。此外，另外一种有效的做法是应用程序代码可以先使用主访问密钥来访问数据，如果验证失败，代码自动使用辅访问密钥，这样用户在切换访问密钥时就不会有宕机时间了。
为了进一步提高对Blob数据访问控制的灵活度，Windows Azure数据存储服务还提供了另外一种叫做Shared Access Signature的数据访问控制方式。使用Shared Access Signature，管理员可以为其他用户生成一个临时的数据访问请求，该临时数据访问请求包含有效的数字签名，所以它可以通过数据验证。该临时数据访问请求也包含该用户可以访问哪些数据和操作权限等信息，而且该临时数据访问请求只会在指定时间内有效。这样管理员既可以允许其他用户访问数据，又不会泄露访问密钥。
二.计算服务
计算服务可以近似认为是CPU+RAM的计算能力
Windows Azure提供三种不同的计算服务：Web Site，Cloud Service和Virtual Machine。
1.Web Site
Web Site比较适合轻量级的计算能力。
Web Site的特点在于快速、轻松部署一个高度可扩展的云环境。使用您所选择的语言和开源应用程序，比如WordExpress，FTP，Git或者TFS，并轻松集成Windows Azure的服务，比如SQL数据库，缓存，CDN和存储。
但是Web Site只能提供比较基本的Windows Azure功能，比如Application和Data。但是更加高级的功能，比如Startup Task，Native Code，Virtual Network等功能，它是不支持的。
Azure Web Site提供四种不同的计算模式：
(1)免费(Free)
- 如果在免费(Free)模式下，客户的计算资源是和其他用户共享的，不是独享的。也就是说，Free Web Site的资源是和别的用户共享CPU。
- 一个Azure账户最多只能创建10个类型为Free的Azure Web Site。
- 在Free模式下，一个Azure Web Site最多能使用的存储大小为1GB
- 在Free模式下，Azure Web Site不支持横向扩展功能
- 在Free模式下，Azure Web Site是没有SLA保障的
(2)共享(Shared)
- 如果在共享(Free)模式下，客户的计算资源是和其他用户共享的，不是独享的。也就是说，Shared Web Site的资源是和别的用户共享CPU。
- 一个Azure账户最多只能创建100个类型为Shared的Azure Web Site。
- 在Shared模式下，一个Azure Web Site最多能使用的存储大小为1GB
- 在Shared模式下，Azure Web Site支持横向扩展功能，且横向支持最多6个共享实例
- 在Shared模式下，Azure Web Site是没有SLA保障的
(3)基本(Basic)
- 如果在基本(Basic)模式下，客户的计算资源是独享的
- Basic模式下，独享的计算资源有三种类型
(A)Small : 1Core/1.75GB RAM
(B)Medium : 2Core/3.5GB RAM
(C)Large: 4Core/7GB RAM
- 一个Azure账户可以创建无限多个类型为Basic的Azure Web Site
- 在Basic模式下，一个Azure Web Site最多能使用的存储大小为10GB
- 在Basic模式下，Azure Web Site支持横向扩展功能，且横向支持最多3个独享的实例
- 在Basic模式下，Azure Web Site支持99.9%的SLA
(4)标准(Standard)
- 如果在标准(Standard)模式下，客户的计算资源是独享的
- Standard模式下，独享的计算资源有三种类型
(A)Small : 1Core/1.75GB RAM
(B)Medium: 2Core/3.5GB RAM
(C)Large: 4Core/7GB RAM
- 一个Azure账户可以创建无限多个类型为Standard的Azure Web Site
- 在Standard模式下，一个Azure Web Site最多能使用的存储大小为50GB
- 在Standard模式下，Azure Web Site支持横向扩展功能，且横向支持最多10个独享的实例
- 在Standard模式下，Azure Web Site支持99.9%的SLA
有关于Azure WebSite的技术指标，请参考：
http://azure.microsoft.com/en-us/pricing/details/web-sites/
2. Cloud Service
Azure PaaS比较适合新开发部署的应用。
注意Azure PaaS是non-persist VM，也就是非持久化虚拟机。这里的非持久化，意思是azure只对客户开发的代码负责，
Azure Cloud Service从广义角度来说有两种：PaaS Web Role/Worker Role和IaaS的DNS，这里我主要介绍PaaS的Web Role/Worker Role。
Azure PaaS允许开发人员，基于微软提供Azure SDK for .NET，Java，PHP，Node.js，Python，Ruby等，将应用程序部署到Azure PaaS平台。
PaaS的Web Role/Worker Role是非常重要的概念。
通过利用Web Role，开发人员可以利用Web Role来部署HTTP/HTTPS的应用程序，包括ASP.NET, PHP(FastCGI), JSP等或者是基于HTTP的WCF应用程序等的Web应用程序。Web Role直接与外界进行通信。
Worker Role可以简单理解成Windows上的Windows Service服务，它是一个无用户界面的应用程序角色，默默地在后台运行，开发人员可以利用Worker Role来处理不需要用户界面的大量计算逻辑。
Web Role可以通过Queue的方式(也就是Azure Storage Queue)，向Worker Role发送一串消息，让Worker 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)，两者是松耦合的。
(2)Web Role和Worker Role的关系是多对多的，比如我可以在Web Role的配置中，设置 Instance Count为10。如下图:
而在Worker Role的配置中，设置Instance Count为3
这样的好处在于，前端有10台Azure Cloud Service Web Role Instance响应客户端HTTP的请求，而后端有3个Worker Role Instance来处理复杂的业务逻辑。
这种架构就好比一个餐厅，里面有10个服务员(Web Role)和3个厨师(Worker Role)。
- 服务员(Web Role)只负责招待客人(响应客户端请求)，并将客人的点菜信息通过队列消息交给厨房(Queue.AddMessage())
- 厨师(Worker Role)读取点菜信息(Queue.GetMessage)，随后负责烧菜做饭(进行后端逻辑)，当饭菜准备完毕后，则删除点菜信息。
- 如果前端压力过大(客户端请求过多)，则Web Role可以横向扩展
- 如果后端压力过大(后端逻辑处理过多)，则Worker Role也可以横向扩展
- 这种松耦合，多对多的关系非常适合企业级应用架构
可以看到，Web Role和Worker Role进行通信的重要途径是经过Azure Storage Queue，了解Queue对于Azure PaaS架构设计非常重要。
相比于下面介绍的IaaS，azure PaaS的好处，总结下来有以下几点：
(1)面向应用，而不是面向IT基础设施。微软作为云计算供应商，让用户将更多的精力放在构建优秀的软件架构上，而不必考虑底层的问题，例如网络、操作系统、虚拟化等IT基础设施上。又比如：PaaS(Platform as a Service)允许云计算供应商能够自动地升级操作系统，安装补丁；而在IaaS云平台上，升级操作系统、安装补丁的操作需要用户手动的去进行配置和升级，及时性、可靠性都不高。采用了PaaS平台后，云计算供应商和软件开发者能够各司其职，将注意力放到自己领域内的问题上。
(2)弹性。Microsoft Azure具有Worker Role和Web Role。Web Role能够响应前端事件，而Worker Role能够响应Web Role发送过来的请求。这样的架构在保证前端快速响应的同时，又使得云计算架构更加弹性。
Azure PaaS平台支持
(1)多种开发语言，包括.NET, Java, PHP, Node.js, Python等
(2)Azure PaaS的虚拟机类型，除了A0以外，都是独享的，支持以下8种虚拟机大小
实例名称 |
CPU |
RAM |
A0 |
Share |
768MB |
A1 |
1 Core |
1.75GB |
A2 |
2 Core |
3.5GB |
A3 |
4 Core |
7GB |
A4 |
8 Core |
14GB |
A5 |
2 Core |
14GB |
A6 |
4 Core |
28GB |
A7 |
8 Core |
56GB |
(3)Azure PaaS还支持虚拟机的动态横向扩展，如10台类型为A7(8Core/56GB)的实例做并行计算处理。
3. Azure Virtual Machine (IaaS)
IaaS (infrastructure as a Service)在云计算分类上，面向于IT基础设施及服务，让用户能够部署和运行自己需要的操作系统、中间件和运行时。对于传统的商业软件来说，迁移到IaaS平台上所花费的时间、精力相比PaaS而言要小很多。IaaS更加适合传统的商业软件。
Azure Virtual Machine虚拟机是以VHD格式进行保存的，并且保存在Azure Storage Blob。因为Azure Storage支持本地冗余、异地冗余、读取访问地域冗余，Azure Virtual Machine从存储的角度来说，已经提供了存储的高可用。
另外，Microsoft Azure支持Hyper-V托管的虚拟机上传至Azure云端进行托管。这样对于那些已经在企业内部实施微软Hyper-V虚拟化技术的企业来说，可以快速将企业内部的Hyper-V虚拟机直接上传至Azure，加快迁移的上线时间。
Azure Virtual Machine支持的类型为：
虚拟机类型 |
CPU |
RAM |
临时磁盘 |
外挂磁盘数量 |
IOPS |
A0 |
Share |
768MB |
20GB |
1 |
500 |
A1 |
1 |
1.75GB |
70GB |
2 |
2 * 500 |
A2 |
2 |
3.5GB |
135GB |
4 |
4 * 500 |
A3 |
4 |
7GB |
285GB |
8 |
8 * 500 |
A4 |
8 |
14GB |
605GB |
16 |
16 *500 |
A5 |
2 |
14GB |
135GB |
4 |
4 * 500 |
A6 |
4 |
28GB |
285GB |
8 |
8 * 500 |
A7 |
8 |
56GB |
605GB |
16 |
16 * 500 |
举例来说，Microsoft Azure单个节点支持的最大计算能力为A7，即8Core/56GB的计算能力。可以外挂16块磁盘，每块磁盘的最大容量为1TB，即外挂16TB的存储。支持的最大的IOPS为16*500=8000
请注意：以上Azure虚拟机CPU和内存是固定搭配的，不可按照用户的想法随意更改。
对于临时磁盘来说，该磁盘容量是与虚拟机类型有关。对于A7类型的虚拟机来说，该临时磁盘容量是605G。
对于Windows操作系统来说，该临时磁盘的盘符为D盘，且该盘符名为(Temporary Storage)。
这块临时磁盘的优势是：它的IOPS非常高，延迟非常低。
但是这块磁盘也有缺点：它不是持久化磁盘，也就是说，如果客户将文件保存在这块磁盘上，会有丢失文件的风险。这块磁盘其实是Azure Virtual Machine虚拟机所在物理机的磁盘，如果Azure Virtual Machine被重置了，或者漂移了，那保存在D盘的文件就会丢失。
我们建议将一些非关键的数据(允许丢失的数据)，比如SQL Server的TempDB，临时文件等保存在Temporary Storage里。
http://blogs.msdn.com/b/wats/archive/2013/12/07/understanding-the-temporary-drive-on-windows-azure-virtual-machines.aspx
Azure Virtual Machine支持的虚拟机操作系统为：
- Windows : Server 2008 R2, Server 2012, Server 2012 R2
- SQL Server：SQL Server 2008 R2, SQL Server 2012 SP1, SQL Server 2014 RTM (Web, Standard, Enterprise)
- Linux :
Ubuntu (12.04 LTS, 12.10, 13.10, 14.04 LTS),
CentOS (6.5),
SUSE (SUSE Linux Enterprise Server 11 SP3)
如何选择Microsoft Azure计算服务
如果我是一个企业级的用户，面对这三种不同的计算能力，我应该选择哪一种服务，将现有的企业应用迁移到Microsoft Azure云计算平台上呢？
从Microsoft Azure提供的三种服务的区别，如下图：
从上图中我们不难发现，在Microsoft Azure服务平台里，Web Site特点是：
(1)在Windows Azure上构建高度可扩展的Web站点。
(2)快速、轻松部署一个高度可扩展的云环境，并且可以从很小的规模开始。
(3)使用您所选择的语言和开源应用程序，比如WordExpress, FTP, Git或者TFS，并轻松集成Microsoft Azure的服务，比如SQL 数据库，缓存，CDN和存储。
(4)Web Site的特点在于快速部署，只能提供比较基本的Windows Azure功能，比如Application和Data。但是更加高级的功能，比如Startup Task，Native Code，Virtual Network等功能，它是不支持的。
Web Site比较适合
(1)现代的Web应用程序。包括客户端脚本，服务器端脚本和数据库的应用程序。并且可以横向扩展。
(2)连续开发。直接从源代码库使用Git或者Team Foundation进行部署。
(3)使用开源应用程序。你可以直接使用开源的应用程序，比如WordPress等。
Cloud Service的特点如下:
(1)在Windows Azure上简历或扩展您的企业应用程序。
(2)利用丰富的PaaS环境，创建高度可用的，可扩展的应用程序和服务。支持高级的多层架构，自动部署和弹性计算。通过Windows Azure PaaS，可以为全世界的客户提供强大的SaaS解决方案。
(3)通过Virtual Network，可以将本地局域网的网络与Windows Azure公有云网络做连接。这样就可以让企业网络享受公有云带来的高度弹性计算和互操作性，同时也保证网络安全。
Cloud Service比较适合
(1)多层的应用程序，每层都可以自我扩展。使用Web Role和Worker Role，Web Role可以响应前端的显示，而将复杂的业务放在后端进行处理。
(2)先进的管理。如果您的应用程序需要管理员权限、远程桌面访问或以提升的权限运行代码，您可以使用Cloud Service。
(3)私有云+公有云。你可以使用Windows Azure Connect与Azure公有云进行点对点的连接，或者使用Azure Virtual Network将企业内网或者私有网络与到公有云相互连接。
Virtual Machine的特点如下：
(1)提供IaaS的服务。不仅仅支持Windows，而且支持Linux操作系统。
(2)轻松地在几分钟内部署和运行Windows Server和Linux虚拟机，迁移运行负载，而且无需改变现有的代码。对于基于Windows OS的应用来说，可以将其部署到Hyper-V里做成VHD文件，然后直接上传到Windows Azure上面进行部署和托管。
(3)支持Virtual Network，将您的局域网企业应用与公有云直接连接，享受云计算带来的便利性。
Virtual Machine的特点如下:
(1)支持Windows或者Linux。你可以将现有的基于Windows或者Linux的应用快速迁移到Windows Azure。
(2)支持更多的服务应用程序。可以在Windows Azure使用SQL Server, MySQL，MongoDB，SharePoint应用程序。
(3)支持将已有应用程序迁移到公有云。你可以将持久化的非关系型数据保存到Windows Azure VHD里。
三.SQL Database (SQL Azure)
请注意，这里的SQL Database不同于传统的SQL Server 2008 R2，SQL Server 2012，SQL Server 2014。
微软在Azure Virtual Machine中提供与传统SQL Server一致的虚拟机服务。请参考Azure Virtual Machine相关内容。
这里介绍的SQL Database，是PaaS的SQL Server服务。在以前的版本称为SQL Azure，后来改名为Windows Azure SQL Database，简称SQL Database。
为了与传统的SQL Server做区分，笔者个人习惯使用老的SQL Azure来称呼Windows Azure SQL Database，请各位读者注意。
一般情况下，如果企业内部需要新建一个数据库服务，需要经历采购硬件、网络布线、安装操作系统、安装驱动程序、安装数据库软件等过程，整个过程显得漫长而繁琐，并且后期需要IT人员来维护数据库服务器。
如果客户订阅了SQL Azure服务的用户，可以方便快速使用SQL Azure服务而不需要采购任何硬件和安装软件。对于用户来说，SQL Azure就像是一个在Internet上已经创建好的SQL Server服务器，由微软托管和运维，并且部署在微软上海和北京的数据中心。用户只要简单的选择离自己物理位置最近的数据中心，就能立刻快速的享受到SQL Azure的服务。
SQL Azure能够提供的服务：
(1)传统SQL Server的功能，如表、视图、函数、存储过程和触发器等。
(2)数据同步：提供数据同步和聚合功能。
(3)管理：为SQL Azure提供自动配置、计量、计费、负载均衡、容错和安全功能。
(4)数据访问：定义访问SQL Azure的不同编程方法，目前SQL Azure支持TDS，包括ADO.NET，Entity Framework，ADO.NET Data Service，ODBC，JDBC和LINQ客户端。
SQL Azure Database与传统SQL Server Database有什么不同?
SQL Azure Database提供由微软托管的在云端的高可用性，可扩展性，多租户数据库服务。SQL Azure Database可以实现自主管理，供应与更简便的多数据库部署。开发者不必安装或管理任何软件。对于企业使用者来说，因为没有安装硬件和部署软件的过程，所以也降低了获得Database的时间与成本。
对于开发者来说，可以利用已有的T-SQL开发知识与熟悉的关系数据模式来使用SQL Azure进行开发和管理。SQL Azure Database可以让我们通过使用已有的开发工具，比如Visual Studio, SQL Server Management Studio来进行开发。同时SQL Azure Database还支持Ado.net, ODBC等连接方式，并且支持Entity Framework。
Criteria |
SQL VM |
SQL Azure |
Time to Solution |
|
|
Migrate Existing Apps |
Fast |
Moderate |
Build New Apps |
Moderate |
Fast |
Cost of Solution |
|
|
Hardware Administration |
None |
None |
Software Administration (Database & OS) |
Manual |
None |
Machine High Availability |
Automated (99.9% Uptime SLA at commercial release) |
N/A |
Database High Availability |
With extra VMs and manual setup via AlwaysOn (at commercial release), DBM; DR via log shipping, transactional replication |
Standard Feature (99.9% DB uptime SLA) |
Cost |
Medium |
Low |
Scale Model |
|
|
Scale-Up |
A7 VM |
Not Supported |
Scale-Out |
Manual via AlwaysOn read-only secondaries, scalable shared databases, peer-to-peer replication, Distributed Partitioned Views, and data-dependent routing (manual to setup, and applications must be designed for these features) |
SQL Database Federation (automated at data tier, with applications designed for Federation) |
Control & Customize |
|
|
OS and VM |
Full Control |
No Control |
SQL Server Database Compatibility, Customization |
Full support for SQL Server 2012 box product features including database engine, SSIS, SSAS, SSRS |
Large subset of SQL Server 2012 features |
Hybrid |
|
|
Domain Join and Windows Authentication |
Yes |
Not possible |
Data Synchronization via Azure Data Sync |
Supported |
Supported |
Manageability |
|
|
Resource Governance & Security Level |
SQL Instance/VM |
Logical DB Server |
Tools Support |
Existing SQL Server tools such as SSMS, System Center, and SSDT |
Existing SQL Server tools such as SSMS, System Center, and SSDT |
Manage at Scale Capabilities |
Fair |
Good |
SQL Azure Database有哪些新特性？
SQL Azure Database会自动进行三重备份，也就是说SQL Azure Database会自动将其自身复制到同一个数据中心不同物理主机之上，产生一个主备份和2个副备份。这样就提高了SQL Azure的可靠性、可用性、企业级别的安全特性，增加了数据库的安全性。如下图所示：
Data Sync(数据同步)
有些特殊的情况下，可能需要让局域网内的SQL Server数据和云端的Windows Azure数据库保持数据一致，SQL Azure的Data Sync功能能方便的让您本地的SQL Server数据库服务器与云端的SQL Azure数据库进行同步。它提供单向和双向数据同步，从而让数据可以轻松地在 SQL Azure 数据库和内部部署 SQL Server 数据库之间以及在同一数据中心或不同数据中心中的多个 SQL Azure 数据库之间进行共享。
使用SQL Azure Database的好处是什么？
(1)降低了总体拥有成本(TCO)
因为SQL Azure Database是云端的关系型数据库，您无需安装硬件、操作系统和数据库软件等过程，所以不需要IT人员来管理数据库，也不会产生License等费用；并且SQL Azure Database的费用是按创建个数和数据库大小来进行收费的，您在不需要的情况下也可以删除数据库，这样就不会产生任何费用。
(2)提高了可用性
因为SQL Azure Database支持三重备份，所以SQL Azure有99.9%的SLA保障。
(3)多租户
对于独立软件研发商(ISV)来说，他们可以在构建一套Web Site的情况下，使用SQL Azure。把用户的数据和配置放在相同(不同)的数据库(数据表)中进行隔离，那就可以让多个用户(租户)使用同一套系统，而且该租户只能看到自己的数据，不能看到其他租户的数据(也可以通过加密的方式，即使其他租户看到该数据也无法解析)。
在使用SQL Azure Database后开发模式有哪些改变？
本文转自Lei Zhang博客园博客，原文链接：http://www.cnblogs.com/threestone/p/3833397.html，如需转载请自行联系原作者
