架构抉择:享用微软SQL云平台就像吃烤鸭

      我们谈云计算SQL Azure本质，我们可以换一个角度先从设计模式上讲起。设计模式(Design Pattern)的一项重要目的就是“沟通”当人们谈到“歌德式”的设计模式时，脑海里浮现的应该都是一幅很类似的景致，例如：高耸的尖顶建筑、教堂式的外观门庭……，这是建筑师的设计模式。当然它也成功的融入了大众的生活层面，而这才可称为“设计模式”。

　　软件界的设计模式破除了语言的隔阂。Gamma的设计模式(Design Pattern)这个术语是在1990年，由Erich Gamma等人从建筑设计领域引入到软件计算机科学里。该书出版至今，国内软件界在开发应用程序上一直很少运用到设计模式的理论，追根究底的原因很多，沟通应该是其罪魁祸首之一。由我们不容易从字面上感受到这种设计模式的目的或精神，但我们可以经过反复的研读才能体会出来。这种劳民伤财的现象，和设计模式当初被推崇的原则完全不符;所以它在这里也就无从生根，程序设计人员当然也就没有从这里得到太多好处。

　　在这里，我想以声名远播的北京烤鸭是大家再熟悉不过的北京特色了!我们就用“北京烤鸭”来谈谈“一目了然的facade设计模式”。Facad(外观模式)设计模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。它的目的是将杂乱或设计不好的应用程序编程接口(API)再加上一层，把它包起来并提供一个容易看懂的新接口，本因就是提供一个简单的接口，让复杂庞大的程序接口隐藏起来。

　　我们可以借用北京烤鸭作例子，想象一下当你听到“北京烤鸭”时脑中浮现的是甚么呢?一只肉香四溢的烤鸭的全景图吗?若是直觉的、自然的反应那就对了，所以我尝试把facade设计模式直接用一目了然的成语作取代。如图1所示。

 

　　如上图所示，我们可以举一个façade模式的例子。比如说，现在有一辆汽车，我们(客户程序)要启动它，那我们就要发动引擎(子系统1)，使四个车轮(子系统2)转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。

　　前面说了一堆，读者们一定会想问，到底北京烤鸭跟SQL Azure到底有甚么关系?答案是“目的相同”，也就是考虑到提供使用者一个易读易写的应用程序编程接口。微软的SQL Azure开发团队，正在思考是否应该在云端上就把SQL数据库整个包装起来，再提一个完整而简单的应用程序编程接口给它，藉此让使用者能够轻易上手。

　　另一个选择是考虑到现有程序能够很容易的运用上来的作法，可以让SQL数据库以原本的风貌放置在云端，再透过标准的存取协议让既有的程序都能够立即能使用。这样的抉择也曾不断的出现在一般的IT部门，其立足点是思考是否隐藏那些数据库中的复杂表格信息，用简单易用的API取代，提供程序人员更容易上手的程序环境。今天的SQL Azure正是历经这种选择后的结果，也就是决定采不采用设计模式包装技术在做这个选择的好范例。

　　另外需要考虑，是否提供有效率的读取云端数据的选择。能够快速读写数据库中的数据一直被视为企业信息中心的必备技能，程序设计人员在进入信息单位报到之初，往往都必先从熟悉数据库表开始，也只有在慢慢熟悉数据库表的Layout后才能开始有产能。因此许多信息部门都会为此制订一套数据库的存取应用程序编程接口，然后美其名为“快速数据库存取API”，目的在让程序设计人员能够更简单更轻易的上手。从此，新进人员只要用很短的前置时间来了解这份API就能很快的上手。上面这一段说词，看起来非常合理，也真的有很多人这么做的，但实际上这么做却隐含着一些不好的后遗症。比方说，随着人员及业务种类的增加，一旦应用界面(API)不够用的时候，负责维护的同事就会开始接到报怨及要求;要求新增合用的快速数据库存取API，然后这个API就开始增加，而随着人员及业务种类的增加，API就又得开始增加，这种情形会一直持续的发生一直到你受不了，终于，你提供了一个可以直接传送SQL脚本到数据库上执行的API为止(这跟程序直接呼叫数据库不用透过API，在意义上是完全相同的，因此这个API接口也就名存而实亡)。

　　SQL团队的抉择。这是一段有趣的话题，当微软的数据库团队面临要将SQL服务器放在云端的时候，也碰到了跟上述话题同样的问题，是应该以提供各式服务接口让用户容易的存取，靠着强大好用的服务接口彻底的将SQL服务器隐藏起来?还是拿掉这个便利存取的抽象层，让SQL服务器直接面对外部的程序接口呢?

　　最后的结果是，微软选择了让SQL服务器直接面对外部的程序接口，也就是让程序能够运用T-SQL直接对数据库作存取的动作。
 

　　SQL Azure开发团队使得SQL服务器直接面对程序开发人员，能够在客户者端的程序中运用传统的TDS(Tabular Data Stream)与位在云端的SQL服务器沟通，但基于安全与横向扩展服务器数量的考虑，特别在中间设计了一层Gateway层，如图2所示的Security Boundary 所指的就是Gateway层。

　　如图2所示，我们隐约可以看出SQL Azure分成了好几个层次，如果再参考图3一起来看的话，就看得出来它实际上能够分成四层，最下面是基础架构(Infrastructure)这是架构底层的服务程序它掺杂着软硬件的I/O配合，也就是处理大量CPU群组的地方，它负责横向的多重架构作业(Fabric)、故障移除(Failover)、复制(Replication)及负载均衡(Load Balancing)，当然还包含软件版本的自动更新维护(它也负责实时侦查软件或是硬件所产生的异常现象并能自动采取相对的措施)等作业，这是一般云端架构的基础层。对于云端应用程序而言，它提供一些自我管理的机制，目前仍然相当神秘并没有对外开放，不过一些基本的API将会在近期内公开出来。

 图3 SQL Azure架构

　　SQL Server层是以SQL 2008为基础上，修改成适合云端作业的数据库层，所谓的“云端工作”指的是高可适用性(High Availability)及快速复制等配合功能。它可以接受传统的Transact-SQL(T-SQL)指令，但从网络端传送过来的资料并不会直接进到SQL服务器内，而是透过更高一层的Gateway层传入。

　　Gateway层的较完整名称应该是TDS Gateway，当程序进行SQL Azure联机时，实际上是联机到Gateway层，在这里进行防火墙及安全验证的安全性的计划后，联机才会真正进入到SQL服务器内，真正进行联机的建立(所有的恶意攻击、或非法的Login企图都依靠Gateway层来做阻挡过滤)。但一旦通过Gateway建立联机之后，就会由另一个通用管道负责后续的传送作业，这样做的目的则是为了减少通信上不必要的耽搁作业。

　　另外，网络的再因特网的入口处，图中在云的下方写着LB的方块，是整个SQL Azure中唯一面对因特网的部分，也就是程序唯一可以看得懂URL地址的部分，在网下就Gateway中存有的相对地址，它负责均衡分配进入点到各个Gateway层。如果你的程序是由Windows Azure呼叫进来的话，也是依循这个相同的端点来进入的。如图2所示，最上方则是你的应用程序，当然你可以采用SQL client Libraries，或是ADO.NET Data Service或是其他更高阶的程序语言来做开发，例如PHP等程序语言。这是由于开发团队决定采用传统的TDS(Tabular Data Stream)作中间的传输协议，造成使用这可以运用许多原有的或是标准的公具来做连线工作，甚至是侦错或监看的动作。

　　SQL Azure选择以传统的TDS为传输协议，而不是将SQL Server使用了一大堆的服务包装起来，让程序设计师十分容易延续对SQL SERVER的开发功能，这算是微软成功的第一步，当然SQL Azure为了适合云端的环境，也拿掉了一些不适合的功能，包括安全性、绝对路径等API功能，参考图2的上半部可以看出，ODBC及ADO.NET是标准的入口，因此，原本在ASP.NET端的大部分功能都能顺利的运用在这里，使得Windows Azure能够成为真正执行云端运算(Cloud Computing)的关系数据库服务，这是一种云端储存(Cloud Storage)的实作，成功的提供网络型的应用程序数据储存的服务，让许多既有的程序只要少许的修改就能存取云端数据资源。

　　facade设计模式可以将杂乱或设计不好的应用程序编程接口(API)再加上一层，把它包起来并提供一个容易看懂的新接口。简单的接口可以让复杂庞大的程序接口隐藏起来。模式与SQL Azure的共同关系既是“目的相同”，也就是考虑到提供使用者一个易读易写的应用程序编程接口，这样使得微软从数据库平台架构演变中，获得更合理的设计抉择。

     为IT168辑文，原文：http://tech.it168.com/a2010/0706/1074/000001074190_all.shtml