系统架构

第1章  系 统 架 构

成功的第一必需品是坚持不懈地把你的精力和心智投注到某一问题上的能力。

——托马斯·爱迪生(Thomas Edison)(1847－—1931)

系统架构最好既被看成过程，又被看成一种原则，它可制造有效的和高效的信息系统。

能被看成过程，是因为它能遵循一系列步骤来制造和改变系统的体系结构。

能被看成原则，是因为这些知识告诉人们什么是最有效的设计方法。

系统是一群互为关联的机器、应用程序和网络资源的集合。系统架构在系统之上施加结构来统筹这个集合。更重要的是，此结构可根据业务目标来安排系统的功能。

系统体系结构包括环绕图1－-1中的基础设施层。

图1-1  企业架构模型

系统架构的基本目的是支持企业架构中更高的一些层次。在许多公司里，软硬件代表企业总资产中重要的一部分。企业架构师们千万不可把自己的职责等同于他所管理的物件、应用程序或机器。他们的主要目的应是支持和促进企业的业务目标。软硬件的基本上寿命基本上是有限的，只是为了履行业务意图而存在于一时。

系统架构也用于保持企业架构和业务目标、组织过程相协调。因此，不仅理解基础设施和运行于其中的应用系统的细节是很重要的，而且也应具备足够的知识，以便和企业架构组一起参与架构的改造过程。这包括如下方面：

· 定义现有系统结构的结构、关系、视图，、前提和逻辑，以及从当前的状况转变为所需求状况的过程中需要涉及的关系、视图、前提和逻辑的变化。

· 创建那些开发系统架构要用到的模型、指南、模板和设计标准。

1.1  卡纳夏引入外来的架构师

让我们为以后的讨论搭建一个舞台，聚焦到卡纳夏上。凯罗•詹姆斯(Kello James)从外部引入了一个架构师，作为他实施卡纳夏企业架构规划的一部分。这是卡纳夏历史上的第一次。

现在我们和卡纳夏的一些核心主管，以及新来的架构师梅勒•斯坦蒂什(Myles Standish)一起坐在一个筹划会议上。在会上，梅勒被介绍给半信半疑的听众们。他在这次会议上的任务是确立卡纳夏系统架构的价值定义，并进一步建立系统架构。他的委任条款规定他有推荐物理设备和企业应用架构的监察职责。这意味着他将随着卡纳夏的发展成为架构小组的一员。

梅勒开始了他的评述。他首先简要概括了对卡纳夏系统架构状态研究中尚未涉及的部分，讨论进行如下：

· 梅勒提到，卡纳夏就如其它其他大型企业集团一样，大部分固定资产是组成系统架构的应用程序和机器。在卡纳夏的业务环境中，能尽善尽美地管理系统架构的公司将会赢得可观的利益。

· 他谈到信息技术(IT)部门的经费主要被卡纳夏基础设施的相关开销侵吞。当前这些开销多数是固定的。如果卡纳夏希望在管理信息技术资源时获得一些敏捷性，就必须为系统架构提供必要的时间、人力和关注，以便极大地节省这类开销。

· 梅勒指出，卡纳夏主要业务的IT功能被孤立封闭地划分到各应用系统，其中有的应用系统甚至创建于30年前。这里梅勒被一个执行副总裁的提问打断：“你不是想告诉我们应该重写或更换这些应用系统吧？我们已经试过了。”梅勒明确地回答，他并无更换任何遗留系统的计划。与其更换，他宁可打破系统间的封闭，让系统可以彼此交流。

· 摧毁纽约世贸中心的恐怖袭击让卡纳夏把灾难恢复作为燃眉之急。系统架构对灾难恢复计划(Disaster Recovery Plan，DRP)是至关重要的。(数据恢复计划中系统架构方面的内容将在本章的后面讨论。)在梅勒的陈述中，他简要概括了灾难恢复计划中由架构小组负责开发的系统结构部分的业务层面。

· 梅勒随后围绕存储讨论了一些问题。他询问执行主管们是否意识到：根据卡纳夏近来的数据存储费用增长率，到2006年用于存储的开销将等同于现有的IT经费。会议室内执行主管们由震惊而带来的沉默告诉梅勒他们还是首次听到这个消息。于是梅勒说他将在控制数据存储经费上寻求他们的支持，以便为卡纳夏获得可观的利益。

    数据存储及围绕于此的问题在本章稍后部分讨论。

· 近来高利润大企业的破产风暴，在美国高级公有企业中引出了强制性的严苛报告规章。这些规章要求IT部门提供几乎是实时的财务报告能力。卡纳夏是适用于财务报告新政策的企业集团之一。梅勒坦率地提到目前财务系统的集中化管理非常不灵活，当前的系统不具备提供更多财务报告的能力，而且其中最快的报告也是按月递交的。梅勒随即指出加速财务汇报速度会在他的日程表里成为高优先级的任务。执行主管们对此纷纷首肯。

· 梅勒还将卡纳夏基础设施状态的可观察性引入议题，这是完整业务视图中重要的一部分。梅勒倾向于建立一个汇报机制，让相关的经理和高层管理人员能够获得他们所管辖的领域的业务智能(Business Intelligence，BI)，这样便可探知系统的基础设施是否对重要的业务标准——例如订单的履行能力——起着消极的作用。梅勒的言下之意是，卡纳夏的旧系统显然是用户对这个汽车制造公司不满的某些根本原因。他认为，把对公司的基础设施性能的度量引入现有BI，会对重建用户满意度起到重要作用。

成百上千个低层次决策所累积的后果已经束缚了卡纳夏，因为基础设施不能满足业务过程需求，并侵吞了IT预算的大部分。在许多情况下，购买决策的制定仅仅是因为这项技术是“很棒的”或者“最时兴的”。“在我的任期内，”梅勒坚决地声明，“我们会一直强调经费不可超过允许的限度。进一步地，项目如何匹配其下的业务过程，项目的投资回报(Return On Investment，ROI)将决定系统基础设施经费应投向何方。”

于是谈到了钱的主题——预算经费问题。梅勒被告知：“你不会指望预算能大幅提高，直到满足所有的需求，是不是？我们没有多少钱来增添预算经费。”梅勒在回应中指出一个企业的系统架构应该被看成是一笔投资：一笔重要的投资，其价值能够与日俱增，而不是日益损耗。性能不佳的领域需要被修补或者替换。尤其应该关注那些让投入、增值或开销节省成为可能的领域。

会后，凯罗和梅勒都深受鼓舞。他们都投入到对有关企业架构的努力中，这方面过去曾经是惨淡失败的。他们一同意识到失败的主要原因是未能鼓励首席执行官参与，并持续参与架构过程。正如卡纳夏的高层管理人员所考虑的，本次会议明确了财务汇报、灾难恢复和费用节制等问题应在最先考虑之列。梅勒和凯罗知道他们拥护建立架构，他们也知道架构将会得到改造，以便满足卡纳夏的业务考虑。

1.1.1  基础设施的架构方法

对系统中的各部分及其相互作用做一个历史性的回顾是非常必要的。

我们建议理解一个系统最有效的方法是建立一个明细表，记录系统外露的接口(interface)和系统履行的契约(contract)。聚焦于契约和接口能容易地从关注于机器转移到关注必须为企业提供的功能上。沿架构层上溯，契约应直接映射于系统对象所保障的业务       过程。

正确地创建和实现一个新的系统架构或改造现有的架构，会涉及到管理过程，通过这个过程组织结构会在获得新架构的同时，也管理架构的组件装配。这里包含管理各涉众间的差异，也包含管理各个零件和部件。此举的目的是改善创建和(或)选择新应用的过程，以及将它们集成到已有系统中的过程，通过提高现有基础设施的效率来节省IT操作的费用。

1.1.2  其它其他关于系统架构的关注点

以下是一些在建立支持企业的系统架构时需要考虑在内的关注点。

· 应用程序、机器和网络所需支持的业务过程。这是企业系统架构的主要关注点。因此，一个架构师需要把公司的所有业务过程映射到用以支撑这些过程的应用和基础设施上。这个映射应下放到符合业务要求的最低水平。无论如何，业务需求和实现间百分之百的吻合总是不可能的。

· 整个架构中折中部分。通常受损的领域有数据和安全架构，以及数据质量。数据架构受损是因为使用者缺乏知识和经验，不知道改变程序可能造成的后果。安全架构受损的原因是安全性常会被员工看成一种不必要的麻烦。数据完整性受损的原因是人们被迫在过短时限内制造过多的数据，而无法对数据进行适当的交叉       检查。

· 系统架构的涉众。这些相关人员包括如下各类：

n 创建已有架构的人员。

n 负责管理和加强架构的人员。

n 业务中通过变更现行的系统架构，会造成积极或消极影响的人员。

n 参与到有效功能操作并持续存在于协作中的业务贸易伙伴和其它其他企业。

n 直接通过因特网处理的任何客户。

涉众的需要和关注点对系统架构应当作何改变和新架构是否成功，会产生巨大的影响。

· 新架构所包含的环境上下文(context)。在这里，环境上下文指系统架构定位的全局的企业现实。如果你的公司限于单个国家、语言、货币，那么你的环境上下文可能会相对简单。卡纳夏是一个全球化的企业，它的相关涉众使用不一样的语言，居住于多个时区；它的企业文化是许多区域文化的复杂混合。总之，这种分布性是增强卡纳夏竞争力的一个积极因素。

· 系统架构处理的数据。

    关于数据架构的详细内容请参见第11章“数据架构”。

1.1.3  工作于现有的系统架构

企业中往往不具备能对业务系统架构具有一致概观的个人或团队。梅勒发现自己所处的境况正是如此。卡纳夏的系统架构没有被规划过。公司发展多年，却从未在它的应用、网络和机器设备上认真地花费过任何时间或努力。这类在发展期间从未有一个一致履行的系统架构的公司可能有所谓的烟囱式架构(stovepipe architecture)。

不佳的架构以设备大杂烩和散布于企业物理各分支的软件为特征。设备和软件是为了短期的、战术化的解决方案而获取的，为着解决某个时刻团体所面临的问题。互联性至多只是事后产生的想法。烟囱式架构通常是偏重功能规划的大型项目的结果，通常其设计目的是实现企业的某个特定的功能。这些系统经常是临危受命的，公司的有效运作必须依靠它们。一般来说，这些系统牵涉到运行它的应用程序和硬件。更换这些系统往往被认为是代价高昂以至于难以承受。烟囱式架构会伴生一些问题。

· 系统不能很好地适应它们所应支持的业务过程，这可能由于以下原因：

n 用以建立应用程序的软件设计过程，在设计阶段就没有很好地捕获业务需求。

n 当业务竞争场景转换时，业务需求不可避免地变更。

    更深入的关于软件开发过程的知识请参见第5章“方法学概述”，第6章“企业统一过程”，和第8章“敏捷建模”。

· 许多烟囱式应用的孤立设计，使得难以协调业务过程和应用程序功能间的差异。

· 未集成于企业数据模型中的数据，通常是因为词汇表、数据格式或者数据字典等问题。

    有关烟囱式应用中数据架构问题的更全面讨论请参见第11章“数据架构”。

· 烟囱式应用绝非为集成到大系统中而设计，它们可能是企业应用集成(Enterprise Application Integration，EAI)或供应链管理的结果。

· 难以为业务智能或业务过程管理获得必要的信息。

· 有些烟囱式应用中应用软件和硬件/操作系统的结合，使不灵活性持续并加剧，导致烟囱式应用具有高昂的总体拥有成本(Total Cost of Ownership，TCO)。

很多时候，把创建企业系统架构看成一个领域定义问题是有用的。开始的时候，应该划分问题集，以便排除不太关键的问题区域。这将让你把精力集中在关键区域。由此可以获取额外的收益，因为小问题有时是可以自我解决的，或者当你钓到了真正的大鱼后会变得无关紧要。有道是，时间能成为你的盟友，耐心是收割时间作物的工具。

1.1.4  系统架构类型

绝少有架构师能被授予一块干净的石板，有幸从草图开始创建新的系统架构。就像多数架构师一样，梅勒继承了一个现有的架构，以及负责支持和加强它的人员、已有系统中全部的相关联系、公司中倚仗它们的部分。我们必须强调现有系统中的人员配置是极为有价值的资源。

以下列举了系统架构类型，其优势和劣势，以及如何利用它们更好地工作。

1．遗留应用系统

遗留应用系统(legacy application)在如下特点上颇为棘手：

· 孤立的设计。由一系列过程组成的应用程序以缺乏逻辑的方式联结起来，难以很好地彼此协作。

· 固定且不灵活的用户界面。字符界面的“绿屏”界面是遗留用户界面(User Interface，UI)的一个通常例子。此类界面难以替换为基于浏览器的界面，也难以集成到工作流应用中去。

· 硬编码(hard-coded)的内部数据定义。这些数据定义通常是特定于应用程序的，并不遵照企业数据模型方案。更甚者，变更它们会涉及对所有进行后续操作的应用程序的重构(refactor)。

· 硬编码的内部业务规则。在这种情况下，由于业务过程的变化而更新规则，就需要把应用都登记造册，找出所有相关的业务规则，重构受到影响的组件。

· 独自存储授权用户列表的应用程序。应用程序相关的授权用户列表，会阻碍应用程序与单独的登录和认证管理技术进行集成。

虽然许多遗留应用系统被抛弃了，也还有相当一部分现在还在继续使用。这些幸存的遗留系统通常对企业至关重要，同时替换它们也是困难而昂贵的，通常被视为不可能。

这就是卡纳夏的状况。它的许多IT部门涉及到遗留应用系统。几个大型主机应用系统控制汽车的制造过程。它的企业资源计划(Enterprise Resource Planning，ERP)始于20世纪90年代。库存和订货系统(一个大型主机系统)创建于1985年。客户关系管理(CRM)应用建立在模块化原则之上，这是最近采用的。卡纳夏的遗留财务应用则来自更匆促的考虑。

卡纳夏是受制于证券交易委员会4-460法令的945个公司之一，因此架构小组明白必须制造出比现有报告更详尽的财务报告。

现有财务部分不支持这些需求。架构小组认为可以采用如下方案：

· 替换遗留财务应用程序。

· 从遗留应用程序中进行提取，转储入满足新报告要求所必需的数据仓库。

替换现有的财务应用程序看来是艰难而耗时的。这一过程关联到相当可观的风险。构架小组认为如果决定走替换的路线，就必须用很高的代价来降低失败的风险。然而，小组还有其它其他领域需要充实资源，不愿把所有的资金都投入到财务报告情况上。

数据提取的解决方案允许遗留应用系统依然按原来的时间和方式运作。数据挖掘方法给卡纳夏带来了如下好处：

· 大为提高财务汇报操作的反应能力。使用数据仓库，使得每周制作公司财务情况的精确视图成为可能。

· 粒度更小的细节能力。对数据的精细粒度访问是数据仓库的主要功能之一。遗留财务系统的主要功能是按企业的会计原则调和会计报表，而不是对数据的精细粒度访问。

· 随机检索(ad hoc querying)。数据仓库里数据是多维可用的，用户可以按照各自的需求精细挖掘。这大为减轻了制作报告的负担。

· 与只做必要之事的敏捷原则相协调。你只需操心数据仓库的实现和创建一些制作所需报告必要的应用程序。你可确信用户团体所熟悉的财务汇报，在需要的时候，会以他们所熟悉的方式出现。

在卡纳夏关于遗留应用的条款里，梅勒遇到了保存遗留应用系统原封不动的决定。特别地，他所面对的计划要求保持遗留财务应用系统百分之百地不做变更，于是他转而为卡纳夏的财务信息实现一个数据仓库。

数据仓库不是管理的一个流行选择。这显然是个防守性的举措，具有比较低的——如果不是负的——投资回报率(ROI)。在关于数据仓库项目费用的某个讨论中，一般的架构小组成员，特别是梅勒被指责为“轻信且偏好新技术”。这是每当引入外来新技术时就会被拿来使用的责问。但是，架构小组恪尽职守，已经很好地做了一些工作，能够很有信心地陈述项目的费用。这个项目会保持在尽可能小的范围里，因而充分降低了失败的风险。另外一个可选方案是替换遗留应用系统，这种方案显然更为昂贵并具有更高的风险。而且，把财务数据带入企业数据模型的确开启了将来协作的可能，这样能充分地增加数据仓库的投资回报率(ROI)。一般而言，关于遗留应用系统的好消息是它们极为稳定，在现有的功能范围内运作良好。物理和数据安全性都非常出色。不太令人满意的是它们极为不灵活。它们需要一个定制的专有输入，并制造出一个专有的输出。对它们行为的修改通常是遗留系统改造的主要任务。在许多情况下，支持遗留应用程序的花费是许多IT预算甚少宽裕的原因之一。

许多架构师将不得不使用遗留应用系统。他们必须通过着重修改遗留应用系统的行为来开拓它们的能力，并关注它们所履行的契约和它们提供的对外接口。

在一个组织中，任何一个应用系统的变化都可能对其它其他应用系统导致无法预期和并非期望的后果。这类情况要求高度独立遗留应用系统的功能。有时，一个功能可以被分解到你了解其所有输入和输出的程度，这就是遗留功能对外化的层次。

2．客户/服务器架构

客户/服务器架构是基于把功能划分为客户端应用和服务器端应用的方式。客户端应用需求数据或服务，服务器端应用满足这些需求。客户和服务器可以在同一或者不同的机器上。客户/服务器架构填补了一定的空缺，并由于多种原因而逐渐流行起来。

在客户/服务器架构的兴起中，知识访问是个很大的驱动原因。从宏观层次上来说，通过大型主机应用系统，用户被给予数据，但他们需要知识。从微观角度上则下达到报告，报告本质上是一纸数据的特定视图。从大型主机中获得标准的报告集是容易的，而获得数据集合的不同视图则需要花费几个月来准备报告。而且，大型主机提供的报告按照标准的日程表进行，而不是根据用户的日程表。

节省开销是客户/服务器应用系统最初流行的另一个重要因素。大型主机运行应用程序的开销都在6~7位数字范围。建立或购置运行于客户台式机上的程序就便宜多了。

快速而便宜的网络技术的兴起也是一个因素。一般来说客户和服务器应用是在分离的机器上的，这些机器通过某种网络互相联接。因此，客户/服务器需要良好的网络使其工作有效。最开始业务系统建立局域网(LAN)以便共享文件。企业网络已经发展到广域网(WAN)和因特网。带宽从10Mbps以太网和3.4Mbps令牌环网发展为100Mbps以太网，千兆以太网也开始出现了。于是大量的应用程序可以在给定的网络上交谈。网络拥塞是架构师们一个永恒的议题。

客户/服务器架构引出和市场化了一些非常强大的桌面应用系统，这些应用已经成为企业级系统里的一个组成部分。电子表格和个人数据库在现代企业已经广为存在。

客户/服务器应用开发引发大量并非程序员的人们做出贡献。各层次的合作员工无须IT人员的参与就开发出一些相当成熟的应用程序。

最初围绕客户/服务器革命的华而不实已经大量消失了。现在它是非常成熟的架构。它已浮现出如下特点：

· 客户/服务器架构所牵涉到的支持费用开始成为一个需要考虑的因素。必须购买和支持大量的PC机。保持客户/服务器应用是当前的通行版本，物理地发布新版本或新应用程序至公司所有需要它们的桌面计算机台式机上，这些开销对许多IT部门来说都是一种震动。客户/服务器应用是另一个许多IT经费被大量地投入于固定的花费的       原因。

· 许多用户创建客户/服务器应用时未曾很好地设计。特别是，在个人数据库里使用的数据模型通常是完全非规格化的。并且，在相当一部分情况下，用户台式机数据存储中的数据并不是百分之百整齐划一的。

· 这些应用中的很大一部分，以及以往分散化的倾向使得架构师极难定位和盘点     它们。

客户/服务器辅助程序，尤其是电子制表软件，促进了客户/服务器应用快速渗入企业。在所有企业阶层上，电子制表软件是一种主流的数据分析工具。客户/服务器开发工具能让电子表格功能直接集成到桌面客户端。建立架构时要更换客户/服务器应用就必须把电子制表功能的重要性计算在内。在许多情况下，如果用户希望在应用中具有电子制表功能，任何更新计划就都需将它包括于内。

关于客户/服务器应用，卡纳夏架构队伍和许多大公司的架构师一样处于如下境况：

· 卡纳夏有大量的客户/服务器应用需被支持。并且，这些应用在今后多年内都需被支持。

· 卡纳夏仍然在进行相当数量的客户/服务器应用开发。有些只是加强已有的应用，但有些的目标则是为了开发全新的客户/服务器应用。

· 梅勒遇见的客户/服务器应用的问题之一，基本上可以被称为一对一的问题，即某个特定的台式机上某个特定的应用只能和一个特定的服务器对话，通常是数据库服务器。这种架构不提供一组团体资源同时访问一个应用程序。架构小组想把企业应用也向分布式的方向发展，以便赢得它们所提供的费用节省和可伸缩性。

架构小组知道他们必须对卡纳夏的客户/服务器应用做某些修整。可以采用如下几个      方法。

· 原封不动。这是对具有以下特征的应用所推荐的方法：

n 复杂的。因而将其转换到瘦客户端架构中会过于困难或者过于昂贵。

n 只有少量的用户基础。通常意味着它不是一个被优先考虑的应用。

n 稳定的。这就是说，不需要许多维护工作或保持一定稳定频率的更新，通常意味对这个应用的支持在经费预算中不是一个值得注意的分支。

n 涉及数据制表功能的。即使试图在一个瘦终端上只实现电子制表能力的一部分子集都是非常困难而昂贵的项目。在这种情况下，我们建议你接受现实，电子制表给图表带来的丰富的图形界面优点，使它成为一个最优的解决方案。

· 将应用放到服务器上，把用户的PC变成哑终端。Microsoft Windows Server 2000版及以后的版本，能够在多用户模式下运行。这允许IT部门在服务器上运行Windows应用程序，对连接其上的PC仅提供屏幕更新。把应用程序放在一个服务器上使得管理客户/服务器应用方便了几个数量级。

· 提取应用程序的功能放入一系列界面中。把客户/服务器应用转变为一系列组件。一些组件能被结合入其它其他的应用中。如果客户/服务器应用被分割成块，它就能每次更换一块，或者是经费预算所能支付的最大替换规模，而其它其他部分仍然是可        用的。

    面向服务的架构(Service-Oriented Architecture，SOA)是一个把应用集成到企业架构中的形式化方法。关于SOA更多的信息，请参见第3章“面向服务的架构”。

· 许多情况下客户/服务器应用仍然是首选的解决方案。如果应用程序有一个复杂的图形用户界面(GUI)，比如Visual Basic、PowerBuilder或者Java Swing应用程序或Applet所创建的那样，那么在浏览器应用中不可能被复现的许多东西都能实现，而且比在HTML中构造更方便快捷。执行密集运算的应用程序是极好的候选对象。你不想让服务器负担沉重的运算任务，或者让网络带宽因为传送图像至客户端而耗竭。因此获取数据让台式机的CPU进行计算就好多了。涉及电子制表功能的应用程序最好在客户/服务器架构下完成。Excel将它的所有功能都呈现为COM(Common Object Model)组件。这些组件能够被透明而方便地结合入VB或者MFC(Microsoft Foundation Classes)应用中。在许多情况下，所有新客户/服务器开发应该使用功能接口而非孤立应用程序来进行。

· 把它们转移到瘦客户端架构上。这时经常意味着创建基于浏览器的应用程序来替换它们。当这些客户/服务器应用对企业数据模型有重大影响时，这是一个理想方案。它具有一个重要的副效果，即有助于把应用所包含的数据资源集中起来。

卡纳夏架构小组决定对它的客户/服务器应用库采用一个多步骤的方法。

· 大约三分之一的应用明显属于“原封不动”类。它们无须强化就可以得到支持。

· 百分之十10%~15%到十五的应用程序将不再被支持。

· 剩余的应用适合使用瘦客户端架构来更换。

在客户/服务器讨论中经常被忽视的一件事是隐藏于桌面数据库的企业数据遍布整个业务。你可设法来处理用户数据存储中重要的公司团体数据：

· 把它从桌面系统中抽取出并移入一个公司数据库。用户便可通过开放式数据库连接性(Open Database Connectivity，ODBC)或JDBC来支持应用。

· 对于被移到浏览器的客户/服务器应用，抽取可能是必须的。

虽然客户/服务器架构并不能很好地适合当前的分布式应用，它仍然在现代企业IT世界中占有一席之地。我们坚决提倡使用接口而非孤立程序。正如我们前面所推荐的一样，应关注最大和最紧迫的问题。

3．瘦客户端架构

瘦客户端架构是一种消除业务逻辑和数据表现形式影响的流行方法。起初瘦客户端是分时计算(time-share computing)的一种改头换面的提法，只是把哑终端换成了浏览器。当架构渐成熟时，在有些情况下客户端也被赋予了一些职责。

如上所述，客户/服务器应用在维护和升级方面具有相当可观的隐藏开销。对这些隐藏开销的不满导致“瘦客户端”概念的诞生。使用瘦客户端系统架构，所有的工作都可以在服务器上进行。

瘦服务器架构的某一引人入胜处是客户端软件组件由第三方提供，不需要业务部分的开销和精力。服务器(这里是Web服务器)为用户浏览器提供内容，并从用户浏览器收集反