- 论坛徽章:
- 0
|
Sun Certified Enterprise Architect for J2EE™ Technology
Study Guide
Mark Cade
Simon Roberts
Publisher: Prentice Hall PTR
First Edition March 11, 2002
ISBN: 0-13-044916-4, 220 pages
第1章. 什么是体系结构？
这本书每一章的基本结构都是相同的。以本章所要描述的测试目标列表开始，紧随其后的是“介绍”部分或“预备知识” 部分（描述了阅读该章内容前应该了解的知识）。接下来是“讨论”部分，描述了针对测试目标的主题。然后是“重点”部分，对该章的关键内容做一个总结。最后的“复习”部分集中在考试中可能出现的问题上。
在完成本章的学习之后，你将能掌握如下的J2EE技术系统架构师测试目标：
Ø 系统架构师的职责
Ø 服务级需求
介绍（概述）
体系结构这个词有很多种不同的定义。Webster的定义是“建筑的科学或艺术” ，计算机工业对体系结构的定义是“计算机或计算机系统的组件的组织和集成方式”。这一章给出了一个Webster的体系结构定义的变种，本书的余下部分将不断强化这个定义。
因为互联网的发展，创建一个体系结构来构建系统的模式在过去的20年中得到了飞速的发展。在互联网爆炸之前，一个系统架构师创建的系统架构只需要处理公公司内部的用户需求，人数大概是在几百以内。然而互联网的出现使得公司可以将他们的计算资源向客户开放，这就意味着系统架构师现在所要创建的系统体系结构必须为数以千计的用户服务，而且他们使用系统的方式是不可预测的。如果你的系统不能满足用户的期望，那么用户会去找其它能够满足他们的期望的公司。因此，你所创建的系统架构能公司的生存底线造成直接的影响。
预备知识
为了不让这本书变得比词典还厚，我们假设读者具有相当的知识水平。如果你没有掌握阅读这本书所必须的预备知识，你应该从其它地方学习一下。这本书要求你掌握如下知识：
l 了解面向对象的概念，例如封装、继承、多态性和接口；
l 你应该有过用面向对象语言编程的经历，最好是用过java语言；
l 你曾经设计过面向对象的程序和系统；
l 你正在用这本书准备Sun认证的J2EE平台企业系统架构设计师（SCEA）考试.
要成为一个真正意义上的系统架构师需要多年的创建架构和系统设计方面的实际经验，这本书提供的内容在帮助你获得SCEA证书的同时还让你具备能够获取这些经验预备性知识。
讨论
这本书的最佳出发点是要确保你和试题的编制者有共同的看法。采用一个共同的词汇表有助于减少你对后继章节的疑问。是否能对系统架构进行清晰准确的定义会影响到你考试成功与否。要理解这个定义，你就必须明白在创建系统架构这个工作中你所担负的责任，你必须意识到你所要完成的任务是什么？最终，你必须明白创建一个系统架构的目的是什么？你所创建的系统架构要支持系统的服务级需求，如果没有服务级需求，你的系统就不能满足客户对可用性、可靠性和可扩展性的要求。这些服务级需求使得公司的计算机系统免于崩溃。
1.1. 理解体系结构
参照Rational统一过程的定义：
“软件系统架构包括了关于软件系统组织结构的所有重要决定。结构化元素的选择，以及这些元素接口的定义，即说明它们在由其共同构成的系统中为进行有效的协作而必须实现的行为。系统架构样式通过确定这个组织结构、有哪些元素、以及它们的接口、协作和组合，来指导如何将这些结构化的行为元素组成一个更大的子系统。 软件系统架构不仅仅涉及系统的结构和行为，还要关注应用场景、功能性、系统性能、resilience, 可重用性，可理解性、经济和技术上的制约、折中平衡trade-offs, and aesthetic 等问题。”
这个定义实在是有点长，还是让我们看看由SunTone系统架构方法学提供的这个简单一点的定义：
“系统架构是一组结构化原则，这些原则使得系统能够由一些较为简单的系统组成，它们有彼此独立的环境，但作为一个整体的大系统时又能彼此保持一致。”
这两个定义的重点都集中在系统结构上，你创建一个系统架构就是要描述即将构建的系统的结构，以及这个结构如何支持业务和服务级需求。你可以把系统结构定义为解决系统通用问题的所采用的机制。机制是一种能够用一致的、统一的方式来满足业务需求的能力。例如，持久化（persistence ）就应该作为一种机制在整个系统中以一致的方式采用，也就是说系统在任何时候进行持久化时都应该以同样的方式进行处理。通过将持久化定义为一种体系结构机制，你为持久化提供了所有的设计者都应该遵循和一致实现的默认的标注方法。诸如持久化、分布式、通讯、事务管理和安全这些体系结构机制是你要在其上构建系统的基础设施，必须在你的系统架构中定义。
创建一个系统架构是什么意思呢？它的含义就是你已经创建了能够满足系统中已确定的服务级需求的软件基础设施。打个比方，如果系统中某个服务级需求已经明确任何用户响应时间都不能超过3秒，那么你所创建的软件基础设施必须满足这个需求。一个关于系统架构的现实问题是：应该在什么时候停止创建系统架构而开始设计过程？这个问题没有一个适用于每个系统的明确的答案。然而我们可以借用重点和控制这两个术语来重新阐述这个问题，系统架构定义了你要创建什么，而设计勾勒出了你要如何创建它。系统架构控制在把工作重点放在系统大方向上的一个或几个人手中的，而设计控制在把工作重点放在如何到达这个大方向的具体细节上的多数人手中。系统架构设计师所创建的系统架构如果能够让设计团队依照它设计出实现全部目标的系统，那么系统架构的创建应该算完成了。所以，如果你为一个经验丰富的设计团队创建系统架构，那么你没必要提供太多的细节，而如果你面对的是一个缺乏经验的设计团队，这些细节你就必须提供。
在你创建系统架构满足系统的业务需求和服务级需求的时候，你通常不会有无限的资金来支付购买硬件、软件和组织开发资源的费用，因此你需要在已有的那些限制条件下让系统运转起来。例如，当只有一台机器为内部员工服务时，你如何使系统可扩展至能够满足互联网时代的需要？如果没有购买软件产品的预算，你该如何创建系统架构？这些例子都是系统架构设计师在创建系统体系架构时所遇到的问题。你将面对很多困难的选择，要做很多困难的折中处理来解决这些难题。当你在做这些折中处理时，很重要的一点就是你要创建文档来记录你所做的关于系统的体系结构的决定。如果你决定采用Oracle数据库来保存系统中的对象，那你应该在文档中说明你选择Oracle而不是其他数据库系统提供商的数据库的理由。这样做的好处是项目的其他参与者或者后来加入项目的成员能够明白为什么会有这个决定，避免你一次又一次的重申你的想法。在创建系统体系架构时你所做的大多数折中处理都集中在服务级需求或者机制上。大多数系统都没有足够的资金保证来满足系统的最终所有者在最初提出的全部服务级需求。所以，作为系统架构设计师，你必须在服务级需求和满足这些需求所要花费的成本间进行平衡。如果为了满足7*24小时可用的需求而花费你全部的预算来购买高可靠性的硬件，因此导致没钱购买一个应用服务器软件来满足服务级需求在软件方面的要求，那你必须对你的软件体系结构进行调整。这些调整依赖于你为之创建系统架构的系统以及你与系统的最终持有者之间的关系。
1.2. 系统架构师的职责
“理想的系统架构师应该是一个文学家、数学家，熟悉历史研究，还是一个优秀的心理学学生，有音乐天份，了解医学，熟悉星相学和天文计算。”
—Vitruvius, circa 25 BC
Vitruvius指的不是软件系统架构师，但基本的观点是系统架构师应该具有如下特性：但系统架构师应该是全面的、成熟的、经验丰富的、受过教育的、有很强的学习能力的领导者，他能进行良好的交流沟通，并且可以在必要的时候做出艰难决定。对于系统架构师来说，全面是指他们应该具有业务或问题领域的工作知识。他们可以通过经验或教育获得这些知识。另外，系统架构师还必须有丰富的技术知识。一个系统架构师可能对某项的技术有第一手的经验，但他们必须还要对同类技术有基本的理解和认识，以便能够选择可以得到最佳使有效果的技术。一个好的系统架构师可以不考虑具体的技术细节评估某一问题的所有可能的解决方案。
这里有一些常见的关于系统架构师的问题。系统架构师是做什么的？他与高级开发人员之间的区别是什么？设计人员关心的是当一个用户按下按钮是会发生什么，系统架构师关心的是当有上万个用户按下按钮时会发生什么。系统架构设计师消除与系统相关的技术风险，技术风险是指一些未知的、或未经验证的、未测试的东西，风险通常是与服务级需求相关的，偶尔也会关系到业务需求。不管是何种类型的风险，在项目早期创建系统架构的时候解决这些风险会容易一些，这要比等到你有了庞大的开发队伍基于这个系统架构进行系统构建的时候再解决它们好的多。
系统架构设计师必须领导开发团队，以确保设计人员和开发人员所创建的系统符合系统架构。作为领导者，系统架构设计师必须在进行系统平衡方面做出艰难决定。要进行领导，系统架构设计师必须具有良好的文字和口头沟通能力。系统架构设计师的职责之一就是与负责构建系统的设计和开发人员就系统的问题进行交流，这种交流通常是以可视化模型和集体决策的方式完成的。如果系统架构师不能进行有效的沟通，那么设计和开发人员很可能不能正确的构建系统。
1.3. 服务级需求
除了系统的业务需求外，你还必须满足服务级或者说服务质量（QoS）需求。作为系统架构师，你的工作之一就是在系统的初始和细化阶段与系统的最终持有者一起确定每一个服务级需求的服务质量评测标准。你创建的系统架构必须标注出了如下的服务级需求：性能、伸缩性、可靠性、可用性、可扩展性、可维护能力、可管理能力和安全性。你必须在这些需求之间进行权衡，例如，如果最重要的服务级需求是系统的性能，那么你可能会牺牲可维护能力和可扩展能力来确保你的系统可以满足性能的服务质量。不断扩展的Internet带给系统更多的计算请求，现在这些Internet系统的用户已不仅仅是公司内部的雇员，公司的客户也开始使用它们，因此服务级需求就变得越来越重要。
性能
性能通常用给定屏幕事务每用户的响应时间来衡量。除了响应时间，还可以用事务吞吐量来衡量系统性能。所谓事务吞吐量，就是指在给定周期时间（通常是1秒）内系统所能处理的事务的数量。例如，你可以用响应时间小于三秒或事务吞吐量为100每秒来指定系统性能。如果不考虑系统性能的测量标准，你创建的系统架构要能够让设计和开发人员无需考虑系统性能指标完成系统构造工作。
伸缩性
可伸缩性是指系统在其所承受负载增长时，无需改变仍能达到所要求的服务质量。如果当系统负载增长时，它仍能在可接受的限制内做出响应，那么就可以认为该系统具有伸缩性。比如说，你有一个响应时间为2到5秒的性能指标，如果当负载增长时系统仍能将响应时间维持在5秒以内，那么你的系统就是可伸缩的。要理解伸缩性，必须先理解系统容量这个概念，它定义了系统在维持服务质量的前提下所能达到的最大处理任务或用户数量。当系统运行在其容量之上并且不再能够在可接受的时间帧之内做出响应，那么系统就已经达到了它的最大伸缩能力。要扩展一个已经达到其容量的系统，你就必须增加额外的硬件。可以从垂直或水平两个方向来给系统增加硬件，垂直扩展包括给当前的机器增加处理器、内存或者硬盘。水平扩展包括给当前的系统环境增加更多的机器，从而在整体上提升系统容量。你创建的系统架构必须能处理硬件的水平和垂直扩展。从垂直方向上扩展软件系统架构要比从水平方向上扩展容易。为什么这么说呢？因为增加处理器和内存基本上不会对你的系统架构产生影响，但如果你的系统架构要在多台机器上运行而仍能表现为一个系统要困难的多。这本书的其余部分会告诉你如何让你的系统实现水平扩展。
可靠性
可靠性确保了应用程序和它所有事务的一致性和完整性。当系统负载增长时，你的系统必须和负载增长前一样能精确的处理请求和事务。可靠性会对伸缩性造成负面的影响，如果当负载增长时系统不能维持可靠性，那么它实际上不具有真正的伸缩性，所以真正可伸缩的系统必须是可靠的。
可用性
可用性确保服务/资源一直都是可以访问到的。达到可靠性有益于实现可用性，但即使系统组件失效了仍然可以达到可用性目标。通过安装冗余的组件和错误恢复环境，虽然某个系统组件失效会影响系统的可靠性，但冗余的组件会继续提供系统服务。
可扩展能力
可扩展能力是指能够在不影响系统已有功能的情况下增加系统功能，或修改某些系统功能。系统部署的时候你并不能评测它的可扩展能力，但在你第一次必须扩展系统功能的时候它就显现出来了。创建系统架构的时候你必须考虑如下几点以确保可扩展能力：低偶合、接口和封装。
可维护能力
可维护能力是指能够在不影响系统其它组件的情况下修正系统已有功能的缺陷。这又是一个你不能在部署时评测的系统质量。在创建系统架构和设计的时候，你必须考虑如下问题以提高系统的可维护能力：低偶合、模块化和文档化。
可管理能力
可管理能力是指能够对系统进行管理以确保系统的伸缩性、可靠性、可用性、性能和安全维持健康状态。可管理能力解决的是QoS需求的系统监控，以及提供无需改变系统仅仅依靠系统配置就能动态提升QoS的能力。你的系统架构必须具有系统监控的能力，并且允许进行动态系统配置。
安全性
安全性是确保系统不被攻陷的能力，它是目前为止最难标识的系统质量。安全性不仅仅是机密性和完整性的问题，它还涉及到拒绝服务攻击（DoS）所影响到的可用性。将系统架构划分为独立的功能组件有助于确保系统的安全，因为你可以在组件外围创建安全域。如果某个组件被攻陷了，那么将安全侵犯限制在这个组件之中就相对容易些。
重点
体系结构是一组结构化原则，利用体系结构使得系统可以由一组较简单的子系统组成，这些子系统都有自己独立的运行环境，但在整个大系统中能够保持一致。
l 系统架构师的职责是使设计和开放人员生产速度尽可能的快。
l 创建一个满足服务级需求的系统架构可以使你免于成为“CNN”的头条。
l 伸缩性是指系统在负载增长时无需改变仍能满足所要求的服务质量。
l 可靠性确保了应用程序及其所有事务的一致性和完整性。
l 可用性确保了服务/资源一直都是可以访问到的。
l 可扩展能力是指可以不影响现有系统功能进行新功能的添加和已有功能的修改。
l 可维护能力是指可以不影响系统的其它组件修正已有功能中的缺陷。
l 可管理能力是指能够对系统进行管理以确保系统的伸缩性、可靠性、可用性、性能和安全维持健康状态。
l 安全性是确保系统不被攻陷的能力。
复习
这章讲的是基础知识，所以你不需要在这里回答任何问题。 |
|
免费注册
发表于 2004-06-12 17:53