软件架构乱d：问题域及其解决方法

一 什么是架构 和架构相关的几个问题域架构需要解决的非业务问题域包括如下 A 系统目标 系统性能 稳定性 B 项目目标 开发成本 质量C 项目过程 需求的不确定性和开发过程的团队协作性不同的问题域 解决之道也不相同！而同一问题域的不同层次的要求 解决之道也不尽相同

什么是架构架构到底是啥 愚以为下面的这段英文描述的很清楚

That s like asking what is culture Culture is the way you do things in a group of people Architecture is the way you do things in a sofare product You could argue by ogy then that architecture is to a sofare product as culture is to a team It is how that team has established and chosen its conventions

Which leads us inevitably to the question of goodness How do you know if an architecture is good Consider an architecture that isn t built using a strong domain model and instead relies heavily on stored procedures That might be OK or it might not be OK You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures right So an architecture is some reasonable regularity about the structure of the system the way the team goes about building its sofare and how the sofare responds and adapts to its own environment How well the architecture responds and adapts and how well it goes through that construction process is a measure of whether that architecture is any good

The system architecture determines how hard or easy it is to implement a given feature Good architectures are those in which it is considered easy to create the features desired In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied

The definition of goodness has to be related to fitness for purpose Is this glove good I don t know What are you doing with the glove Are you throwing snowballs cooking barbeques or playing golf There s a set of changes that are going to occur to a sofare system over time Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy If they are then it s probably a good architecture

架构的背后为了实现架构的目标涉及到以下三个方面 技术 组织和过程 这里举例说明 ) 技术对开发效率和运行性能 以及组织和过程的影响 案例A．映射的问题 公司产品的一个重要需求是根据客户输入 映射到PDF文件上 技术上整体实现需要四个步骤 在PDF文件上画好所有的数据域 通过读入一个XML映射文件 获得运行数据并生成FDF 合并FDF和PDF生成目标文件 后两步工作都由代码自动化了 因而实现的主要工作在于前两步

在第一个实现版本里 XML映射文件的DTD太简单 致使一个xml文件至少在 行左右 同时xml文件太verbose了 这样的结果直接导致运行系统在峰值时 由于XML消耗了大量内存 G的内存根本吃不消 同时对XML解析执行使用了CPU的大量时间 导致开发人员需要做大量的工作 开发效率降低了 通常需要尽一周才能完成一个xml文件 员工都不愿意做 也导致开发过程的漫长 开发部门对于BA部门和ST部门的要求反应变的缓慢

在第二个版本的实现中 重新实现了DTD 加入了大量的关键字同时也消除了verbose 大量的缩小了XML大小 从 多行减低到 多行 不仅减低了内存使用 提高执行效率 也提高了开发效率 基本只要一天就可以完成一个映射文件 同时对BA部门和ST部门的反应也快了

案例B 脚本的问题 产品在web层提供了脚本支持 出于方便开发的目的 但是没有对脚本的环境限制 脚本可以做系统程序的大部分工作 导致开发人员偷懒 在web层混入了大量业务逻辑代码 最终造成业务逻辑分散而不可控制

) 组织结构对技术 开发效率和应变能力的影响 案例A 部门的分工问题 开发部门根据不同的职责 分成A B和C等数个小组 大部分开发中互不相干 但也有时候 需要跨组的支持 比如B要实现某个需求 需要A在一定条件在记录一个或多个信息 因为每个开发人员各自负责一部分工作 导致跨组沟通的困难 同时由于整个开发部采取任务绩效 有时间压力 加上只是一个小的要求 于是在A人员的同意下 B人员直接在A代码中写入业务逻辑 每次都是这样的小改动 不断的发展后 代码开发变凌乱

案例B 开发的历史问题 当某个开发人员写下的代码 有是问题的 接手开发人员由于文档不全以及没有测试用例 不愿意承担变化的代价 选择小修小补 这个小修小补有可能和有问题的代码混杂 导致更大的代码

) 过程对开发效率和应变能力 以及组织的影响案例A 过程的问题 开发部门的上下游部门BA部门和ST部门的合作关系 ST部门的绩效考核 考核基于发现错误的数量 导致ST为了完成任务 提出一些非正常性要求 PM部门出于部门的方便通常提出一些实现难度比较大要求 开发部门本身又存在时间压力 导致一些需求的实现本应在低一层的代码中实现的 却在高层用蹩足的方式实现

案例B 帮助系统的问题 帮助系统一开始采用一个个单独分散的静态页面 出于性能的考虑和部门负责考虑 帮助系统不断改进中 过程缺乏组织性 文件的命名规则随意 存储位置随意 造成了管理的混乱 直接的后果是页面的入口混乱和各自引用关系混乱 在帮助系统的第二版 从静态页面转成动态页面 采取统一分类和命名规则 并统一了入口 同时采取分级管理引用关系 适度冗余 虽然减低了运行性能 但提高了开发效率和可维护性

二 架构的性能问题解决讨论性能问题——嗯 一个非常神圣而高深的问题的 从我刚刚开始工作的时候 至今依然是 然而我相信 一定存在一个基本的思路和方法 我以为解决性能问题的工作还是在于分解 通过分解来确定问题域

先介绍三个公式性能问题的公式: 总处理单量 = 总处理时间/ 单笔请求处理时间 总并发数这个公式另一个写法为:总处理时间 = 单笔请求处理时间 总处理单量 / 总并发数不同的写法代表不同个关注点 适合不同类型的业务类型 一般说前一种写法代表在线请求的 后一种写法代表后台batch

也有客户给明确要求系统要支持xxx并发 这个就需要了解客户的这个并发数是如何计算得来 需要通过分析客户的业务 而通常是根据总处理单量来确定客户实际的并发数

但无论如如何 四个变量中 总处理单量和总处理时间是先被确定的 换句话说需要关注是单笔请求处理时间和并发数 也就是降低单笔请求处理时间或者增加并发数

对于单笔请求处理时间 其公式为 单笔请求处理时间 ＝ 数据计算时间 ＋ 数据读写时间＋其它技术导致时间消耗很显然降低单笔请求处理时间就需要降低三个因素消耗的时间 降低单笔请求处理时间第一原则是 只计算一次 缓存计算结果 降低数据读取时间 分三种 Global的 系统启动时加载 Long Time 可采用LRU方式cache Per operation 第一次访问加载 operation结束后丢弃 降低数据写入时间例如文件写入通过buffer一次flush 对于SQL采用batch提交（hibernate的做法）

改进计算时间 针对不同技术结构采用不同手段 让计算支持并发 提高性能 例如采用MapReduce的方式 改进算法 例如数据库中的SQL改进 减少不必要计算时间 减少其它技术原因导致的消耗如JVM的GC导致性能消耗等对于总并发数 其公式为 总并发数 ＝ 单机服务器并发能力 总并发服务器数那么如何确定那些因素需要调整呢 在于两个方面的分解

业务层面业务层面只是指通过业务行为分析 把性能问题分解为不同的部分 每个部分面临性能压力现状和目标 最终确定需要优化的问题域

业务层面分解包括 个内容: 功能 内容 时间和区域 最重要的是前三个 以ebay为例 ebay对于前端功能划分划分为 多个功能 不同的服务器处理不同的功能

内容是指内容热点 比如对于search来说 就按体育 数码 音乐等划分 不同内容有不同热点数据 以及不同搜索关键匹配 时间 时间是一个非常重要的因素 在一些特点是时间段呢 性能的要求会非常高 比如下半夜的访问点击量和白天的就有不同 对于一些batch来说 月末或者年末处理的单量就有明显的提高 比如分红险的记息 平时每天只有 单 而年末会有 w单

地点划分 不太常见 不过也有助于分配计算资源 业务层面的分析不仅是确定问题所在 还是确定优化的策略 比如有一个batch计算 执行时间比较长 而通过业务分析 发现该计算只针对特定的业务 系统全部有效单量是 w单 而符合计算要求的只有 单 只要加上一个前置判断就可以免除无谓的计算 运行时间减少数个小时(大约 秒一单)

技术层面系统建立时技术结构 通常一个系统结构如下:接入网络 Web服务器 应用服务器 以及数据库服务器 在这样结构下 要小心的分析和验证系统性能的瓶颈 需要优化Web服务器 或者提高数据库并发能力等等 这部分网上的资料非常多

三 架构的开发成本以及品质问题解决讨论架构一个重大关注点在于控制开发成本 这点很重要 因为通常讲维护成本是开发成本的 倍 降低开发成本核心 在于提高效率 这也意味着提高了开发对需求的响应时间 而时间对公司来说是重要的

提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点 好处不用说了 可以并发的工作 每个人面对的问题都简单而容易 *** 作 而与分解对应的集成 只有提供了好的集成能力 分解才成为现实 而只有分解了 才能清晰的提供业务更多适应性 分解和集成的手段分为编程语言和技术框架两个层面 所谓语言就是强框架 而框架就是弱语言

现代面向对象的语言提供如下能力 抽象和派生能力 以及接口隔离能力 实际提供两种分解和集成能力 把逻辑分解在两个层次中 而通过继承的方式把两个部分集成在一起 把逻辑的外观和实现分解在两个地方 而通过接口实现的方式把两部分集成在一起

另一种语言AspectJ或者C#语言 之后提供的特性 把流程逻辑 分解在不同的地方 而通过签名匹配 利用代码生成的方式来把几部分集成在一起

然而语言提供的集成能力 毕竟底层 而且有限 扩展起来也格外小心 因而技术框架提供另外的集成能力就格外重要 对象关联关系的分解和集成 如Spring提供容器管理能力 模块间关联关系的分解和集成 如OSGi ESB等 不同系统的类型分解和集成 如Spring利用动态代理提供的Exporter模式 流程逻辑的分解和集成 如Spring Web Flow以及jBPM 讨论完手段 现在要转身看看我们面临的问题域了 问题域可分解为两种类型 业务上和技术上 （又见分解 分而治之真是老祖宗传下的灵丹妙药啊）

业务上 问题域分解为 逻辑的纵向抽象层次 以及逻辑的横向模块分解和集成 技术上 问题域分解为 纵向的技术主题 以及横向的技术职责的分解和集成 所以通常而言 领域模型设计中 模块分解 抽象分层和职责分层都是重要手段 问题域为 流程 业务实体和计算（包括规则）

对象的抽象分解和集成 对象的依赖分解和集成（模块内和模块外） 流程的分解和集成（页面流 工作流以及计算流程） 进程边界 用户请求重定向 以及业务数据持久化等 B 通常语言做为架构的基础引入和更换是有巨大风险的 而通过提供强大的框架能力 框架尽可能多的完成技术问题 并通过元数据 模式以及约定降低业务和框架的耦合 避免因为框架升级带来不必要的成本

从技术手段上 提高开发效率的另外两个手段是代码生成和类库引用 但代码生成和类库引用 都只解决了逻辑的分解能力 没有提供集成能力 所以一般情况下需要提供框架集成 尤其代码生成需要在系统的最外层 避免集成带来的问题

lishixinzhi/Article/program/net/201311/15671

host-base：基于主机
lan-base：基于局域网
lan-free：基于SAN
server-free：基于SAN
LAN-FREE
环境：RS6000+FASTT700+3583带库,所谓LAN-free，是指数据不经过局域网直接进行备份，即用户只需将磁带机或磁带库等备份设备连接到SAN中，各服务器就可把需要备份的数据直接发送 到共享的备份设备上，不必再经过局域网链路。由于服务器到共享存储设备的大量数据传输是通过SAN网络进行的，局域网只承担各服务器之间的通信(而不是数 据传输)任务。
LAN_FREE是专门用于SAN环境下的备份,可以使备份的数据直接通过SAN的链路从备份客户端(AIX主机)到备份设备(磁带机,支持光纤),有别 于传统通过LAN链路的备份方式,这样可以不占用以太网络的带宽,一般要求硬件设备支持光纤存储(磁带机,阵列),需要通过SAN交换机(2109等)设 备将这些设备连接起来,软件要求TSM,和TSM对LAN_FREE支持的AGENT数据库可用TDP。
下图展示了Lan Free备份的方案架构图:
在这里插入描述
SERVER-FREE
SAN Server-Free备份 LAN Free备份对需要占用备份主机的CPU资源，如果备份过程能够在SAN内部完成，而大量数据流无需流过服务器，则可以极大降低备份 *** 作对生产系统的影响。SAN Server-Free备份就是这样的技术。
在这里插入描述
一、备份的概念
备份顾名思义，就是将数据以某种形式保存下来，备份的根本目的在于恢复，在这些数据丢失、毁坏和受到威胁的时候，使用数据的备份来恢复数据。虽然备份的定 义可能很简单，不过具体实施存储系统的备份却可能是一份艰巨的任务，其中包含了许多可以预见的以及不易预见的需要考虑的因素。
二、备份与拷贝、归档的区别
备份不能仅仅通过拷贝完成，因为拷贝不能留下系统的注册表等信息；而且也不能留下历史记录保存下来，以做追踪；当数据量很大时，手工的拷贝工作又是何其麻 烦。备份=拷贝+管理。管理包括备份的可计划性、磁带机的自动化 *** 作、历史记录的保存以及日志记录等等。正如生命周期理论将在线数据分级为在线和近线数据 一样，离线数据亦可分为备份与存档数据，以降低投资和运维成本。
存档的目的是将需要长期备查或转移到异地保存/恢复的数据存放到可移动存储介质上。严格意义上讲，存档的目的不是为了保障数据安全，而只是为了实现数据仓 储。如果说备份相当于桌头的字典，工作时会经常翻用，存档则好像日常工作中生成的一些具长期保存价值的文字资料，被转移到书架上或档案馆里备查。
三、常规备份的实现方式
通常一套完整的备份系统包含备份软件、磁带机/磁带库、和备份服务器，具体的备份策略的制定、备份介质的管理以及一些扩展功能的实现，都是由备份软件来最 终完成的。在备份服务器上安装备份软件的服务器端，在应用服务器端安装备份软件的客户端代理，如果是数据库应用还需要相应的数据库接口程序，客户端代理软 件和服务器端软件协调工作，按照预先制定的备份策略自动或手动的将数据备份到磁带上。然而一个具有一定规模的数据中心的数据备份要涉及到多种UNIX平台 和不同的数据库类型，可以想象每天的备份工作对于管理员来说都是一个挑战。
备份策略制定是备份工作的重要部分。一般来说需要备份的数据存在一个2/8原则，即20%的数据被更新的概率是80%。这个原则告诉我们，每次备份都完整的复制所有数据是一种非常不合理的做法。事实上，真实环境中的备份工作往往是基于一次完全备份之后的增量或差量备份。
完全备份很好理解，即把所有数据进行一次完整的备份，当进行恢复的时候只需要一盘磁带；
增量备份是只有那些在上次完全备份或者增量备份后被修改了的文件才会被备份，如下图，优点是备份数据量小，需要的时间短，缺点是恢复的时候需要多盘磁带，出问题的风险较大，
差量备份是备份那些自从上次完全备份之后被修改过的文件，如下图，因此从差量备份中恢复速度是很快的，因为只需要两份磁带（最后一次完全备份和最后一次差量备份），缺点是每次备份需要的时间较长。
备份窗口是在进行备份 *** 作时，应用系统可以接受的最长备份时间，对于某些5X8类型的非关键应用备份窗口可以很大，但是对于7X24小时的应用备份窗口就会很小。
四、LAN Free和Serverless备份
所谓LAN Free Backup顾名思义，就是指释放网络资源的数据备份方式。
在SAN架构中，备份服务器向应用服务器发送指令和信息，指挥应用服务器将数据直接从磁盘阵列中备份到磁带库中。在这个过程中，庞大的备份数据流没有流经 网络，为网络节约了宝贵的带宽资源。在NAS架构中，情形十分类似，磁带库直接连接在NAS文件服务器上，备份服务器通过NDMP协议，指挥NAS文件服 务器将数据备份到磁带库中。细心观察之下会发现，这两种方式虽然都节约了网络资源，但却增加了服务器的工作负荷，缺点是价格非常昂贵，大多数备份软件的 LAN Free功能选项都需要用户付出高昂的价格。
Serverless Backup技术是以全面的释放网络和服务器资源为目的的，技术核心就是在SAN的交换层实现数据的复制工作，这样备份数据不仅无需经过网络，而且也不必 经过应用服务器的总线，完全的保证了网络和应用服务器的高效运行。但是现实情况却没有这么理想，Serverless Backup技术目前只能停留在纸面上，实际实施效果很差，完全不需要主机干预还不现实。
存储基础知识（八）：备份技术（下）
一、主流备份软件
备份软件厂商中头把交椅当属Veritas公司。这家公司经过近几年的发展和并购，在备份软件市场已经占据了四成左右的份额。其备份产品主要是两个系列 ——高端的NetBackup和低端的Backup Exec。其中NetBackup适用于中型和大型的存储系统，可以广泛的支持各种开放平台。NetBackup还支持复杂的网络备份方式和LAN Free的数据备份，其技术先进性是业界共同认可的。
Backup Exec是原Seagate Soft公司的产品，在Windows平台具有相当的普及率和认可度，微软公 司不仅在公司内部全面采用这款产品进行数据保护，还将其简化版打包在Windows *** 作系统中，我们现在在Windows系统中使用的“备份”功能，就是 OEM自Backup Exec的简化版。2000年初，Veritas收购了Seagate Soft之后，在原来的基础上对这个产品进一步丰富和加强，现在，这款产品在低端市场的占用率已经稳稳的占据第一的位置。
Legato公司是备份领域内仅次于Veritas公司的主要厂商。作为专业的备份软件厂商，Legato公司拥有着比Veritas公司更久的历史，这 使其具有了相当的竞争优势，一些大型应用的产品中涉及到备份的部分都会率先考虑与Legato的接口问题。而且，像Oracle等一些数据库应用干脆内置 集成了Legato公司的备份引擎。这些因素使得Legato公司成为了高端备份软件领域中的一面旗帜。在高端市场这一领域，Legato公司与 Veritas公司一样具有极强的技术和市场实力，两家公司在高端市场的争夺一直难分伯仲。
Legato公司的备份软件产品以NetWorker系列为主线，与NetBackup一样，NetWorker也是适用于大型的复杂网络环境，具有各种 先进的备份技术机制，广泛的支持各种开放系统平台。值得一提的是， NetWorker中的Cellestra技术第一个在产品上实现了Serverless Backup的思想。仅就备份技术的先进性而言，Legato公司是有实力可以挑战任何强大对手的。
除了Veritas和Legato这备份领域的两大巨头之外，IBM Tivoli也是重要角色之一。其Tivoli Storage Manager产品是高端备份产品中的有力竞争者。与Veritas的NetBackup和Legato的NetWorker相比，Tivoli Storage Manager更多的适用于IBM主机为主的系统平台，但其强大的网络备份功能觉对可以胜任任何大规模的海量存储系统的备份需要。
CA公司是软件领域的一个巨无霸企业，虽然主要精力没有放在存储技术方面，但其原来的备份软件ARCServe仍然在低端市场具有相当广泛的影响力。近年 来，随着存储市场的发展，CA公司重新调整策略，并购了一些备份软件厂商，整合之后今年推出了新一代备份产品——BrightStor，这款产品的定位直 指中高端市场，看来CA公司誓要在高端市场与Veritas和Legato一决雌雄。
二、带机、带库厂商及产品
备份设备的生产厂家很多，每个厂家都有着较长的产品线，由于篇幅所限，我们不可能一一列举。这里主要介绍那些国际知名的、国内有影响力的带机和带库原厂商 及其主打产品。目前，带机正在朝快的数据传输速度和高的单盘磁带存储容量方向发展，具有主流驱动技术的带机厂商包括Quantum、Exabyte和 Sony等。
Quantum带机在中档产品中占据了市场大部分份额，但其中很大一部分走了OEM的销售渠道。其自动加载机SuperLoader可将多个备份目标集中 到一个共享的自动系统中，降低处理成本，而基于磁盘（备份介质是磁盘）又具有磁带海量特性的近线备份设备DX30可显著缩短备份与恢复时间。
Exabyte的磁带驱动技术包括8mm Mammoth和VXA技术，VXA是定位低端的新的磁带技术，它以包的格式读写数据，并可对磁带上的数据记录区进行无空隙扫描，具有高质量、高可靠性、低成本等性能特点。其中VXA－1带机专为苹果机设计的存储方案；VXA－2同样具有较高的性价比，并具有12MB/s传输速率及160GB容量，与VXA－1向下兼容。
这里我们有必要讲一讲Sony的基于AIT技术的带机产品：AIT－1、AIT－2和AIT－3，其中AIT－3是高性能和大容量的新存储方案，容量（未 压缩）为100GB，速率为12MB/s，而且能够与AIT－1、AIT－2完全读和写逆向兼容，并具有分层磁头、创新性的磁带内存储器(MIC) 驱动器接口系统等多项专利技术，提高磁轨密度和存储速度。
磁带库厂商相对品牌较多，用户的选择空间也更大一些。目前主流的磁带库厂商主要有STK，Quantum，Exabyte和IBM等。
在带库厂商中，市场份额最大的当属美国存储技术公司（StorageTek，STK）。STK目前最主要的产品线是L系列，包括L20、L40、L80、 L180、L700、L5500，从最小20磁带槽位到最大5500磁带槽位。在其入门级产品上，支持LTO、DLT和SuperDLT等开放技术，只有 在高端产品上才同时支持其自身拥有的9840、9940驱动技术。
Quantum拥有DLT、SuperDLT技术，其用户基础和发展前景都很好。其P系列的主打产品P4000和P7000分别可以支持几百槽位和十几个 驱动器，适合于企业级用户；M系列是模块化的产品，可根据用户系统需求的增长灵活扩展带库的容量和性能，M1500可从20槽位扩展到200槽 位，M2500则可从100槽位扩展到300槽位，非常适合于那些快速发展的中小企业。美中不足的是，ATL对超大容量的解决方案不是非常理想，在这一部 分市场上的竞争力较弱。
8mm是安百特（Exabyte）公司的独立技术，具有速度快、容量大、可靠性高、价廉、体积小等特点，主要用于带库，其8mm带库的智能机械臂系统可任 意存取磁带，采用模块化设计，产品线全，从VXA自动化/驱动器产品系列AutoPak230/115/110、VXA-1/1到Mammoth Tape自动化/驱动器产品系列X200/80/430M/215M/EZ17、M2/Mammoth/Eliant 820，容量从单盘（非压缩）33GB到整库12TB，涵盖由低到高的用户市场，可实现无人值守自动数据存储管理，适用于服务器备份、网络备份、自动归 档、分级存储管理及图形图像等领域。
IBM，众所周知，生产和销售所有IT类产品，当然也包括带库产品。IBM的带库和带机产品大体可分2个系列：用于IBM环境的和用于开放环境的。如 IBM的3494、3575等带库只支持其专用的驱动器，开放性差，虽然这些带库产品也支持HP、SUN等主流服务器平台，但实际上几乎只用在IBM环境 中。随着SAN技术的普及，追求开放性和互联性成为存储行业的潮流。结合LTO驱动技术的投产，IBM为其开放存储系统解决方案推出了新的带库系列—— 3583和3584。
三、备份技术新趋势
D2D2T是Disk to Disk toTape的缩写，即数据备份从磁盘阵列到磁盘库到磁带的过程。传统的磁带备份总是会带给用户以下苦恼：
1、备份速度慢，备份窗口冗长
2、备份的根本目的在于恢复，而磁带的恢复速度很慢，对于TB级的数据恢复等待时间过长
3、磁带介质受灰尘、温度、湿度影响很大，难以保证已经离线保存的磁带在需要的时候可以正常工作
4、磁带库的机械手等物理设备的故障率和磨损率相对电子元件较高
相信长期从事磁带备份工作的管理员（尤其是大数据量关键应用的磁带备份）对以上几点都会深有感触，尤其是当在线数据受到破坏，需要依靠磁带备份来恢复正常生产的时候，大家都会为能否顺利恢复数据捏一把汗。
有什么办法可以解决磁带备份固有的劣势呢？随着磁盘容量的增长价格的下降，使用磁盘备份作为磁带备份的补充甚至替代都成为可能，当然磁带体积小，便于归档 等特点是磁盘设备不具备的，因此D2D2T即磁盘到磁盘到磁带备份方式有效地中和了磁盘备份和磁带备份的优点，在线数据保存在高速磁盘阵列，备份数据首先 保存在性价比较高的SATA磁盘阵列中，然后定期将磁盘备份的数据保存到磁带上，这样既缩短了备份窗口又增强了数据恢复的可靠性。

BS架构是指浏览器/服务器架构，通常包含3层：浏览器层次作为客户端，Web服务器（或者应用服务器）作为业务处理端，数据库服务器作为数据存储端。

可以做BS架构的语言有很多，比较常见的有Java、PHP、Python，近几年NodeJS也比较流行。

一般是SAN和NAS两种体系。
网络接入存储（Network-Attached Storage，简称NAS）和存储区域网络（Storage Area Network，简称SAN）
存储区域网络（Storage Area Network，简称SAN）采用光纤通道（Fibre Channel）技术，通过光纤通道交换机连接存储阵列和服务器主机，建立专用于数据存储的区域网络。SAN经过十多年历史的发展，已经相当成熟，成为业界的事实标准（但各个厂商的光纤交换技术不完全相同，其服务器和SAN存储有兼容性的要求）。SAN存储采用的带宽从100MB/s、200MB/s，发展到目前的1Gbps、2Gbps。
网络接入存储（Network-Attached Storage，简称NAS）采用网络（TCP/IP、ATM、FDDI）技术，通过网络交换机连接存储系统和服务器主机，建立专用于数据存储的存储私网。随着IP网络技术的发展，网络接入存储（NAS）技术发生质的飞跃。早期80年代末到90年代初的10Mbps带宽，网络接入存储作为文件服务器存储，性能受带宽影响；后来快速以太网（100Mbps）、VLAN虚网、Trunk(Ethernet Channel) 以太网通道的出现，网络接入存储的读写性能得到改善；1998年千兆以太网（1000Mbps）的出现和投入商用，为网络接入存储（NAS）带来质的变化和市场广泛认可。由于网络接入存储采用TCP/IP网络进行数据交换，
NAS：用户通过TCP/IP协议访问数据，采用业界标准文件共享协议如：NFS、>它使企业能够开发、部署和集成新一代电子商务应用(如 B2B 的电子交易)，并且支持从简单的 Web 发布到企业级事务处理的商务应用。WAS 转变了企业对客户、合作伙伴及雇员之间关系的管理方式。例如您可以通过它提高站点传输数据的数量和质量，从而大幅提升您的Web应用的性能，并将扩展的应用程序与移动设备相结合，让销售队伍能够为客户提供更快捷的服务，或者构建电子市场以降低资源获取的成本。 这个平台的基础是 WebSphere Application Server ，它有三个版本，具有为满足您最严格的业务需要而设计的专业化配置。它通过一个简单的 Java引擎来驱动，当需求改变时，您可以容易地把应用程序移植到不同的平台上。
标准版：通过使用 servlet、JavaServer Page 以及 XML，快速地将静态 Web 站点转换为富有勃勃生机的动态站点。 高级版：包含高性能企业级 Java Bean 组件的服务器。 企业版：集成了 EJB 和 CORBA 技术，为构建流量高、容量大的电子商务应用提供可靠的保证。 WebSphere应用服务器架构图
基于WebSphere应用服务器在企业内部应用的核心地位，如何保证其正常高效运行就显得非常重要。 运行在WebSphere应用服务器上的应用随时可能出现性能问题，如何智能地分析这些问题是一项挑战。当关键的J2EE业务应用出现问题时，系统和服务器管理员需要尽快识别问题的原因。使用内置管理控制台进行手工分析是十分不方便的，并且需要大量的应用服务器专业知识，并且传统的监控软件在监控websphere方面存在着很大的缺点：不能监控；监控的深度和广度不够；没有清晰的可视化效果；不能监控WebSphere应用服务器的集群。
Mocha BSM对WebSphere应用服务器监控的优势 摩卡业务服务管理(Mocha Business Service Management，简称Mocha BSM)为系统管理员提供一个关于WebSphere应用服务器性能的图形化视图；通常在用户意识到问题之前即提供可快速识别和排除这些问题所需要的关键细节信息。 1．以独特的可视化方式展现WebSphere应用服务器架构、服务器和应用中的实时活动。
2．实时性能诊断 Mocha BSM以直观的图形用户界面方式提供WebSphere应用服务器集群，服务器和应用中活动和流程的细节信息，显示服务器中的活动，当问题出现时，通过这些活动可以识别出问题的根源。您可以方便的查看集群，服务器和应用组件的当前状态，如响应时间、堆使用情况、线程池、JDBC连接池、Servlet、JSP和EJB的使用情况等。从摘要信息到组件的详细信息，并且提供了直观灵活的导航功能。
3．在一个窗口中显示所有关键组件并可深入分析更为详尽的信息 。 4．以不断的状态更新和警告通知等方式突出显示有问题的地方 。 主要特点 快速安装 安装快速，无干扰。允许WebSphere应用服务器管理员立即开始监测服务器活动并在恶化之前消除潜在的性能问题。 实时的性能视图 实时显示性能，当应用处理最终用户请求的过程时，管理员可以看到问题的发展变化情况。产品按照WebSphere应用服务器的处理流程，检查集群，服务器和应用中的瓶颈。 统一的中心控制台 通过精心优化设计的控制台，可主动的发现问题，显示相关应用组件和处理流程。当资源达到危险警告值时给管理员发出警告，将J2EE资源间的连接和使用情况展现为易于理解的应用状态图。 智能的深入诊断引导分析者深入诊断，找到引起瓶颈的组件。

1 大型网站系统的特点

2 大型网站架构演化历程

21 初始阶段架构

问题：网站运营初期，访问用户少，一台服务器绰绰有余。

特征：应用程序、数据库、文件等所有的资源都在一台服务器上。

描述：通常服务器 *** 作系统使用 linux，应用程序使用 PHP 开发，然后部署在 Apache 上，数据库使用 Mysql，通俗称为 LAMP。汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

22 应用服务和数据服务分离

问题：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，一台服务器已不足以支撑。

特征：应用服务器、数据库服务器、文件服务器分别独立部署。

描述：三台服务器对性能要求各不相同：应用服务器要处理大量业务逻辑，因此需要更快更强大的 CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；文件服务器需要存储大量文件，因此需要更大容量的硬盘。

23 使用缓存改善性能

问题：随着用户逐渐增多，数据库压力太大导致访问延迟。

特征：由于网站访问和财富分配一样遵循二八定律：80% 的业务访问集中在 20% 的数据上。将数据库中访问较集中的少部分数据缓存在内存中，可以减少数据库的访问次数，降低数据库的访问压力。

描述：缓存分为两种：应用服务器上的本地缓存和分布式缓存服务器上的远程缓存，本地缓存访问速度更快，但缓存数据量有限，同时存在与应用程序争用内存的情况。分布式缓存可以采用集群方式，理论上可以做到不受内存容量限制的缓存服务。

24 使用应用服务器集群

问题：使用缓存后，数据库访问压力得到有效缓解。但是单一应用服务器能够处理的请求连接有限，在访问高峰期，成为瓶颈。

特征：多台服务器通过负载均衡同时向外部提供服务，解决单一服务器处理能力和存储空间不足的问题。

描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

25 数据库读写分离

问题：网站使用缓存后，使绝大部分数据读 *** 作访问都可以不通过数据库就能完成，但是仍有一部分读 *** 作和全部的写 *** 作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

特征：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到一台服务器上。网站利用数据库的主从热备功能，实现数据库读写分离，从而改善数据库负载压力。

描述：应用服务器在写 *** 作的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。这样当应用服务器在读 *** 作的时候，访问从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离的对应用透明。

26 反向代理和 CDN 加速

问题：中国网络环境复杂，不同地区的用户访问网站时，速度差别也极大。

特征：采用 CDN 和反向代理加快系统的静态资源访问速度。

描述：CDN 和反向代理的基本原理都是缓存，区别在于 CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器时反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

27 分布式文件系统和分布式数据库

问题：随着大型网站业务持续增长，数据库经过读写分离，从一台服务器拆分为两台服务器，依然不能满足需求。

特征：数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：分布式数据库是数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用。不到不得已时，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

28 使用 NoSQL 和搜索引擎

问题：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。

特征：系统引入 NoSQL 数据库及搜索引擎。

描述：NoSQL 数据库及搜索引擎对可伸缩的分布式特性具有更好的支持。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

29 业务拆分

问题：大型网站的业务场景日益复杂，分为多个产品线。

特征：采用分而治之的手段将整个网站业务分成不同的产品线。系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：应用之间可以通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

210 分布式服务

问题：随着业务越拆越小，存储系统越来越庞大，应用系统整体复杂程度呈指数级上升，部署维护越来越困难。由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

特征：公共业务提取出来，独立部署。由这些可复用的业务连接数据库，通过分布式服务提供共用业务服务。

3 大型网站架构模式

31 分层

大型网站架构中常采用分层结构，将软件系统分为应用层、服务层、数据层：

分层架构的约束：禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。

分层结构内部还可以继续分层，如应用可以再细分为视图层和业务逻辑层；服务层也可以细分为数据接口层和逻辑处理层。

32 分割

将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。这有助于软件的开发和维护，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

33 分布式

大于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。

分布式意味可以用更多的机器工作，那么 CPU、内存、存储资源也就更丰富，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

分布式也引入了一些问题：

常用的分布式方案：

34 集群

集群即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

集群需要具备伸缩性和故障转移机制：伸缩性是指可以根据用户访问量向集群添加或减少机器；故障转移是指，当某台机器出现故障时，负载均衡设备或失效转移机制将请求转发到集群中的其他机器上，从而不影响用户使用。

35 缓存

缓存就是将数据存放在距离最近的位置以加快处理速度。缓存是改善软件性能的第一手段。

网站应用中，缓存除了可以加快数据访问速度以外，还可以减轻后端应用和数据存储的负载压力。

常见缓存手段：

使用缓存有两个前提：

36 异步

软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，彼此影响就越小，也就更容易独立发展。

大型网站架构中，系统解耦的手段除了分层、分割、分布式等，还有一个重要手段——异步。

业务间的消息传递不是同步调用，而是将一个业务 *** 作拆分成多阶段，每个阶段间通过共享数据的方式异步执行进行协作。

异步架构是典型的生产者消费模式，二者不存在直接调用。异步消息队列还有如下特性：

37 冗余

大型网站，出现服务器宕机是必然事件。要保证部分服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。这样当某台服务器宕机是，可以将其上的服务和数据访问转移到其他机器上。

访问和负载很小的服务也必须部署 至少两台服务器构成一个集群，目的就是通过冗余实现服务高可用。数据除了定期备份，存档保存，实现 冷备份 外；为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现 热备份。

为了抵御地震、海啸等不可抗因素导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围内部署 灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。

38 自动化

大型网站架构的自动化架构设计主要集中在发布运维方面：

39 安全

4 大型网站核心架构要素

架构 的一种通俗说法是：最高层次的规划，难以改变的决定。

41 性能

性能问题无处不在，所以网站性能优化手段也十分繁多：

42 可用性

可用性指部分服务器出现故障时，还能否对用户提供服务

43 伸缩性

衡量伸缩的标准就是是否可以用多台服务器构建集群，是否容易向集群中增删服务器节点。增删服务器节点后是否可以提供和之前无差别的服务。集群中可容纳的总服务器数是否有限制。

44 扩展性

衡量扩展性的标准就是增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或很少改动，既有功能就可以上线新产品。主要手段有：事件驱动架构和分布式服务。

45 安全性

安全性保护网站不受恶意攻击，保护网站重要数据不被窃取。

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 721575865

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

在开源的Java应用服务器领域 像JBoss Tomcat及Apache的Geronimo 他们不仅仅是商业领域的领跑者 同时是技术领域的先行者 当然 所有的Java EE应用服务器的实现不尽相同 但其很多方面具有一定程度的可比性 本文对JBoss Geronimo 及Tomcat 三种开源的Java EE应用服务器 就他们的特性 部署及性能等方面进行一一比较 一         前言 当企业级的Java应用程序需要真正的应用部署时 Java EE应用服务器是必不可少的工具 研究表明 除了商业的应用服务器之外 开源的Java EE应用服务器开始成为很多Java企业级应用的最佳选择 而JBoss Tomcat及Apache的Geronimo是其中最主流的开源Java EE应用服务器 而这三者中 尽管JBoss和Tomcat并非 %的实现了Java EE 标准 但这二者占有的市场份额相对比较大 Geronimo是对Java EE 标准 %的实现 正在快速的发展 如果读者想在Java EE领域找份像样的工作 对这三种开源的应用服务器应该达到比较熟悉的程度 并能在一定程度上进行比较区分 在本文中 对这三种主流的应用服务器 就其特性 部署及性能等方面进行比较 分析了他们各自的特色对该应用服务器的重要性 当然 也提供了一些如何选择适合项目的服务器的原则及建议

二         特性比较 表 就JBoss Tomcat 及Geronimo 的特性进行全面的比较 请注意 表中用到的 部分支持 表述 表明该应用服务器并非完全的支持 需要安装一些额外包 而其中的 原则上支持 表述 表明该应用服务器需要第三方的安装包的支持 注 三种应用服务器均在Linux Solaris Windows及Mac OS X上进行过测试 表 Java EE应用服务器特性比较

  特性 JBoss Geronimo Tomcat Java EE 一致性 部分支持 完全支持 部分支持 支持EJB 支持 支持 原则上支持 JSP 和Servlet 支持 支持 支持 JSF 支持 支持 原则上支持 客户化插件 支持 支持 不支持 业务规则引擎 原则上支持 原则上支持 原则上支持 Hibernate x 支持 原则上支持 原则上支持 集群 支持 支持 部分支持 Eclipse IDE 支持 支持 支持   当读者的应用需要比较特殊的扩展 或是想与Java EE 最贴近时 那么 Geronimo 是最佳的开源Java EE应用服务器选择 尽管JBoss 与Sun的Java EE标准在实现上有一定的出入 但JBoss team提供了许多与Java EE标准很符合的技术 同时也扩充了Java EE 的标准范围 而Tomcat 本身就是一种轻量级的解决方案 所以它不并包括Java EE 的所有特性 或是在JBoss及Geronimo中所提供的特性 但正是由于它的轻量级 才使它对内存的占有量比较少 并且比其它两种服务器运行起来更快 ．Java EE 一致性 Sun公司的Java EE 标准是一种行业标准 而作为这种标准的实现 开源的Java EE 应用服务器应该与其尽量的保持一致 因此Java EE 的一致性是一个很重要的指标 在这三种开源的实现中 Geronimo是实现得最好 与Java EE 标准最贴近的应用服务器 JBoss 支持绝大部分Java EE 的特性 当然 不久即将发布的JBoss 将完全支持Java EE 的所有特性 而Tomcat一般看成是JSP/servlet的容器 仅仅支持Java应用服务器的基本特性

．支持EJB EJB（Enterprise JavaBeans）是指能在Java EE服务器部署的Java组件 它通常将一些业务功能打包成可重用的组件 新发布的EJB 提供了许多新功能 解决了旧版本中许多问题 JBoss 及Geronimo 均支持EJB Tomcat 本身并不支持EJB 但Apache OpenEJB项目可以使Tomcat支持EJB 据称Tomcat可以运行一种嵌入式的JBoss EJB 容器

．支持JSP /Servlet 对JSP/servlet的支持是绝大部分Java服务器应提供的最基本功能 JSP 和Servlet 是Java EE 对JSP/servlet的升级功能 JBoss Geronimo 及Tomcat 均支持JSP/servlet这一特性

．支持JSF JSF（Java Server Faces）是一种在Java EE应用部署的组件式架构 提供基本的Web开发的用户界面 与请求驱动的MVC（Model View Controller）的架构不同的是 JSF采用了组件驱动的模式 就目前的JSF 而言 JBoss 及Geronimo 都有很好的支持 而运行在Tomcat 时有不少的问题待解决

．支持客户化插件 客户化插件支持 意味着可以在原有应用服务器功能的基础上 开发新的功能 并能很好的协同使用 在JBoss中使用MBeans（managed beans）来处理插件开发 而Geronimo也采用类似的处理方式 只是名称不一样 叫GBeans 这些客户的Beans为开发及部署客户资源时 提供一系列统一的接口

．支持业务规则引擎 几乎所有的应用程序都是建立在一系列业务规则之上 或称之为业务逻辑 而业务规则引擎组件则能帮助管理与简化业务逻辑编程 一般的编程过程中 程序员最常见的逻辑有如if/then逻辑 而有了业务规则引擎 则可以实现许多更加智能的业务逻辑 Drools作为一种业内很流行 标准化的业务规则引擎 在JBoss Geronimo 及Tomcat 中均可得到支持 Geronimo完全支持Drools 而JBoss支持Drools的历史最久 已达三年之久 并使JBoss/Drools成为了一种非常有市场竞争力的业务规则解决方案

．支持Hibernate x Hibernate为Java编程提供了强有力的关系/对象模型（ORM Object relational mapping） Hibernate可以将面向对象的模型映射为关系型数据库 这对Java开发来说是最有吸引力的 Hibernate作为一种开源的软件 最早就是由于JBoss的一个团队所开发（Gavin King） 当然 JBoss Geronimo 及Tomcat 均支持Hibernate

．支持JBoss Seam JBoss Seam是一种著名的应用框架 集成了众多的Java及Web技术 例如Ajax JSF Java Portlets BPM（Business process management）等技术 Seam是JBoss的项目 理所当然 JBoss 自然支持它 同样Geronimo 也支持JBoss Seam 据JBoss Seam的开发团队称 Tomcat可以通过使用JBoss嵌入式EJB 容器来支持JBoss Seam

．支持集群 集群通过并行在多台服务器运行同样的服务 从而大大的提高应用的吞吐量 达到所谓的高负荷的效果 由于采用了数台服务器同时运行 所以当其中的某台服务暂时或死机时 对客户不会造成服务停止 从而达到业务的可持续 集群极大的提高了企业级的Java应用的性能 吞吐量等能力 JBoss Geronimo 及Tomcat 均以同样的方式来支持集群 JBoss在集群层使用及时复制的方式来达到集群的目的 而Geronimo所发布的集群 还处于测试阶段 需要时间的考验 如果有兴趣 可以与Apache基金组织联系

．              支持Eclipse IDE Eclipse是目前最流行的Java开发工具 自然 与Eclipse的集成是众多Java EE 应用服务器应该提供的功能 JBoss Geronimo及Tomcat均支持与Eclipse整合 特别地 JBoss还有自己的Eclipse版本 称为Red Hat Developer Studio 目前正处于测试的阶段 利用Geronimo提供的工具 可以省去手工配置XML文件的烦琐 同时 数据库连接池工具都可以自动的下载所需要的数据库连接驱动

三         部署 这三种应用服务器的安装均十分简单 在相关的网站上下载zip或tar包进行解压 唯一需要配置的是设置JAVA_HOME环境变量（不过一般均有配置） 注意 在Linux/Unix系统下 需要先发送chmod命令 ．Geronimo 对Geronimo 来说 进行配置及部署Java应用程序非常的简单 特别是通过它提供的Web控制台更加简单 Geronimo控制提供了许多简单的功能来帮助开发人员进行应用程序的配置 可以进行数据库的连接池测试及安全设置或配置等

图 Geronimo控制台

JBoss JBoss 有非常漂亮的Web管理控制台 但它所提供的管理功能及特性与Geronimo不尽相同 首先看到的是JBoss的状态及其监测信息 但并没有提供部署功能 而部署Java应用时 只需要将它复制到default/deploy文件夹下面 JBoss会自动的检测到它并进行相关的快速部署 当然 也可以通过修改配置jboss service xml来进行客户应用程序所在目录的映射

图 JBoss控制台 Tomcat Tomcat 不愧为一款快速的轻量级的应用服务器 它的控制台提供了基本的部署功能 可以通过Tomcat的控制台进行服务的启动/停止及WAR包的deploy/undeploy *** 作 当然也提供了Tomcat的运行状态及监测信息 同时有很好的用户授权系统

图 Tomcat控制台

四         性能 就可靠性而言 性能应该是所以的应用服务器所应该提供的最重要的特性 在本文中 笔者做了一个小实验 使用JSP页面及编译好的servlet来测试应用服务器所能处理的用户会话个数以及所能连接的用户数量 当然 实际的Java应用是更加复杂的 而本实验中的JSP页面及servlet是比较简单的 主要用于测试Web应用服务器的稳定性 可靠性及速度 使用的测试机器为 双核 位 CPU G的内存 在实验中 让第一种应用服务器运行到 个会话 当然 这些会话不并是同时连接

图 多Session测试JSP页面结果

lishixinzhi/Article/program/Java/ky/201311/28190

可以的，注意本文是从技术角度，而不是商业角度来分析。。
从技术角度来看，C/S和B/S除了UI不同，BLL(1)层和DAL层使用相同的DLL；BLL(0)层可以根据C/S、B/S特点开发；
即使用UI-->应用服务器(BLL0)-->BLL1-->DAL的架构方式。
1 首先看一下典型的使用场景
用户下载网页A，此时服务器更新了A的提交逻辑，A再提交后新的逻辑立即起作用，并保证所有的客户端是一样的。
在这一个场景中，有两类人：一类是客户，二类是程序开发者；客户访问了网站，程序开发者更新了网站程序。
2Client：客户端，Server：服务器端，最大的问题就在Server这个词，多数的C/S应用是C/DatabaseServer，而不是C/ApplicationServer。
21 C/DatabaseServer：即各个客户端直接访问了数据库，如果此时各个客户端的BLL层和DAL层是一样的，那没有什么问题；如果因为更新等因为BLL层和DAL层造成了不一致，就可能出现问题。 C/ApplicationServer：即各个客户端访问了应用服务器，而不能直接访问数据库
3接着说B/S，B/S=Browser +C/ApplicationServer，这里C是指Web服务器前端的请求分发的路由器，ApplicationServer即Web服务器。如果有一台Web服务器配置多个域名的经验，应该很清楚这个意思。从技术角度，B/S的本质是，不让Browser 直接读写数据库，而C/S开发则“不会舍近求远”来开发应用服务器层。B/S架构：商业逻辑总是通过Web服务器，才能到达数据库，从而有了保证。而C/S架构，各C均直接访问了数据库，这是最大的不同。

---