SQL Azure架构——有竞争力的区别
两周之前Kalen Delaney发布了关于SQL Azure内部架构的白皮书，其中的重点在于SQL Azure是如何达到可伸缩性和高可用性的。 大多数与之竞争的云解决方案都基于托管在虚拟机中的数据库的单一实例。 区分SQL Azure和它的云数据库竞争对手的基础特性是多客户共享的架构，而它也正是构建在该架构之上的。 白皮书为我们提供了关于SQL Azure架构的详细说明。
数据库创建
为了使用SQL Azure，我们需要一个Windows Azure平台账户，然后可以通过SQL Azure门户创建和管理数据库。 完成对SQL Azure服务器和主数据库的初始化工作之后，开发者就可以在开发过程中使用Visual Studio 2010或者SQL Server Management Studio。 当前对数据库的大小限制是50GB，对于企业版本还会再多10GB，而在每台SQL Azure服务器上，最多可以有149个数据库。
安全性和主数据库
安全性主要是由微软管理的，但是使用用户ID和密码仍然可以获得访问权。 Guest用户无法访问主数据库。 在主数据库中有两种新的角色，dbmanager和loginmanager。 主数据库还有其它的区别，体现在提供了以下视图： sys.firewall_rules、sys.bandwidth_usage和sys.database_usage。
所有在SQL Azure和客户端之间的IP通信都是经过SSL加密的，并且用户可能会基于一系列可接受的IP地址来创建访问控制列表。 它不支持USE命令，所有客户端连接都会直接与用户的数据库连接。
架构
尽管逻辑数据库对于开发者来说是单独的逻辑单元，但实际上开发者的数据会在三个SQL Server数据库中建立副本，一个主副本和两个二级副本。 微软对物理架构进行了抽象，并使用了负载均衡和连接路由，从而在访问数据库的时候提供灾难恢复和可伸缩性。
SQL Azure实现了和SQL Server一样的TDS接口，这样就为客户端库和应用程序提供了和SQL Server一样的访问方式。 此外，网络拓扑提供了四种清晰的层，从而提供了SQL Server的逻辑实例：
客户端层——应用程序会使用它来与SQL Azure通信
服务层——运行通道（gateway）服务，像连接路由、提供（provisioning ）和计费（billing）
平台层——托管在实际SQL Server数据库中的结点
基础架构层——物理硬件、网络和操作系统
高可用性
SQL Azure保证存储账户99.9%的正常运行时间，并且能够处理他们接收到的格式正确的请求，从而添加、更新、读取和删除数据。 直到主副本和二级副本都报告成功，并且向磁盘写入了事务日志，它才会认为数据已经成功提交。
所有节点都会由存在于不同物理机架上的六个点监控，而这些点会被视为是相邻的。 当在指定的节点上发生了故障，那么区块管理器（Partition Manager）就会执行重新配置，从而处理这个故障。 区块管理器会以随机的顺序处理故障，并且会一直做下去，直到没有需要处理的故障为止。
可伸缩性
对SQL Azure达到可伸缩性有帮助的有两种特性，首先是引擎流量调节（engine throttling），其次是负载平衡器（load balancer）。 每个节点都包含有引擎流量调节组件，它会监控节点的健康状况、日志大小、日志写入时间、CPU使用量以及数据库大小限制。 当超出限制的时候，数据库就会开始拒绝读写，根据微软的建议，开发者必须通过通过异常处理以编程的方式处理这种情况。
负载均衡器使用的是一种即时的方法，它会基于集群中各节点的当前负载来选择主副本和二级副本的位置。 同样，如果节点过载，负载均衡就会从主副本转移到另一个负载较少的节点上。 重要的是要注意到所有的读写都发生在主副本上，所以这会对SQL Azure数据库的性能造成很大的影响。
结论
微软期望把它的数据提供服务与云计算竞争对手区分开来，但是现在还只是通过对多客户共享架构提供了与SQL Server中类似的功能。 微软暂时也还没有为SQL Azure提供大家感兴趣的性能保证。 此外，我们可以从两个不同的角度来看待对多客户共享机制的使用，SQL Azure想要从软件创建者那里把实现和管理细节抽象出来，从而使其更易于使用。 然而，竞争厂商——像Oracle、IBM和Sybase——可能认为开发者想要得到这个级别的能力和配置，不过他们是通过使用虚拟机来提供的。
