如何架构和开发高性能,高伸缩性web 应用系统


如何架构和开发高性能,高伸缩性WEB 应用系统 软件架构师 童景文 © 2010 IBM Agenda 经 典 架 构经 典 架 构经 典 架 构经 典 架 构 前 言前 言前 言前 言 © 2010 IBM2 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议 前言 在我们给客户构建相应的WEB 应用系 统中, 会使用J2EE 架构/.NET 架构/LAMP 架 构之一 或 者其中的混合。在很多场合下我们是 不需要 考虑整 个系统 的可伸 缩性以 具备更 好的性 能(例 如 高吞吐量和低响应时间);因为我们 有足够 强的硬 件资源 和用户 的压力 并不大 或者受 到项目 资 源的问题(例如项目的预算,人力资 源,技 术风险 等)。 但是对于有些场合下,例如用 户的并 发用户 数很高 并且有 足够的 项目预 算或者 项目预 算也 比较充分并且我们需要让我们的软件 价值更 好地体 现(例 如我们 不需要 使用昂 贵的硬 件资源 , 仅仅可以利用低成本的硬件就可以让 整个系 统具有 很好的 性能和 可靠性 )。我 们就非 常地需 要 考虑整个应用系统的高可伸缩性的设 计。 当然如果不考虑场合,我们对 所有的 应用系 统的设 计都需 要考虑 高可伸 缩性的 设计那 我们 © 2010 IBM3 当然如果不考虑场合,我们对 所有的 应用系 统的设 计都需 要考虑 高可伸 缩性的 设计那 我们 的应用系统将非常地具有竞争力。并 且对我 们的技 术人员 (架构 师/开发人 员/测 试人员 )来说 提升相应的技术能力对自己本身和对 公司来 说都是 百益而 无一害 。 前言 误 区误 区误 区误 区::::很多技术人员(架构师,开发人 员等)受到 各种外 部因素 和自我 因素的 影响都 会觉得 借 助各种系统软件(操作系统,数据 库系统 ,中间 件等)的 强大功 能和强 大的硬 件资源 能够为 我们 解决应用系统高可伸缩性的问题以达 到很高 的性能 和可靠 性;例 如买更 好的硬 件资源 (更强 劲 的服务器,存储),实施数据库集群 (例如ORACLE RAC), 实施中间件集群和均衡负载 (例如 WAS 集群和F5 硬件均衡负载器),调优(例如数 据库调 优,硬 件调整 ,操作 系统调 优,中 间 件调优).但是这种方式只能解决 一定层 次上的 问题, 并不能 解决根 本问题 ;往往 带来的 结果是 花了更多的钱而办不好事情。当然这 种方式 是需要 做的特 别是调 优但是 我们不 能过度 (例如 没 有必要买更多的更好的机器,没有必 要做ORACLE RAC 等)。 © 2010 IBM4 前言 挑 战挑 战挑 战挑 战::::可伸缩性是我们每天奋力抵抗的一大 架构压 力。我 们所做 的每一 项架构 及设计 决策 ,身前身后都能看到它的踪影。对于 大并发 量的用 户核心 业务应 用系统 ,可伸 缩性是 生死交 关 的问题。在一个可伸缩的架构中,资 源的消 耗应该 随负载 线性( 或更佳 )上升 ,负载 可由用 户 流量、数据量等测量。如果说性能衡 量的是 每一工 作单元 所需的 资源消 耗,可伸缩性则是衡量 当工作单元的数量或尺寸增加时,资 源消耗 的变化 情况。 换句话 说,可 伸缩性 是整个 价格-性能 曲线的形状,而不是曲线上某一点的 取值。 并且我 们需要 达到以 下几点 : 1. 资源利用率能够随着负载的增长能 够线性 增长。 形象点 就是说 ,如果 负载不 断地增 加,我 们 能够通过不断的添加机器(通过负载 均衡机 制)来 处理; 并且系 统的响 应时间 不会产 生剧烈 的 波动 © 2010 IBM5 波动 2. 系统的架构设计应该能 够面对 系统数 据、用 户数增 长10 倍以 上的情 况。形 象点说 :如果 现在 的系统能够承受10000 个用户的使用,那系统 现在的 这个设 计能够 承受10 万 个用户 的使用 。 3. 由于整个系统将是由多 台机器 之间协 同工作 ,单台 机器的 失效、 以及性 能严重 退化不 会影响 到整个系统的对外提供的较好地服务 质量。 4. 系统能够提供一个稳定 的响应 时间, 不能出 现剧烈 的波动 。 5. 系统监控、管理起来方 面简单 ,并且 通过相 应的诊 断日志 和工具 能够很 方便的 定位出 错误的 原因和性能的瓶颈所在。 Agenda 经 典 架 构经 典 架 构经 典 架 构经 典 架 构 前 言前 言前 言前 言 © 2010 IBM6 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议 经典架构 下图所示的是一个我们最喜欢用的经 典的应 用分层 架构设 计图。 © 2010 IBM7 J2EE 架构经典实现:一般来说我们会使用Structs/WebWork+Spring+Hibernate/iBitas 来进行实现,.NET 架构基本也是如此; 并且会引入相应的Ajax 框架(例如YUI,DOJO,EXTJS,GWT,PROTYPE etc). 一种改良实现:UI( 用户界面逻辑)采用php/asp.net/flex/html5 进行开发,业务逻辑层和数据访问层采用JAVA 进行开发。UI( 用 户界面逻辑)层与业务逻辑层采用REST WebService 进行集成。 经典架构 下图所示的是我们最经典的部署架构 之一( 包括应 用服务 器集群 和数据 库服务 器HA)。 © 2010 IBM8 经典架构 下图所示的是我们最经典的部署架构 之一( 包括应 用服务 器集群 和数据 库服务 集群)。 © 2010 IBM9 经典架构 部 署部 署部 署部 署TIPS::::1. 除了运行数据库的机器建议运行在 小型机 上特别 是IBM P 小型机上;其它 都建议运行在PC 服务器或者刀片服务器上 。因为数据库系统稳定第一,并 且伸缩 性扩展 能力 交较差;而应用服务器的可伸缩性能 力/集群能 力非常 好(只要应 用设计 上没有 太大的 问题). 并且在部署的时候都要对相应 的操作 系统进 行打补 丁和进 行相应 的内核 参数调 优,网 络参数 调 优等;数据库系统也要进行补丁和调 优;应 用服务 器也要 进行补 丁和调 优。 © 2010 IBM10 经典架构 部 署部 署部 署部 署TIPS::::2. 有时候在实施一个比较大的应用服 务器集 群的时 候,例 如HTTP SERVER 需要做HA,需要建立更多应用服务器实例( 为了充 分利用CPU)。 而客户 仅仅是 提供了 少量 几台高性能的服务器,要实现上面所 述的部 署架构 会发现 机器是 不够的 。所以 我们需 要利用 虚 拟化技术(例如VMWARE,XEN,POWERVM)。下图是一个例子,在2台好的PC 服务 器或者 刀 片服务器上利用虚拟化技术的部署架 构。 © 2010 IBM11 经典架构 部 署部 署部 署部 署TIPS::::3. 对于我们WEB 应用的部署包,例如J2EE 应用的WAR 包,请把相应的 静态 内容(例如JS,HTML,CSS, 图片等)拆分出来放 到HTTP SERVER 上,而只把相应的动态内容( 例如JSP,CLASSES 等)打包到WAR 包中部署在应用服务器上。 © 2010 IBM12 Agenda 经 典 架 构经 典 架 构经 典 架 构经 典 架 构 前 言前 言前 言前 言 © 2010 IBM13 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议 一个高伸缩性的WEB 应用系统架构示例图 F5 负载均衡器 © 2010 IBM14 App App App App App AppApp App App 数据库层面 问 题 起 源问 题 起 源问 题 起 源问 题 起 源::::在理想情况下,我们希望有一台性 能超级 强大的 机器上 安装一 个性能 强大的 数据库系统(例如DB2/ORACLE ),但是我们都知道 随着用 户数的 增长和 应用数 目或者 应用的 功能模块数目的增长,一台数据库服 务器不 管它的 硬件条 件是如 何的强 劲,是 不可能 承受很 大 的处理压力的(oracle RAC/DB2 PureScale 也解决不了这个问题,因为数据库的 瓶颈关 键在 存储IO 而RAC/ PureScale 是Share IO 的)。所以说硬 件的投 入和数 据库 系统软件的投入是基 本上解决不了这个问题的,我们需要 找到一 个性价 比合适 的解决 方案。架构师和程序员的价值架构师和程序员的价值架构师和程序员的价值架构师和程序员的价值 开始体现了开始体现了开始体现了开始体现了…………………… © 2010 IBM15 数据库层面 解 决 方 式 一解 决 方 式 一解 决 方 式 一解 决 方 式 一::::在很多场合下我们可能会形成一个 主-备方式 的数据 库架构 方案来 分解压 力如下图所示,这种方式能够缓解相 应的性 能压力 (当然 需要建 立在SQL 语句 良好的 情况下 ) ,但是我们都知道存在相应的数据热 点问题 ,即某 些数据 存在高 强度的 删除, 修改, 查询等 操 作;一台服务器还是不能够满足相应 的需求 。 App © 2010 IBM16 数据库层面 解 决 方 式 二解 决 方 式 二解 决 方 式 二解 决 方 式 二::::在按照功能域进行分解,即利用多 台服务 器,安 装相应 的数据 库系统 ;并 且按照相应的功能域把数据分解到不 同机器 上的数 据库系 统中。 相应的 逻辑图 如下所 示,例 如 把关于交易的数据放在一台数据库服 务器上 ,产品 的数据 放在一 台数据 库服务 器上。 这样的 话 就把数据给分离到不同的物理机的数 据库服 务器上 。这样 的话可 以大大 地提高 整体大 规模系 统 的性能。但是还是会存在一个比较严 重的数 据热点 问题, 例如关 于交易 的数据 的请求 强度太 高 这台服务器还是不能购满足。这样的 话我们 就提出 了下面 所示的 第三种 解决方 案。 © 2010 IBM17 数据库层面 解 决 方 式 三解 决 方 式 三解 决 方 式 三解 决 方 式 三::::进行数据的水平切分(即Sharding ),即根据相 应的数 据关键 字进行hash (例如一致性HASH 算法)把数据分布到不同机器上 去。相 应的架 构如下 图所示 ,通过 下图我 们可以看到数据的分布存取和数据的 聚合需 要在应 用服务 器上增 加相应 的数据 访问层 代码来 解 决。通过这种方式可以大大降低数据 热点问 题。如 果对某 些数据 还存在 热点问 题的话 我们就 需 要在应用服务器层这一端的应用代码 进行优 化增加memcache 功能 © 2010 IBM18 数据库层面 TIPS:::: 1. 少用存储过程和触发器,除非在没 有办法 的情况 下。 2.SQL 语句不要太过复杂,一般来说2个表联 合查询 就差不 多了不 要出现 许多表 联合查 询。 3. 要知道关系型数据库是 很难伸 缩扩展 的要珍 惜数据 库服务 器资源 ,编写 良好的SQL 语 句。 4. 要与存储工程师紧密配 合设计 好关系 型数据 库的物 理模型 。 5. 要相信JAVA,C# 等这些现代语言的能力是 非常强 劲的, 只要设 计的好 的话; 应用服 务器可 以 无限的线性扩展。 © 2010 IBM19 应用服务器层面 问 题 起 源问 题 起 源问 题 起 源问 题 起 源(1) ::::应用服务器运行着我们编写的业务逻 辑和数 据访问 层等代 码,进 行相应 的 业务逻辑计算和数据库访问操作以完 成相应 的业务 功能( 例如数 据的查 询,录 入,报 表展现 , 数据或者服务的交互等)。在这一层 中存在 大量的 数据库 操作代 码频繁 的访问 数据库 ,并且 随 着我们应用的完善我们会发现很多数 据是可 以缓存 的不需 要到数 据库重 新访问 的,所 以我们 可 以增加一层即高速数据缓存这一层以 大幅提 高应用 系统的 性能并 降低对 数据库 服务器 的要求 。 架构师和程序员的价值又开始体现了架构师和程序员的价值又开始体现了架构师和程序员的价值又开始体现了架构师和程序员的价值又开始体现了…………………… © 2010 IBM20 应用服务器层面 解 决 方 式解 决 方 式解 决 方 式解 决 方 式(1) ::::增加高速数据缓存这一层后的业务逻 辑会变 更成如 下简要 的流程 :1) 先 到高速数据缓存服务器上去查询所需 要的数 据是否 存在。2) 如果数据不存在,则操作数据 库 获取数据并把数据序列化并存储到高 速数据 缓存服 务器上 。3) 如果数据存在,则直接从高 速 数据缓存服务器上获取并反序列化成 相应的java 对象。并 且数据 缓存服 务器还 需要提 供数据 过 期功能(即数据在数据缓存服务器存 在的时 间超过1个小时 后则过 期将被 从数据 缓存服 务器中 删除掉。并且数据缓存服务器是可以 利用多 台机器 形成一 个大的 内存缓 存池, 数据存 在于那 个 数据缓存服务器上是根据相应的key 值 进行hash 后得 到相应 的具体 某台数 据缓存 服务器 并存储 和获取。相应的根据key 值进行hash 后的的内存高速数据缓冲服 务器的 架构图 如下所 示(即根据 Consistent Hashing 算法算出具体的数据分布): © 2010 IBM21 应用服务器层面(仅适合WAS 应用服务器)—动 态缓存 动态缓存是目前大型复杂应用 特别是 互联网 应用中 提升性 能和并 发能力 的关键 技术之 一。 因为在很多场合有些动态页面经过一 次执行 后所反 映的内 容,在 一定时 间内基 本上是 不会经 过 任何变化的所以就可以在后续的访问 后不用 再执行 而直接 访问这 将大大 提升应 用系统 的的响 应 能力和吞吐能力,在同等的硬件条件 下提供 更强大 的处理 能力, 满足企 业日益 增长的 业务需 要 。高速动态缓存做为 WAS 的一个扩展服务从 5.0.2 开始就被包含在从 WAS Express 开始的各 个版本。该服务可以缓存 WebSphere Command 对象、Servlet 和 JavaServer Pages (JSP )的输出,从而明显提升应用程序性 能。动 态高速 缓存服 务位于 应用程 序服务 器Java 虚拟机 (JVM)内部,通过拦截对可高速缓存对象 的调用 隐式的 实现了 对缓存 的调用 ,程序 员甚至 意 识不到它的存在。下图展示了缓存命 中和不 命中的 两种情 况下系 统的流 程,如 果缓存 命中将 避 免执行后面复杂的商业逻辑,业务逻 辑的执 行时间 大大缩 短了。 © 2010 IBM22 免执行后面复杂的商业逻辑,业务逻 辑的执 行时间 大大缩 短了。 应用服务器层面(仅适合WAS 应用服务器)—动 态缓存 Web Output – HTML, servlet/JSP, JSF, AJAX, Web Services © 2010 IBM23 Business Logic – Command beans Data – Java objects, Persistence L2 cache 应用服务器层面 TIPS:::: 在我们很多的应用场合中,为了提高 系统的 性能; 我们都 会对应 用服务 器进行 相应的 集群然 后 又相应的均衡负载器进行均衡负载。 然而我 们在应 用设计 和开发 的时候 都会在session 中放入 相应的数据以维护我们应用的执行, 如果在session 中放入大量的 数据将 会引起 应用服 务器集 群各个实例之间的数据同步会带来很 大的压 力从而 降低了 集群的 效果, 为了提 高集群 的效率 以 实现线性的扩展我们建议把相应的放 入session 中的数据放入到高 速内存 数据缓 冲中。 并且建 议应用最好实现成无状态. © 2010 IBM24 HTTP Server 层面 HTTP SERVER 软件(例如Nginx/IBM HTTP Server ),完成HTTP SERVER 所具有的一些功 能例如反向代理、均衡负载等。 但是我们都知道我们的应用系统 有大量 的模块 ,并且 不同模 块的优先程度是不一样的,有些优先 程度是 很高, 有些优 先程度 是中等 ,有些 优先程 度是较 低 的。在我们传统的方式中我们会遇到 这样的 一个情 况就是 当大量 的用户 请求上 来,并 且是请 求 的是不同的重要优先程度的功能模块 ;然后 由均衡 负载器 转接到 相应的 应用服 务器执 行;我 们 会发现一个现象就是所有请求都在执 行导致 所有的 请求执 行效率 都很低 很慢甚 至大家 都锁死 在 那,并且有些机器却很空闲。所以我 们需要 引入WVE:ODR( 按需路 由)这一层 所提供 的功能 , 此层接受到大量请求后,根据预先设 置好的 分类对 请求进 行分类 排队, 高优先 级的请 求将优 先 得到执行并能够占用更多的资源并且 也可以 根据需 要把空 闲机器 上的停 止的应 用启动 起来进 行 请求的执行从而可以更好的利用硬件 资源。这个思 路就是 动态集 群和应 用虚拟 化,相 应的架 构 © 2010 IBM25 请求的执行从而可以更好的利用硬件 资源。这个思 路就是 动态集 群和应 用虚拟 化,相 应的架 构 图如下所示: HTTP 层面 TIPS:::: 1. Make Fewer HTTP Requests. 2. Add an Expires Header 3. Put Stylesheets at the Top 4. Put Scripts at the Bottom 5 …… 等更多,请参考参考资料\High Performance Web Sites.pdf 或者google 或者到http://nate.koechley.com/talks/2007/atmedia-london/high-performance- web -sites.pdf 下载 © 2010 IBM26 web -sites.pdf 下载 代码安全 TIPS:::: 很多安全都是代码编写的问题导致很 多系统 很不安 全,例 如SQL 注入、 跨域脚 本。 请参考参考资料\What Every Web Programmer Needs To Know About Security 或者访问 http://code.google.com/intl/zh-CN/edu/submissions/daswani/index.html http://code.google.com/intl/zh-CN/edu/submissions/web_security/listing.html 下载相应的资料 © 2010 IBM27 Agenda 经 典 架 构经 典 架 构经 典 架 构经 典 架 构 前 言前 言前 言前 言 © 2010 IBM28 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 按 功 能 分 割按 功 能 分 割按 功 能 分 割按 功 能 分 割::::相关的功能部分应该合在一起,不 相关的 功能部 分应该 分割开 来—— 不管 你把它叫做SOA、功能分解还是工程秘 诀。而 且,不 相关的 功能之 间耦合 程度越 松散, 就越能 灵活地独立伸缩其中的一部分。 在编码层次,我们无时不刻都 在运用 这条原 则。JAR 文件、包 、Bundle 等等,都是用 来隔 离和抽象功能的机制。 在应用层次,将不同的功能划 分成几 个应用 程序池 。销售 功能由 一组应 用服务 器运行 ,投 标功能由另一组负责,搜索又是另外 一组服 务器。 这样就 可以根 据某项 功能的 资源消 耗,单 独 地伸缩其中一个池。我们也因此得以 进一步 隔离及 合理化 资源依 赖关系—— 比如销售池只需要 访问后台资源的一个相对较小的子集。 © 2010 IBM29 访问后台资源的一个相对较小的子集。 在数据库层次,我们也采取同 样的做 法。没 有无所 不包的 单一数 据库, 相反我 们有一 组数 据库主机存放用户数据、一组存放商 品数据 、一组 存放购 买数据……。 同样, 这种做 法让我 们 得以单独为某一类数据伸缩其数据库 设施。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 水 平 切 分水 平 切 分水 平 切 分水 平 切 分::::按功能分割对我们的帮助很大,但 单凭它 还不足 以得到 完全可 伸缩的 架构。 即使将功能一一解耦,单项功能的资 源需求 随着时 间增长 ,仍然 有可能 超出单 一系 统的能力。 我们需要常常提醒自己,“没有分割 就没有 伸缩” 。在单 项功能 内部, 我们需 要能把 工作负 载 分解成许多我们有能力驾驭的小单元 ,让每 个单元 都能维 持良好 的性能价格比。这就是水平分 割出场的时候了。 在应用层次,将各种交互都设 计成无 状态的 ,所以 水平分 割是轻 而易举 之事。 用标准 的负 载均衡服务器来路由进入的流量。所 有应用 服务器 都是 均等的,而且任何服务器都不会 维持事 务性的状态,因此负载均衡可以任意 选择应 用服务 器。如 果需要 更多处 理能力 ,只需 要简单 地增加新的应用服务器。 © 2010 IBM30 地增加新的应用服务器。 数据库层次的问题比较有挑战 性,原 因是数 据天生 就是有 状态的 。我们 会按照 主要的 访问 路径对数据作水平分割(或称为“sharding” )。例 如用户 数据被分割到20 台主机上,每台主 机存放1/20 的用户。随着用户数量的增 长,以 及每个 用户的 数据量 增长, 我们会 增加更 多的 主机,将用户分散到更多的 机器上去。用例不同,我们分割 数据的 方案也 需要不 同:有 些是对 主键简单取模(ID 尾数为1的放到第一 台主机,尾数为二的放到下一台 ,以此 类推) ,有些 是 按照ID 的区间分割(1-1M 、1-2M 等等 ),或 者一致 性HASH 算法。不过具 体 的分割方案如何 ,总的思想是支持数据分割及重分割 的基础 设施在 可伸缩 性上远 比不支 持的优 越。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 避 免 分 布 式 事 务避 免 分 布 式 事 务避 免 分 布 式 事 务避 免 分 布 式 事 务::::看到这里,你可能在疑惑按功能划 分数据 和水平 划分数 据的实 践如 何满足事务要求。毕竟,几乎任何有 意义的 操作都 要更新 一个以 上的实 体—— 立即就 可以举 出 用户和商品的例子。正统的广为人知 的答案 是:建 立跨资 源的分 布式事 务,用 两段式 提交来 保 证要么所有资源全都更新,要么全都 不更新 。很不 幸,这 种悲观 方案 的成本很可观。伸缩、性 能和响应延迟都受到协调成本的反面 影响, 随着依 赖的资 源数量 和客户 数量的 上升, 这些指 标 都会以几何级数恶化。可用性亦受到 限制, 因 为所有依赖的资源都必须就 位。实 用主义 的答案 是,对于不相关的系统, 放宽对 它们的 跨系统 事务的 保证。 左右逢源是办不到的。保 证跨多 个系统 或分区 之间的 即时的 一致性 ,通常 既无必 要,也 不 现实。Inktomi 的Eric Brewer 十年前提出的CAP 公理是这 样说的:分布 式系统 的三项 重要指 标 © 2010 IBM31 现实。Inktomi 的Eric Brewer 十年前提出的CAP 公理是这 样说的:分布 式系统 的三项 重要指 标 —— 一致性(Consistency )、可用性(Availability )和 分区耐受性(Partition-tolerance ) —— 在任意时刻,只有两项能同时成 立。对 于高负 载量的 应用例 如互联 网应用 来说, 我们必 须选 择分区耐受性,因为它是实 现可伸缩的根本。对于24x7 运行的 应用, 选择可 用性也 是理所 当 然的。于是只好放弃即时一致性(immediate consistency )。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 避 免 分 布 式 事 务避 免 分 布 式 事 务避 免 分 布 式 事 务避 免 分 布 式 事 务::::对于高负载量和高可用性的应用, 我们应 该绝对 不允许 任何形 式的 客户端或者分布式事务—— 因此绝不 需要两 段式提 交。在 某些经 过仔细 定义的 情形下 ,我们 会 将作用于同一个数据库 的若干语句捆绑成单个事务性 的操作 。而对 于绝大 部分操 作,单 条语句 是自动提交的。虽然我们故意放宽正 统的ACID 属性 ,以致 不能在 所有地 方保证 即时一 致 性, 但现实的结果是大部分系统在绝大部 分时间 都是可 用的。 当然我 们需要 采用了 一些技 术来帮 助 系统达到最终的一致性(eventual consistency ):周密调整数据库操作的次 序、异 步恢复 事件 ,以及数据核对(reconciliation )或者集中决算(settlement batches )。具体选择哪种技术要 根据特定用例对一致性的需求来决定 。 对于架构师和系统的设计者来 说,关 键是要 明白一 致性并 非“有 ”和“ 没有” 的单选 题。 © 2010 IBM32 现实中大多数的用例都不要求即时一 致性。 正如我 们经常 根据成 本和其 他压力 因素来 权衡可 用 性的高低,一致性也同样可以量体裁 衣,根 据特定 操作的 需要而 保证适 当程度 的一致 性 。。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 用 异 步 策 略 解 耦 程 序用 异 步 策 略 解 耦 程 序用 异 步 策 略 解 耦 程 序用 异 步 策 略 解 耦 程 序::::提高可伸缩性的另一项关键措施是 积极地 采取异 步策略 。如 果组件A同步调用组件B,那么A和B就是紧密耦合的, 而紧耦 合的系 统其可 伸缩性 特征是 各部 分 必须共同进退—— 要伸缩A必须同时 伸缩B。同 步调用 的组件 在可用 性方面 也面临 着同样 的 问题。我们回到最基本的逻辑:如果A推 出B,那么非B推 出非A。也 就 是说,若B不可用,则A 也不可用。如果反过来A和B的联系是异步的, 不管是 通过队 列、多 播消息 、批处 理还是 什么其 他手段,它们就可以分别地伸缩。而 且,此 时A和B的可用性特征是相互独立的—— 即使B受困 或者死掉,A仍然能够继续前进。 整个基础设施从上到下都 应该贯 彻这项 原则。 即使在 单个组 件内部 也可通 过SEDA(分阶 段的事件驱动架构,Staged Event-Driven Architecture )等技术实现异步性,同时保 持一个 易 于理解的编程模型。组件之间也遵守 同样的 原则—— 尽可 能避免 同步带 来的耦 合。在 多数情 况 © 2010 IBM33 于理解的编程模型。组件之间也遵守 同样的 原则—— 尽可 能避免 同步带 来的耦 合。在 多数情 况 下, 两个组件在任何事件中都不 会有直 接的业 务联系 。在所 有的层 次,把 过程分 解为阶 段( stages or phases ),然后将它们异步地连接起来 ,这是 伸缩的 关键。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 将 过 程 转 变 为 异 步 的 流将 过 程 转 变 为 异 步 的 流将 过 程 转 变 为 异 步 的 流将 过 程 转 变 为 异 步 的 流::::用异步的原则解耦程序,尽可能将 过程变 为异步 的。对 于要求快速响应的系统,这样做可以 从根本 上减少 请求者 所经历 的响应 延迟。 对于网 站或者 交 易系统, 牺牲数据或执行的延迟时间( 完成全 部工作 的实践 )来换 取用户 的延迟 时间( 用户得 到响应的时间)是值得的。活动跟踪 、单据 开付、 决算和 报表等 处理过 程显然 都 应该属于后台 活动。主要用例过程中常常有很多步 骤可以 进一部 分解成 异步运 行。任 何可以 晚点再 做的事 情 都应该晚点再做。 还有一个同等重要的方面认识 到的人 不多: 异步性 可以从 根本上 降低基 础设施 的成本 。同 步地执行操作迫使你必须按照负载的 峰值来 配备基 础设施—— 即 使在 任务最重的那一天里任务 最重的那一秒,设施也必须有能力立 即完成 处理。 而将昂 贵的处 理过程 转变为 异步的 流,基 础 设施就不需要按照峰值来配备,只需 要满足 平均负载。而且也不需要立即 处理所 有的请 求,异 © 2010 IBM34 设施就不需要按照峰值来配备,只需 要满足 平均负载。而且也不需要立即 处理所 有的请 求,异 步队列可以将处理任务分摊到较长的 时间里 ,因而 起到削 峰的作 用。系 统的负 载变化 越大, 曲 线越多尖峰,就越能从 异步处理中得益。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 虚 拟 化 所 有 层 次虚 拟 化 所 有 层 次虚 拟 化 所 有 层 次虚 拟 化 所 有 层 次::::虚拟化和抽象化无所不在,计算机 科学里 有一句 老话: 所有问 题都 可以通过增加一个间接层次来解决。 操作系 统是对 硬件的 抽象, 而许多 现代语 言所用 的虚拟 机 又是对操作系统的抽象。对象-关 系映射 层抽象 了数据 库。负 载均衡 器和虚 拟IP 抽 象了网 络终端 。当我们通过分割数据和程序来提高 基础设 施的可 伸缩性 ,为各 种分割增加额外的虚拟层次就 成为重中之重。 我们建议虚拟化数据库。应用 与逻辑 数据库 交互, 逻辑数 据库再 按照配 置映射 到某个 特定的 物 理机器和数据库实例。应用也抽象于 执行数 据分割 的 路由逻辑,路由逻辑会把特 定的记 录(如 用户XYZ)分配到指定的分区。这两类 抽象需 要有我 们自己 开发相 应的DAL 层实现 的。 © 2010 IBM35 用户XYZ)分配到指定的分区。这两类 抽象需 要有我 们自己 开发相 应的DAL 层实现 的。 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 适 当 地 使 用 缓 存适 当 地 使 用 缓 存适 当 地 使 用 缓 存适 当 地 使 用 缓 存::::最后要适当地使用缓存。这里给出 的建议 不一定 普遍适 用,因 为缓 存是否高效极大地依赖于用例的细节 。说到 底,要 在存储 约束、 对可用 性的需 求、对 陈旧数 据 的容忍程度等条件下最大化缓存的命 中率, 这才是 一个高 效的缓 存系统 的最终 目标。 经验证 明 ,要平衡众多因素是极其困难的,即 使暂时 达到目 标,情 况也极 可能 随着时间而改变。 最适合缓存的是很少改变 、以读 为主的 数据—— 比如 元数据 、配置 信息和 静态数 据。我 们建议 积极地缓存这种类型的数据,并且结 合使用 “推” 和“ 拉”两种方法保持系统在一定程 度上的 更新同步。减少对相同数据的重复请 求能达 到非常 显著的 效果。 频繁变 更、读 写兼有 的数据 很 难有效地缓存。我们建议不要对请求 间短暂 存在的 会话数 据作任 何缓存。 © 2010 IBM36 难有效地缓存。我们建议不要对请求 间短暂 存在的 会话数 据作任 何缓存。 做得好,缓存系统能让可伸缩 性的曲 线向下 弯曲, 也就是 比线性 增长还 要好—— 后续 请求从 缓 存中取数据比从主存储取数据成本低 廉。反 过来, 缓存做 得不好 会引入相当多额外的经常耗费 ,也会妨碍到可用性。我们还没见过 哪个系 统没机 会让缓 存大展 拳脚的 ,关键 是要根 据具体 情 况找到适当缓存策略。 Agenda 经 典 架 构经 典 架 构经 典 架 构经 典 架 构 前 言前 言前 言前 言 © 2010 IBM37 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则可 伸 缩 性 最 佳 实 践 准 则 几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议几 点 架 构 建 议 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 现 有 的 困 境现 有 的 困 境现 有 的 困 境现 有 的 困 境::::在过去的十几年中Web 应用变得越来越 流行。 我们都 希望我 们的Web 应 用 系统能够应对不断增长的用户量和数 据量, 以及适 应用户 和其它 开发人 员对我 们的WEB 应用系 统的高吞吐量和低响应时间的要求。 但是如 果我们 的WEB 应用系统依 赖现今 的数据 库系统 时, 我们会发现数据存储将成为我们最大 的瓶颈 。 © 2010 IBM38 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 解 决 思 路解 决 思 路解 决 思 路解 决 思 路1::::如何伸缩我们的应用以应付此局 面,我 们一般 来说有 两种策 略;第 一种也 是 最简单的即是垂直扩展伸缩,即把我 们的应 用(特 别是数 据库系 统)运 行在性 能更加 强劲的 服 务器上,但是此种策略最大的限制是 性能越 好的服 务器越 昂贵以 及还有 相应的 锁限制 并且还 需 要进行复杂的应用迁移;其实更让我 们沮丧 的是当 我们的 数据量 和访问 负载量 以及实 现的复 杂 程度到达一定程度的时候,这个世界 上压根 就不存 在这种 服务器 。 © 2010 IBM39 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 解 决 思 路解 决 思 路解 决 思 路解 决 思 路2::::第二种也是最简单的即是水平扩 展伸缩 ,此种 伸缩是 相当的 复杂但 是提供 了 更好的伸缩性。水平数据分区伸缩可 以从两 个方向 来进行 。先按 照功能 域的划 分把处 于不同 功 能域的数据放在不同的数据库上相同 功能域 的数据 放在同 一个数 据库上 。然后 对于同 一个功 能 域的某些数据按照相应的算法(例如 一致性HASH 算法)把 数据进 行切分 水平(即sharding) 分布 到不同的数据库上.相应的图例如 下所示 : © 2010 IBM40 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 ACID理 论 简 介理 论 简 介理 论 简 介理 论 简 介::::指数据库事务正确执行的 四个基 本要素 的缩写.包 含:原 子性(Atomicity )、一致性(Consistency )、隔离性(Isolation )、持久性(Durability ) 。一个 支持事 务( Transaction )的数据库系统,必需要具有这四种 特性, 否则在 事务过 程(Transaction processing )当中无法保证数据的正确性,交易过程极 可能达 不到交 易方的 要求. 原 子 性原 子 性原 子 性原 子 性 整个事务中的所有操作,要 么全部 完成, 要么全 部不完 成,不 可能停 滞在中 间某个 环节。事务在执行过程中发生错误, 会被回 滚(Rollback )到事务开始前的状 态,就 像这个 事 务从来没有执行过一样。 一 致 性一 致 性一 致 性一 致 性 在事务开始之前和事务结束 以后,数据库 的完整 性约束 没有被 破坏。 © 2010 IBM41 一 致 性一 致 性一 致 性一 致 性 在事务开始之前和事务结束 以后,数据库 的完整 性约束 没有被 破坏。 隔 离 性隔 离 性隔 离 性隔 离 性 两个事务的执行是互不干扰 的,一 个事务 不可能 看到其 他事务 运行时 ,中间 某一时 刻的数据。 持 久 性持 久 性持 久 性持 久 性 在事务完成以后,该事务所 对数据 库所作 的更改 便持久 的保存 在数据 库之中 ,并不 会被回滚。 数据库厂商在很早就认识的到 ,如果 数据进 行水平 切分分 布到不 同的数 据库系 统上的 话(即数 据库分区:partitioning databases) 为了保证ACID 特性,提出了两阶 段事务 递交技 术(2PC) 并实 现,此技术的特点就是第一阶段:事 务协调 器要去 所有参 与全局 事务的 数据库 准备递 交事务 , 如果所有的数据库都同意并准备好则 转入第 二阶段 ;第二 阶段: 事务协 调器要 求所有 的参与 全 局事务的数据库递交数据,要么全部 成功要 么全部 失败。 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 ACID理 论 的 缺 陷理 论 的 缺 陷理 论 的 缺 陷理 论 的 缺 陷::::如果数据进行水平切分 分布到 不同的 数据库 系统上 的话(即数 据库 分区:partitioning databases) 为了保证ACID 特性,我们必须运用两 阶段事 务递交 技术(2PC) 。 但是此技术有以下几大缺陷: 1. 当一个2PC 事务包含两个数据库 的话, 如果我 们估计 每个数 据库的 有效性 为99.9%, 则整体 的 有效性变成99.8%. 2. 由于2PC 事务是采用悲观锁机制 ,当业 务逻辑 复杂程 度提高 以及负 载量增 大的情 况下效 率将 很低下,对于一个高性能,高伸缩性 的应用 系统是 不可能 接受的 。 为了解决这个问题,我们 需要引 入相应 的理论 和经验 来支撑 我们以 解决此 问题。 © 2010 IBM42 为了解决这个问题,我们 需要引 入相应 的理论 和经验 来支撑 我们以 解决此 问题。 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 CAP 理 论 介 绍理 论 介 绍理 论 介 绍理 论 介 绍::::此理论由Eric Brewer( 加州大学 伯克利 教授)提出 ,他认 为在任 何的数 据共享系统中最多只能同时满足以下 三个属 性之中 的两个 ,如下 图所示 : © 2010 IBM43 C: Consistency 一致性 A: Availability 可用性 P: Tolerance of network Partition 分区容忍性 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 CAP 理 论 介 绍理 论 介 绍理 论 介 绍理 论 介 绍::::对于我们的数据库系统来说 满足以 下两个 特性, 如下图 所示: © 2010 IBM44 但是对于一个高伸缩性的应用系统, 必然会 选择水 平扩展 策略也 就是进 行数据 的水平 切分分 布 到不同的数据库系统上 ;所以为了高性能我们必须 放宽一 致性( 即允许 瞬时不 一致而 最终会 达到一致性),会尽量朝着 A、P 的方向设计,然后通过其它 手段保 证对于 一致性 的商务 需求 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 BASE 理 论 介 绍理 论 介 绍理 论 介 绍理 论 介 绍::::如果BASE 是一种为了高性能我们必须放 宽一致 性(即 允许瞬 时不 一致而最终会达到一致性)的一种设 计策略 ,它按 照CAP 理论尽量朝 着A、P 的方向设计,然 后通过其它手段保证对于一致性的商 务需求 。它是 一个缩 写词, 相应的 缩写词 如下定 义: Basically Availble -- 基本可用 Soft-state -- 软状态/柔性事 务(也可 理解成 无连接) Eventual Consistency -- 最终一致性。 所符合的CAP 理论的图例如下所示: © 2010 IBM45 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 一 个 示 例一 个 示 例一 个 示 例一 个 示 例::::由于采用这个理论后,很多的逻辑 将从数 据库层 转移到 应用层 进行处 理,架 构师和程序员的价值又开始体现。 我们先设计一个非常简单 的两张 表,这 两张表 的数据 分布在 不同机 器上的 数据库 上;通 过这两 张表完成以下的的业务逻辑,用户表 存储用 户信息 并且包 含用户 所购买 和卖出 的总的 金额, 交 易表存储相关的交易信息例如交易双 方是谁 ,交易 金额等 。相应 的表关 系图如 下所示 : © 2010 IBM46 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 使 用使 用使 用使 用ACID理 论 的 伪 代 码理 论 的 伪 代 码理 论 的 伪 代 码理 论 的 伪 代 码::::由于数据分布在不同机 器上不 同数据 库,为 了保证 数据 的一致性我们必然会使用2PC ,相应的伪代码 如下图 所示, 当然此 代码是 及其简 单的。 © 2010 IBM47 BASE 理 论 简 介理 论 简 介理 论 简 介理 论 简 介:ACID 理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择理 论 的 另 外 选 择 使 用使 用使 用使 用BASE 理 论 的 伪 代 码理 论 的 伪 代 码理 论 的 伪 代 码理 论 的 伪 代 码::::为了达到高性能和 高伸缩 性,我 们根据CAP 理论按 照 往A,P 方向进行设计,牺牲瞬时一致性但是 达到最 终的一 致性; 从而可 以实现 一个高 伸缩性 的 可扩展系统。对此我们引入了持久化 消息队 列机制 ,当然 这里的 伪代码 的一个 前提是 此持久 化 消息队列与数据库系统融合在一起( 即持久 化消息 队列的 后台存 储资源 与数据 库系统 是相同 的 ),当然对于如果不在一起的话,相 应的细 节请参 考此文 档:BASE:An Acid Alternative © 2010 IBM48 © 2010 IBM49 参 考 文 档参 考 文 档参 考 文 档参 考 文 档 参 考 文 档参 考 文 档参 考 文 档参 考 文 档 1. High Performance Web Sites 2. memcached 全面剖析 3. BASE:An Acid Alternative 4. SEDA 架构理论 5. WAS 动态缓存介绍 6. What Every Web Programmer Needs To Know About Security 7. DB2 V9.5 力助SASS 应用 8. CAP 理论介绍 9. Problem Solving on Large Scale Clusters © 2010 IBM50 9. Problem Solving on Large Scale Clusters 注:这些资料都可以通过GOOGLE 搜索得到。 Questions ? © 2010 IBM51
还剩50页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 20 金币 [ 分享pdf获得金币 ] 18 人已下载

下载pdf

pdf贡献者

melity78

贡献于2011-05-30

下载需要 20 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf