软件可伸缩性研究.docx
《软件可伸缩性研究.docx》由会员分享，可在线阅读，更多相关《软件可伸缩性研究.docx（10页珍藏版）》请在冰豆网上搜索。
软件可伸缩性研究
软件的可伸缩性研究
随着经济社会的飞速发展，企业规模的不断壮大，企业对满足业务需求的系统也提出了更高的要求。
企业总是希望开发人员能够创建出符合业务规则需要的强大系统。
另外，处于不断发展壮大的企业，要不断的适应用户需求的变化和用户数量的增长。
为此他们要求系统能够快速扩展，以满足用户计划内和计划外的增长需求。
这也意味着应用程序将有更多的用户，或者说虽然用户数量不变，但对应用程序的功能要求越来越高。
所以一个企业在这个竞争残酷的社会要有立足之地，就需要有一个具有良好伸缩性的系统，如果说由于设计的系统不具有很好的可伸缩性，随着用户的数量增加或企业业务需求的变化，导致系统无法正常运行，或运行速度增长缓慢，产生瓶颈，此时就有可能要重新设计或编码。
这是费时费力且代价昂贵的事情。
但是反过来，如果能在设计阶段就开始考虑系统的可伸缩性，如何去应对未来的业务需求变化和预期的增长，这将是一件非常有意义的事情，因为它即可以被迅速的上扩以满足更多的用户负载，又能在系统不能充分利用时而下扩，以节约成本。
同时还可以根据不断变化的业务需求，方便的修改系统。
现在，开发人员经常面临的问题是，如何进行设计，才能使我们的系统具有良好的可伸缩性。
要开发可伸缩性系统必须从体系结构设计、合理划分逻辑层、各层内部设计、系统资源占用等多个角度进行考虑。
当今社会，随着对应用程序的可伸缩性要求越来越高，对这个问题的研究也是非常有实用价值和学术价值的。
可伸缩性可以被定义为系统通过增加或减少服务器从而提升或降低系统性能的难易程度。
但是其具体含义从专业的角度给一个详细的解释，估计每个人都说法不一。
可伸缩性致力于两个方面:
增容和扩容。
从硬件角度考虑，增容意味着在单
个服务器上增加处理器、硬盘驱动器和工/0设备等的数量。
另一方面，扩容意味
着增加更多的服务器，而不是更大的服务器。
当扩容时，单个服务器的处理速度
和容量不影响整个网络的处理能力。
仅靠安装更多更快的处理器和I/0设备，可
以使性能有所改善，但是不能成功的做到性能的线性增长，因为这与软件还有一
定的关系。
应用程序可伸缩性要求两个不同的域:
软件和硬件之间保持平衡的合作关系。
如果仅在一个域中大大提高可伸缩性，这些努力会因在另一个域中所犯的错
误而打折扣。
例如，对于被设计为仅在单机上运行的Web应用程序，生成负载
平衡的Web服务器网络场并不会使其受益。
同样，设计一个高度可伸缩的应用
程序，然后将其部署到与低带宽网络连接的计算机，这样做并不会在网络通信量
饱和时很好地处理大量负载。
要做到真正的可伸缩必须做到采用可伸缩的硬件和
支持该硬件特制的软件的平衡搭配选择。
所以，设计过程中必须包括可伸缩性，因为可伸缩性不是一个可以在以后就能添加的孤立功能。
同其它应用程序功能一样，在前期设计和早期编码阶段所采用的决策和方法将在很大程度上决定该应用程序的可伸缩性。
可伸缩性包括：
横向可伸缩性和纵向可伸缩性
横向可伸缩性是指系统向外扩展，也就是通过增加系统的处理节点的方式来提高系统的整体处理能力，特别是提高其性能。
具体说就是通过使若干台计算机专门执行常见的任务，增加了应用程序容错能力。
横向可伸缩性的优点是：
1.服务器成本低，仅仅通过价格便宜的PCServer搭建出一个处理能力非常强大的计算集群。
2.基本上不存在用户量或数据量增加就再次遇到系统性能增加的瓶颈，因为理论上来说，通过增加PCServer或服务器主机的个数时没有限制的。
3.单个服务器节点出现故障对系统整体的影响也比较小。
相反它的缺点是：
l .因为服务器节点增多，造成系统架构整体复杂度提高，比如会有很多架构方面的问题需要解决，比如session复制的问题等。
2.集群维护难度增大，维护成本更高。
纵向可伸缩性是指向上扩展，也就是通过增加当前服务器节点的处理能力来提升系统的整体处理能力。
具体说来，包括通过升级现有服务器的配置，如增加内存，增加CPU,增加存储系统的硬件配置，或者更换更强的服务器和更高端的存储系统。
上扩可以使系统在不需要改变底层源代码的情况下就可以增加容量，实现可伸缩性。
纵向可伸缩性的优点是：
1.处理的节点少，维护很简单，维护成本低。
2.系统集中在一台服务器，架构设计简单，开发容易。
缺点是：
1.整个系统集中在一台服务器，为满足应用系统的需求，对服务器的硬件配置必然很高，而高端设备的服务器价格都很贵，成本自然很高。
2.应用系统业务需求量可能无限增加，但是单台服务器的处理能力总是很有限，所以很容易遇到无法解决的性能瓶颈。
3.整个系统集中在一台服务器，发生故障后影响是很大的。
从横向伸缩和纵向伸缩的优缺点来看，纵向可伸缩性更适合短期处理问题，因为这样成本低，架构简单，技术上要求也简单，风险也小，特别是系统上线要求比较急，项目进度要求比较紧的情况下，纵向可伸缩性还是不错的选择。
但是对于一个需要长期运维的系统来说，纵向可伸缩性不能从根本上解决问题因为业务量和数据量上去了，迟早会有性能瓶颈出现的，硬件技术的发展是有限的，很多时候都难以赶上业务的发展，如果数据量持续增加，可能隔不了多少时间，又要升级服务器，经常会更换硬件设备。
然而横向可伸缩性在这方面却有优势，服务器成本低，理论上是可无限扩展，当然技术上的复杂度是会不少，当时值得研究，解决起来也问题不大。
可伸缩性的测试方法是通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的，这种操作也称为负载测试。
但是负载测试通常描述一种特定类型的压力测试—增加用户数量以对应用程序进行压力测试。
也就是说压力测试是负载测试的进一步测试，是通过模拟越过应用程序能处理的最大限度的用户负载，把系统置于超过当前和最大用户负载的压力状态。
而负载测试是为了检验系统在给定负载下是否能达到预期性能指标。
可伸缩性测试可以看成性能测试的一个扩展，从前面的论述中可以看到，系统的可伸缩性可以从硬件和软件两个方面来理解:
是不是可以通过增加更多的硬件设备的来支持更多的用户;是不是可以通过运行更多的实例或者采用分布式处理来支持更多的用户。
那么再说具体一点就是一个可伸缩的系统必须具有随负荷增加，响应时间也线性增加的特点。
这样就可以通过线性的增加硬件设备、实例个数或者分布式处理点来处理更多的数据量，也就能更好的在不增加响应时间的前提下支持更多的用户。
可伸缩性测试具体的测试过程为:
进行负载测试，记录不同负载下的平均响应时间，然后查看平均响应时间是否线性增加。
如线性增加，说明系统具有可伸缩性，否则说明系统可伸缩性较差或者没有。
构建可伸缩软件系统的原则和方针：
1.减少处理时间
增加应用所做工作数量的一个方法就是减少完成单项工作所花费的时间。
举例来说，减少处理一个用户请求所需的时间意味着你能在同样长的时间内处理更多的用户请求。
软件开发人员总爱在不需要的地方引入抽象和层。
是的，这些概念对软件组件之间的解耦来说是很好的工具，但它们可能会增加复杂性、影响性能，尤其是在每层的数据表示之间都需要转换的情况下。
因此，减少处理时间还要注意保证抽象不要过于抽象化，并且没有过多的分层。
另外，对于我们视为理所当然的运行时服务，有必要理解其成本，因为除非它们提供了特定的服务水平协议，否则很有可能最终会成为应用中的瓶颈。
2.分区
减少单个工作单元的处理时间能达到不错的效果，但当你达到单进程方案的极限，最终还是需要对系统作水平伸缩。
在典型的Web应用中，水平伸缩可能很简单，只要加入更多的Web服务器来处理用户请求，再给它们加上负载均衡就行了。
但是，你可能会发现总体架构的某些部分会成为资源争用的焦点，因为一切东西都会在同一时间变得忙碌起来。
一个很好的例子就是所有Web服务器后端的单一数据库服务器。
当这个单一的数据库服务器变成瓶颈时，你必须改变方法，其中一种方式就是采用分区策略。
简而言之，这涉及到将架构的单个部分分解成更小、更容易管理的部分。
将单个的元素分割成更小的部分能实现水平伸缩，这恰恰也是eBay这样的大型网站采用、以此来确保它们的架构可伸缩的技术。
分区是一个很好的解决办法，尽管你可能会发现牺牲了一致性。
至于如何分割你的系统，那要看情形而定。
真正无状态的组件能简单地作水平伸缩，将工作负载分散到所有实例上，让组件的所有实例都能有效地运行。
另一方面，如果需要维护某状态，你需要找到一种工作量分割策略能允许有状态组件的多重实例，让每个实例负责工作和/或数据的一个独特的子集。
3.并发
可伸缩性天生就和并发联系在一起；毕竟，它就是要在同样的时间内做更多的工作。
像EJB早期版本这样的技术试图提供一种简化的编程模型，鼓励我们编写单线程的组件。
遗憾的是，组件往往要依赖于其它组件，还是导致了并发问题。
如果没有考虑并发，系统中的数据会很容易被损坏。
另一方面，围绕并发做了太多的保护会导致系统实质上变成串行的，限制了伸缩的能力。
并发编程不是很难做到，在构建可伸缩系统的时候，一些简单的原则会有所帮助。
4.持续测试
我们提出的设计、编写的代码实际上都是静态的，所以你在执行之前不能完全断定它会怎样运转。
此外，所有关于性能和可伸缩性的决策应该由证据支持的原因也在于此，而且应当从项目一开始就收集和审核这些证据，此后也要一直继续。
换句话说，就是设立贯穿系统的可度量目标，证实并度量实际的性能，并在项目的各个阶段考虑性能。
5.架构先行
或许对构建可伸缩的系统来说是最重要的原则，如果你需要使系统具备这样的性质，就必须预先设计出这样的性质。
很多人陷入的陷阱，就是以为可以构建一个应用，它会自动地纵向伸缩或横向伸缩，尤其是在J2EE刚出现的时候。
设计为可横向伸缩的应用几乎总能横向伸缩，但是设计为纵向伸缩的应用几乎不可能横向伸缩。
大多数应用能通过在更加强大的硬件上运行来纵向伸缩，但横向伸缩却是一个更为复杂的问题。
6.着眼于全局
最后，记着要着眼于全局——看到树木之前先看看森林。
对我们来说，在细粒度代码级别调整组件确实很容易，但最终需要优化的却是作为一个整体的系统。
关注每一个环节的性能和可伸缩性，必要时牺牲局部的优化。
如果你需要使用性能分析工具确定瓶颈，不妨去做，但在对全局的性能有所认识之前先不要急于动手。
由于性能与整个系统所有等待时间的集合成反比，任何等待时间增加得比负载还快的操作都会成为问题。
当前社会上关于可伸缩性的应用
J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。
J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容,，企业内部或外部难以互通的窘境。
J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。
通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持EnterpriseJavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。
J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制。
在企业中，企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。
基于JZEE平台的应用程序可被部署到各种操作系统和平台上。
例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器，具备极强的处理能力。
JZEE领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署，这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。
另外也可以部署在小型机上，在系统管理的参保人数增长到系统不能负担时，再增加服务器数量，进行集群;甚至，在一些性能要求较低的区域，还可以采用PCSever作为应用服务器或数据库的载体。
编写一个JavaBeans要比编写一个EJB容易多，在可伸缩性发面，基于JBoss/EJB的完整JZEE系统架构是JZEE中重量级解决方案，具有可伸缩性，但
目前不易于学习;基于Tomcat的Struts+Hibernate/Spring+Hibernate轻量级
解决方案目前无太大可伸缩性，但是易于学习使用，因为轻量解决方案易于学习
新技术，容易使用，选中率比较高，但是对系统的可伸缩性能比较差。
强调可伸
缩性的系统开发时，不能因为要跟进新的设计思想和技术，而盲目地采用一个无
可伸缩性的设计方案。
JZEE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用
组件根据他们所在的层分布在不同的机器上。
事实上，SUN设计JZEE的初衷正
是为了解决两层模式（Client/Server）的弊端。
在传统模式中，客户端担当了过
多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级
或改进，可伸展性也不理想，而且经常基于某种专有的协议一一通常是某种数据
库协议，它使得重用业务逻辑和界面逻辑非常困难。
现在JZEE的多层企业级应
用模型将两层化模型中的不同层面切分成许多层，一个多层化应用能够为不同的
每种服务提供一个独立的层，作为一个被业界广泛采用的中间件标准，JZEE是开发可伸缩的、具有负载平衡能力的多层分布式跨平台企业应用的理想平台。
JZEE的首要任务在于提供一个标准中间件基础架构，由该基础架构负责处理企业开发中所涉及的所有系统级问题，从而使得开发人员可以集中精力重视商业逻辑的设计和应用的表示，提高开发工作的效率。
.NET（.NETFramework）是由微软开发，一个致力于敏捷软件开发、快速应用开发、平台无关性和网络透明化的软件开发平台。
.NET是微软为下一个十年对服务器和桌面型软件工程迈出的第一步。
NET包含许多有助于互联网和内部网应用迅捷开发的技术。
.NET框架是微软公司继WindowsDNA之后的新开发平台。
.NET框架是以一种采用系统虚拟机运行的编程平台，以通用语言运行库为基础，支持多种语言（C#、VB.NET、C++、Python等）的开发。
Mierosoft.NET最重要的部分是.NET框架（.NETFramework）。
.NET框架的
目的是使人们更容易建立网络应用程序和网络服务。
.NET框架是windows操作系统中的一个很重要的新元素，是下一代应用软件的基石，它使下一代应用软件更容易开发、发布以及和其他网络系统集成。
对用户来说，运行在他们机器上的.NETFramework使他们的机器更稳定易用，并且能很方便的和其他的系统相联。
对开发者来说，.NETFramework简化了Windows软件的开发，它提供了一个单一的方法来建立C/S和B/S构架样式，它允许开发者用同一种工具和技术为各种设备开发软件。
.NETFramework实际上封装了操作系统，将在.NET环境下开发的软件与操作系统的具体工作如文件处理和内存分配相脱离。
这就使.NET环境下开发的软件可以在各种硬件和操作系统之间迁移。
.NETFramework构架包含了在操作系统上进行软件开发的所有层，它使Microsoft或其他平台上的显示技术、组件技术和数据技术实现了高度的集成。
这个架构使开发工Internet应用程序就像开发桌面程序一样简单。
整个开发框架的基础是公共语言运行库（CLR）以及它所提供的一组基础类库，在这之上，.NET提供了全新的数据库访问技术ADO.NET，以及网络应用开发技术ASP.NET和WindowS编程技术WinFormS等。
在编程语言上，.NET提供vB.NET、C++、C#、JScriPt等多种语言支持;微软也支持第三方生产针对MICrosoft.NET的编译器和开发工具，这意味着几乎所有市场上的编程语言都有可能应用于Microsoft.NET开发框架。
在这里，特别指出C#语言，C#是专为.NET而设计。
C#继承了众多语言的优点，是一种简单的，现代的，面向对象的语言。
VisualStudio.NET则是全面支持.NET的一个可视化开发工具。
利用它，我们可以方便的建立界面，编写代码，调试和部署我们的应用程序。
NET在许多方面增强了可伸缩性,.NET中对于会话做了大量的改进。
在ASP.NET会话中所作的最显著的改进之一是能支持那些不支持Cookie的浏览器。
代替把会话的功作为一个Cookie存储的做法，ASP.NET的运行库能在给用户返回一个页面的时候，将会话的ID直接插入URL。
开发人员可以在ASP.NET的配置文件中直接配置这个选项，而不必再另添一行代码。
ASP.NET会话以三种方式的一种方式驻留:
在进程内，在进程外（或称在一个专用的进程内），或以SQL模式（会话存储在一个SQLServer数据库里）。
这三种不同的模式为会话的存储方式提供了很大的灵活性。
在.NET中只有一种线程，而且没有以前的线程模型的任何一种限制。
.NET可以用与任何一种别的语言相同的方式创建线程了。
有了一个统一的线程模型，并且放置线程类的System.ThI’eading命名空间从逻辑上和功能上都很容易让开发人员理解。
在ASP.NET中的SeSSion和Application对象中，由COM的线程模型带来的限制已经被消除。
用任何一种.NET托管语言写成的对象可被保存在会话和应用程序中，而不用考虑因争用线程而限制可伸缩性的问题。
ASP.NET允许开发人员在内存中存储页面、页面的某些部分、控件或自定义
对象。
ASP.NET提供了两个基本的缓存方法:
输出缓存和程序化缓存。
它们是可
伸缩的Web应用程序最好的性能改进之一。
在.NET中极大地改进了COM和COM十以前提供的中间层的功能。
.NET提供了两个中间层应用托管技术，分别是Remoting和webServiCeS，这两个中间层应用托管技术极大的提高了.NET应用程序的可伸缩性。
.NET平台极大的方便了创建可伸缩性的应用程序。
.NET与同类产品的比较从某种角度来看，.NET并没有发明什么先进的技术，
而只是多家思想的拷贝和整合。
虽然.NET没有多少创新，但它对很多公司的思
想和自己的工业基础作了较好的整合。
.NET使用COM十来提高软件的可伸缩性。
COM十是一套成熟的中间件产品，屏蔽掉底层的通信协议，提供了系统与系统之间灵活、多样的通信方式，并提供了一套系统服务来支持分布式系统的开发。
COM+
和WindowS2000联合起来使得企业应用直接进入分布式应用领域，基于COM+开
发分布式应用系统，可以实现真正可伸缩性。
COM十在构筑分布式应用所必备的远程调用支持、事物服务、事件服务、命名与发现服务、安全服务等都己具备。
构筑中小型分布式应用系统方面选择COM十可伸缩性比较高，、在微软发布的NET平台中，COM+升级为2.0版本，CLR（公共语言运行时）的引入简化了组件的引用计数管理，组件编程模型被进一步简化，ORPC协议被一个性能更优良的协议代替，COM+系统服务有了一套更易于使用的接口，性能、功能、易用性方面都得到整体增强。
COM+在新平台下依然是分布式系统中间层设计的基石。
在JZEE构架中，JavaBean和EJB（EnterpriseJavaBeans）被用来完成事物逻辑。
其中EJB和JavaBean有着类似的模型，但它被用来创建分布式的企业应用。
在微软的.NET平台中，旧的COM和COM+的组件模型被新的组件模型所代替。
增加了像基于沙箱的安全模型和垃圾回收等功能，并且实现了多重接口继承，扩展的元数据和新的代理模型等。
旧有的COM和COM+组件也可被映射到新的运行环境中。
.NET与JZEE相比，JZEE比较成熟，可伸缩性能更好，只是JZEE框架结构
比较复杂，比较难学，对开发人员的要求比较高。
要设计一个稳定的软件并不难，
但要构建一个高度可伸缩性软件，以适合企业长期发展的需求，必须要进行详细
而周密的考虑，同时也需要软件开发人员具有丰富的经验，对软件框架有比较深
刻地认识。
如果设计不是很理想，反而会产生瓶颈，降低软件的性能。
而.NET
开发框架比较简单，.NET不断改进，有效地解决了构建伸缩性应用程序的问题。
中间层可伸缩性技术
中间层通常是应用程序的核心逻辑被执行的地方。
因为所有系统在逻辑上是不同的，中间层的作用域可能区别很大。
在一个意图向数据库推入数据和从数据库拉出数据的系统中，中间层可能是很简单的。
在大型的计算密集的应用程序中，中间层一般负责执行计算和应用“应用逻辑”。
中间层的开发使应用程序比把代码下推给各个用户的做法能扩展得好。
可以想像有一个WindowS窗体应用程序，其中间层被部署在每一个客户PC机上，如果中间层是逻辑密集的，也许客户PC机没有足够的能力来及时地处理逻辑。
然而，如果中间层是物理地分隔开的，就有能力外扩中间层使响应时间更快。
一个共用的中间层，通过利用共享资源也能改进可伸缩性。
一个中间层能为大量客户端服务，单一的接触点产生了许多正面的外部效应。
例如，能实现数据缓存、对象入池和连接入池来减少应用程序为客户端服务必需的资源。
物理的把中间层和
客户应用程序分隔开，能方便的进行上扩或外扩，这取决于应用程序变化的情况。
在许多方面，.NETRemoting和Web服务允许展示中间层体系结构，而不必做DCOM带来的那些苦差事。
Remoting和Web服务允许以编程方式从用户表示层，或也许是网络内或网络外的另一个中间层访问应用程序。
下面将分别介绍这两种技术。
ASP.NET的可伸缩性
ASP.NET是MICrosoft‘NET中的网络编程结构，它使得建造、运行和发布网络应用非常方便和高效〔到。
ASP.NET建立在.NET框架类的基础之上，它提供了由控件和基础部分组成的Web程序模板，大大简化了Web程序和XMLWeb服务的开发。
微软的ASP.NET在传统Web开发技术ActiveServerPage（ASP）的基础上进行了很大的改变。
ASP.NET提供了一种新的编程模型和结构，不仅使开发者更易于创建动态Web内容，还使它们更易于创建生成更安全、可伸缩和稳定的企业级Web应用程序〔24]。
webFormS是AsP.NET技术，可用于创建可编程的web页。
它们可以使用任何标记语言来为使用任何浏览器的用户提供信息，并在服务器上用代码实现应用程序逻辑。
WebFormS将Web应用程序用户界面划分为两个部分:
可视界面和用户逻辑。
可视界面用作要显示的文本和控件的容器。
而用户逻辑由为了与界面进行交互而创建的代码组成，它可以和可视界面的内容分离，这样就大大提高了Web应用程序的可维护性。
ASP.NET的WebForms的设计目的就是使得开发者能够非常容易地创建网络表单，它把VISualBasic中的快速开发模型引入到网络开发中来，从而大大简化了网络应用的开发。
ASP.NET还提供了丰富的Web控件，括运行在服务器端的Form控件，如Button，TextBox等，也包括一些特殊控件。
在可伸缩性方面，ASP.NET引入了一系列的特性，并把它们作为基础.NETFramework的组成部分：
1.增强的编译性能ASP.NET是在服务器上运行的编译好的公共语言运行库代码。
与被解释的传统的ASP不同，ASP.NET可利用提前绑定，即时编译，本机优化和缓存服务，这相当于在编写代码行之前便提高了性能，从而支持更多的用户。
2.会话
在ASP.NET会话中所作的最显著的改进之一是能支持那些不支持Cookie的
浏览器。
代替把会话的ID作为一个Cookie存储的做法，ASP.NET的运行库能在给用户返回一个页面的时候，将会话的ID直接插入URL。
开发人员可以在ASP.NET的配置文件中直接配置这个选项，而不必再另添一行代码。
ASP.NET会话以三种方式的一种方
升级会员 