重庆邮电大学实验指导书-应用系统架构

编制单位：计算机专业实验中心编制人：李鸿健段小林编制时间：2017年5月

前言一、课程介绍《应用系统架构》是我校计算机工科专业本科学生的一门主要的专业选修课程，主要介绍应用系统架构基本概念、基本原理和方法，也是计算机科学技术的一个重要领域。学生通过本课程的实验，一方面培养系统解决方案设计、软件架构设计，模块设计等能力，培养设计领域尖端人才。另一方面培养学生开展前沿课题研究的能力，搜索文献，提出问题，激发创新思维，开展科学研究的能力。二、课程要求根据课程的性质、任务、要求及学习的对象，学生进行的实践应完成2个大题，一是对系统架构前沿的探索研究，包括软件危机，软件重用，软件产品线和SOA方法；二是设计一个大型系统的完整架构方案，内容包括：功能目标决策分析，物理视图，逻辑视图，开发视图和过程视图，非功能目标分析等。必须首先完成实验任务书规定的任务。通过实验学生应达到下列基本要求：学生应能设计系统架构，进行结构化需求分析，找出关键功能，设计五种视图对架构进行描述，掌握SOA方法。学生应了解前沿应用系统架构研究进展，研究科学家的最新观点，提出自己观点，撰写一篇以系统架构相关的科研论文。能根据需要选学参考书，查阅手册，通过独立思考，深入钻研有关问题，学会自己独立分析问题、解决问题，具有一定的创新能力。能正确使用实验环境，掌握测试原理，明确实验目的及任务，课前做好预习，及时发现及解决实验中的问题。能独立撰写实验报告。报告要求：分析设计思想，绘出流程图，编制程序，准确分析实验结果，解答思考题，以及本次实验的心得体会。计算机专业实验中心2017年5月

目录实验1系统架构基本理论 5实验2系统架构设计原则 6实验3CAP基本理论 8实验4CAP的延伸BASE理论 10实验5软件重构模式 12实验6软件产品线 13实验7负载均衡算法 18实验8负载均衡模式 21实验9无共享架构 23实验10分布式计算架构 26实验11SOA架构设计 29实验12ED-SOA架构 33实验13高并发系统架构 37实验14高可用系统架构 41实验15五视图法架构设计-用例分析 45实验16五视图法架构设计-逻辑架构 48实验17五视图法架构设计-开发架构 50实验18五视图法架构设计-数据架构 52实验19五视图法架构设计-运行架构 55实验20五视图法架构设计-物理架构 57实验21领域模型分析法基础与案例 59实验22大规模软件开发基础 61实验23大规模软件开发-案例分析 63实验24基于云和大数据的软件架构基础 66实验25基于云和大数据的软件架构基础-案例分析 68实验26遗留系统的改造基础 70实验27遗留系统的改造-案例分析 72实验28主流应用架构案例剖析 74实验29应用架构方案设计 77

实验1系统架构基本理论一、实验目的1．了解系统架构基本理论。2．了解系统架构与软件工程的关系。3.了解系统架构发展前沿二、实验学时 2学时三、实验内容1.查阅文献分析总结系统架构的发展历程。2.系统架构的最新发展趋势总结。3．小组讨论大数据时代系统架构发展的新方向。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验2系统架构设计原则一、实验目的1．了解系统架构设计原则。2.了解系统架构设计发展前沿二、实验学时 4学时三、实验内容实验任务：查阅文献分析系统架构设计原则，系统架构的最新发展趋势总结。小组讨论以下系统架构设计原则为架构设计带来的好处及避免那些风险，形成观点，撰写报告。1.单一职责原则（SRP）：一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP，SingleResponsibilityPrinciple）。单一职责，强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。关于单一职责原则，其核心的思想是：一个类，最好只做一件事，只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。因此，SRP原则的核心就是要求对类的改变只能是一个，对于违反这一原则的类应该进行重构，例如以Façade模式或Proxy模式分离职责，通过基本的方法ExtractInterface、ExtractClass和ExtractMethod进行梳理。2．开放-封闭原则（OCP）无论如何，开放封闭原则（OCP，OpenClosedPrinciple）都是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。关于开发封闭原则，其核心的思想是：软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。因此，开放封闭原则主要体现在两个方面：对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。“需求总是变化”、“世界上没有一个软件是不变的”，这些言论是对软件需求最经典的表白。从中透射出一个关键的意思就是，对于软件设计者来说，必须在不需要对原有的系统进行修改的情况下，实现灵活的系统扩展。而如何能做到这一点呢？只有依赖于抽象。实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/聚合复用原则。关于这两个原则，我们在本书的其他部分都有相应的论述，在应用反思部分将有深入的讨论。对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有TemplateMethod模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。3.里氏代换原则（LSP）4.依赖倒转原则(DIP)要依赖抽象，不要依赖具体。5.迪米特法则(LoD)一个对象应该对其他对象有尽可能少的了解。6.接口隔离原则(ISP)使用多个专门的接口比适用单一的接口要好。7.合成/聚合复用原则(CARP)要尽量使用合成/聚合，尽量不要使用继承。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验3CAP基本理论一、实验目的1．了解CAP基本理论。2．了解CAP的发展历程。3.了解数据库事务架构发展前沿二、实验学时 4学时三、实验内容1.查阅文献分析CAP的发展历程。2.数据库事务架构的最新发展趋势总结。3．小组讨论如何构建不可变模型避免CAP的复杂性。1985年Lynch证明了异步通信中不存在任何一致性的分布式算法（FLPImpossibility）的同时，人们就开始寻找分布式系统设计的各种因素。一致性算法既然不存在，但若能找到一些设计因素，并进行适当的取舍以最大限度满足实现系统需求成为当时的重要议题。比如，在CAP之前研究者就已经发现低延迟和顺序一致性不可能同时被满足。2000年，EricBrewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征，断言用此三者可以划分所有的分布式系统，并指明这三个特征之间的不可能性关系。Brewer猜想比单纯的“低延迟和顺序一致性不能被同时满足”的结论更具体，对实际系统的构建也更具有可操作性！Brewer教授当时想象的分布式场景是webservice，一组websevrice后台运行着众多的server，对service的读写会反应到后台的server集群，并对CAP进行了定义：C（一致性）：所有的节点上的数据时刻保持同步A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）高可用、数据一致是很多系统设计的目标，但是分区又是不可避免的事情：CAwithoutP：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。CPwithoutA：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。APwihtoutC：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验4CAP的延伸BASE理论一、实验目的1．了解BASE基本理论。2．了解数据库架构中ACID和BASE的区别与联系。3.了解分布式系统BASE理论的发展前沿二、实验学时 4学时三、实验内容针对以下内容进行小组讨论，提出观点。一、BASE理论eBay的架构师DanPritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（EventualConsitency）。BASE是指基本可用（BasicallyAvailable）、软状态（SoftState）、最终一致性（EventualConsistency）。二、基本可用（BasicallyAvailable）基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。三、软状态（SoftState）软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysqlreplication的异步复制也是一种体现。四、最终一致性（EventualConsistency）最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。五、ACID和BASE的区别与联系ACID是传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。ACID和BASE代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和BASE又会结合使用。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验5软件重构模式一、实验目的1．了解软件重构模式基本理论。2．掌握软件重用形式分类。3.掌握软件重用分类编辑方法二、实验学时 4学时三、实验内容软件制作中有三种级别的重用，重用是为了提高效率和降低成本。这是软件制作的核心目的。1.内部重用，即在同一应用中能公共使用的抽象块;2.代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；3.应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。4.基于已有系统，设计以上三种级别的可重用案例。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验6软件产品线一、实验目的1．了解什么是软件产品线。2．掌握软件产品线开发模式。3.掌握软件产品线工程方法二、实验学时 4学时三、实验内容基于软件产品线完成针对单一系统（酒店预定系统）的面向服务的分析与设计。SoSPL方法的核心是面向服务的分析与设计（ServiceOrientedAnalysisandDesign，SOAD）活动。SOAD是一个新兴领域，它涉及到基于业务需求来确定和构建服务。SOAD将服务视为第一级实体，非常类似于处理类和对象的面向对象的分析与设计（ObjectOrientedAnalysisandDesign，OOAD）。OOAD中的典型起点是用例模型，但SOAD中的起点是业务流程建模。需求活动业务流程建模（Businessprocessmodeling，BPM）通常用于说明服务需求。业务流程

是一组执行用于实现某个目标的相关业务任务。其重点集中于业务流程而不是用例。其中没有对任何参与者建模，并且重点在于从业务角度看到的业务流程行为。可以使用统一建模语言（UnifiedModelingLanguage，UML）活动关系图对业务流程建模。活动关系图对于在域业务建模期间详细描绘业务流程工作流特别有用。图1显示了一个酒店预订流程。该关系图中的每个活动都表示一个包含子活动的高级活动。图1.酒店预订流程的UML活动关系图此阶段的产物是一组BPM模型，这些模型以描述业务流程行为的UML活动关系图表示。分析活动候选服务是基于需求模型来确定的。确定可重用服务是一个主要目标，因为可重用性是面向服务的最重要好处之一。一个业务流程模型可以由单个服务或由多个服务来实现。可以分析业务流程模型以确定可重用的自主操作。其目标是指定满足所需业务流程的最基本操作，以便能够逻辑地将它们分组到候选服务中。必须决定是在单个服务中集合所有操作，还是将相关操作分组到不同的服务中。表1.服务构造条件构造型角色abstractservice非具体；未绑定到实际的服务实现applicationservice具体standaloneservice不允许成为某个组合的一部分composableservice允许成为某个组合的一部分compositeservice由两个或更多个服务构成entitycentricservice数据密集型taskcentricservice业务逻辑controllerservice控制和协调其他服务monitorservice监视其他服务分析阶段的产物是一个元类模型，此模型描述候选服务、候选服务的角色构造型及其操作。设计活动在此阶段，将设计在分析阶段确定的候选服务。服务接口

是对该服务提供的操作的描述。它详细描述操作、输入/输出参数和消息类型。还可以指定候选服务所需要的其他服务。服务接口设计要求同时指定所提供的和所需要的接口。用于软件产品线的SOAD需求活动：必须用共性和可变性分析对需求活动进行扩充。需要从业务流程模型转变到功能模型。SPL需求共性和可变性分析阶段广泛使用功能模型来对SPL成员应用程序的所有可能配置建模。相关功能被分组到各个功能组中。产品线成员从功能组中选择它们所需的功能。通过自定义，可以将服务用在多个系统中。基本的通用服务可由具有不同功能的多个系统调用。要在软件产品线中使用服务，需要在考虑可变性的情况下对服务进行分析。通过在UML活动关系图中引入可变点，可以对需求可变性建模。为此，可以使用分支和监护结构，以及指示可变位置（可变点）和要在那些可变点处插入的不同行为的UML构造型。图2显示了酒店预订活动关系图中的一些可变点。可变点对约定、居住和会议预定进行区分。图2.酒店预订流程的UML活动关系图中的变化按照图书

DesigningSoftwareProductLineswithUML（请参见参考资料部分）中介绍的分类，需要确定公共、可选和替代功能。公共功能是产品线的所有成员中都存在的需求。可选功能是产品线的部分成员中存在的需求，替代功能是产品线的部分成员从中进行选择的需求。可以基于业务流程活动关系图中的可变点确定功能。每个可变点可以映射到单个功能，或者多个可变点可以映射到一个功能。此外，整个业务流程可以映射到一个功能，或者一个功能可以包含多个业务流程。最后，将为整个产品线开发一个功能模型（以UML元类关系图表示），如图3所示。图3.酒店预订流程的UML元类功能模型分析活动首先，你要使用针对单一系统的分析部分中描述的方法，确定产品线的所有成员共有的候选服务。然后，通过使用前面讨论的针对单一系统的相同技术，考虑可选和替代的服务。下一步，要分析业务流程模型中已确定的可变点。必须确定是要作为单个服务的一部分还是作为多个服务的一部分对这些可变点建模。如果可变点非常小，可通过对服务的操作和参数应用可变点来对单个候选服务建模。但是，如果可变点在业务流程模型中普遍存在，则更加可管理的方法是将相关功能逻辑地分组到单独的服务中。在一个服务中对所有可变点分组时，可以考虑某种参数化的服务方法。参数化可应用于服务的操作、参数和消息。（有关Web服务参数化的示例，请参见参考资料部分）。当将相关功能分组到单独的服务中时，通过基于服务所提供的功能来发现和绑定到不同的服务，从而可以实现可变性。功能建模可以为提供软件产品线成员的服务组合性质的早期指示。服务需要按特定的顺序组合才能交付所需的功能。因此，可变性会影响各个参与服务以及它们在组合中的执行顺序。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。5.课内完成实验内容，课后进行分析比较，写出心得体会，完成实验报告。

实验7负载均衡算法一、实验目的1．了解什么是负载均衡算法。2．掌握负载均衡算法分类。3.实现一种负载均衡算法。二、实验学时 4学时三、实验内容

实现以下一种负载均衡算法。负载均衡（LoadBalance），顾名思义，是把服务的并发请求均衡地负载到后端多个具有相同能力的服务进行处理分担，以廉价有效透明的方式扩展网络设备或服务的带宽，增加吞吐量，增强服务的整体处理能力，提供服务的灵活性和可用性。常见的典型的负载均衡应用场景：（1）、web集群：将大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间。（2）、MapReduce：单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给⽤户，系统处理能⼒得到大幅度提高。负载均衡算法

负载均衡算法是负载均衡设备（包括虚拟设备或相关软件）在执行负载均衡调度，选择具体处理的后端服务的时候使用的调度和分发的逻辑。负载均衡的算法只是规定了调度和分发的逻辑，在不同的负载均衡方案中都可能使用相同和（或）类似的算法，它只是负载均衡方案的一部分。常见的主流负载均衡算法包括：(1)轮询算法：RoundRobin/WeightRoundRobinScheduling

轮询算法通过依次轮叫的方式依次将请求调度不同的后端服务器(RealServer)。通常可以分为普通轮询和加权轮询两种方式。算法的优点是简洁且无状态。

算法简单表示为：i=(i+1)modn(2)Hash算法:随机数Hash，SourcesHashingScheduling

Hash算法，又叫取余算法。一般是对请求报文中的某项数据(key，一般常用客户端来源IP)计算Hash值，然后按机器数量(n)取模。

算法简单表示为：idx=Hash(key)%n

Hash算法中，Key的选择常用实践如下：

a、请求时间或随机数特点是简单，具有一定分散性，但不稳定，一般用于要求不高的负载均衡场景。

b、来源IP

特点是简单。如果客户的分布比较广，这种方式分散性较好。但如果较多的客户请求来源于同一IP（公司网络通过路由器上网），分散效果较差。

大多负载均衡设备都支持这种算法，著名的nginx和LVS等软件也支持。(3)一致性Hash算法：ConsistencyHashScheduling

一致性Hash算法最常用于分布式缓存（如memcached、redis等）的定位，但同时也可以在系统或程序中用于负载均衡，该算法本来的意义就在于分散负载和快速定位。(4)最少连接或请求数:(Weight)LeastConnection/RequestScheduling

最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。

算法主要逻辑是，调度设备或服务记录后端服务器接受请求的计数，每次请求总是发给计数最小的服务器处理。(5)最大空闲：MostidleFirst(基于监控CPU,内存,带宽等综合评估)（6）、平均最快响应：平均最快响应（7）、最少流量：LeastTrafficScheduling

四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验8负载均衡模式一、实验目的1．了解什么是负载模式算法。2．掌握负载均衡模式分类。二、实验学时 4学时三、实验内容

为大型电子商务网站设计负载均衡方案。撰写文档。

负载均衡模式主要是指在整体方案中选择从服务网络的哪个层次或哪个产品来实现负载均衡方案。1、外部模式（RR-DNS）

RR-DNS，即DNS轮询模式，它的原理是利用DNS服务器支持同一域名配置多个独立IP指向，然后轮询解析指向IP实现多次访问的调度和分发，实现负载均衡。它的主要特点为：a、负载均衡实现与后端服务完全没有关系，有DNS在本地解析指向实现轮询调度。这个方面来看性能最佳效率最高。b、DNS服务无法检测到后端服务器是否正常，在TTL失效前，会一直指向失效的服务器，这就要求在实践生成中，必须解决后端服务器的高可用问题。c、一般的第三方DNS服务提供商都支持该功能，但如果更新频率高或附带更新逻辑，一般会在系统内自键DNS服务，然后在注册为公共DNS服务。2、应用层模式

正向代理：用户通过代理服务访问internet,把internet返回的数据转发给用户。正向代理对于整个网络请求，它的角色实际是客户端，代理客户对外的访问请求。反向代理：接受internet上用户的请求，转发给内部的多台服务器处理，完成后转发后端服务器的返回给对应的用户。反向代理对于整个网络请求，它的角色实际是服务器，代理接受（accept）所有用户的请求。

反向代理应用模式：常见的反向代理应用模式，比如通过Apache,nginx等Web服务器软件实现WEB应用的负载均衡和高可用。利用反向代理软件实现负载均衡是性价比较高的模式。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写科研论文报告。4.基于小组观点制作演讲ppt。

实验9无共享架构一、实验目的1．了解什么是无共享架构。2．掌握无共享架构特征及设计方法。二、实验学时 4学时三、实验内容

为大型电子商务网站例如淘宝网设计一种无共享数据架构，考虑保证“双十一”期间其平台正常运转，并撰写文档。

无共享架构（sharednothingarchitecture）是一种分布式计算架构。这种架构中的每一个节点（node）都是独立、自给的，而且整个系统中没有单点竞争。有些系统需要集中保存大量的状态信息——数据库、应用服务器或是其他类似的单点竞争系统。

图1无共享架构设计无共享架构的一个重要实践指导原则就是避免在互联系统中使用Session，因为实践已经证明，在一个集群分布式计算环境中，若Session状态维护在各个节点服务器上，为了保证状态一致性，节点间Session数据需要互相拷贝同步，严重影响性能，我们需要尽可能的改造现有架构不要使用Session。无共享架构在Web应用开发中尤其受到欢迎，究其原因是这种方案提供的scalability。Google在这个方面做了很好的示范。在一个纯SharedNothing系统中，通过简单地增加一些廉价的计算机做为系统的节点却可以获取几乎无限的扩展。正是由于SharedNothing架构中不存在单一瓶颈而降低系统运行速度。Google称之为sharding。Sharednothing系统通常需要将他的数据分布在多个节点的不同数据库中（不同的计算机处理不同的用户和查询）或者要求每个节点通过使用某些协调协议来保留它自己的应用程序数据备份，这通常被成为数据库Sharding。

无共享架构是一种分布式计算架构，这种架构中不存在集中存储的状态，系统中每个节点都是独立自治的，整个系统中没有资源竞争，这种架构具有非常强的扩张性，目前在web应用中被广泛使用。

2、对比shared-nothing、shared-memory、shared-disk是并行系统最常使用的模式。

shared-memory：多个cpu共享同一片内存，cpu之间通过内部通讯机制进行通讯

shared-disk：每一个cpu使用自己的私有内存区域，通过内部通讯机制直接访问所有磁盘系统

和shared-memory、shared-disk相比，shared-nothing优势明显，在针对多用户并行访问的时候，通过横向扩充资源，能够大大减少响应时间，提升整体吞吐量和效率。3、分片sharednoting需要确立一种分片策略，使得依据不同的分片策略，减少资源竞争。三种基本的分片策略结构：(1)功能分片根据多个功能互相不重叠的特点进行分片，这种方式已经在ebay取得巨大成功。缺点也很明显，即技术人员需要深入理解应用领域，才能更好地分片;(2)键值分片在数据中找到一个可以均匀分布到各个分片中的键值。(3)查表在集群中有一个节点充当目录角色，用于查询哪个节点拥有用户要访问的数据。缺点在于这个表可能成为整个系统的瓶颈及单点失效点;四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写报告。4.基于小组观点制作演讲ppt。

实验10分布式计算架构一、实验目的1．了解什么是分布式计算架构。2．掌握分布式计算架构特征及设计方法。二、实验学时 4学时三、实验内容实验任务：某公司的计算机系统很庞大，自然是一个整的分布式系统，为了方便组织管理，公司将整个技术部按业务和平台拆分为部门，订单的，会员的，商家的等等，每个部门有自己的web服务器集群，数据库服务器集群，通过同一个网站访问的链接可能来自于不同的服务器和数据库，对网站及底层对数据库的访问被分配到了不同的服务器集群,这个便是典型的按业务做的垂直拆分，每个部门的服务器在无法支撑时，会有弹性的扩展，这便是水平扩展。采用zookeeper为该大型电子商务公司设计一种分布式架构，并撰写文档。

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。分布式系统的设计方式假设我们有一台服务器，它可以承担1百万/秒的请求，这个请求可以的是通过http访问网页，通过tcp下载文件，jdbc执行sql，RPC调用接口…，现在我们有一条数据的请求是2百万/秒，很显然服务器hold不住了，会各种拒绝访问，甚至崩溃，宕机，怎么办呢。一台机器解决不了的问题，那就两台。所以我们加一台机器，每台承担1百万。如果请求继续增加呢，两台解决不了的问题，那就三台呗。这种方式我们称之为水平扩展。如何实现请求的平均分配便是负载均衡了。另一个例子，我们现在有两个数据请求，数据190万，数据280万，上面那台机器也支撑不住，我们加一台机器来负载均衡一下，每台机器处理45万数据1和40万数据2，但是平分太麻烦，不如一台处理数据1，一台处理数据2，同样能解决问题，这种方式我们称之为垂直拆分。水平扩展和垂直拆分是分布式架构的两种思路，但并不是一个二选一的问题，更多的是兼并合用。下面介绍一个实际的场景。这也是许多互联网的公司架构思路。在数据库层，有些表非常大，数据量在亿级，如果只是纯粹的水平的扩展并不一定最好，如果对表进行拆分，比如可以按用户id进行水平拆表，通过对id取模的方式，将用户划分到多张表中，同时这些表也可以处在不同的服务器。按业务的垂直拆库和按用户水平拆表是分布式数据库中通用的解决方案。负载均衡设计前面我们谈到了分布式来解决性能问题，但其附带的问题是怎么分布，即如何负载均衡。这里要解决的问题是当客户端请求时，应该让它请求分布式系统中哪一台服务器，通常的做法是通过一台中间服务器来给客服端分配目标服务器。这里同样拿两个不同的分布式系统做说明，下图左边是分布式文件系统FastDFS,右边是一个用于分布式的RPC中间件。

FastDFS的一次文件下载请求过程是这样的

1.client询问tracker可以下载指定文件的storage；

2.tracker返回一台可用的storage；

3.client直接和storage通信完成文件下载。其中tracker便是负载均衡服务器，storage是存储文件和处理上传下载请求的服务器。而另一个RPC中间件Hedwig也是类似的

1.client询问zookeeper哪台server可以执行请求；

2.zookeeper返回一台可用server；

3.client直接与service完成一次RPC。zookeeper是分布式系统中一个负载均衡框架，google的chubby的一个开源实现，是是Hadoop和Hbase的重要组件。同样的在http中，常听说的nginx也是一个负载均衡服务器，它面向的是分布式web服务器。至于具体的负载均衡算法轮询，hash等这里就不深入了。同步设计分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写报告。4.基于小组观点制作演讲ppt。

实验11SOA架构设计一、实验目的1．了解什么是SOA架构。2．掌握SOA架构架构特征及设计方法。二、实验学时 4学时三、实验内容以大型电子商务网站为例，基于SOA架构设计方法为其设计架构。1.SOA的架构层次进行SOA类型的架构设计就需要搞清楚SOA架构模型才行。并不能想当然的对系统进行简单的拆分就行，需要搞清楚SOA的架构模型是怎样的，每一块是干什么用的，这样设计由分析阶段输出的需求时才能正确的划分职责。如果把SOA的架构简单的理解为是多个子系统之间的整合其实有点太过于简单，也没有真正搞清楚SOA的架构模型。按照SOA的正确方法论及目标模型，其实SOA在实现架构落地上，需要考虑到对服务的组合，不断的重用现有的服务，让企业应用可以逐步集成，快速实现业务的迭代。其实这就是本节要讲的服务的分层，通过分层将服务按照使用类型进行分配，上层服务对下层服务的包装，下层服务负责原子性的操作，上层服务对下层服务进行业务性的组合。我们来看具体的每一层的作用及主要职责。2..应用服务（原子服务）图1：原子服务划分应用服务就是诸如：订单服务、仓库服务、销售服务、客户管理服务，这些服务直接对应不同的应用系统，直接服务这些应用系统的原子操作。订单服务直接原子性的插入订单，没有任何跨其他服务的分支逻辑。仓库服务只管自己的仓库逻辑。同样其他的应用服务只管好自己的职责，杜绝对其他服务的调用。应用服务位于UI与后台之间，后台我们可以认为它是一异构的系统或者是数据库之类的。应用服务的位置位于前端与后端之间，起到类似一个服务API的作用，但是SOA中的服务还远远不止这一个应用服务，如果我们的SOA架构中只有一种类型的服务，那么这会增加我们系统的耦合程度，因为你没有对系统的服务进行层次的划分，你的业务功能会直接的落到某一个应用线上的服务，继续往下看。3.组合服务组合服务是对应用服务的一个组合,根据实际项目的规模大小,不一定非要进行物理的隔离,在代码层面的服务化也是可以的,在将来的某一天有必要的情况下再进行物理的拆分,毕竟物理的拆分有着严重的成本和代价，对系统的稳定性带来很多挑战。所以经验告诉我们必要的时候在进行拆分。”图2组合服务设计组合服务对下层的应用服务进行了组合，完成了一个基本的业务动作，应用服务中是最基本的基础性的原子性的操作。但是在复杂的业务需求下大部分业务功能都需要跨越多个应用线来完成一个最外层的企业动作。提交订单可能需要穿过很多应用线，订单管理、仓库、财务等等环节。所以这里我们还需要一个能在最外层对组合服务进行编排的业务服务。这个编排服务可以完全是自动化的，通过工作流引擎进行组合自动化来完成，这对企业应用的自动化流程很有意义。4.业务服务（编排服务）业务服务是最外层的服务，向下编排了组合服务。业务服务位于最上层，当需要有跨越多个应用线来完成的业务，这个业务就放入业务服务中。比如提交订单，先检查库存、扣减库存（冻结库存），然后下单，再往后通知财务，再往后通知物流等等都是一个复杂的企业服务线。这种最外层的业务逻辑如果你不进行SOA分层然后将其放入最外层的业务服务中，你把它放入任何一个应用线都会使系统调用混乱不堪。所以问题就是需要进行纵向的划分层次。如果进行了SOA的层次划分后就不会出现互相乱用的情况。其实这里可以参考阿里的服务设计方法。图3业务服务设计当在业务服务中执行的业务逻辑时，需要跨越多个应用线来完成。这部分的逻辑也说是职责，如果不放入这个位置，放在哪个应用线都不合适，放入哪个应用线都会使系统调用出现混乱。其实这里的问题就是我们不能用一个维度来进行SOA系统的设计，本来服务就具有组合特性，所以适当的提升服务的层次是有好处的，但是应用服务和组合服务可以在代码层面上进行构建，而业务服务也叫编排服务是需要进行物理隔离的，毕竟考虑到系统复杂度和稳定性问题这是值得的。在排查问题，系统性能、稳定性等等方面，物理的隔离有一定的作用，毕竟业务服务本来就是来组合多个应用线的，这样做会使整个系统架构很清晰。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写报告。4.基于小组观点制作演讲ppt。

实验12ED-SOA架构一、实验目的1．了解什么是ED-SOA架构。2．掌握ED-SOA架构特征及设计方法。二、实验学时 4学时三、实验内容以股票交易系统为例，基于ED-SOA架构设计方法为其设计架构。1.Event-DrivenSOA一般将SOA和EDA的集成体称之为事件驱动的面向服务架构(Event-DrivenSOA)，可以将其理解为SOA的一种衍生。SOA和EDA的交互主要体现在以下几个方面：（1）将事件处理的能力引入到SOA一个事件的产生可以触发一个或多个服务被调用，这样就把这些静态的功能动态地串联起来。（2）服务本身也可以产生事件服务除了完成特定的功能外，也可以根据自身需要产生某个事件。回页首2.Event-DrivenSOA架构的特点任何一种架构模式都有其适用的场景，Event-DrivenSOA自然也不例外。首先，它适用于异步的环境。如果你的系统对实时性要求比较高，请不要使用该架构。第二，如果你的系统需要面对复杂的异构环境——跨平台/跨语言，那么面向服务的架构能够很好地应对。第三，将系统功能分解为适当粒度并且重用性高的一个个服务，可以显著地提高IT系统的适应性和效率，进而提高投资回报率(ROI)。第四，引入事件处理的能力以后，每个服务都是由不同的事件驱动，这样当某个事件发生后，系统的不同服务就能够自动地进行触发。这对那些有更高自动化要求的系统来说非常适合。第五，与面向过程的系统中客户端必须轮询更改请求(通过API调用)不同，事件驱动架构允许系统和组件在事件发生时实时动态地做出响应。事件驱动架构通过引入长时间运行的处理功能来弥补SOA的不足。这一点对于金融系统来说尤其重要，比如说一次股票买卖从客户下单到最终交割会经历几天的生命周期。最后，Event-DrivenSOA使得增加事件的consumer和producer非常容易，这样就使得增加系统吞吐量也变得很简单，系统的弹性非常好，非常适合那些业务量持续增加的系统。在这方面，有一个EDA的变体SEDA（StagedEvent-DrivenArchitecture）将这方面的设计发挥到了极致，详细的介绍请参考正文后的参考资料。回页首3.Event-DrivenSOA在金融系统的应用在当今社会，市场变化莫测，商机稍纵即逝，企业需要有极强的灵活性和应变能力，金融行业尤其如此，特别是在中国这样一个金融行业处于快速发展的市场里。企业要求IT系统能够快速地对业务需求做出应对，否则就会丧失先发优势。这有点类似于现代战争条件下，各国都要求部队具备快速反应能力，这种能力主要体现在IT部门能够通过快速开发或者重用/整合现有资源来达到快速响应业务需求。还有，金融行业业务越来越庞大复杂，所涉及的第三方系统或者遗留系统非常多，这就要求IT系统有很强的整合能力及对异构环境的适应能力。最后，由于金融行业的发展日新月异，特定金融业务都会在其初期发展后迎来一个快速膨胀期，业务量和业务类型会急剧增加，这也要求IT系统有很好的可扩展性。对照前面提到的Event-DrivenSOA的特点，我们可以很直观地发现该架构可以很好地满足金融系统的实际需求。当然，金融系统也是包罗万象，特点各不一样，这里可能更偏重于金融行业的交易系统。我们还可以深入到具体系统的内部，从一些微观层面来考虑Event-DrivenSOA是否仍然能够符合我们的要求。下图是一个证券公司股票交易系统的简图：

图1.证券公司股票交易系统概略图

从上图我们可以看出，整个应用被分为很多子系统，各个子系统之间存在着大量的信息交互。而且大部分应用输入都需要经历一个比较长的生命周期，比如说一个客户订单输入到系统后，会先后经历前台系统(FrontOffice)，中台系统(MiddleOffice)以及后台系统(BackOffice)，而且每个系统内部又包括很多服务组件。除了系统层面的跨度外，这个生命周期也体现在时间长度上。而且，如今所有的金融系统都追求STP(StraightThroughProcessing)的能力，主张尽可能少的人工干预，这样所有的服务组件都需要具备自触发的能力。回页首4.Event-DrivenSOA架构设计架构师在着手每次的架构设计时，其实都是在提出并回答一系列的问题，把这些问题都回答了，架构设计也就出来了。比如我们每次肯定都会问：系统的最终用户是谁，他们会如何来使用该系统，他们的核心诉求是什么。当然，不是所有的问题都能有一个圆满的答案，更多的时候其实是一个取舍的过程。比如说系统的关键指标我们很难一下子全部满足，就需要结合具体的业务需求和人力物力以及时间的具体情况来做取舍。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写报告。4.基于小组观点制作演讲ppt。

实验13高并发系统架构一、实验目的1．了解什么是高并发系统架构。2．掌握高并发系统架构设计方法。二、实验学时 4学时三、实验内容以电子商务搜索系统为例，为其设计并行与高性能计算系统架构。1.空间换时间1)多级缓存，静态化客户端页面缓存（httpheader中包含Expires/CacheofControl，lastmodified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）反向代理缓存应用端的缓存(memcache)内存数据库Buffer、cache机制（数据库，中间件等）2)索引哈希、B树、倒排、bitmap哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。2.并行与分布式计算1)任务切分、分而治之(MR)在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffleandsort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。2)多进程、多线程并行执行(MPP)并行计算（ParallelComputing）是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一问题，即将被求解的问题分解成若干个部分，各部分均由一个独立的处理机来并行计算。和MR的区别在于，它是基于问题分解的，而不是基于数据分解。3电子商务搜索系统高并发架构设计在电子商务平台中搜索是一个非常的重要功能，主要有搜索词类目导航、自动提示和搜索排序功能。开源的企业级\o"搜索引擎知识库"搜索引擎主要有lucene,

sphinx，这里不去论述哪种搜索引擎更好一些，不过选择搜索引擎除了基本的功能需要支持外，非功能方面需要考虑以下两点：a、

搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高可用性b、

索引的实时性c、

性能Solr是基于lucene的高性能的全文搜索服务器，提供了比lucene更为丰富的查询语言，可配置可扩展，对外提供基于http协议的XML/JSON格式的接口。从Solr4版本开始提供了SolrCloud方式来支持分布式的索引，自动进行sharding数据切分；通过每个sharding的master-slave(leader、replica)模式提高搜索的性能；利用zookeeper对集群进行管理，包括leader选举等等，保障集群的可用性。Lucene索引的Reader是基于索引的snapshot的，所以必须在索引commit的后，重新打开一个新的snapshot，才能搜索到新添加的内容；而索引的commit是非常耗性能的，这样达到实时索引搜索效率就比较低下。对于索引搜索实时性，Solr4的之前解决方案是结合文件全量索引和内存增量索引合并的方式，参见下图。图1-3搜索解决方案Solr4提供了NRT

softcommit的解决方案，softcommit无需进行提交索引操作，就可以搜素到最新对索引的变更，不过对索引的变更并没有sync

commit到硬盘存储上，若发生意外导致程序非正常结束，未commit的数据会丢失，因此需要定时的进行commit操作。平台中对数据的索引和存储操作是异步的，可以大大提高可用性和吞吐量；只对某些属性字段做索引操作，存储数据的标识key，减少索引的大小；数据是存储在分布式存储\o"Hbase知识库"Hbase

中的，HBase对二级索引搜索支持的不好，然而可以结合Solr搜索功能进行多维度的检索统计。索引数据和HBase数据存储的一致性，也就是如何保障HBase存储的数据都被索引过，可以采用confirm确认机制，通过在索引前建立待索引数据队列，在数据存储并索引完成后，从待索引数据队列中删除数据。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写报告。4.基于小组观点制作演讲ppt。

实验14高可用系统架构一、实验目的1．了解什么是高可用系统架构。2．掌握高可用系统架构设计方法。二、实验学时 4学时三、实验内容以电子商务系统为例，为其设计高可用数据存储架构。1)

内存型数据库内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格，以开源nosql数据库mongodb、redis为例通信方式多线程方式，主线程监听新的连接，连接后，启动新的线程做数据的操作（IO切换）。数据结构图1MongoDB在数据结构MongoDB在数据存储上按命名空间来划分，一个collection是一个命名空间，一个索引也是一个命名空间。同一个命名空间的数据被分成很多个Extent，Extent之间使用双向链表连接。在每一个Extent中，保存了具体每一行的数据，这些数据也是通过双向链接连接的。每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据update变大后可以不移动位置。索引以BTree结构实现。如果你开启了jorunaling日志，那么还会有一些文件存储着你所有的操作记录。持久化存储MMap方式把文件地址映射到内存的地址空间，直接操作内存地址空间就可以操作文件不用再调用write,read操作，性能比较高。mongodb调用mmap把磁盘中的数据映射到内存中的，所以必须有一个机制时刻的刷数据到硬盘才能保证可靠性，多久刷一次是syncdelay参数相关的。

journal（进行恢复用）是Mongodb中的redo

log，而Oplog则是负责复制的binlog。如果打开journal，那么即使断电也只会丢失100ms的数据，这对大多数应用来说都可以容忍了。从1.9.2+，mongodb都会默认打开journal功能，以确保数据安全。而且journal的刷新时间是可以改变的，2-300ms的范围,使用

--journalCommitInterval

命令。Oplog和数据刷新到磁盘的时间是60s，对于复制来说，不用等到oplog刷新磁盘，在内存中就可以直接复制到Sencondary节点。

事务支持Mongodb只支持对单行记录的原子操作

HA集群用的比较多的是Replica

Sets，采用选举算法，自动进行leader选举，在保证可用性的同时，可以做到强一致性要求。通信方式因都在内存操作，所以逻辑的操作非常快，减少了CPU的切换开销，所以为单线程的模式（逻辑处理线程和主线程是一个）。

reactor模式，实现自己的多路复用NIO机制（epoll，select，kqueue等）

单线程处理多任务数据结构

hash+bucket结构，当链表的长度过长时，会采取迁移的措施（扩展原来两倍的hash表，把数据迁移过去，expand+rehash）

持久化存储a、全量持久化RDB（遍历redisDB,读取bucket中的key,value），save命令阻塞主线程，bgsave开启子进程进行snapshot持久化操作，生成rdb文件。

在shutdown时，会调用save操作

数据发生变化，在多少秒内触发一次bgsavesync，master接受slave发出来的命令b、增量持久化（aof类似redolog），先写到日志buffer,再flush到日志文件中（flush的策略可以配置的，而已单条，也可以批量），只有flush到文件上的，才真正返回客户端。要定时对aof文件和rdb文件做合并操作（在快照过程中，变化的数据先写到aof

buf中等子进程完成快照<内存snapshot>后，再进行合并aofbuf变化的部分以及全镜像数据）。在高并发访问模式下，RDB模式使服务的性能指标出现明显的抖动，aof在性能开销上比RDB好，但是恢复时重新加载到内存的时间和数据量成正比。

集群HA通用的解决方案是主从备份切换，采用HA软件，使得失效的主redis可以快速的切换到从redis上。主从数据的同步采用复制机制，该场景可以做读写分离。目前在复制方面，存在的一个问题是在遇到网络不稳定的情况下，Slave和Master断开（包括闪断）会导致Master需要将内存中的数据全部重新生成rdb文件（快照文件），然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空，把rdb文件重新加载到内存中。这种方式效率比较低下，在后面的未来版本Redis2.8作者已经实现了部分复制的功能。2）分布式数据库对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案，但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。高可靠HBase的数据存储基于HDFS，提供了冗余机制。Region节点的宕机，对于内存中的数据还未flush到文件中，提供了可靠的恢复机制。可用性存在单点故障，Region

Server宕机后，短时间内该server维护的region无法访问，等待failover生效。通过Master维护各Region

Server健康状况和Region分布。多个Master，Master宕机有zookeeper的paxos投票机制选取下一任Master。Master就算全宕机，也不影响Region读写。Master仅充当一个自动运维角色。HDFS为分布式存储引擎，一备三，高可靠，0数据丢失。HDFS的namenode是一个SPOF。为避免单个region访问过于频繁，单机压力过大，提供了split机制。HBase的写入是LSM-TREE的架构方式，随着数据的append，HFile越来越多，HBase提供了HFile文件进行compact，对过期数据进行清除，提高查询的性能。Schema

freeHBase没有像关系型数据库那样的严格的schema，可以自由的增加和删除schema中的字段。HBase分布式数据库，对于二级索引支持的不太好，目前只支持在rowkey上的索引，所以rowkey的设计对于查询的性能来讲非常关键。四、实验要求1.学生每三人分为一组，通过搜索阅读分析等方法，查阅本实验相关的文献资料；2.针对本实验内容，分析已有前沿文献的观点，讨论提出小组的观点。3.基于小组观点，撰写报告。4.基于小组观点制作演讲ppt。

实验15五视图法架构设计-用例分析一、实验目的1、了解五视图设计方法的基本内容；2、掌握用例分析的基本方法；3、掌握相关UML图形的绘制方法；二、实验环境Windows7+Visio2010+Word2010三、实验内容1、架构设计五视图法五视图法可以帮助软件架构师以不同的视角对软件的各个方面的属性：功能需求，约束，运行期质量属性，开发期质量属性。1）物理架构物理架构的目的是确定物理节点和物理节点的拓扑结构；其中物理节点包括服务器、PC机、专用机、软件安装部署以及系统软件的选型；拓扑结构明确物理节点的关系。2）运行架构运行架构的目的是确定控制流和控制流的组织；其中控制流包括进程、线程、服务程序；控制流组织包括系统的启动与停机、控制流通讯、同步与加锁。3）开发架构开发架构的目的是确定程序单元以及程序单元的组织结构；其中程序单元包括源文件、配置文件、程序库、框架、目标单元；程序单元组织包括project划分、project目录结构、编译依赖关系。4）逻辑架构逻辑架构的目的是职责的划分，并明确其与协作关系；其中职责的划分注意逻辑的分层、子系统以及关键类的定义；协作的定义关注接口的定义与协作关系的明确。5）数据模型数据架构的目的是确定要存储的数据以及存储格式；其中存储的数据可以是文件、关系数据库、实时数据库；存储格式包括文件格式、数据库图表。2、用例分析用例分析是五视图法的基础。系统的用户视图由用例图组成，用例图包含执行者、用例、及它们的关系，用例图表示了系统对外部实体提供的功能，用例图由执行者和用例组成（执行者对系统做什么的）执行者主要可分为四类：主要执行者–直接与系统交互的人，次要执行者–涉及到系统维护的人，外部硬件–运行应用的非计算机的系统部分，其他系统–为其工作需要与你系统交互的外部系统。3、案例分析 设计一个面向全国的绩效考核系统。如何进行用例分析？如何进行流程分析？如何进行领域分析？ 原始需求：系统根据操作规范制定考核指标，通过分析业务系统的数据产生考核结果；过错责任人可以对自己的过错提出申辩，通过申辩受理、调查确认、领导审批后，对过错进行调整；对最终考核结果的过错责任人进行过错追究，根据过错程度进行罚款与行政追究；各级机关对当月工作情况进行通报；工作性质与内容相似的部门相互进行评比。用例分析如下所示：其中一个用例描述如下所示：四、实验步骤1、针对教师讲授内容，明确用例分析与建模的基本方法，熟悉常用的UML图形类型。2、分小组展开讨论，确定项目选题。针对选题明确系统的功能性需求和非功能性需求。针对功能性需求进行用例分析与建模。五、实验要求针对选定项目的业务场景进行用例建模，绘制用例图并编写用例描述，绘制活动图和鲁棒图。

实验16五视图法架构设计-逻辑架构一、实验目的1、了解五视图设计方法的基本内容；2、掌握逻辑架构设计的基本方法；3、掌握相关UML图形的绘制方法；二、实验环境Windows7+Visio2010+Word2010三、实验内容1、逻辑架构：逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”。2、逻辑架构的建立是基于用例模型分析基础之上，可采用领域分析方法进行系统的建模。3、案例分析：最初的业务需求：维护一个员工档案表每来一个新员工，录入员工档案根据员工档案每月发放工资人力专员手工录入各个工资项目汇总并计算工资打印出工资报表系统的领域模型如下所示：需求开始变更：根据规则生成工资表基本工资来源于对员工的职务定级考核工资=职务定级×绩效考核项目提成来源于项目结束后的收益……更新后的领域模型：四、实验步骤1、针对教师讲授内容，明确用例分析与建模的基本方法，熟悉常用的UML图形类型。2、分小组展开讨论，针对用例模型进行系统的逻辑模型设计。五、实验要求针对选定项目的用例模型，采用领域分析法进行系统的逻辑架构设计并完成相关文档编写和UML图形绘制！

实验17五视图法架构设计-开发架构一、实验目的1、了解五视图设计方法的基本内容；2、掌握开发架构的基本方法；3、掌握相关UML图形的绘制方法；二、实验环境Windows7+Visio2010+Word2010三、实验内容开发架构开发架构的目的是确定程序单元以及程序单元的组织结构；其中程序单元包括源文件、配置文件、程序库、框架、目标单元；程序单元组织包括project划分、project目录结构、编译依赖关系。好的开发架构设计需满足下面两图所说的分层结构：案例分析原始需求：全国性的绩效考核系统。开发架构如下所示：四、实验步骤1、针对教师讲授内容，明确用例分析与建模的基本方法，熟悉常用的UML图形类型。2、分小组展开讨论，针对用例模型进行系统的逻辑模型设计。五、实验要求针对选定项目的逻辑模型，进行系统的开发架构设计并完成相关文档编写和UML图形绘制！实验18五视图法架构设计-数据架构一、实验目的1、了解五视图设计方法的基本内容；2、掌握数据架构设计的基本方法；3、掌握相关UML图形的绘制方法；二、实验环境Windows7+Visio2010+Word2010三、实验内容1、数据架构数据架构的目的是确定要存储的数据以及存储格式；其中存储的数据可以是文件、关系数据库、实时数据库；存储格式包括文件格式、数据库图表。2、案例分析：下图给出了绩效考核的领域模型，在此基础上进行数据架构的设计：数据库的映射如下所示：四、实验步骤1、针对教师讲授内容，明确数据架构设计的基本方法，熟悉常用的UML图形类型。2、分小组展开讨论，在逻辑架构基础上进行系统的数据架构设计。五、实验要求针对选定项目的逻辑架构，进行系统的数据架构设计并完成相关文档编写和UML图形绘制！

实验19五视图法架构设计-运行架构一、实验目的1、了解五视图设计方法的基本内容；2、掌握运行架构设计的基本方法；3、掌握相关UML图形的绘制方法；二、实验环境Windows7+Visio2010+Word2010三、实验内容1、运行架构运行架构的目的是确定控制流和控制流的组织；其中控制流包括进程、线程、服务程序；控制流组