架构变革-云计算的架构_服务器软件

PPT 内容
PPT 图集

1. 架构变革-云计算的架构软件架构师童景文 Weibo:@景文童
2. 声明本文件中有些图片源自互联网，其版权归属相关图片的所有者。
3. Agenda采用云计算技术后新系统的架构初探现有IT系统的主要问题前言
4. 云计算起源和发展1961年斯坦福教授John McCarthy 提出计算资源可以成为一种重要的新型工业基础。类似水、电、气和通信。 1999年Salesforce成立，2001年发布在线CRM系统 2001年Google CEO Eric Schmidt 在搜索引擎大会上首次提出”Cloud Computing“概念。 2003年Google逐步开始在内部使用云计算，2008年推出Google AppEngine云计算平台 2006年Amazon正式对外推出弹性计算服务（EC2）。。。各大全球知名厂商跟进(IBM,MicroSoft….)
5. (本页无文本内容)
6. 基础设施作为服务(IaaS)软件平台作为服务(PaaS)软件作为服务(SaaS)服务器网络存储中间件协同合作业务流程CRM/ERP/HR行业应用数据中心Fabric共享的虚拟化的, 动态部属数据库Web 2.0 应用运行环境Java 运行环境开发工具云计算分类Computing onDemandBlue Cloud,PureScale Appliication System市场的例子IBM 的例子Source: Hagen Wenzek CHQ Strategy, 2/09
7. 云计算应用(服务)的分类操作系统+应用服务引擎应用系统基础设施应用平台应用软件(IaaS)(PaaS)(SaaS)根据提供的服务类型，将云计算应用(服务)分为三类Infrastructure as a Service 以服务的形式提供虚拟硬件资源，如虚拟主机/存储/网络/安全等资源。用于无需购买服务器、网络设备、存储设备，只需通过互联网租赁即可搭建自己的应用系统典型应用：Amazon Web服务　IDCPlatform as a Service 提供应用服务引擎，如互联网应用编程接口/运行平台等。用户基于该应用服务引擎，可以构建该类应用。典型应用：Google AppEngine, IBM　PureScale Application System,SAESoftware as a Service 用户通过标准的Web浏览器来使用Internet上的软件。用户不必购买软件，只需按需租用软件典型应用：Lotus　Live, Salesforce.com
8. (本页无文本内容)
9. Agenda采用云计算技术后新系统的架构初探现有IT系统的主要问题前言
10. 对于我们的Web 业务应用（架构师、开发人员将会围绕数据创建了传统的“n”层软件栈（数据存储层、业务逻辑层与显示层））来说相应的应用全景图
11. 随着按照这种方式建设的应用系统越来越多,就出现了如下图所示的情况
12. 下图所示的是一个我们最喜欢用的经典的应用分层架构设计图
13. 应用竖井和数据孤岛数据库1应用1数据库2应用2数据库3应用3 数据分析缺少统一的数据标准，格式复杂，逻辑复杂如何形成一个好的数据分析平台？应用系统集成缺少好的设计规范和架构以及代码质量,如何进行集成？让企业整体IT应用形成一个整体，信息可靠可信，提高重用性降低开发成本和风险，应用集成方便快速太难了
14. 很多企业当中都在建设数据中心以形成一个好的商业智能(BI)平台；以达到辅助业务决策管理的功能。相应的数据流架构图例子1.无法获取准确、完整的数据；甚至不知道从哪获取2.。数据量太大，处理速度太慢了；疯掉3。用户会认为我们这个系统就是一个报表系统罢了
15. 集群、均衡负载、数据分区架构设计Web服务器数据库浏览器浏览器浏览器浏览器浏览器Web服务器Web服务器均衡负载应用服务器应用服务器应用服务器均衡负载分区1 分区2 分区3让应用系统高效、可靠、安全的运行太难了设计一套稳定高效的集群系统是很难的
16. 应用系统的逻辑部署架构--DB2数据库HA、WAS集群、HTTP Server 均衡负载方式对于我们现在的应用系统的数据库系统没有遇到很大的性能问题的时候，我们不建议DB2数据库系统进行集群和均衡负载而建议采用数据库HA方式以提供数据库系统的高性能和高可靠性，相应的扩展性通过单台数据库服务器的纵向扩展能力来支撑（即采用增加CPU和内存的方式），J2EE应用服务器采用集群和均衡负载的方式。相应的应用系统的逻辑部署架构图如下图所示：
17. 应用系统的逻辑部署架构--DB2数据库集群、WAS集群、HTTP Server 均衡负载方式对于我们现在的应用系统在将来某个时间，DB2数据库系统无法通过对前面所示图的Active 主DB2数据库服务器进行增加CPU和内存也无法提高性能的时候且要满足数据库服务器的CPU利用率超过70%的条件，我们将建议对DB2进行集群即采用DB2 PureScale技术对DB2数据库进行集群从而让多台DB2数据库服务器都是Active状态以提高性能，并且需要增加相应J2EE应用服务器增加J2EE应用服务器集群（WebSphere Application Server集群）的规模。这样的话就需要对DB2、WAS进行扩容，和对相应的存储系统、IBM服务器进行扩容。相应的应用系统的逻辑部署架构图如下图所示：
18. 应用系统的逻辑部署架构--DB2数据库集群、WAS集群、前端均衡负载采用硬件方式如果当我们的数据库服务器集群和J2EE应用服务器集群规模较大、并且能够提供高性能、高可靠性、高扩展性服务的时候，却发现在最前端的WEB服务器（IBM HTTP Server做为HTTP Server的功能和做为J2EE应用服务器集群的均衡负载的功能)出现了性能瓶颈的时候，我们建议采用硬件的方式来进行解决。当然这种方式仅仅是为苏州提供服务的话出现这种机率很低，一般会出现在全省大集中的时候。这样的话就需要采购相应的WebSphere DataPower XC10 Appliance 硬件。相应的应用系统的逻辑部署架构图如下图所示：
19. 硬件利用率太低，费电、占空间、运维成本高；简而言之太不低碳了利用率1101530硬件资源峰值负载空闲时间
20. 监控对我们的业务至关重要,并且监控不是买一个东西实施下就好了的Is it the Web server?Is it the Application server?Is it the Portal server?Is it the Process server?Is it the CPU?Is it the Operating System?Is it the database?Or some combination?Is it really slow?Is it the network?
21. 移动互联网、物联网的发展；特别是移动互联网的发展所带来的变革
22. Agenda采用云计算技术后新系统的架构初探现有IT系统的主要问题前言
23. (本页无文本内容)
24. (本页无文本内容)
25. High Level View of Paas Cloud 硬件-服务器/存储/网络 Iaas- Iaas云计算平台管理：服务器虚拟化、存储虚拟化、网络虚拟化、自动化数据-关系型数据库、NoSQL etc 应用运行支撑-J2EE应用服务器、MQ、ESB、WorkFlow 、Hadoop、Web服务器 etc 应用-核心支撑应用（统一用户管理中心、数据开发平台、监控）,各种业务应用 etc 接入端-PC、智能手机、智能平板等
26. (本页无文本内容)
27. 高密度堆叠服务器，服务器低功耗、高性能。服务器 CPU：x86/ Power DRAM DISK:HDD/SSD Architect：机架式/刀片Racks（机柜） 10台以上的服务器以太网交换（光纤)/或者Infiniband网络Cluster(服务器集群）
28. 硬件体系层次提供的存储能力：一个例子One Server DRAM 32GB DISK 1TB Local Rack(16 Servers) DRAM 512GB DISK 16TB Cluster(10 Racks) DRAM 5TB DISK 160TB
29. 使用SSD固态硬盘提升性能
30. 使用固态硬盘提高性能ProcessorsMemoryDiskSSDVery, very, very, very, very fastVery, very, very fastVery, very slow comparativelyFast< 10’s ns~100 ns~200,000 ns1,000,000 -8,000,000 nsAccess Speed~1 second~33 minutes~ 12.5 hoursHuman Time Context
31. 高速网络1.万兆以太网 2.Infiniband 网络，此网络技术特别适合于关系数据库集群机制中（例如DB2 PureScale）。
32. 很多云计算项目都是在做硬件虚拟化等一些事情
33. 在云计算实施的前期或者在很多场景的时候；主要关注点在于应用的可靠运行、快速开发和部署、机器资源的充分利用、以及方便的运维等问题；对于这个时候我们应该定位于主要采用Iaas云计算架构（即很依赖于硬件虚拟化技术）和部分采用Pass云计算架构来解决. 1.重点采用Iaas 云计算架构中的硬件虚拟化技术等技术（服务器虚拟化、网络虚拟化、存储虚拟化）以提高硬件的利用率、降低机房占用空间和功耗。 2.快速和方便地给应用提供应用所需要的服务器资源（VM)、网络资源、存储资源。 3.快速和方便地给应用提供应用所需要依赖的平台软件资源，例如数据库系统（DB2)、J2EE应用服务器（WAS)、WEB 服务器（IHS)等。 4.快速和方便地自动地把应用部署到相应的硬件环境中。 5. 硬件虚拟化技术（例如VMWare，PowerVM,xen等）的能力需要在这体现。注意：1.对于在这种情况下，每台服务器所具有的CPU core数目和内存数量越大越好。不要弄一些性能较差的机器干这种事情。2. SSD和大内存对数据库性能的提升是很明显的。3. 这个就是我们通常所说的以大变小 Iaas&部分Pass
34. Iaas&部分Pass
35. Iaas&部分Pass
36. Power虚拟化技术简介
37. VMControl技术简介
38. VMControl技术简介
39. 很多云计算项目都是在做硬件虚拟化等一些事情，但是实施好的话也大大地提高了应用的可靠性、性能；和降低了维护成本（机器少了）和降低机房占用空间和降低了能耗（新机器的能源利用率更高、单位TPS值的功耗更低）。但是数据孤岛、应用竖井这些最关键的问题并没有解决。
40. 我们一定要坚信特别是信息架构师更要坚信，处于大多数系统核心的是数据，而不是算法（或者称之为代码）。随着互联网（固定互联网和移动互联网）技术和物联网技术的发展，最终用户产生和消费的数据将比以往更加推动信息技术的使用，我们业务流程的运转需要各个环节的人员产生和消费相应的数据，数据需要更加地及时、有效、精确；我们的业务的运营越来越离不开相应的数据。在任何情况下我们需要通过Web来呈现给用户使用的所有功能归根结底都是一个界面一个具有较好用户体验的界面来更好地产生和消费数据，以促进人与人之间的协同、人与机器之间的协同以及业务流程更加高效、精准的运转从而提高企业的经营效率和效益。这些数据就构成了我们企业应用信息系统的核心价值，不论这些数据是合作伙伴创建的还是我们的一线员工和管理层所创建的。市场需求的变化促进了业务和业务流程的变化和促进了人的变化，促进了数据的变化即需要创建和消费、利用更多类型、更多种类、更大量的数据，数据推动了我们需要更多的产品/应用，所以架构师、开发人员将会围绕数据创建了传统的“n”层软件栈（数据存储层、业务逻辑层与显示层）即我们的应用都是由数据来驱动的。数据开放平台，数据既是服务
41. 问题：如下图按照传统的方式建设的方式必然产生数据孤岛，能够被共享的业务核心数据被分散到各个应用，并且各个应用的开发商很多不一样的甚至是同一个开发商由于各种问题导致数据编码标准不一致，数据不一致和不可信等问题；这些问题导致不能够形成完整和精准的数据视图，导致很难进行数据分析和支撑业务流程的运营。数据开放平台，数据既是服务
42. 目标：我们需要采用新的思路，即把在企业中能够被支撑各个业务场景的业务应用系统所共享的基础数据全部放入到统一的数据存储池中，并且让这个统一的数据存储池提供相应的服务API让各个业务应用使用（查询、增加、修改等），各个业务应用系统不再保存和维护这些数据，与各个业务应用私有相关的数据有相应的各个业务应用进行维护和控制。这个数据存储池我们称之为数据开发平台，统一相应的编码规则、数据元定义等等。数据开放平台，数据既是服务
43. 在我们建设支撑企业业务运营的业务应用当中，我们不仅仅需要管理关系型的业务数据，还有许多非关系型的数据需要进行管理（例如office文档、图片、音频/视频等），我们不能把这些数据信息由不同的单独业务应用进行单独管理，我们应该统一管理起来提供服务器让不同的业务应用进行利用(存储、提取等）。数据开放平台，数据既是服务Distribute Simple Storage Services（DS3）Simple Storage Service Simple Storage Service Simple Storage ServiceSimple Storage ServiceSimple Storage ServiceSimple Storage Service上层的应用或者服务API/Rest Services/http url/SOAPIndex ServiceAPI/ Rest Services/SOAPNot SQL
44. Distribute Simple Storage Services（DS3）Simple Storage Service(Name Node)Simple Storage Service(Data Node)上层的应用或者服务Index ServiceHDFSRDB业务元数据信息文件元数据信息和文件数据块Simple Storage Service(Data Node)Simple Storage Service(Data Node)Simple Storage Service(Data Node)Simple Storage Service(Data Node)
45. 统一用户管理中心（UMC) 问题：建设了大量的业务应用系统来支撑我们的业务运营，但是这些业务应用系统在用户认证、用户授权等权限控制方面都自己建设自己的相应权限模块来完成用户认证、用户授权等功能即每个业务应用都完全拥有和控制自己的用户认证和用户授权信息；但是这种建设方式导致了以下的主要的问题： 1. 同一个用户在不同的业务应用中都有相应的用户信息，例如用户名、密码等信息；这就会导致会以下几个问题： 1.1 用户信息不一致，例如某个用户密码不一致。 1.2 因为修改了相应的信息需要到不同的业务应用进行修改（修改了密码、地址等基础信息）导致修改的工作量大增，所以绝大部分用户不愿意修改相应的信息（因为改了不是给自己找麻烦嘛）。并且这种现象也导致了一些安全隐患，例如用户的密码很多都是初始密码例如88888，因为按照安全策略一般来说是需要定期修改密码和密码需要符合一定的安全强度的，如果我都改我哪记得住，这不是自己给自己找麻烦啊。 1.3 间接地导致数据孤岛的形成。 2. 在各个业务应用中都按照自己的编码规则建设一套组织机构，导致从业务角度来看是同一套组织机构但是在各个业务应用中是不一样的，这不是间接地导致数据孤岛的形成。 3. 实现SSO(单点登录）困难，一个完整地单点登录SSO是一个完善的用户认证、用户授权的机制而不仅仅是一个用户的登陆过程。从而导致界面集成的困难，即我们建设门户实现后的效果是很差的，实现的效果距离与我们所熟知的一些互联网应用有很大的差距。 4. 很多情况下每上一个应用系统，这个应用系统都要重新实现用户认证、用户授权等权限控制模块，这不是做重复地事情增加工作量也做不好嘛 。。。等等其它问题。
46. 统一用户管理中心（UMC) 目标：建设一个统一用户管理中心系统（UMC）以避免上述所述问题的时候了，它主要要达成以下的目标： 1. 统一用户管理中心系统（ UMC ）统一完全管理和控制相应的用户、组织机构、基础权限控制信息，以形成一个完善地用户认证、用户授权机制。业务应用（不管新应用还是老应用）不再保留自己的用户认证、用户授权信息，不再需要建设单独的用户、组织机构、基础权限控制等模块，除非是和应用特定需求密切相关的详细的数据访问权限信息。 2. 业务应用通过统一用户管理中心系统（ UMC ）提供地API来完成相应的用户认证、用户授权。 3. 让整个企业的IT应用系统的单点登录（SSO)更加地简单、快捷、有效。 4. 统一用户管理中心系统(UMC ）的数据信息其实是主数据的一部分。
47. 一个非常简单的整体逻辑架构如下图所示：用户信息组织机构信息权限控制信息其它信息统一用户管理系统（用户中心）业务应用1业务应用2流程平台企业应用集成平台 etcJava API/Rest Services/ protocolbuf etc
48. 各种业务应用统一用户管理系统用户认证和用户授权：例子流程用户1.用户名和密码2.调用API发起认证请求3.认证通过：返回相应的Token 4.认证通过5.用户希望访问某些应用资源6.调用API发起授权请求7.授权通过：返回相应的Token 8.授权通过9.用户进行业务操作
49. 应用集成和流程整合应用集成平台(WMB) 流程整合平台(Lombardi)业务应用1业务应用2业务应用3MQ/Rest Services/SOAPMQ/Rest Services/SOAPMQ/Rest Services/SOAP/API我们不能为了应用集成而集成，为了流程整合而整合；而把相应应用集成和流程整合系统包含在某个应用当中；我们应该在企业架构层面建设应用集成平台和流程整合平台，所有应用之间的集成和跨应用业务流程的整合通过应用集成平台和流程整合平台来完成。
50. 我们需要面对大并发和大数据量的挑战
51. 挑战：可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。对于大并发量的用户核心业务应用系统，可伸缩性是生死交关的问题。在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。并且我们需要达到以下几点： 1.资源利用率能够随着负载的增长能够线性增长。形象点就是说，如果负载不断地增加，我们能够通过不断的添加机器（通过负载均衡机制）来处理；并且系统的响应时间不会产生剧烈的波动 2.系统的架构设计应该能够面对系统数据、用户数增长10倍以上的情况。形象点说：如果现在的系统能够承受10000个用户的使用，那系统现在的这个设计能够承受10万个用户的使用。 3.由于整个系统将是由多台机器之间协同工作，单台机器的失效、以及性能严重退化不会影响到整个系统的对外提供的较好地服务质量。 4.系统能够提供一个稳定的响应时间，不能出现剧烈的波动。 5.系统监控、管理起来方面简单，并且通过相应的诊断日志和工具能够很方便的定位出错误的原因和性能的瓶颈所在。
52. OLTP关系数据库层面我们大部分应用都是建立在关系型数据库上（例如DB2),让关系型数据库体现出很好的性能有很多种方式： 1、大机器、大内存、SSD、高端存储。（IBM 高端小机、存储） 2、优良的数据库物理设计 3、编写优良、执行效率高的SQL语句。 4、编写优良、执行效率高的业务逻辑代码。 5、关系数据库集群（DB2 Purescale）并且但是上面做好后，在数据量急速增长和并发用户数急速增长的情况下，还是可能会遇到较为严重的性能问题。
53. 解决方式一：在很多场合下我们可能会形成一个主-备方式的数据库架构方案来分解压力如下图所示，这种方式能够缓解相应的性能压力，但是我们都知道存在相应的数据热点问题，即某些数据存在高强度的删除，修改，查询等操作；一台服务器还是不能够满足相应的需求。如果性能要求并不是特别高的话实施对某个数据库实施数据库集群也可解决 OLTP关系数据库层面
54. OLTP关系数据库层面解决方式二：按照功能域进行分解和数据的水平切分（即Sharding）。如果还遇到相应的性能问题，可能需要对某个数据库实施数据库集群甚至需要在业务逻辑代码层引入memcache 用户信息产品信息交易流水信息客户信息业务类型信息上层的应用或者服务JDBC功能域用户信息1水平切分（sharding）交易流水信息1交易流水信息2
55. OLTP关系数据库层面-多重复制某DB2数据库系统某DB2数据库系统生产数据库查询数据库某DB2数据库系统数据仓库：ODS某DB2数据库系统灾备中心上层的应用或者服务增加，修改等OLTP操作只读查询操作为了进行BI所进行的一系列操作（例如ETL，cubeview等）基于数据库日志的实时复制技术
56. 应用执行环境层面-J2EE应用服务器层面问题起源：应用服务器运行着我们编写的业务逻辑和数据访问层等代码，进行相应的业务逻辑计算和数据库访问操作以完成相应的业务功能（例如数据的查询，录入，报表展现，数据或者服务的交互等）。在这一层中存在大量的数据库操作代码频繁的访问数据库，并且随着我们应用的完善我们会发现很多数据是可以缓存的不需要到数据库重新访问的，所以我们可以增加一层即高速数据缓存这一层以大幅提高应用系统的性能并降低对数据库服务器的要求。
57. 应用执行环境层面-J2EE应用服务器层面解决方式(1)：增加高速数据缓存这一层后的业务逻辑会变更成如下简要的流程：1）先到高速数据缓存服务器上去查询所需要的数据是否存在。2）如果数据不存在，则操作数据库获取数据并把数据序列化并存储到高速数据缓存服务器上。3）如果数据存在，则直接从高速数据缓存服务器上获取并反序列化成相应的java对象。并且数据缓存服务器还需要提供数据过期功能（即数据在数据缓存服务器存在的时间超过1个小时后则过期将被从数据缓存服务器中删除掉。并且数据缓存服务器是可以利用多台机器形成一个大的内存缓存池，数据存在于那个数据缓存服务器上是根据相应的key值进行hash后得到相应的具体某台数据缓存服务器并存储和获取。相应的根据key 值进行hash后的的内存高速数据缓冲服务器的架构图如下所示(即根据Consistent Hashing 算法算出具体的数据分布)：
58. WebSphere eXtreme Scale (WXS)DB2 应用执行环境层面-J2EE应用服务器层面Not SQL：KV
59. 应用执行环境层面-J2EE应用服务器层面WebSphere eXtreme Scale (WXS)
60. 应用执行环境层面-J2EE应用服务器层面
61. 应用执行环境层面-J2EE应用服务器层面应用服务器层面(WAS应用服务器)—动态缓存
62. 应用执行环境层面-J2EE应用服务器层面应用服务器层面(WAS应用服务器)—动态缓存Web Output – HTML, servlet/JSP, JSF, AJAX, Web ServicesBusiness Logic – Command beansData – Java objects, Persistence L2 cacheNO CODINGNO CODING
63. Web服务器集群服务服务器集群反向代理服务器集群应用服务器集群关系型数据库群集DB2分布式非关系型数据库集群分布式高速内存缓冲集群MemCacheMemCache其它支撑信息和服务VM/物理机VMVMVM应用服务器集群(WAS)WEB服务器集群(IHS/WAS)反向代理服务器集群(Nginx)均衡负载均衡负载均衡负载均衡负载均衡负载应用执行环境层面-应用静态集群和均衡负载支撑核心层业务逻辑层WEB层接入层
64. Web服务器集群服务服务器集群反向代理服务器集群应用服务器集群关系型数据库群集DB2分布式非关系型数据库集群分布式高速内存缓冲集群MemCacheMemCache其它支撑信息和服务VM/物理机VMVMVM应用服务器集群(WAS)WEB服务器集群(IHS/WAS)反向代理服务器集群(Nginx)均衡负载均衡负载均衡负载均衡负载均衡负载应用执行环境层面-应用动态集群和均衡负载支撑核心层业务逻辑层WEB层接入层动态加入的WAS 实例VM到集群中动态加入的WAS 实例VM到集群中
65. quiesce & stopEdition 1.0Edition 1.0Edition 1.0On-demand routersDynamic clusterEdition 2.0restartapplicationrequestsAPPAPPAPP应用执行环境层面-应用动态集群: 应用升级Group Rollout
66. restartquiesce & stopEdition 1.0Edition 1.0Edition 1.0On-demand routersDynamic clusterEdition 1.0applicationrequestsEdition 2.0Edition 2.0quiesce & stopEdition 2.0Edition 2.0requestrequestrequestrestartAPPAPPAPPAPP应用执行环境层面-应用动态集群:应用升级Atomic Rollout
67. 应用执行环境层面-应用动态集群：优先级调度—应用虚拟化股票交易优先级和流程控制路由及负载均衡分类运作策略WVE节点组WVE随需而变路由器WVE 决策者账户管理财务建议重要性高重要性中重要性低账财节点 5账股节点 2财股节点 3账财节点 4账股节点 1Placement 执行股票交易账户管理财务建议应用需求资源状态Placement 决策
68. 可伸缩性最佳实践准则1、按功能分割：数据按照功能域进行分割；应用代码按照功能域进行分割并使用服务的方式集成起来，高内聚、松耦合。 2、水平切分：数据进行水平切分；应用交互设计成无状态以进行水平切分，让应用服务器可以无限伸缩 3、避免分布式事务 4、用异步策略解耦程序：可通过SEDA（分阶段的事件驱动架构，Staged Event-Driven Architecture）等技术实现异步性 5、虚拟化所有层次：应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的路由逻辑，路由逻辑会把特定的记录（如用户XYZ）分配到指定的分区。这两类抽象需要有我们自己开发相应的DAL层实现的。
69. BASE理论简介:ACID 理论的另外选择现有的困境：在过去的十几年中Web应用变得越来越流行。我们都希望我们的Web应用系统能够应对不断增长的用户量和数据量，以及适应用户和其它开发人员对我们的WEB应用系统的高吞吐量和低响应时间的要求。但是如果我们的WEB应用系统依赖现今的数据库系统时，我们会发现数据存储将成为我们最大的瓶颈。
70. BASE理论简介:ACID 理论的另外选择 CAP 理论介绍：此理论由Eric Brewer(加州大学伯克利教授)提出，他认为在任何的数据共享系统中最多只能同时满足以下三个属性之中的两个，如下图所示： C: Consistency 一致性 A: Availability 可用性 P: Tolerance of network Partition 分区容忍性
71. BASE理论简介:ACID 理论的另外选择 CAP 理论介绍：对于我们的数据库系统来说满足以下两个特性，如下图所示：但是对于一个高伸缩性的应用系统，必然会选择水平扩展策略也就是进行数据的水平切分分布到不同的数据库系统上；所以为了高性能我们必须放宽一致性（即允许瞬时不一致而最终会达到一致性），会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求
72. BASE理论简介:ACID 理论的另外选择 BASE 理论介绍：如果BASE 是一种为了高性能我们必须放宽一致性（即允许瞬时不一致而最终会达到一致性）的一种设计策略，它按照CAP理论尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。它是一个缩写词，相应的缩写词如下定义： Basically Availble --基本可用 Soft-state --软状态/柔性事务(也可理解成无连接) Eventual Consistency --最终一致性。所符合的CAP理论的图例如下所示：
73. BASE理论简介:ACID 理论的另外选择随着Web 的发展，电子商务和社交计算的兴起所引起的企业里不受控的非结构化并且面向信息的数据大爆炸和那些超大规模和高并发的应用场景下，该如何应对呢？企业确实不需要关系型数据库来管理这些数据，因为关系型数据库的特点决定了它不适用于这些数据的性质和使用方式。关系型数据库针对这些信息来说确实不是银弹或者称之为万金油的解决方法，最关键的是关系型数据库已经显得力不从心，暴露了很多难以克服的问题：（1）对数据库高并发读写的需求（2）对海量数据的高效率存储和访问的需求（3）对数据库的高可扩展性和高可用性的需求。所以我们需要分布式的非关系型数据库（即NOSQL，它的意思是对于我们的应用类型，信息类型Only SQL是不够的，所以需要Not Only SQL）。
74. NOSQL is simply Not Only SQL!BASE理论简介:ACID 理论的另外选择
75. BASE理论简介:ACID 理论的另外选择
76. NOSQL特点它们不是关系型数据库，它也不是什么类型应用都能用有自己的使用场景它们可以处理超大量的数据它们运行在较为便宜的服务器集群上它们打破了性能瓶颈没有过多的操作。缺点：现在基本上都是开源产品还不是特别成熟。BASE理论简介:ACID 理论的另外选择
77. 几个主流开源的NoSQL产品Apache CouchDB：源自IBM，（IBM 支持） Apache cassandra：源自Facebook Apache MongoDB 相应的介绍文档可以从http://www.slideshare.net/ 网站上搜索获取BASE理论简介:ACID 理论的另外选择
78. 在BA（数据挖掘分析等）领域我们遇到的大数据挑战更加严峻
79. 业务系统生产数据库层ODS层数据仓库和数据集市层Cognos UI导入/录入ETLETL批量导入和基于日志实时复制营销系统数据库专卖系统数据库其它业务系统数据库ODS 数据库数据仓库Cognos Cube View数据集市ETLXLS数据很经典的一个BA系统的技术架构
80. 内存很经典的一个BA系统的技术架构 SSD 高端HDD 低端HDD
81. 特点： 1.如果每天产生的增量数据不大（例如几十个G以下的话），在一定机器配置的情况下；进行相应地装载、清洗、数据挖掘等工作没有多大的问题。 2.如果数据量非常之大的话，一般会采用大机器、大内存、SSD、高端存储、高速网络（万兆网/Infiniband网络)来进行；但是成本可能非常巨大（例如硬件成本、正版的软件成本）；并且还会出现数据量上到一个量级别后甚至会出现硬件再好也无法应对。 3.实施的架构其实是非常复杂的 4.在大部分客户场景（很多客户没有那么多的数据）的情况下用此架构是合理有效的很经典的一个BA系统的技术架构
82. 改良后以适应Big Data 的BA系统技术架构业务数据库（Oracle）业务数据库（DB2）业务数据库（MS SQL）业务系统数据XLS数据批量导入和基于日志实时复制数据存储区（数据仓库、数据集市）录入和导入数据分析区-Cognos/SPSS（CubeView）ETL
83. 改良后以适应Big Data 的BA系统技术架构-Netezza简介
84. 特点： 1.架构更加简单。 2.性能足够强劲：处理更大的数据量、更快的装载、更快的处理 3.它仅仅适合SQL场景改良后以适应Big Data 的BA系统技术架构
85. 引入Hadoop框架：IBM InforSphere BigInsight 在我们的企业应用系统中，不仅仅是关系型数据还存在大量的非关系型数据都需要进行分析，例如日志、Office文档等等；并且在很多数据量（关系型和非关系型）增长到一个让人非常恐怖的时候（例如一些互联网应用），在做数据分析的时就必须采用Hadoop框架进行大规模的机器集群来进行处理。
86. 引入Hadoop框架：IBM InforSphere BigInsight
87. 业务系统数据源增量实时装载/全量/非实时装载 Hadoop集群: IBM InforSphere BigInsight 计算结果结果装载关系型数据库数据非结构化数据半结构化数据引入Hadoop框架：IBM InforSphere BigInsight DB2DB2 10将能与Hadoop（ IBM InforSphere BigInsight）无缝紧密的进行集成
88. 业务系统数据源增量实时装载/全量/非实时装载 Hadoop集群: IBM InforSphere BigInsight 计算结果结果装载关系型数据库数据非结构化数据半结构化数据引入Hadoop框架：IBM InforSphere BigInsight DB2DB2 10将能与Hadoop（ IBM InforSphere BigInsight）无缝紧密的进行集成数据可视化SPSSCognos其它
89. (本页无文本内容)
90. Hadoop框架与Netzza集成的混合场景
91. 架构的小结
92. (本页无文本内容)

架构变革-云计算的架构

关键词

相关PPT