【IT168专稿】“同步”是一种要求数据一致的作法，可以用到的地方非常多，但以架构设计的观点而言，在主从(Client/Server)的架构下或是在服务导向(SOA)的世界里，采用Rich Client作设计能够减轻服务端的负荷会远比使用Thin Client来得多，而且它对通讯带宽的要求非常少，更能够让服务器的负荷更小，是设计上的好选择。
 

　　Rich Client可以透过数据自动同步的机制，做到脱机工作的能力，但基本上程序设计人员必须相信这个同步工作才可以，所以这个“同步”工作的动作必须要有某一种足以完成任务的架构来支撑才行。就是因为这种需求让微软开发了Sync Framework，一种高适用性又能拿来支持Rich Client或是Smart Client的机制。

　　Sync Framework是免费的架构，并且也只能应用在.Net的架构上面，没有采用任何的标准协议，因此也一定无法进行跨平台，这是比较遗憾的地方。但还是有些机制可以弥补这个缺憾的，这一点我们留到后面再讨论。

　　再看一个有关个人需要用到同步功能的例子，如图2所示。

 
图2 Live Mesh工作页

　　如图2所示，它是微软Live Mesh的工作网页，当你取得Live ID之后，便可以登入这个微软为你准备位于云端的桌面系统，但它不属于Windows Azure Platform的一员，因为这个云端的桌面属于SaaS(Software as a Service)的范畴，并不是本文的主题，但却是同步工作的好示例。

　　图中显示了你可以登入的多个设备名称，这是一个完全属于个人的服务网页，主旨是提供个人在云端的桌面系统，目的是让你能够同步自己在各个电子设备上的信息，它是以文件系统的方式存在Live Mesh的桌面上，因此完全适用Sync Framework。很明显，这是一个未来大家都会希望拥有的一个云端服务，它对个人或是家庭都十分的适用，也就是说;你可以在出游的时候，利用随手可得的智能型设备将相片或数据上传到云端的桌面上，然后其它的装置连上来时，自然会做到同步的动作，也就是看到及时最新的资料。至于它是怎么做到的，请接着看下去…正是Sync Framework的佳作。

　　观念分享：一位朋友在Facebook里说了一段劣币驱良币的故事，我节录了一段如下，话说他觉得iPhone拍完立刻上传快捷好用，若采用单眼相机则必须等到事后再作处理，一旦开始累积相片，便成为一种负担，久而久之便无心再做了，干脆放弃单眼相机，因此便有了劣币驱良币这个数字故事。

　　话说Sync Framework的初始阶段，也就是登入设备时，便把他们做了区分，分别是Full Participants、Partial Participants及Simple Participants三种类别，而数码相机则属与Partial Participants类别，当Sync Framework启动时相机中的数据就可以借助在一旁的智能型手机传输到云端进行同步，接着所有的装置便都能够享受相片以最好的画面像素呈现了，大家也就不用再担心劣币驱良币的数位故事。

　　如图3所示，SQL Azure同步功能来自微软著名的Sync Framework，这是2004年就有的技术，目前的版本是2.0。这种技术的目的是提供非专业人士比较容易处理的同步操作，包括：

　　数据库的同步作业，描述如何使用 Sync Framework 来同步处理数据库。

　　档案同步作业，描述如何使用 Sync Framework 来同步处理文件系统。

　　Web摘要的同步作业，描述如何使用Sync Framework来同步处理RSS 和Atom摘要与本地存储内的数据。

　　Sync Framework提供一个全面的同步处理平台，可以处理各种应用程序、服务与装置的共同工作和脱机存取。Sync Framework配备各种技术和工具，可启用漫游(Roaming)、数据共享及脱机处理数据。使用Sync Framework，开发人员可以建立同步处理生态系统，透过任何网络上的任何通讯协议，将任何应用程式与任何存放区中的数据整合在一起。基本架构，如图4所示。

　　如上图所示，我们可以称它为“天使之翼”，因为它是对称的而且数据也来自云端，但其实真正的目的是要提醒设计云端程序的架构师，不要忘了运用数据同步的拓扑(Topology 指的是它的连接方式可以是任何形状，例如中央星状、多支点、或点对点等)。尤其是当网络的通讯速度及质量都不够稳定的时候，此时既能提供协通工作，又能提供脱机快速读写能力，Sync Framework正是发挥功能的时候，设计师们不应该错过。至Sync的程序怎么写呢?非常简洁，可以参考以下示例：

　　这是典型的运用Sync Framework所提供的档案同步功能(File Provider)进行指定档案同步的例子。在这里我们要同步的是本机端的C:\temp\floder目录与位于Windows Live Mesh端(云端的桌面)上面命名为MyMeshFolder的目录，程序十分简单，也反映了SyncFramework的简洁特性。

　　首先，建立一个SyncOrchestrator 的对象，它将负责同步的工作处理，也是应用程序的重要接口Orchestrator。接着就是个别创建本地端与云端的提供者(Provider)，这里采用Sync Framework所提供的档案提供者，最后一个指令就是启动它的同步工作Orch.Synchronize。由以上可以看出运用提供者的方式可以使的程序变得十分简单，当然一些有关的冲突现象得处理功能，Sync Framework与原有数据库的Replication功能间的差异读者可以参考相关资料，在这里就不在赘述。

　　我们再扩充一下上面的主从架构下的同步工作图标。如图5所示，显示的是运用同步机制让你的另一个程序也能同步处理相同的数据，这一点也可以广义的运用在云端同时处理多个相同程序的机制。

　　同步工作的运用可举一个在线游戏的示例，上面的这张图示，它可以运用在一般在线的游戏，詴想你在在线玩一个对打的游戏，图下方的二个相同的Client Ap.应用程序分别代表甲乙二方，他们正在进行对战的游戏，这个时候SYNC服务可以依据双方的按键动作同步提供给二个个别的Client Ap.让他们自行运算并做出个别的反映，这样就能达到二个人看到同样的画面，并且进行同步的互动效果了。至于上方的Service方块，则在于可以提供多于二人的架构模式，让多人同时参与，而数据同步的部分则依靠此Service 进行同步作业。这样的需求到处都有，至于在云端上如何呢?我再针对SQL Azure Data Sync的同步功能做一下描述。

　　在SQL Azure Data Sync的特性中，两个必要的配置：

　　? Sync Framework 2.0

　　? Sync Framework Power Pack for SQL Azure

　　它提供了几种只有云端特有的功能：

　　? 一个新的数据库提供者(SQLAzureSyncProvider)。

　　? 一个独立执行的同步数据库转换功能程序。

　　? 一个Visual Studio的Plug In脱机作业展示程序。

　　目的：

　　? 将公司内部现有的SQL Server连结到SQL Azure。

　　? 在Windows Azure中新建应用程序时，不需要舍弃现有的公司内部应用程序。

　　? 脱机使用 Windows Azure 和SQL Azure的应用程序。

　　独立执行的同步数据库转换功能程。

　　这是附在Sync Framework Power Pack for SQL Azure内的可独立执行的SQL Azure同步数据库转换功能程序。目的是将本地端的SQL服务器上的数据与位于云端的SQL Azure数据库进行手动式的同步作业。这个功能程序基本上是为了第一次将本地端原有的数据库数据上传至云端的SQL Azure做第一次同步动作的手动作业功能。

　　 

　　如上图所示，点击Next开始输入SQL Azure端必要的数据，包括SQL Azure的服务器名称、数据库名称、Administrator名称及密码。Server Name的地方请输入[你的sql azure server name].database.windows.net。

　　这是第一次设定时最容易犯的问题，请键入包含Server Name的整个URL值，如图7所示。

　　然后点选Next，开始输入本地端必要的数据，这个例子里，我们采用将整个AdventueWorksDWAZ2008R2的范例数据库送到云端的SQL Azure上面，它的大小大概是92.2Mbytes，如图8所示。

　　然后点选Next，功能程序详列数据库中的字段，供操作者以手动选取欲同步的字段。如图9所示。

　　接着点选Next，提供调整字段顺序的功能，这里提供我们调整字段顺序的功能。如图10所示。

　　接着点选Next，开始同步前的总结说明，如图11所示。

　　点选Process，开始同步工作，如图12所示。

　　同步完毕的画面，如图13所示。

　　看完上述功能，你可能会想知道它的运作原理，那么就可以来分析一下。我们称想要进行同步的程序为同步应用程序(Sync Application)，它是起始的根源，但真正看得懂两边数据的是靠所谓的同步提供者(Sync Provider)，它们分别为对应到SQL Server的SQL Server Sync Provider以及对应到SQL Azure的SQL Azure Sync Provider，同步提供者才是真正看得懂二边数据的存取者。

　　同步应用程序负责则设定同步的方式。而真正执行的则是由Sync Orchestor去驱动Sync Framework的执行其对象(Runtime)。上面的SQL Server与SQL Azure我们称之为Data Store，它也可以是档案或其他对象，重点是只要同步提供者能够看得懂就可以了。如图14所示。

　　从上图中你可以发现，Sync Framework并没有在云端执行起来，实际上，两对翅膀(我喜欢如此称呼对称的两个目标)都在本地端，而通讯协议则是依靠原有传统的TDS(Tabular Data Stream)负责数据的读写。这个架构是最典型得脱机执行模式的架构。当然我们可以改用其他的方式作架构，也能做到此效果，但基于效率的考虑，这是一个很有效率的方式了。

　　展示SQL与SQL Azure。在这里的目的是运用程序来展示读取本地端的SQL服务器跟云端的SQL Azure的写法上有何不同。而作法如下：

　　(1)第一阶段是采用ASP.NET 撰写一简单读取本地端的SQL服务器的Web应用程序。

　　(2)第二阶段是将程序修改成读取云端的SQL Azure的程序。

　　结语：

　　SQL Azure与SQL服务器之间的差异：SQL Azure是将SQL服务器放置在云端，然后再在它的前面加上通讯上必要的LB(Load Balance)以及安全性的机制Gateway层，并在底层提供足以大量复制及多重多写的基础结构(这里并未采用Windows Azure的VM机制)。如果以因特网的观点来看，就是在SQL服务器上直接加入因特网的Web应用接口，供外部程序作呼叫而已。但基本上，SQL Azure提供了所有的维护作业，这是一般运用SQL服务器的信息部门的一大福音。当然这也是云端产品的最基本的功能，另外除了自动的维护作业，还有无时无地都可以读取的高度适用性以及横向放大的能力。

　　同步目的是让Rich Client分担一些工作，而不是把所有的工作都丢给服务(service)去做。同步架构(Sync Framework)的目的是提供一个稳固简洁的同步环境，减少一般程序人员在设计上的复杂度。在这里唯一的遗憾是没有标准，高效能的同步机制处处可见，但却一直没有标准诞生，这造成即使是号称能够跨平台的工具，也无法相呼沟通很是可惜。云端同步作业的重要性，是在可以实时提供多组不同地点的使用者共享相同的资料来源，一起作协同的作业。对于Windows Azure Platform而言，它可以协助架构设计设发挥多样化的拓扑来架构更有效率的解决方案，也能帮助程序设计人员做好协同作业或脱机的高效能工作模式(例如：非常适合像Silverlight 这种智慧型的应用程序)。对一般的使用者而言，它属于SaaS(Software as a Service)的优良解决方案，可以让多组设备读取一组位于云端的正确数据。