第八讲架构变革 云计算架构.ppt

* * * * * * * * * * * * * * * * * * * * * * * * 在如上图所示的一般的传统n层软件栈架构中，应用将输入（对于Web来说，就是GET、POST和cookie信息的集合）映射为对原始数据的请求，这些原始数据可能存在于数据库中。它们被转换为内存中的数据，并通过一些业务逻辑进行智能化处理。输出模块将针对显示对这些数据对象进行转换，变成HTML、JavaScript、CSS等。 这种方式即是以应用为划分的“烟囱”结构，数据基于应用，并被锁定在应用系统中，形成一个个数据的孤岛。带来以下一些最基本的问题： 1、 数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，并且其设计工作也缺乏相互之间的协调，因此，数据模型基本按照各个应用系统的功能需求进行设计和实现。 2、 由于缺乏有效的数据共享，在有些业务环节上，一个应用所需的数据无法从相关的其他应用系统中获得，而只好重复录入。 3、 另一方面，由于同一个数据可能存在多个数据源（从多个应用系统中被重复录入），由此导致了信息的不一致。 J2EE架构经典实现：一般来说我们会使用Structs/WebWork+Spring+Hibernate/iBitas 来进行实现，.NET架构基本也是如此；并且会引入相应的Ajax框架（例如YUI,DOJO,EXTJS,GWT,PROTYPE etc). 一种改良实现：UI(用户界面逻辑）采用php//flex/html5进行开发，业务逻辑层和数据访问层采用JAVA进行开发。UI(用户界面逻辑）层与业务逻辑层采用REST WebService进行集成。 这些应用系统按照传统的方式进行设计和开发，从而形成一个个的数据孤岛、应用的竖井等。以至不能形成完整的数据视图（例如相互有关联的数据分散于不同的应用系统，数据编码标准不一致，数据不一致和不可信等；让进行数据的整合和数据分析基本上不太可能）和应用系统集成复杂度和难度很高（没有好的设计规范和架构以及代码质量，基本上代码重用程度都很低；从界面集成、数据集成、应用集成这三个方向来做都很困难）；甚至出现无法集成或者为了集成而集成纯粹完成任务而已） * * 对于一个性能要求很高的系统（例如高负载量和高数据量的系统，和将来会做的全省大集中系统和新一代的应用系统）我们会利用大量的硬件资源和相应的集群技术等技术进行相应的数据分区、集群和均衡负载来应对峰值的访问情况。即利用多台机器和技术形成Web服务器的集群，利用多台机器和技术形成应用服务器的集群，利用多台机器和技术形成数据库服务器的分区和集群等。要设计和很好地实施如此复杂的集群牵涉到非常多的技术，所以我会经常看到当系统压力上来的时候会遇到各种各样的问题并且这方面的问题很严重（因为很多应用开发商提出的思路基本上是购买更好的硬件来解决又带来了更多的硬件资源的浪费，而我们都知道仅仅是通过购买好的硬件是解决不了这个问题的）。 * 这些应用系统按照传统的项目建设方式，即每建设一套业务应用系统基本上都要购买新的硬件设备（例如服务器、存储等）和平台系统软件（例如数据库、中间件等）。带来了大量的硬件资源的浪费（例如大量的服务器利用率低下、存储利用率不高和管理复杂）和占用大量的空间、电力的浪费、运维成本的提高.对于一些高负载和高数据量的应用系统，我们对硬件资源的要求是按照此应用系统高峰值的需要来进行购买以应用此应用的需要，但是此应用的高峰期是具有周期性的 * 没有一个完整地、 端到端的整体IT系统监控解决方案，无法对我们整体IT系统（例如主机、存储、网络、数据库、应用服务器、应用）的运行情况进行一个很好的监控，通过监控产生的数据来指导我们优化我们的IT系统 * 随着将来市场需求的变化、国家政策的变化、新技术和新方式的出现等一系列的变化。如果我们在技术、架构、设计、应用方式、管理不进行优化（甚至重构）的话，我们将会面临更大的痛苦。下面主要阐述几个将会面对的问题： 我们在将来肯定会建设一些应用系统，来满足我们的员工、供应商、分销商、大众的需要。比如建设新一代的电子商务系统和新的Web 2.0应用等，对于这种新一代的应用它的特点就是负载量大（例如高并发量和高数据量），数据类型复杂（例如关系型数据、半结构化数据、非结构化数据（音频视频等等）,业务种类繁多和需求变化快。即我们需要把应用的访问方式扩展到新一代智能手机上;所以我们有些应用的功能需要运行在Google Android 和Apple iOS(例如iPhone 、iPAD )上。并且由于移动设备本身存在的局限性（计算\存储能力有限，更重要的是电池容量有限），相应大量的业务应用的执行能力大量移到后台。那就意味着我们应用的特点更是负载量