A. 语义web的体系结构
下图描述了语义Web的七层体系结构： 自描述
文档 数据 数据 规则 信任 证明 数
字
签
名 逻辑 本体 RDF+RDF Schema XML+NS+XML Schema 名称空间 Unicode URI 第一层：Unicode和URI。
Unicode是一个字符集，这个字符集中所有字符都用两个字节表示，可以表示65536个字符，基本上包括了世界上所有语言的字符。数据格式采用Unicode的好处就是它支持世界上所有主要语言的混合，并且可以同时进行检索。URI(Uniform ResourceIdentifier)，即统一资源定位符，用于唯一标识网络上的一个概念或资源。在语义Web体系结构中，该层是整个语义Web的基础，其中Unicode负责处理资源的编码，URI负责资源的标识。
第二层：XML+NS+xmlschema。
XML是一个精简的标准通用标记语言，它综合了标准通用标记语言的丰富功能与HTML的易用性，它允许用户在文档中加入任意的结构，而无需说明这些结构的含意。NS(NameSpace)即命名空间，由URI索引确定，目的是为了避免不同的应用使用同样的字符描述不同的事物。XML Schema是文档类型定义（外语缩写：DTD）的替代品，它本身采用XML语法，但比DTD更加灵活，提供更多的数据类型，能更好地为有效的XML文档服务并提供数据校验机制。正是由于XML灵活的结构性、由URI索引的NS而带来的数据可确定性以及XMLSchema所提供的多种数据类型及检验机制，使其成为语义Web体系结构的重要组成部分。该层负责从语法上表示数据的内容和结构，通过使用标准的语言将网络信息的表现形式、数据结构和内容分离。
第三层：RDF+rdfschema。
资源描述框架（外语缩写：RDF）是一种描述WWW上的信息资源的一种语言，其目标是建立一种供多种元数据标准共存的框架。该框架能充分利用各种元数据的优势，进行基于Web的数据交换和再利用。RDF解决的是如何采用XML标准语法无二义性地描述资源对象的问题，使得所描述的资源的元数据信息成为机器可理解的信息。如果把XML看作为一种标准化的元数据语法规范的话，那么RDF就可以看作为一种标准化的元数据语义描述规范。Rdfschema使用一种机器可以理解的体系来定义描述资源的词汇，其目的是提供词汇嵌入的机制或框架，在该框架下多种词汇可以集成在一起实现对Web资源的描述。
第四层：“本体词汇”（Ontology vocabulary）。
该层是在RDF(S)基础上定义的概念及其关系的抽象描述，用于描述应用领域的知识，描述各类资源及资源之间的关系，实现对词汇表的扩展。在这一层，用户不仅可以定义概念而且可以定义概念之间丰富的关系。
第五至七层：Logic、Proof、Trust。
Logic负责提供公理和推理规则，而Logic一旦建立，便可以通过逻辑推理对资源、资源之间的关系以及推理结果进行验证，证明其有效性。通过Proof交换以及数字签名，建立一定的信任关系，从而证明语义Web输出的可靠性以及其是否符合用户的要求。
B. 分布式Web服务器架构
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于 ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦，因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步，差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及，像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易
C. www采用什么体系结构目前的web服务器提供哪些功能
目前常用的Web服务器有IIS和Apache等；其中IIS可能是最容易懂的。Web服务器嘛主要就提供网站服务功能了哈，如用户登陆、在线支付、等等。采用的B/S架构。
D. 简述SOA软件体系结构的基本概念,简述Web Service的主要协议
Web服务（Web Services）在很多人眼里还是个十分神秘的概念，究其根源，我想主要是由于Web服务被宣传得很多，但实际应用却鲜见，给人一种很复杂和难以理解的感觉。另外，Web服务是基于XML的，不少人对XML本身也缺乏理解，虽然他们可能每天都在写XML格式的配置文件。
提到Web服务的起源就一定要先说一说SOA（面向服务的体系结构），和很多具有划时代意义的软件技术一样，SOA的出现根本上也是为了解决软件危机问题。做过项目的人都有过这种感受，随着项目推进，模块之间关系越来越紧密，任何一个小的修改都可能引起整个系统的不稳定，而客户需求偏偏总是在改变，结果是项目以差不多失败的结果告终。
从（分布式）软件发展的趋势来看，C/S->B/S->SOA，模块之间的耦合度是由紧密到松散的，松散的耦合有利于修改。我们常说的各种设计模式，其中大部分不也是为了降低类之间的耦合度吗。
这里我引用一下IBM网站上对SOA的定义：面向服务的体系结构（service-oriented architecture）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。（全文）
说得通俗一点就是，系统中分为三种角色：服务提供者、服务使用者和注册中心，提供者发布服务到注册中心，使用者通过注册中心发现所需服务，然后与该服务的提供者绑定，并调用服务。
那么Web服务和SOA是什么关系呢，可以这样说，Web服务是SOA的一种实现，有点像Tomcat和JSP/Servlet规范的关系。SOA是一个比较虚的概念，例如它只提出定义一些接口和协议，那么这些东西具体应该怎样定义呢，Web服务就将它们具体化了：Web服务使用的协议都是基于XML的；SOA只说应该有三种角色，而Web服务里这三种角色都有具体的实现方式。看到这里你应该会问，那么SOA还有哪些实现呢？CORBA、DCOM和J2EE都可以算是，但我认为它们不能算很纯粹，至少它们并不都具有中立的协议。
现在该用一个具体的例子来说明一下Web服务了，假设我们的系统中需要一项功能是查询当地的天气情况（世界时间、货币汇率等等，都一样），显然我们不会自己做一个从气象部门数据库中查找数据的程序，这需要很多手续也没有必要，更要命的是，这样做会增加我们与气象部门的耦合度。试想某一天气象部门的数据库结构改变了，我们将不得不修改自己的代码，如果他们忘记通知我们这一改变，想象一下客户会看到什么？
为了利用Web服务，我们从某一注册中心查找和天气有关的服务，在结果中也许我们会选择收费较低，或者收费稍高但更稳定和准确的服务。从注册中心我们能够得到所选服务的完整描述，其中包含了各种数据类型和调用方式，利用这些信息，可以使用工具生成这些必要的类，以及客户端Stub，利用这个Stub就可以调用远程的Web服务了。在我们的例子中，调用后服务提供者会返回一个含有结果的消息，在我们的系统中可以从这个消息里得到所要的结果，并显示给客户。这样就形成一个完整的Web服务调用。这种调用方式被称为静态调用，因为在Stub里服务提供者的地址（被称为调用端点endpoint）是写定的，还有另外一种方式被称为动态调用，以后会讲到。
那么Web服务和以前的RPC（远程过程调用）有什么分别呢？RPC通常要求调用者和被调用者是同构的，即使用同样的语言编写，而Web服务没有这个要求（诀窍在于使用了XML封装消息），这就大大增加了灵活程度；另外，Web服务的调用除这种类似RPC的方式外，还可以是基于消息的方式，服务使用者可以只接收消息，或是只发送消息，在一些应用中这种方式十分有用。
内容总结一下就是：Web服务是SOA的实现，Web服务不是RPC。
E. 什么是web五层结构
就是B/W/C/D/C结构
B: Browser; W: Web Server; C: CRUBA Server; D: Database; C: Client
传统的Web数据库B/W/D结构也逐渐暴露出了许多不足：
（1）由于浏览器只是为了进行Web浏览而设计的，当其应用于Web应用系统时，许多功能不能实现或实现起来比较困难。比如：通过浏览器进行大量的数据的录入，或进行报表答应都是非常困难和不便的。
（2）复杂应用构造困难。虽然可以用ActiveX，Java等技术开发较为复杂的应用，但是相对于发展已经非常成熟C/S的一系列应用工具来说，这些技术的开发复杂，并没有完全成熟的技术供使用。
（3）Web Server成为Database的唯一的客户端，所有对数据库的连接都通过该服务器实现，Web服务器同时要处理与客户请求及数据库服务器的连接，当访问量大时，Server负载过重。
2.1 Web数据库的五层体系结构
正是由于B/W/D结构自身具有的这些弱点，为了改善其不足，在其基础上，提出了一新的结构体系—— B/W/C/D/C结构
五层体系结构有如下优点：
（1）充分发挥了B/S结构与C/S结构系统的优势，扬长避短。充分考虑用户利益，保证浏览查询者操作方便的同时也使得系统的更新简单，维护简单灵活，易于操作。
（2）信息发布端采用B/S结构，保持了瘦客户端的优点。装入客户机的软件可以采用统一的WWW浏览器。而且由于WWW浏览器和网络综合服务器都基于工业标准，可以在所有平台上工作。客户机或服务器的操作系统也可以完全统一，客户端存在的各种问题迎刃而解。
（3）数据库端采用C/S结构，通过ODBC/JDBC进行连接。这一部分的功能只涉及到系统维护，数据更新等，客户端很少，不存在完全采用C/S结构带来的客户端维护工作量大等缺点。并且，在客户端上可以构造非常复杂的应用，界面友好灵活，易于操作，能解决许多B/S存在的固有的缺点。
（4）许多原有的基于C/S结构的系统可以非常容易地升级到五层体系结构，只需要开发用于发布的WWW界面，可以保留原有的C/S结构的某些子系统，充分地利用现有资源。使得现有系统或资源无需进行大的改造即可以连接使用，保护了用户以往的投资。
（5）由于应用了CORBA服务器，对数据库的访问提供了一个统一的接口，使CORBA服务器具有共享性，形成了模块性更强的结构，更易扩充，升级。
F. 简述web技术的结构
它是超级文本的简称。 二、超媒体（hypermedia） 超媒体是超文本（hypertext）和多媒体在信息浏览环境下的结合。它是超级媒体的简称。用户不仅能从一个文本跳到另一个文本，而且可以激活一段声音，显示一个图形，甚至可以播放一段动画。 Internet采用超文本和超媒体的信息组织方式，将信息的链接扩展到整个Internet上。Web就是一种超文本信息系统，Web的一个主要的概念就是超文本连接，它使得文本不再象一本书一样是固定的线性的。而是可以从一个位置跳到另外的位置。可以从中获取更多的信息。可以转到别的主题上。想要了解某一个主题的内容只要在这个主题上点一下，就可以跳转到包含这一主题的文档上。正是这种多连接性把它称为Web。 三、超文本传输协议（HTTP） Hypertext Transfer Protocol超文本在互联网上的传输协议。 当你想进入万维网上一个网页, 或者其他网络资源的时候，通常你要首先在你的浏览器上键入你想访问网页的统一资源定位符（UniformResourceLocator)，或者通过超链接方式链接到那个网页或网络资源。这之后的工作首先是URL的服务器名部分，被名为域名系统的分布于全球的因特网数据库解析，并根据解析结果决定进入哪一个IP地址(IP address)。 接下来的步骤是为所要访问的网页，向在那个IP地址工作的服务器发送一个HTTP请求。在通常情况下，HTML文本、图片和构成该网页的一切其他文件很快会被逐一请求并发送回用户。 网络浏览器接下来的工作是把HTML、CSS和其他接受到的文件所描述的内容，加上图像、链接和其他必须的资源，显示给用户。这些就构成了你所看到的“网页”。 大多数的网页自身包含有超链接指向其他相关网页，可能还有下载、源文献、定义和其他网络资源。像这样通过超链接，把有用的相关资源组织在一起的集合，就形成了一个所谓的信息的“网”。这个网在因特网上被方便使用，就构成了最早在1990年代初蒂姆·伯纳斯-李所说的万维网。 传统的Web数据库系统体系结构 传统的Web数据库系统一般实现Web数据库系统的连接和应用可采取两种方法，一种是在Web服务器端提供中间件来连接Web服务器和数据库服务器，另一种是把应用程序下载到客户端并在客户端直接访问数据库。中间件负责管理Web服务器和数据库服务器之间的通信并提供应用程序服务，它能够直接调用外部程序或脚本代码来访问数据库，因此可以提供与数据库相关的动态HTML页面，或执行用户查询，并将查询结果格式化成HTML页面。通过Web服务器返回给Web浏览器。最基本的中间件技术有通过网关接口CGI和应用程序接口API两种。 （一）、基于通用网关接口CGI CGI是WWW服务器运行时外部程序的规范，按照CGI编写的程序可以扩展服务器的功能，完成服务器本身不能完成的工作，外部程序执行时间可以生成HTML文档，并将文档返回WWW服务器。CGI应用程序能够与浏览器进行交互作用，还可以通过数据库的API与数据库服务器等外部数据源进行通信，如一个CGI程序可以从数据库服务器中获取数据，然后格式化为HTML文档后发送给浏览器，也可以将从浏览器获得的数据放到数据库中。几乎使用的服务器软件都支持CGI，开发人员可以使用任何一种WWW服务器内置语言编写CGI，其中包括流行的C、C、VB和Delphi等。 从体系结构上来看，用户通过Web浏览器输入查询信息，浏览器通过HTTP协议向Web服务器发出带有查询信息的请求，Web服务器按照CGI协议激活外部CGI程序，由该程序向DBMS发出SQL请求并将结果转化为HTML后返回给Web服务器。再由Web服务器返回给Web浏览器。这种结构体现了客户/服务器方式的三层模型，其中Web服务器和CGI程序实际起到了HTML和SQL转换的网关的作用。CGI的典型操作过程是：分析CGI数据；打开与DBMS的连接；发送SQL请求并得到结果；将结果转化为HTML；关闭DBMS的连接；将HTML结果返回给Web服务器。 基于Web的数据库访问利用已有的信息资源和服务器。其访问频率大，尤其是热点数据。但其主要的缺点是：①客户端与后端数据库服务器通信必须通过Web服务器，且Web服务器要进行数据与HTML文档的互相转换，当多个用户同时发出请求时，必然在Web服务器形成信息和发布瓶颈。②CGI应用程序每次运行都需打开和关闭数据库连接，效率低，操作费时；③CGI应用程序不能由多个客户机请求共享，即使新请求到来时CGI程序正在运行，也会启动另一个CGI应用程序，随着并行请求的数量增加，服务器上将生成越来越多的进程。为每个请求都生成进程既费时又需要大量内存，影响了资源的使用效率，导致性能降低并增加等待时间；④由于SQL与HTML差异很大，CGI程序中的转换代码编写繁琐，维护困难；⑤安全性差，缺少用户访问控制，对数据库难以设置安全访问权限；⑥HTTP协议是无状态且没有常连接的协议，DBMS事务的提交与否无法得到验证，不能构造Web上的OLTP应用。 （二）、基于服务器扩展的API 为了克服CGI的局限性，出现的另一种中间件解决方案是基于服务器扩展API的结构。与CGI相比，API应用程序与Web服务器结合得更加紧密，占用的系统资源也少得多，而运行效率却大大提高，同时还提供更好的保护和安全性。 服务器API一般作为一个DLL提供，是驻留在WWW服务器中的程序代码，其扩展WWW服务器的功能与CGI相同。WWW开发人员不仅可以API解决CGI可以解决的一切问题，而且能够进一步解决基于不同WWW应用程序的特殊请求。各种API与其相应的WWW服务器紧密结合，其初始开发目标服务器的运行性能进一步发掘、提高。用API开发的程序比用CGI开发的程序在性能上提高了很多，但开发API程序比开发CGI程序要复杂得多。API应用程序需要一些编程方面的专门知识，如多线程、进程同步、直接协议编程以及错误处理等。目前主要的WWWAPI有Microsoft公司的ISAPI、Netscape公司的NSAPI和OReily公司的WSAPI等。使用ISPAI开发的程序性能要优于用CGI开发的程序，这主要是因为ISAPI应用程序是一些与WWW服务器软件处于同一地址空间的DLL，因此所有的HTTP服务器进程能够直接利用各种资源这显然比调用不在同一地址空间的CGI程序语句要占用更少的系统时间。而NSAPI同ISAPI一样，给WWW开发人员定制了NetscapeWWW服务器基本服务的功能。开发人员利用NSAPI可以开发与WWW服务器的接口，以及与数据库服务器等外部资源的接口。 虽然基于服务器扩展API的结构可以方便、灵活地实现各种功能，连接所有支持32位ODBC的数据库系统，但这种结构的缺陷也是明显的：①各种API之间兼容性很差，缺乏统一的标准来管理这些接口；②开发API应用程序也要比开发CGI应用复杂得多； ③这些API只能工作在专用Web服务器和操作系统上。 （三）、基于JDBC的Web数据库技术 Java的推出，使WWW页面有了活力和动感。Internet用户可以从WWW服务器上下载Java小程序到本地浏览器运行。这些下载的小程序就像本地程序一样，可独立地访问本地和其他服务器资源。而最初的Java语言并没有数据库访问的功能，随着应用的深入，要求Java提供数据库访问功能的呼声越来越高。为了防止出现对Java在数据库访问方面各不相同的扩展，JavaSoft公司指定了JDBC，作为Java语言的数据库访问API。 采用JDBC技术，在JavaApplet中访问数据库的优点在于：直接访问数据库，不再需要Web数据库的介入，从而避开了CGI方法的一些局限性；用户访问控制可以由数据库服务器本地的安全机制来解决，提高了安全性；JDBC是支持基本SQL功能的一个通用低层的应用程序接口，在不同的数据库功能的层次上提供了一个统一的用户界面，为跨平台跨数据库系统进行直接的Web访问提供了方案。从而克服了API方法一些缺陷；同时，可以方便地实现与用户地交互，提供丰富的图形功能和声音、视频等多媒体信息功能。 JDBC是用于执行SQL语句的Java应用程序接口API，由Java语言编写的类和接口组成。Java是一种面向对象、多线程与平台无关的编程语言，具有极强的可移植性、安全性和强健性。JDBC是一种规范，能为开发者提供标准的数据库访问类和接口，能够方便地向任何关系数据库发送SQL语句，同时JDBC是一个支持基本SQL功能的低层应用程序接口，但实际上也支持高层的数据库访问工具及API。所有这些工作都建立在X/Open SQL CLI基础上。JDBC的主要任务是定义一个自然的Java接口来与X/OpenCLI中定义的抽象层和概念连接。JDBC的两种主要接口分别面向应用程序的开发人员的JDBC API和面向驱动程序低层的JDBC DriverAPI。JDBC完成的工作是：建立与数据库的连接；发送SQL语句；返回数据结果给Web浏览器。
G. 如何读懂Web服务的系统架构图
大数据数量庞大，格式多样化。大量数据由家庭、制造工厂和办公场所的各种设备、互联网事务交易、社交网络的活动、自动化传感器、移动设备以及科研仪器等生成。它的爆炸式增长已超出了传统IT基础架构的处理能力，给企业和社会带来严峻的数据管理问题。因此必须开发新的数据架构，围绕“数据收集、数据管理、数据分析、知识形成、智慧行动”的全过程，开发使用这些数据，释放出更多数据的隐藏价值。
一、大数据建设思路
1）数据的获得
四、总结
基于分布式技术构建的大数据平台能够有效降低数据存储成本，提升数据分析处理效率，并具备海量数据、高并发场景的支撑能力，可大幅缩短数据查询响应时间，满足企业各上层应用的数据需求。
H. 架构Web Service:什么是Web服务
松散耦合，这一特征也是源于对象/组件技术，当一个Web服务的实现发生变更的时候，调用者是不会感到这一点的，对于调用者来说，只要Web服务的调用界面不变，Web服务的实现任何变更对他们来说都是透明的，甚至是当Web服务的实现平台从J2EE迁移到了.NET或者是相反的迁移流程，用户都可以对此一无所知。对于松散耦合而言，尤其是在Internet环境下的Web服务而言，需要有一种适合Internet环境的消息交换协议
。而XML/SOAP正是目前最为适合的消息交换协议。
使用协约的规范性，这一特征从对象而来，但相比一般对象其界面规范更加规范化和易于机器理解。首先，作为Web服务，对象界面所提供的功能应当使用标准的描述语言来描述(比如WSDL)；其次，由标准描述语言描述的服务界面应当是能够被发现的，因此这一描述文档需要被存储在私有的或公共的注册库里面。同时，使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到Web服务的聚合、跨Web服务的事务、工作流等，而这些又都需要服务质量(QoS)的保障。其次，我们知道安全机制对于松散耦合的对象环境的重要性，因此我们需要对诸如授权认证、数据完整性(比如签名机制)、消息源认证以及事务的不可否认性等运用规范的方法来描述、传输和交换。最后，在所有层次的处理都应当是可管理的，因此需要对管理协约运用同样的机制。
使用标准协议规范，作为Web服务，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。这些标准协议具有完全免费的规范，以便由任意方进行实现。一般而言，绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。
高度可集成能力。由于Web服务采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，无论是CORBA、DCOM还是EJB都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高的可集成性。
Web Service "Stack"在前一节中，我们已经了解到为了完成在松散耦合的环境下的对象访问，以及在基本对象访问之上的诸如事务、工作流、安全机制等。实现一个完整的Web服务体系需要有一系列的协议规范来支撑。
其中，绿色部分是先前已经定义好的并且广泛使用的传输层和网络层的标准：IP、HTTP、SMTP等。而蓝色部分是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现/集成协议UDDI，以及服务工作流描述语言WSFL。而橙色部分描述的是更高层的待开发的关于路由、可靠性以及事务等方面的协议。黄色部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成。
首先，这些协议本身都是简单的，无论是HTTP, FTP等传统的TCP/IP系统的网络协议，还是SOAP, WSDL, UDDI, WSFL等基于XML的协议，他们设计原则中的一个最重要点就是力求简单性。相信大家如果对XML、SOAP等有深入了解的话，一定会深深体会这一点。
其次，一个可以使用的Web服务应当按照需要选用若干层次的功能，而无需所有的特性。比如在目前状况下，一个简单应用可能只要使用WSDL/SOAP就可以架构一个符合规范的Web服务了。
最后，所有的机制完全是基于现有的技术，并没有创造一个完全的新体系。无论是IPv4、HTTP、FTP这些现有的网络协议，还是SOAP、WSDL等这些基于XML而定义的协议都是遵循着一个原则：继承原有的被广泛接受的技术，这样才能使得Web服务被广泛接受。
Web服务的类别综合当今的Web应用以及Web服务的特点，我们认为Web服务实施的领域可以分为四类：Business-Oriented Web Service: 该类服务针对的是那些面向企业应用服务，包括企业内部的ERP系统，企业间的SCM/CRM等系统。当这些系统以Web服务的形式在网络(Internet和intranet)中出现时，企业内的应用集成将更未容易，而在企业间的众多合作伙伴的系统对接也将不再是无法完成的任务。目前现有的解决方案和产品的提供商有Bowstreet、Epicentric等。
Consumer-Oriented Web Service: 此类服务针对的是那些原先的B2C的网站的改造，为这些Browser-Oriented的Web应用增加(注意是增加)了Web服务的应用界面，使得第三方的桌面工具或其自身提供的增值的桌面工具能够利用更优秀的用户界面提供跨越多个B2C服务的桌面服务。这将使得用户使用Internet更为方便，能够获得更加便捷的服务。比如我们完全就可以在个人理财桌面系统中集成(调用)Internet上的股票价格查询Web服务、机票预定Web服务等，使得个人理财应用的自动化程度更高。
Device-Oriented Web Service: 此类服务的使用终端一般是手持设备和日用家电，对于前者而言，可以在不用修改网络服务的体系架构的前提下，令先前的网络服务支持除PC以外的各种终端，比如Palm、PocketPC、手机等。如此，那些天气预报服务、Email服务、主动信息服务等将更为有效和便捷。而后者对于日用家电，则可能是一个市场的启动期，有了Web服务作为基础框架，智能型的日用家电将真正获得标准的支持，从而有了广泛使用的可能。
System-Oriented Web Service: 一些传统意义上的系统服务，比如用户权限认证，系统监控等，如果被迁移到全球范围的Internet上，或者企业内部的intranet上，其作用范围将从单个系统或局部网络拓展到整个企业网络或整个Internet。如此，基于同一系统服务的不同应用将得以在整个Internet环境中部署，譬如跨国企业的所有在线服务可以使用同一个用户权限认证Web服务。
Web服务: 当今的技术最亮点以上这幅图是Gartner Group在研究了所有IT主流时尚技术的发展道路后，作出的抽象模型。Y轴表明技术的受关注程度，而X轴则表示技术的应用的成熟度。每一项技术在从出现到成熟的整个过程都将沿着图中的曲线前进，而且典型地，都将被划分为五个阶段：技术显现：一门技术被发明或定义之后，开始进入公众的视野；
不断膨胀的期望期：由于该项技术的划时代的突破，使人们对这项技术有着无比美好的想象和期望，这一阶段类似"网络的泡沫器"；
希望破灭之后的醒悟期：由于每项技术都不是万能的，真正获得使用仍然需要务实的加以应用研究，因此此时人们发现这项技术似乎并没有期望中那么有用，这一阶段类似"网络的泡沫破灭"；
豁然开朗的应用发展期：经过了一个阶段的开发和研究，该项技术终于走上了良性发展的轨道，越来越多的人接受并使用了该项技术；
大量的工业化生产期：该项技术成为业界主流，大量应用在具体的环境中。
I. .Web服务的原理是什么，描述一下Web服务的基本架构和主要技术。
提供一种统一的、面向组件的编程模型。
Web Service的体系结构描述了三个角色（服务提供者、服务请求者、服务代理者）以及三个操作（发布、查找、绑定）。
Web主要技术特征：在传输层和网络层采用TCP/IP协议，缺省断口的80；在应用层采用HTTP协议，使用HTML文档实现信息交互；基本上运行在C/S模式下。
J. 在Web应用程序体系结构中，（）服务用来保证Web站点和应用程序的数据完整性。（选择一项）
d、证书