《如何架构和开发高性能，高伸缩性WEB应用系统》由会员分享，可在线阅读，更多相关《如何架构和开发高性能，高伸缩性WEB应用系统（51页珍藏版）》请在金锄头文库上搜索。
1、如何架构和开发高性能，高伸缩性WEB 应用系统,软件架构师 童景文,Agenda,BASE理论简介:ACID 理论的另外选择,可伸缩性最佳实践准则,几点架构建议,经典架构,前言,前言,在我们给客户构建相应的WEB应用系统中，会使用J2EE架构/.NET架构/LAMP架构之一或者其中的混合。在很多场合下我们是不需要考虑整个系统的可伸缩性以具备更好的性能（例如高吞吐量和低响应时间）；因为我们有足够强的硬件资源和用户的压力并不大或者受到项目资源的问题（例如项目的预算，人力资源，技术风险等）。但是对于有些场合下，例如用户的并发用户数很高并且有足够的项目预算或者项目预算也比较充分并且我们需要让我们的软件
2、价值更好地体现（例如我们不需要使用昂贵的硬件资源，仅仅可以利用低成本的硬件就可以让整个系统具有很好的性能和可靠性）。我们就非常地需要考虑整个应用系统的高可伸缩性的设计。当然如果不考虑场合，我们对所有的应用系统的设计都需要考虑高可伸缩性的设计那我们的应用系统将非常地具有竞争力。并且对我们的技术人员（架构师/开发人员/测试人员）来说提升相应的技术能力对自己本身和对公司来说都是百益而无一害。,前言,误区：很多技术人员(架构师，开发人员等)受到各种外部因素和自我因素的影响都会觉得借助各种系统软件(操作系统，数据库系统，中间件等)的强大功能和强大的硬件资源能够为我们解决应用系统高可伸缩性的问题以达到很高
3、的性能和可靠性；例如买更好的硬件资源（更强劲的服务器，存储），实施数据库集群（例如ORACLE RAC),实施中间件集群和均衡负载（例如WAS集群和F5硬件均衡负载器），调优（例如数据库调优，硬件调整，操作系统调优，中间件调优）.但是这种方式只能解决一定层次上的问题，并不能解决根本问题；往往带来的结果是花了更多的钱而办不好事情。当然这种方式是需要做的特别是调优但是我们不能过度（例如没有必要买更多的更好的机器，没有必要做ORACLE RAC等）。,前言,挑战：可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。对于大并发量的用户核心业务应用系统，可
4、伸缩性是生死交关的问题。在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消 耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。并且我们需要达到以下几点：1.资源利用率能够随着负载的增长能够线性增长。形象点就是说，如果负载不断地增加，我们能够通过不断的添加机器（通过负载均衡机制）来处理；并且系统的响应时间不会产生剧烈的波动2.系统的架构设计应该能够面对系统数据、用户数增长10倍以上的情况。形象点说：如果现在的系统能够承受
5、10000个用户的使用，那系统现在的这个设计能够承受10万个用户的使用。3.由于整个系统将是由多台机器之间协同工作，单台机器的失效、以及性能严重退化不会影响到整个系统的对外提供的较好地服务质量。4.系统能够提供一个稳定的响应时间，不能出现剧烈的波动。5.系统监控、管理起来方面简单，并且通过相应的诊断日志和工具能够很方便的定位出错误的原因和性能的瓶颈所在。,Agenda,BASE理论简介:ACID 理论的另外选择,可伸缩性最佳实践准则,几点架构建议,经典架构,前言,经典架构,下图所示的是一个我们最喜欢用的经典的应用分层架构设计图。,J2EE架构经典实现：一般来说我们会使用Structs/WebW
6、ork+Spring+Hibernate/iBitas 来进行实现，.NET架构基本也是如此；并且会引入相应的Ajax框架（例如YUI,DOJO,EXTJS,GWT,PROTYPE etc).一种改良实现：UI(用户界面逻辑）采用php/ WebService进行集成。,经典架构,下图所示的是我们最经典的部署架构之一（包括应用服务器集群和数据库服务器HA)。,经典架构,下图所示的是我们最经典的部署架构之一（包括应用服务器集群和数据库服务集群)。,经典架构,部署TIPS：1.除了运行数据库的机器建议运行在小型机上特别是IBM P小型机上；其它都建议运行在PC服务器或者刀片服务器上 。因为数据库系
7、统稳定第一，并且伸缩性扩展能力交较差；而应用服务器的可伸缩性能力/集群能力非常好(只要应用设计上没有太大的问题).并且在部署的时候都要对相应的操作系统进行打补丁和进行相应的内核参数调优，网络参数调优等；数据库系统也要进行补丁和调优；应用服务器也要进行补丁和调优。,经典架构,部署TIPS：2.有时候在实施一个比较大的应用服务器集群的时候，例如HTTP SERVER需要做HA，需要建立更多应用服务器实例（为了充分利用CPU）。而客户仅仅是提供了少量几台高性能的服务器，要实现上面所述的部署架构会发现机器是不够的。所以我们需要利用虚拟化技术（例如VMWARE,XEN,POWERVM)。下图是一个例子，
8、在2台好的PC服务器或者刀片服务器上利用虚拟化技术的部署架构。,经典架构,部署TIPS：3.对于我们WEB应用的部署包，例如J2EE应用的WAR包，请把相应的静态内容（例如JS,HTML,CSS,图片等)拆分出来放到HTTP SERVER上，而只把相应的动态内容（例如JSP,CLASSES等）打包到WAR包中部署在应用服务器上。,Agenda,BASE理论简介:ACID 理论的另外选择,可伸缩性最佳实践准则,几点架构建议,经典架构,前言,一个高伸缩性的WEB应用系统架构示例图,数据库层面,问题起源：在理想情况下，我们希望有一台性能超级强大的机器上安装一个性能强大的数据库系统（例如DB2/ORA
9、CLE），但是我们都知道随着用户数的增长和应用数目或者应用的功能模块数目的增长，一台数据库服务器不管它的硬件条件是如何的强劲，是不可能承受很大的处理压力的（oracle RAC/DB2 PureScale也解决不了这个问题，因为数据库的瓶颈关键在存储IO而RAC/ PureScale是Share IO的）。所以说硬件的投入和数据库 系统软件的投入是基本上解决不了这个问题的，我们需要找到一个性价比合适的解决方案。架构师和程序员的价值开始体现了,数据库层面,解决方式一：在很多场合下我们可能会形成一个主-备方式的数据库架构方案来分解压力如下图所示，这种方式能够缓解相应的性能压力（当然需要建立在SQL
10、语句良好的情况下），但是我们都知道存在相应的数据热点问题，即某些数据存在高强度的删除，修改，查询等操作；一台服务器还是不能够满足相应的需求。,数据库层面,解决方式二：在按照功能域进行分解，即利用多台服务器，安装相应的数据库系统；并且按照相应的功能域把数据分解到不同机器上的数据库系统中。相应的逻辑图如下所示，例如把关于交易的数据放在一台数据库服务器上，产品的数据放在一台数据库服务器上。这样的话就把数据给分离到不同的物理机的数据库服务器上。这样的话可以大大地提高整体大规模系统的性能。但是还是会存在一个比较严重的数据热点问题，例如关于交易的数据的请求强度太高这台服务器还是不能购满足。这样的话我们就提
11、出了下面所示的第三种解决方案。,数据库层面,解决方式三：进行数据的水平切分（即Sharding），即根据相应的数据关键字进行hash（例如一致性HASH算法）把数据分布到不同机器上去。相应的架构如下图所示，通过下图我们可以看到数据的分布存取和数据的聚合需要在应用服务器上增加相应的数据访问层代码来解决。通过这种方式可以大大降低数据热点问题。如果对某些数据还存在热点问题的话我们就需要在应用服务器层这一端的应用代码进行优化增加memcache功能,数据库层面,TIPS：1.少用存储过程和触发器，除非在没有办法的情况下。2.SQL 语句不要太过复杂，一般来说2个表联合查询就差不多了不要出现许多表联合查
12、询。3.要知道关系型数据库是很难伸缩扩展的要珍惜数据库服务器资源，编写良好的SQL语句。4.要与存储工程师紧密配合设计好关系型数据库的物理模型。5.要相信JAVA,C#等这些现代语言的能力是非常强劲的，只要设计的好的话；应用服务器可以无限的线性扩展。,应用服务器层面,问题起源(1)：应用服务器运行着我们编写的业务逻辑和数据访问层等代码，进行相应的业务逻辑计算和数据库访问操作以完成相应的业务功能（例如数据的查询，录入，报表展现，数据或者服务的交互等）。在这一层中存在大量的数据库操作代码频繁的访问数据库，并且随着我们应用的完善我们会发现很多数据是可以缓存的不需要到数据库重新访问的，所以我们可以增加
13、一层即高速数据缓存这一层以大幅提高应用系统的性能并降低对数据库服务器的要求。架构师和程序员的价值又开始体现了,应用服务器层面,解决方式(1)：增加高速数据缓存这一层后的业务逻辑会变更成如下简要的流程：1） 先到高速数据缓存服务器上去查询所需要的数据是否存在。2） 如果数据不存在，则操作数据库获取数据并把数据序列化并存储到高速数据缓存服务器上。3） 如果数据存在，则直接从高速数据缓存服务器上获取并反序列化成相应的java对象。并且数据缓存服务器还需要提供数据过期功能（即数据在数据缓存服务器存在的时间超过1个小时后则过期将被从数据缓存服务器中删除掉。并且数据缓存服务器是可以利用多台机器形成一个大的
14、内存缓存池，数据存在于那个数据缓存服务器上是根据相应的key值进行hash后得到相应的具体某台数据缓存服务器并存储和获取。相应的根据key 值进行hash后的的内存高速数据缓冲服务器的架构图如下所示(即根据Consistent Hashing 算法算出具体的数据分布)：,应用服务器层面(仅适合WAS应用服务器)动态缓存,动态缓存是目前大型复杂应用特别是互联网应用中提升性能和并发能力的关键技术之一。因为在很多场合有些动态页面经过一次执行后所反映的内容，在一定时间内基本上是不会经过任何变化的所以就可以在后续的访问后不用再执行而直接访问这将大大提升应用系统的的响应能力和吞吐能力，在同等的硬件条件下提
15、供更强大的处理能力，满足企业日益增长的业务需要。高速动态缓存做为 WAS 的一个扩展服务从 5.0.2 开始就被包含在从 WAS Express 开始的各个版本。该服务可以缓存 WebSphere Command 对象、Servlet 和 JavaServer Pages（JSP）的输出，从而明显提升应用程序性能。动态高速缓存服务位于应用程序服务器 Java 虚拟机（JVM）内部，通过拦截对可高速缓存对象的调用隐式的实现了对缓存的调用，程序员甚至意识不到它的存在。下图展示了缓存命中和不命中的两种情况下系统的流程，如果缓存命中将避免执行后面复杂的商业逻辑，业务逻辑的执行时间大大缩短了。,应用服务
16、器层面(仅适合WAS应用服务器)动态缓存,Web Output HTML, servlet/JSP, JSF, AJAX, Web Services,Business Logic Command beans,Data Java objects, Persistence L2 cache,应用服务器层面,TIPS：在我们很多的应用场合中，为了提高系统的性能；我们都会对应用服务器进行相应的集群然后又相应的均衡负载器进行均衡负载。然而我们在应用设计和开发的时候都会在session中放入相应的数据以维护我们应用的执行，如果在session中放入大量的数据将会引起应用服务器集群各个实例之间的数据同步会带来很大的压力从而降低了集群的效果，为了提高集群的效率以实现线性的扩展我们建议把相应的放入session中的数据放入到高速内存数据缓冲中。并且建议应用最好实现成无状态.,
