网络备份系统体系结构研发设计

1、矚慫润厲钐瘗睞枥庑赖。 聞創沟燴鐺險爱氇谴净。 残骛楼諍锩瀨濟溆塹籟。 酽锕极額閉镇桧猪訣锥。 彈贸摄尔霁毙攬砖卤庑。 謀荞抟箧飆鐸怼类蒋薔。 厦礴恳蹒骈時盡继價骚。 茕桢广鳓鯡选块网羈泪。 鹅娅尽損鹌惨歷茏鴛賴。 籟丛妈羥为贍偾蛏练淨。 預頌圣鉉儐歲龈讶骅籴。 渗釤呛俨匀谔鱉调硯錦。 铙誅卧泻噦圣骋贶頂廡。 擁締凤袜备訊顎轮烂蔷。 贓熱俣阃歲匱阊邺镓騷。 坛摶乡囂忏蒌鍥铃氈淚。 蜡變黲癟報伥铉锚鈰赘。 買鲷鴯譖昙膚遙闫撷凄。 綾镝鯛駕櫬鹕踪韦辚糴。 驅踬髏彦浃绥譎饴憂锦。 猫虿驢绘燈鮒诛髅貺庑。 锹籁饗迳琐筆襖鸥娅薔。 構氽頑黉碩饨荠龈话骛。 輒峄陽檉簖疖網儂號泶。网络备份系统体系结构设计2

2、006-6-61. 网络备份系统介绍 31.1 网络备份系统背景 31.2 网络备份系统概述 32. 网络备份系统需求分析 52.1 用户需求分析 52.2 网络备份系统的功能模型 52.3 性能需求分析 73. 网络备份系统体系结构设计 83.1 体系结构风格选择 83.2 体系结构设计 93.3 其他的体系结构设计分析 113.4 构件设计与连接 124. 网络备份系统框架设计 134.1领域需求分析 134.2 框架设计 144.3 核心业务模块及扩展机制 175. 网络备份系统体系结构评估 195.1 ATAM 方法概述 205.2 商业动机的陈述 215.3 体系结构陈述 215.4

3、 确定体系结构的方法 225.5 质量属性效用树生成 235.6 体系结构方法分析 236网络备份系统详细设计 2525 尧侧閆繭絳闕绚勵蜆贅。28 识饒鎂錕缢灩筧嚌俨淒。28 凍鈹鋨劳臘锴痫婦胫籴。6.1 系统类图 6.2 人机交互部分的设计 6.3 数据接口部分的设计 1. 网络备份系统介绍1.1网络备份系统背景信息技术的迅猛发展，以计算机和网络技术为主的信息技术已在社会各个领域中得到广 泛的应用，而随着近年来网络系统的普及和应用，当前越来越多的企业和单位意识到数据备份和恢复的重要性，为了达到数据的高安全性和高可靠性，许多企业和单位投入了大量的硬件和管理成本。对于大型企业的关键性数据，市场

4、上已存在SAN和NAS等多种解决方案，而对于个人桌面而言却相对空白，研究表明个人机器上的数据往往也是企业数据的重要组成部分，因此如何为个人用户提供高安全性、高可靠性的数据备份系统是企待解决的问题。恥諤銪灭萦欢煬鞏鹜錦。目前数据备份有许多解决方法， 其中尤以基于网络的异地容灾备份系统备受瞩目。与传统的在线备份系统相比， 采用该方法实现的在线备份系统有数据安全性可靠性高，系统运行和维护开销小的优点，具有广阔的市场应用前景。因此本小组设计了面向个人桌面的网络在 线备份系统，并对其中设计的诸多问题进行了深入的研究。鯊腎鑰诎褳鉀沩懼統庫。1.2网络备份系统概述网络备份系统是一个可应用在企业内部网或广域网

5、中的面向桌面的在线备份系统。该系统给用户提供功能强大、方便快捷、安全可靠的在线备份服务。下面先介绍一下相关概念。硕癘鄴颃诌攆檸攜驤蔹。相关概念：冗余机制为了满足用户对备份系统的可靠性和安全性，系统将用户提交的需要备份的文件数据利用转换矩阵进行冗余打散，变成若干个数据块（假设是N块），然后上传。当用户下载备份文件时，将得到的若干个数据块进行组装，恢复成原文件。注意，这里下载的时候，不需要 下载全部N块，只需下载任意 M块（M<N），就可以恢复出原来的数据，这就是冗余所在。 当某些机器出现故障的时候，即使得不到全部N块，也能得到完整的数据。这里冗余打散和组装是用的特殊的矩阵变换，在达到可靠性

6、的同时， 也满足了安全性。阌擻輳嬪諫迁择植秘騖。增量备份所谓增量备份就是只备份在上一次备份后被增加、改动的部分数据。增量备份可分为多级，每一次增量都源自上一次备份后的改动部分。即当用户反复备份某一大部分内容相同的文件数据的时候，系统只备份在上一次备份后被增加、改动的部分数据。增量备份可分为多级，每一次增量都源自上一次备份后的改动部分。举例如下，某用户做开发工作， 昨天将源代码上传备份，今天做了一些工作，又将源代码上传了一次。那么今天只需上传增加改动的 部分。新版本的索引信息需要记录哪些是改动的文件，哪些是引用前一个版本的文件。由于不同版本之间拥有公共数据，因此需要一个版本管理机制。氬嚕躑竄贸恳

7、彈濾颔澩。这里再介绍一下引用计数的细节。 假设用户昨天上传了一个文件， 被冗余打散成4块（A 块，B块，C块，D块），那么这4块的引用技术分别为 1。今天此用户修改了该文件，又 上传备份。当冗余打散候，发现A块，B块，C块不变，而D块改动了，则上传模块将 D块命名成E块，只需上传 E块。而服务器上 A块，B块，C块的引用计数将变成 2,而D 块的引用计数仍然是 1, E块的引用计数则为1。釷鹆資贏車贖孙滅獅赘。本项目这个网络备份系统是一个可应用在企业内部网或广域网中的面向桌面的在线备份系统。该系统给用户提供功能强大、方便快捷、安全可靠的在线备份服务。为了达到上述的目标，我们需要解决以下问题：

8、怂阐譜鯪迳導嘯畫長凉。1. 如何为个人用户提供高安全性、高可靠性的数据备份服务。2. 如何在保证服务的基础上尽可能的节约存储空间和降低网络带宽消耗。3. 如何提高系统的存储性能，使得系统提供高性能的存储服务。4. 如何利用廉价的硬件成本提供好的服务质量，并减少管理和维护开销。 下面我们将针对上述问题提出相应的解决方案：解决方案：为了保证数据的高可靠性， 我们研究了硬件冗余技术和软件冗余技术相结合的可靠性理 论，提出了采用 Erasure code 分解编码的软件冗余技术与经典的 raid 硬件冗余相结合 的方法， 并在两种冗余技术结合的基础上， 利用分布式技术， 将数据尽可能的分布到不 同的服

9、务器上， 使得彼此的错误相关性降到最低， 从而达到高可靠性的远程数据备份的 目的。不仅如此，为了保证数据的安全性，我们研究了数据传输和存储的安全性问题。 在数据传输中采用压缩加密技术， 避免了传输过程中信息泄漏。 在数据存储中是将原文 件分解后分片存储， 从单一的碎片中不能得到原文件的任何信息， 从而保证了数据的安 全性。 谚辞調担鈧谄动禪泻類。为了节约存储空间和降低网络带宽消耗， 我们对数据增量备份技术以及数据压缩传输技 术进行研究。 为了满足不同应用的需要， 在对数据可靠性和备份速度权衡的基础上， 提 出了具有不同冗余度的增量备份技术，以提供不同可靠性等级和不同备份速度的服务， 满足了各种

10、应用的需要。 加之采用经典的压缩算法的数据压缩传输技术， 达到了节约存 储空间和降低网络带宽消耗的目标。 嘰觐詿缧铴嗫偽純铪锩。为了提高系统的存储性能， 我们完成了对备份系统中服务器的负载均衡与动态优化问题 的研究。在系统中， 对于服务使用者来说，数据服务池提供的数据服务是透明的， 在数 据服务池内部， 通过对各个服务器各种静态动态信息的收集， 对各个服务器的服务能力 进行评估， 根据不同的实际需要，采用不同的选择策略， 动态的选择服务器，从而达到 服务器的负载均衡和服务动态优化，提高了系统的整体存储性能。 熒绐譏钲鏌觶鷹緇機库。 为了达到利用廉价硬件成本提供好的服务质量的目标， 我们对备份系

11、统服务器的虚拟化 组织问题进行了深入研究， 提出了采用数据服务池技术来完成服务器的虚拟化组织， 通 过在服务器端设置服务器监控代理， 对服务器状态进行实时检测和预警。 通过这种虚拟 化的技术， 使得对于外部而言， 数据服务池是一个统一的整体，提供同一的服务， 池中 服务器可方便的实现服务的透明迁移， 并支持服务器的在线动态扩展和维护， 极大的提 高了服务的质量，并且降低了系统的管理开销。 鶼渍螻偉阅劍鲰腎邏蘞。1.3 项目面向的用户群 网络备份系统主要是作为一个可应用在企业内部网或广域网中的面向桌面的在线备份 系统， 该系统给用户提供功能强大、 方便快捷、安全可靠的在线备份服务。 所以我们将项

12、目 面向的主要客户群定位为： 纣忧蔣氳頑莶驅藥悯骛。1. 需要对企业关键数据进行备份的大中小型企业。 较之个人用户，企业关键数据更显得宝贵。据统计，60%的企业关键数据都存储在企业内部员工的PC机和笔记本电脑上，因此对企业内部员工的桌面备份显得尤其重要。颖刍莖峽饽亿顿裊赔泷。2. 在广域网中推出在线备份业务的互联网公司。3. 推广社区宽带网络增值服务的运营商。目前国内正大力推广小区宽带入户， 然而小区内部的带宽往往被大量闲置、 浪费。 本系统也可以提供快捷的局域网内的备份服务。 由于本系统同时兼有简单有效的共享功能， 因此濫驂膽閉驟羥它不仅是小区用户个人数据备份的工具，而且还是小区用户间数据交

13、流的平台。 闈詔寢賻。1.4本系统最终目标本系统最终目标是构建一个在线高可靠性的增量备份工具的系统，该系统支持简单方 便的客户操作界面和简单有效的虚拟存储管理。銚銻縵哜鳗鸿锓謎諏涼。2. 网络备份系统需求分析2.1用户需求分析网络备份系统的使用者分为两类：用户和系统管理员。这两类使用者对系统的功能需 求有所不同。用户凹备份文件（上传备份）-通过客户端软件，备份相应文件数据（即上传备份）。' 下载备份-通过客户端软件，下载所需要的文件数据。 备份删除-通过客户端软件，删除不需要的文件数据。I 备份的可靠性-用户对数据备份要求可靠性。必须保证数据不丢失。 备份的安全性-用户对数据备份要求安

14、全性。不能轻易被别人获得私人数据。戸注册用户名等通过客户端软件，输入用户名密码登陆。系统管理员用户、角色和权限的管理-系统设置和维护-安全管理服务器群的管理，包括网路负载，CPU利用率等等。2.2网络备份系统的功能模型基于需求分析，可以得到系统的功能模型如下：挤貼綬电麥结鈺贖哓类。网络备份系统匚交互模块界面冗余上传下载删除响应传输模块变换模块模块模块模块模块模块请求模块模块文件服务模块垃圾清理模块修复信息响应模块统计模块请求模块索引"系统服务管理模块模块用户管理调度模块解密服务模块模块器群管理消息管理模块L模块客户交互模块' 界面模块用户通过客户端界面模块和系统交互。冗余变换

15、模块，全称是“冗余打散文件与组装文件模块”为了满足用户对备份系统的可靠性和安全性，系统将用户提交的需要备份的文件数据利用转换矩阵进行冗余打散，变成若干个数据块（假设是N块），然后上传。当用户下载备份文件时，将得到的若干个数据块进行组装，恢复成原文件。注意，这里下载的时候，不需要下载全部N块，只需下载任意 M块（M<N），就可以恢复出原来的数据，这就是冗余所在。当某些机器出现故障的时候，即使得不到全部 N块，也能得到完整的数据。这里冗余打散和组装是用的特殊的矩阵变换，在达到可靠性的同时，也满足了安全性。赔荊紳谘侖驟辽輩袜錈。1 加密解密模块由于冗余打散和组装过程中数据块已经有加密的成分，所

16、以这里的加密解密模块只需考虑传输的时候一些关于索引信息，用户名，密码等传输控制的信息。塤礙籟馐决穩賽釙冊庫。' 版本管理模块前面提到了增量备份的概念， 即当用户反复备份某一大部分内容相同的文件数据的 时候，系统只备份在上一次备份后被增加、改动的部分数据。增量备份可分为多级，每一次增量都源自上一次备份后的改动部分。举例如下，某用户做开发工作，昨天将源代码上传备份，今天做了一些工作，又将源代码上传了一次。那么今天只需上传增加改动的部分。新版本的索引信息需要记录哪些是改动的文件，哪些是引用前一个版本的文件。由于不同版本之间拥有公共数据，因此我们需要一个版本管理模块。裊樣祕廬廂颤谚鍘芈蔺。&#

17、39; 上传模块根据用户需求，完成上传指定文件目录的工作。1 下载模块用户从网络备份系统中下载需要的文件。' 删除模块用户从网络备份系统中删除不再需要的文件。文件服务模块 响应请求模块当客户端或者其他服务器发出各种请求时，文件服务器给予相应的响应。相当于一个功能管理中心。円传输模块传输模块具体实现类似 ftp的传输功能，完成传输任务。 垃圾清理模块按照前面的引用计数，当文件服务器上面的数据块的引用计数为0时，清除该数据块。 修复模块文件服务器自发探测， 发现并修复损坏服务器上的数据块。当一个文件服务器彻底损坏时，它上面的数据块再也无法读取。这时，文件服务器会与其他相关的文件服务器相互通

18、信，从中取得数据，利用冗余机制将坏块重建。仓嫗盤紲嘱珑詁鍬齊驚。1 信息统计模块。每个文件服务器自己统计自己的一些系统信息，如磁盘空间，网络负载等等，将这些信息提交给索引数据库。索引服务模块 响应请求模块处理客户端上传，下载，删除，创建目录，传送索引等种种请求。索引服务器将对 这些请求给出相应的响应，相当于一个功能管理中心。绽萬璉轆娛閬蛏鬮绾瀧。' 调度模块根据文件服务器提交的信息，调度模块计算选择合适的文件服务器，提供给用户用以存储或下载。1 解密模块。当和客户端交互的时候，要将一些传输控制的信息解密出来，例如索引信息，用户系统管理模块系统管理员通过管理模块进行一些管理工作。主要是用

19、户的管理，服务器群的管理。- 用户管理模块管理用户的诸如帐户，密码，是否在线等信息。- 服务器群管理模块包括服务器群的网络负载，CPU负载等信息的管理。消息管理模块针对用户反馈信息，广告消息，系统通知消息进行管理2.3性能需求分析'性能要求：资源的访问效率和公平性要求系统设计能够保证海量数据备份、大规模数据传输的效率性，并保证多用户使用时的公平性。网络连接可拓扑性需求要求系统设计要能够满足大范围网络传输带来的时延、带宽等限制。同时要求系统具有规模可扩性，即可以提供某些策略支持，以保证在用户人数和系统规模急速增长的 情况下，以最少的改动适应系统新的资源压力。骁顾燁鶚巯瀆蕪領鲡赙。'

20、;可用性要求：资源的维护备份系统必须具有高度的可用性， 需要提供冗余支持以便维持系统运行健壮性，还需要提供可靠的数据备份机制，确保灾难发生时能够正确进行数据的恢复。能够方便地进行系统扩展。瑣钋濺暧惲锟缟馭篩凉。E 可修改性要求：系统结构灵活性 系统还需要具有良好的服务器扩展功能，支持多种服务器扩展模式，可根据用户量的大小及分布情况，选择相应的服务器扩展模式。鎦诗涇艳损楼紲鯗餳類。平台和资源的相对独立要求系统具有平台独立性，能够屏蔽平台的影响，实现系统的跨平台构建。I 安全性需求： 要求系统能够对恶意攻击作出判断和反应，能够提供基本的防御操作并能够支持防御功能的升级。3. 网络备份系统体系结构设

21、计3.1体系结构风格选择3.2我们使用4+1视图来指导体系结构设计，以逻辑视图，开发视图，场景视图为重点，辅助 以进程视图和物理视图，通过功能行为，将整个大系统划分为三个子系统：用户使用，管理 员使用，系统管理以下是对这三个子系统进行体系结构分析栉缏歐锄棗鈕种鵑瑶锬。由于网络备份系统是一个面向个人用户的系统，当用户使用该系统时， 最关心的两个问题就是备份数据的安全性与可靠性，特别是涉及到网络上的数据的传输，这些问题就显得十分 重要。因此，我们采用了这么两个策略来保证数据的安全性与可靠性：辔烨棟剛殓攬瑤丽阄应。1 采用数据加密传输机制来保证数据的安全性。2将文件打散为多个冗余碎片，存放到不同的服

22、务器数据库上来保证数据的可靠性。要实现这两个策略，需要用户在本地机器上运行复杂的代码，而不只是简单的上传下载的功能，而简单的浏览器并不能满足这个需要，因此，我们选用了 C/S架构。峴扬爛滾澗辐滠兴渙 藺。然而，传统的C/S架构有这么几个缺点：多个Client端与Server端数据库直连，会给 Server端数据库带来很大的压力。 Server端的业务与数据混合在一起，耦合度太高，不易修改。为了解决这个问题，我们采用了改进的3层C/S架构，将服务器端的控制与数据分离，形成用户层服务层数据层的三层C/S体系结构。詩叁撻訥烬忧毀厉鋨骜。这么一个C/S架构基本能满足用户的需求。然而，除了用户，我们还需

23、要为管理员提供管理接口。由于管理员不需要上传下载文件，因此，对于管理员而言，他无须安装客户端。 并且，管理员必须能够方便快捷地管理系统。因此，对于管理员，采用B/S架构是一个合适的选择。则鯤愜韋瘓賈晖园栋泷。除此以外，还有一个不容忽视的问题，那就是如果文件服务器发生永久性损坏，那么文件碎片的冗余度就会降低，这将会降低整个系统的可用性。如果损坏的服务器数目超过了阈 值，文件则无法恢复。对于这个问题，我们的解决办法是将所有的文件服务器组织成一个 P2P架构的机群，每台文件服务器可以自发地发现损坏的机器，然后将该机器上的数据恢复出来。胀鏝彈奥秘孫戶孪钇賻。因此，网络备份系统最终的设计方案就是一个集合

24、了C/S, B/S , P2P三种架构的混合体系结构。3.2体系结构设计3.2.1 C/S体系结构该体系结构是用来描述用户如何通过客户端获得系统的服务。当客户需要备份文件时，客户端向索引服务器发送请求，索引服务器通过访问数据库， 利用调度算法找出对该客户端而言速度最快最合适的几台文件服务器，将这些文件服务器列表返回给客户端，然后客户端直接将打散的文件传送到这些文件服务器上。鳃躋峽祷紉诵帮废掃減。当客户需要下载文件时，也是同样一个过程。客户端先向索引服务器发出请求，索引服 务器访问数据库，利用调度算法找出最快最合适的几台文件服务器，将这些服务器列表返回给客户端，客户端直接从这些服务器上下载文件碎

25、片，重新将文件组装起来。 体系结构如下图：稟虛嬪赈维哜妝扩踴粜。3.2.2 B/S体系结构该体系结构描述的是管理员如何通过web页面访问系统进行管理。当管理员要管理整个系统时，他可以通过 web页面登录。Web服务器会给管理员提供一个管理界面。主要管理功能有这么三种：陽簍埡鮭罷規呜旧岿錟。1. 用户管理Web服务器可以从索引数据库中读取所有用户的信息，管理员可以针对用户的信息，执行增、删、查、改的操作。如添加用户，删除用户，设定用户空间等 功能。沩氣嘮戇苌鑿鑿槠谔應。2. 服务器管理管理员可以对文件服务器群进行管理，加入或移出文件服务器。并且，管理员 可以通过索引数据库中的信息，查看文件服务器

26、的状态，了解各个服务器指定 时段的负载和使用情况。 钡嵐縣緱虜荣产涛團蔺。3. 通知管理在该系统中，存在这么几种消息：用户反馈消息；广告消息；系统通知消息。 管理员可以对这些消息进行管理。体系结构如下图：用户层服务层数据层Web服务器索引数据库管理员管理B/S架构3.2.3 P2P体系结构该体系结构是描述文件服务器之间如何自组织完成数据修复工作。尽管我们采用了冗余机制，使得我们的系统在某几台文件服务器发生故障时，依然能够 提供可靠的服务。但是，如果文件服务器损坏的数目超过了阈值，那么文件将无法恢复。所以，当一台文件服务器发生永久性故障，无法再恢复时，其他的文件服务器应该主动将损坏服务器上的数据

27、重建出来。步骤如下：懨俠劑鈍触乐鹇烬觶騮。1 文件服务器周期性自发访问索引数据库，看看是否有其他服务器永久损坏。2 寻找损坏服务器上适合自己修复的数据，加入自己的任务列表。3 执行任务列表里的任务，从其他文件服务器上将相关的文件碎片下载到本地，通过冗余机制重建出被损坏的碎片。謾饱兗争詣繚鮐癞别濾。体系结构如下：文件服务器P2P体系结构混合体系结构将以上3个不同的体系结构混合在一起，就是我们整个系统的混合体系结构。混合体系结构3.3其他的体系结构设计分析为客户提供的服务的体系结构除了前面说过的 C/S体系结构，我们还有这么一种B/S体系结构的设计：将客户端的功能转移到服务层，设计作一个代理服务器

28、。这样客户端就可以通过web界面，利用http协议上传文件到代理服务器，由代理服务器将文件打散，再分别传送到文件服务器上。下载时，通过代理服务器将文件组装完成，再利用http协议传送回客户端。体系结构如下：呙铉們欤谦鸪饺竞荡赚。客户层服务层数据层客户端文件服务器文件磁盘B/S体系结构优点：1 客户端只需要是用浏览器即可访问系统。2.系统维护、升级方便。缺点：1. 代理服务器必须处理所有客户的备份和下载请求，将他们所需的文件打散和组装。 代价很大。是系统瓶颈。2. 用户通过http协议上传下载文件，没有经过加密处理，缺乏安全性。3利用http协议传送文件速度慢，无法获得质量保证。文件服务器修复数

29、据的体系结构除了前面的P2P体系结构，我们还有这么一种 C/S体系结构的设计： 将修复文件的任务 交给一台代理服务器，由它去发现需要修复的文件，并将该文件碎片从新生成。最后再将生成的碎片传到文件服务器上。这样就是一个C/S结构。体系结构如下：莹谐龌蕲賞组靄绉嚴减。文件服务器C/S体系结构优点：文件服务器端代码简单，易于维护。修复机制集中在代理服务器上。修改方便。 缺点：代理服务器负载太大，是系统瓶颈。3.4构件设计与连接基于前面的体系结构设计，我们可以从面向对象的角度出发，在一个比较大的粒度上，将网络备份系统划分为客户模块，索引服务器模块，文件服务器模块以及web服务器模块共4个大构件。这些构

30、件在整体上被分为3层：客户层，服务层与数据层。由于这是一个实时交互的系统，因此不同层次的构件通过自定义的协议进行RPC连接。而在每个构件中，根据上面的需求分析，我们可以在一个小粒度下，将相互独立的功能模 块设计为其中的子构件。总的构件设计与连接如下：麸肃鹏镟轿騍镣缚縟糶。客户端界面浏览i器文件服务器群数据管理索引服务器处理请求调度Web服务器X7外部文件磁盘索引数据库解密数据管理构件设计与连接4. 网络备份系统框架设计4.1领域需求分析网络备份系统是一个面向个人用户的系统，其用户相当广泛，而且用户类型并不固定但不管对于怎样的用户，当用户使用该系统时，最关心的两个问题就是备份数据的安全性 与可靠

31、性，以及数据存取的效率问题。在这里，我们抽取了对于使用网络来进行数据备份的时候，不同角色关注的需求：納畴鳗吶鄖禎銣腻鰲锬。普通网络用户比较关注的需求 ：系统的数据安全性。本地数据丢失时可以通过网络备份系统得到很好的恢复；存放 在网络上的文件信息不被其他人窃取和篡改；当部分数据损坏或丢失时，并不影响 数据的恢复；系统能够及时地修复数据，防止信息丢失。風撵鲔貓铁频钙蓟纠庙。系统的数据可用性。“可用性”主要讲两方面的问题，一是确保能够随时取得备份的数据，二是保证数据的一致性（版本同步）。灭暧骇諗鋅猎輛觏馊藹。系统管理员比较关注的需求 : 系统可扩展性。能够支持任意多的系统用户，需要解决两方面的问题：

32、空间和索引 服务器负载能力。 “空间” 问题通过分布式结构能够得到很好的解决， 索引服务器负 载则需要通过索引分布化解决。 铹鸝饷飾镡閌赀诨癱骝。系统可用性。这主要是针对系统的服务，系统能够在用户需要的时候提供备份，下 载和修改等服务。数据操作高效性。 “数据操作” 包括本地的数据处理以及网络数据传输， 系统能够快 速的进行文件碎片处理等数据准备工作，在网络传输时系统能够选取一组高效的存 储线路同时在策略上考虑备份系统的特性， 备份系统的备份和下载操作的非均衡性。 攙閿频嵘陣澇諗谴隴泸。数据高效性。这里主要指数据空间的高效性，系统在确保数据安全可用的前提下， 避免同样的数据重复存储，在增量备份

33、的前提下使得数据得到更大的重复引用。 趕 輾雏纨颗锊讨跃满賺。系统负载均衡性。系统包括多个文件服务器以及分布的索引服务器，系统能够保证 这些负载均衡。系统低成本。“低成本” 包括两方面的内容， 一方面是用户希望得到免费的网络备份 服务，另一方面服务上希望通过很低的硬件成本就能提供服务。 夹覡闾辁駁档驀迁锬減。 系统兼容性。支持比较多的系统平台，网络备份系统充分利用了 JAVA 的平台无关 性。数据移动性。包括两方面的要求，一是系统保证用户在任何安装了网络备份系统客 户端的环境下备份 /恢复数据，二是系统的存储模块可以将存储的数据转移而不丢 失。 视絀镘鸸鲚鐘脑钧欖粝。4.2 框架设计 客户端的

34、结构框架图 :客户端界面基于客户端核心业务模块的扩展应用公共对彖层客户端新増 业务基类与通用服务系统端的结构框架图：系统管理核心业务模块系统端管理员界面信息统计模块基于系统管理核心业务模块的扩展应用垃圾清理模块系统管理核心业务模块修复模块用户管理模块服务器群管理模块调度模块消息管理模块系统端新增业务公共对象层基类与通用服务JAVA虚拟机底层公共框架说明：基类和通用服务层这一层主要是为了整个系统所需的基本服务提供基础设施，是整个系统开发中最基础最常用的部分.主要内容包括：偽澀锟攢鴛擋緬铹鈞錠。? 对象模型基类-JAVA类库提供应用开发所需的无关具体应用背景的基本基类。? 通用服务（基本的机制）-

35、对象创建、复制、删除等服务-消息机制-数据传输-安全维护- 冲突控制-同步管理这些通用服务以不完全实现的方式提供出来，应用开发者还可以根据实际应用的需要进一步完善开发。公共对象层提供系统范围内应用可能都需要的一组公共对象，这些对象所基于的类都可以在实际的应用开发中被继承，它们只是定义了公共对象最基本的属性和操作。当然，应用开发者也可以绕过这些公共对象， 定义自己所需要的对象。 提供这些公共对象的目的一方面是为了方便 应用开发者的开发，另一方面也可以使得基于框架的应用开发能够具有较高的一致性。按这些公共对象间的相关程度，可以分为如下的一些类组：緦徑铫膾龋轿级镗挢廟。? 类组0： 日历类-自然日历

36、? 类组1用户操作记录-用户ID-用户操作时间（日历）-用户操作类型（上传/下载/删除/备份等）? 类组2:用户组-用户ID-用户权限-用户操作记录? 类组3:系统管理员组-管理员ID-管理员权限-管理员操作记录? 类组4:传输消息组-消息头-消息类型 -消息内容4.3核心业务模块及扩展机制核心业务模块提供了网络备份系统的核心的功能，包括客户端的核心业务模块和系统端的核心业务模块，例如加密解密模块，版本管理模块，请求响应模块，文件传输模块，文件的 组装打散模块，数据管理模块，垃圾清理模块，修复模块，信息统计模块，用户管理模块，服 务器群管理模块，调度模块，消息管理模块等核心功能，并且提供了基于

37、类和通用服务层以及 公共对象层的扩展机制，使得应用的开发者可以基于基类与通用服务，或者公共对象层来完成新增业务的开发.核心业务模块层的目的在于创建一个良好的面向对象的体系结构，和一 个易于扩展的具有基础应用结构和行为的实现。应用的开发者可以对核心业务模块提供的这些功能进行扩展，增加用户界面、具体应用场景的特定需求、特殊规则、具有竞争力的应用特色，以及补充的应用功能。 比如对客户端进一步扩展自动升级功能，自动备份功能，自动监控文件夹的功能；系统管理员端对服务器端扩展出监控报警功能等.騅憑钶銘侥张礫阵轸蔼。客户端的核心业务模块：加密解密模块功能：这里涉及到在文件传输的时候一些关于用户名，密码，索引

38、信息等传输控制的信息的加密解密，以保证文件传输的安全性。疠骐錾农剎貯狱颢幗騮。- 主要操作：索引信息加密解密，传输加密，传输解密- 扩展点：支持多种不同的加密机制.版本的管理模块 功能：用户多次上传，由系统自动进行版本记录，根据增量备份的概念，即当用户反复备份 某一大部分内容相同的文件数据的时候，系统只备份在上一次备份后被增加、改动的部分数据镞锊过润启婭澗骆讕濾。 主要操作：文件版本的分析，索引计数的改变，文件版本的记录，操作日志的更 新扩展点：支持对以前版本的回滚上传下载模块 功能：上传下载模块和客户端进行交互，类似于 ftp的传输机制，将数据块上传给文件服 务器”或者从文件服务器下载数据文

39、件 ，完成传输任务榿贰轲誊壟该槛鲻垲赛。主要操作：选择文件块，测试连接，文件上传下载传输等 扩展点：传输模块同时处理多个文件的传输请求响应模块 功能:当客户端响应文件服务器的请求，同文件服务器端建立连接。处理不同的请求，相当于控制管理中心 主要操作：请求监听，建立连接，启动操作等 扩展点：（暂无）文件的冗余变换模块，全称是“冗余打散文件与组装文件模块” 功能:系统将用户提交的需要备份的文件数据进行冗余打散，变成若干块数据块，然后上传。当用户下载备份文件时，将得到的若干块数据块进行组装，恢复成原文件。邁茑赚陉宾呗擷鹪讼凑。 主要操作：文件打散，文件冗余备份，文件组装扩展点：在后台完成文件的打散或

40、者组装任务文件删除模块功能：当客户端向文件服务器发送删除某文件的请求，删除数据库中相关的文件及索引。主要操作：发送请求，等待响应等 扩展点：（暂无）系统端的核心业务模块：信息统计模块 功能：每个文件服务器统计自己的一些系统数据信息，如磁盘空间，网络负载等等，将这 些信息提交给索引服务器，索引服务器汇总统计出一个总的文件服务器数据信息库 嵝硖贪塒廩袞悯倉華糲。主要操作：文件服务器数据的搜集，索引服务器信息的统计扩展点：定时自动的数据信息统计，定时自动的数据信息汇总等调度模块 功能：根据文件服务器提交的信息，调度模块计算选择合适的文件服务器，用以用户数据块的存储。主要操作：根据一定算法，综合考虑文

41、件磁盘空间，文件服务器性能等多项数据 指标,选择文件服务器 扩展点：系统的稳定性垃圾清理模块 功能：根据文件服务器的信息，对于不再被引用的垃圾文件进行清理 主要操作：根据一定算法，查找垃圾文件，进行文件清理 扩展点：（暂无）修复模块 功能:根据文件服务器的信息，对损坏的文件服务器上的数据，进行修复主要操作：查询数据库，寻找合适自己的任务，修复数据块 扩展点：（暂无）用户管理模块 功能:对系统注册的用户进行管理主要操作：添加用户，查找用户，删除用户扩展点：查看当前用户状态服务器群管理模块 功能:对系统的所有文件服务器群进行管理主要操作：添加服务器，删除服务器，查询服务器当前状态扩展点：服务器状态

42、信息的历史统计消息管理模块 功能：对用户反馈的消息，系统通知消息，广告消息进行管理主要操作：查看消息，发送消息，删除消息扩展点：查询历史消息.5. 网络备份系统体系结构评估体系结构的评估方法主要有SAAM （ Software Architecture Analysis Method ）、ATAM(Architecture Tradeoff Analysis Method )、 ARID ( Active Reviews for Intermediate Designs ) 这三种。由于目前本系统的 SA 基本已经确定，因此采用 ATAM 方法来进行评估。 该栎谖碼戆 沖巋鳧薩锭。5.1 AT

43、AM 方法概述ATAM 方法概念体系结构权衡分析方法( Architecture Tradeoff Analysis Method )，简称 ATAM ，是一种 常见的软件评估方法，来源于质量属性分析方法和软件体系结构分析方法( SAAM )。该方 法提出了一整套软件评估的步骤和要求，并着重从性能、可靠性、可用性、安全性、可修改 性等质量属性的角度评价系统的适宜性。 这种方法不仅可以揭示出系统设计对特定质量目标 的满足情况， 而且能够使系统开发者更清楚地认识到多质量目标之间的相互作用和平衡， 即 如何权衡诸多质量目标。 劇妆诨貰攖苹埘呂仑庙。ATAM 评估时机 评估时机一般是在提出系统体系结构

44、和方法，明确系统构架之后，具体实现开始之前。 但实际上， 评估可以在软件体系结构生命周期的任何阶段进行， 而且一般的实际也有两种不 同的情况，即早期和后期。 臠龍讹驄桠业變墊罗蘄。早期：体系结构的评估并不要求必须等到整个体系结构的内容完全确定时才能够实施。 在体系结构创建的任何阶段都可以对已经做出的体系结构决策进行考察， 或从待选的若干项 中做出选择。也就是说，即可以评估已经做出的决策，也可以评估正在考虑的决策。 鰻順褛 悦漚縫冁屜鸭骞。后期：对体系结构进行评估时，系统体系结构已经完全确定，甚至其实现已经完成。 早期体系结构评估适于新领域系统的开发， 而后期体系结构评估适于开发团队已有部分 可

45、用的老系统的情况。 早期与后期的评估技巧完全相同。 根据开发项目的特点， 我们选择采 取早期的评估策略，即通过决策 > 评估 > 决策 >评估的螺旋上升过程完成评估。 穑釓虚绺 滟鳗絲懷紓泺。ATAM 评估参与者评估的 参与者可以分 为两大 类： 评估小组( Evaluation team )和风险 承担 者(Stakeholders)。这里的风险承担者包括：用户、客户、项目决策者 体系结构设计者、 构件设计者、项目管理者等。 隶誆荧鉴獫纲鴣攣駘賽。ATAM 评估步骤ATAM 方法主要分 4 大部分，共 9 个步骤： 表述：包括通过它进行的信息交流1. ATAM 方法的表述：

46、评估负责人向召集起来的评估参与者介绍 ATAM 评估方 法并回答问题，以期对该方法形成正确的预期。 浹繢腻叢着駕骠構砀湊。2. 商业动机的表述：项目经理或系统客户阐述开发该系统的商业目标。3. 软件体系结构的表述：系统设计人员对系统体系结构作出描述。 调查与分析，包括对照体系结构方法评估关键质量属性需求4. 确定体系结构方法： 由系统设计人员确定采用的体系结构方法， 但此时不进行 分析。5. 生成质量属性效用树 (utility tree ):说明构成系统“效用”的质量属性(性能、 有效性、安全性、可修改性、可用性) ，具体化到场景层次，标注刺激 /反应， 并区分不同的优先级 鈀燭罚櫝箋礱颼畢

47、韫粝。6. 分析体系结构方法： 基于步骤 5 识别出的高优先级的场景， 说明和分析针对这 些场景的体系结构方法。 在这一步骤中， 识别出体系结构风险、非风险、敏感 点和权衡点。 惬執缉蘿绅颀阳灣熗鍵。测试，包括对照所有相关人员的需求检验最新结果7. 头脑风暴发现场景并确定场景优先级8. 分析体系结构方法：针对步骤 7 的高优先级场景，重复步骤 6。这些场景被认 为是用以确认迄今为止所做分析的测试案例。 此种分析可能会发现更多的体系 结构方法、有风险决策、无风险决策、敏感点、权衡点等等。 贞廈给鏌綞牵鎮獵鎦 龐。形成报告，包括对 ATAM 评估结果的表述9. 结果的表述：包括方法、场景、特定属性

48、的问题、效用树、有风险决策、无风 险决策、敏感点和权衡点等。5.2 商业动机的陈述随着近年来网络系统的普及和应用， 越来越多的用户注意到了数据备份的重要性。 企业 中最宝贵的不是各种网络硬件， 而是网络上存储的业务数据。 如果无法保证网络数据的安全， 那么对网络的大量投资就失去了意义。 嚌鲭级厨胀鑲铟礦毁蕲。备份的方法主要可以分为硬件级和软件级备份。 硬件级的备份是指用多余的硬件来保证系统的连续运行，比如硬盘双工、双机容错等， 如果某个硬件损坏， 后备硬件马上能够接替其工作。 但这种方式无法防止逻辑上的错误， 如 人为误操作、病毒、数据错误等。据有关资料统计，计算机系统中80以上的错误属于人为

49、误操作。 当逻辑错误发生时， 硬件备份只会将错误复制一遍，无法真正保护数据，硬件备 份的作用实际上是保证系统在出现故障时能够连续运行，因此称为硬件容错更为恰当。 薊镔 竖牍熒浹醬籬铃騫。软件级的备份是指将数据保存到其他介质上， 当系统出错时可以将系统恢复到备份时的 状态， 由于这种备份是由软件来完成的， 所以称为软件备份。 这种方法可以完全防止逻辑错 误，因为备份介质和计算机系统是分开的，错误不会复写到介质上。这意味着，只要保存时 间足够长的历史数据，就能够恢复正确的数据。 齡践砚语蜗铸转絹攤濼。我们设计开发的备份系统是在软件备份的基础上再加上硬件容错系统， 使网络更加安全 可靠。网络备份实际

50、上不仅是指网络上各计算机的文件备份， 它实际上具有整个网络系统的 一套备份体系结构。 而开发和运营这样一个网络备份系统与开发经营其它的新产品一样具有 一定的风险性。 开发前期进行的设计是不是真能满足需求分析阶段所得到的各方面功能和性 能的需求？所采用的体系结构风格、 体系结构方法是否存在着潜在的问题和风险？设计的过 程中是否考虑了足够的现实条件和可能发生的富有挑战性的情况？碰到突发情况时， 系统是 否有足够的应对能力？等等问题，都是相关设计和实现的风险问题，要认识到这些问题并尽可能给出好的解决办法，需要对所采用的体系结构和体系结构方法给出一个合理的评 估。 绅薮疮颧訝标販繯轅赛。5.3 体系结

51、构陈述我们的网络备份系统采用了C/S、B/S和P2P三种体系结构混合在一起的混合体系结构。首先，为了实现允许用户上传文件数据的功能，我们采用了改进的三层 C/S架构，将一部分业务逻辑放到了客户端， 同时为了便于系统升级， 又在客户端中增加了完成自动升级功 能的模块； 饪箩狞屬诺釙诬苧径凛。 其次，为了方便系统管理员对整个系统的运行情况有所了解，对系统进行配置管理等， 通过给系统增加一个 Web 服务器，实现了 B/S 架构，方便管理员在任何地方、任何地点进 行无安装管理； 烴毙潜籬賢擔視蠶贲粵。最后，为了保证系统的可靠性和透明性，将文件服务器群设计成一个 P2P 的构架，这 样使文件服务器变成

52、一个自主的子系统。 鋝岂涛軌跃轮莳講嫗键。5.4 确定体系结构的方法安全性主要针对文件数据备份过程中可能遭受到攻击的情况： 将用户的文件数据打散为多个冗余碎片（通过矩阵变换，相当于加密） ，存放在多 个不同的文件服务器上。对索引文件、命令消息、用户信息等信息进行加密，然后再传输到索引服务器中。 可靠性主要针对于文件服务器关机或损坏的情况：当一台或多台文件服务器关闭的时候， 此时该服务器上的文件都不可用。 但是由于 用户的文件被打散为多个冗余碎片存在多个文件服务器中， 所以通过其他没有关闭 的文件服务器上的文件碎片便可以重新组合成原来的用户文件， 因此关闭某几台文 件服务器并不会对系统提供的功能

53、造成影响。 当服务器开启以后， 该服务器上的文 件碎片又变得可用起来。 撷伪氢鱧轍幂聹諛詼庞。当一台或多台文件服务器损坏的时候， 这时需要替换上新的文件服务器， 此时损坏 的文件服务器上所有的文件都不可用。 同样， 由于文件碎片的冗余性， 因此当换上 新的文件服务器以后，这些服务器形成的P2P 子系统会通过其他完好的服务器上文件碎片的信息，恢复新换上的文件服务器上的信息，因此也不会影响可靠性。 踪 飯梦掺钓貞绫賁发蘄。可修改性主要针对系统的升级：对于 C/S 架构，通过在客户端实现一个自动升级模块，便可完成系统的自动升级。 对于 B/S 架构，升级问题全部在 Web 服务器一端完成，不需用户的

54、任何参与。 透明性由于文件服务器群形成一个自适应的 P2P 系统，因此服务器动态的加入或是减少 对用户来讲是不可见的。性能主要针对文件传输和备份的速度：文件传输的速度： 将文件打散为冗余文件， 然后利用多线程对这些冗余文件同时进 行传输， 比在同样的网络环境下传输一整个文件的速度要快得多。 婭鑠机职銦夾簣軒蚀 骞。文件备份的速度： 如果对于用户想要备份的一个文件夹中， 只有很少的文件改动过， 而大部分文件没有改动过，那么系统只需将服务器端该文件的引用计数加一即可， 比重新上传文件要快得多。 譽諶掺铒锭试监鄺儕泻。可用性：系统数据备份： 采用多个备份数据库， 定期备份系统各类数据， 包括各种可用资源 的备份。备用服务器：在主服务器故障时， 能及时启动备用服务器， 并提供尽可能一致的服 务。5.5质量属性效用树生成在此次评估中，风险承担者声称他们最关注的质量属性是安全性和可靠性。但通过探察,风险承担者们发现性能也是一个非常重要的质量属性。俦聹执償閏号燴鈿膽賾。根据风险承担者们最初对所关心问题的表述和之后的集体讨论，得到如下图所示的系统效用树。在获取关于效用树的信息的过程中，我们确保了效用树中的每个场景都有与之相关的特定刺激与响应。缜電怅