系统架构设计师复习资料【自己整理】

系统架构设计师复习资料【自己整理】

系统架构师是怎样炼成的

坦率的讲，除了少数对开发程序极其热爱并愿意为之奋斗终身的编程者来说，对于大多数开发人员，写代码只是他们未来获得职业提升的一个必不可少的积累阶段，在做开发的时间里，他们会积极学习各种知识，经验，培养自己的商业头脑，包括扩展自己各方面的资源，这些积累会为他们未来成为管理者或创业打下牢固的基础。

成为架构设计师是广大开发者职业发展道路之一，架构师究竟是个什么样的职业？需要具备什么基本能力？如何才能成为一个优秀的架构设计师以及架构设计师需要关注哪些内容？针对有关问题，本期我们为您采访了(微软认证专家，系统分析员，希赛顾问团顾问，中国计算机学会会员) 张友邦，他会就相关问题与大家分享他的看法。

“在我工作的六年多时间里，除了第一年是纯粹编码以外，其余时间都在做和架构设计有关的工作，当然也还一直在写各种各样的代码。”张友邦认为架构设计可能看起来很神秘，新入门或没有架构设计经验的程序员刚开始的时候会有种不知所措的感觉，但其实架构设计是件很容易的事，它只是软件系统开发中的一个环节而已，整个软件系统的开发和维护以及变更还涉及到很多事情，包括技术、团队、沟通、市场、环境等等。

同时，张友邦表示，虽然架构设计是件容易的事情，但也不是大多数没有架构设计经验的程序员想象中的画画框图那么简单。把几台服务器一摆，每一台服务器运行什么软件分配好，然后用网络连接起来，似乎每个企业级应用都是如此简间单单的几步。但现实生活中的软件系统实实在在可以用复杂大系统来形容，从规划、开发、维护和变更涉及到许许多多的人和事。架构设计就是要在规划阶段都把后面的事情尽量把握进来，要为稳定性努力，还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。除了技术上的考虑，还要考虑人的因素，包括人员的组织、软件过程的组织、团队的协作和沟通等。

另外，架构设计还需要方法论的指导。张友邦强调，这些方法论

的思路包括，至上而下的分析，关注点分离，横向/纵向模块划分等。有时候觉得架构设计决策就像是浏览Google Earth，实际上反映的是一种自上而下的决策过程。对问题的分解是软件思维的基本素质，可以有横向分解、纵向分解以及两者的结合。能不能有效快速准确的分解问题，是软件开发人员需要首先训练的工程。另外，架构设计中图形化的工具非常有用，它能把系统的结构和运作机制以图形化的方式表达出来。也正因为这样才有了架构设计就是画框图的误会。再者，架构设计是一个工程性质的工作，对当事人的实际从业经验要求较高。只有对市场上的各种技术有较全面的了解之后才有可能设计出一个尽可能满足各种设计约束的架构。

在谈到架构师需要具备的能力上，张友邦认为架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进(重构)方案(也就是通常说的反模式)。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。

在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信(对象访问、函数调用、数据交换、线程同步等)以及进程外(包括跨计算机)的通信(如RMI、DCOM、Web Service)。在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图。而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括/doc/, Web

Service、.NET Remoting、企业服务组件等。总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来

实实在在的可行性。

其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。

再次，张友邦提到，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。

另外，张友邦认为架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点

来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。

构架师不是通过理论学习可以搞出来的，不学习并且亲自实践相关知识肯定是不行的。就像前面说到的，架构设计是一个工程性质的事情，只有在不断实践的基础上才能逐渐熟悉起来。实践的内容并不是去深挖各种语言的特性，因为系统架构师是设计应用系统架构而不是设计语言(除非你是要实现DSL)。更多的时候需要带着一种比较的眼光去实践，把不同的实现方式下的优缺点做个总结，做到自己心里有数，等具体的上下文环境下才好判断采用什么样的方式方法。把基础打牢的同时掌握一定的方法，架构设计不是想象中的那么难。

张友邦，男，微软认证专家，系统分析员，希赛顾问团顾问，中国计算机学会会员。1980年生于四川宜宾，2002年获得国防科技大学宇航科学与工程系空间工程专业学士学位，2004年初成立长沙石斑软件有限公司并担任总经理，2006年底出任广州快网信息技术有限公司技术总监，2007年10月任湖南新邮信息技术有限公司软件中心副经理。主要研究领域包括软件架构与设计、WEB RIA、流媒体与计算机图形图像。受国家自然科学基金资助，于2001年发表国家级核心刊物学术论文一篇。

系统架构:小议软件架构设计要

点

2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见：

如何更好地进行软件架构设计，这是软件工程领域中一个永恒的重点话题。过去几十年来，国际软件工程界在软件架构设计方面已经获得了长足发展，大量图书、文章和文献记载了这方面的成熟经验与成果。软件架构设计往往是一件非常复杂的工作，涉及到很多细节和方方面面，可探讨的话题也非常之多。囿于篇幅限制，以下只能根据

笔者个人理解，遴选出软件架构设

计的个别要点，结合当前流行的敏捷软件工程思想，与大家分享一下自己在软件架构设计方面的心得和体会。

架构决定成败软件架构是软件产品、软件系统设计当中的主体结构和主要矛盾。任何软件都有架构，哪怕一段短小的HelloWorld程序。软件架构设计的成败决定了软件产品和系统研发的成败。软件架构自身所具有的属性和特点，决定了软件架构设计的复杂性和难度。

这几年流行一个说法（管理谚语）：“细节决定成败”，这句话其实只说对了一半。细节确实很重要，很多工程、产品就输在细节的执行上。一方面，战术细节固然很重要，但另一方面，战略全局也同样重要，对应的我们可以说：“战略决定成败”。战略性失败，就好比下一盘围棋，局部下得再漂亮、再凌厉，如果罔顾大盘，己方连空都不够了，还有官子（细节）获胜的机会吗？必然是中盘告负。

类似地，正确的软件架构设计，应该既包括战略全局上的设计，也包括战术细节（关键路径）上的设计。有一种错误的观点认为，软件架构设计只要分分层和包，画一个大体的轮廓草图，就完事了。这种“纸上谈兵”型的架构师行为是非常有害的。事实上，既然软件架构是软件建筑的主体结构、隐蔽工程、承重墙和要害部位，那么软件架构也必然要落实到实际的算法和代码，不但要有实现代码，还要包括对这部分架构进行测试的代码，以保证获得高质量的、满足各种功能和非功能质量属性要求的架构。除了完成概念、模型设计外，软件架构师一定要参与实际的编码、测试和调试，做一位真正的hands-on

practitioner，这已经成为了敏捷软件工程所倡导的主流文化。

两个架构我们在日常的软件产品和系统开发中，实际上会遇到两种、两个部分的软件架构，即待开发的应用部分的软件架构（简称“应用架构”），以及既有的基础平台部分的软件架构（简称“基础架构”）。这两部分架构之间是互为依赖、相辅相成的关系，它们共同组成了整个软件产品和系统的架构。

基础架构的例子包括：.NET和J2EE等主流的基础平台和各种公共应用框架，由基础库API、对象模型、事件模型、各种开发和应用的扩

展规则等内容组成。我们只有熟悉基础架构的构造细节、应用机理，才能有效地开发出高质量、高性能的上层应用。然而，开发一个面向最终用户的软件应用系统和产品，仅仅掌握一般的计算机高级编程语言知识和基础平台架构、API的使用知识显然是不够的，我们还需要根据客户应用的类型和特点，在基础架构之上，设计出符合用户要求的高质量应用软件。

熟悉OOA、OOD抽象建模技术、设计原则以及架构模式和设计模式等等方法技术，不但有助于我们更好地理解和利用基础平台架构，也有助于我们设计开发出更高质量的应用软件架构。

风险驱动、敏捷迭代的架构设计与开发软件架构将随着软件产品和系统的生命周期而演化，其生命期往往超过了一个工程、一次发布，甚至有可能长达数年之久，因而软件架构无论对于客户还是开发商来说都是一项极其重要的资产。

软件架构的设计应该遵循什么样的开发过程？或者说，有没有更好的、成熟的软件架构设计和开发过程？回答是，21世纪的软件架构设计应该优先采用敏捷迭代的开发方式和方法。与传统做法不同，敏捷迭代开发主张软件架构采用演进式设计（evolutionary design），一个软件产品或系统的架构是通过多次迭代，乃至多次发布，在开发生命周期中逐步建立和完善起来的。

好的软件架构不是一蹴而就的。在架构设计开发过程中，我们应该尽量避免瀑布式思维，通过一个“架构设计阶段”来完成系统的架构设计乃至详细设计，然后再根据架构图纸和模型，在“编码实现阶段”按图索骥进行架构的编码与实现。这种传统做法的错误在于认为软件架构就是图纸上的模型，而不是真正可以高质量执行的源代码。几十年的软件工程实践表明，没有经过代码实现、测试、用户确认过的架构设计，往往会存在着不可靠的臆想、猜测和过度设计、过度工程，极易造成浪费和返工，导致较高的失败率。

风险是任何可能阻碍和导致软件产品/系统研发失败的潜在因素和问题。软件架构是软件产品和系统研发的主要矛盾和主要技术风险，软件架构的质量决定了整个软件系统和产品的质量。不确定性往往是

软件架构设计当中一种最大的潜在风险。因此，软件架构的设计与开发应该遵循风险驱动的原则，在整个开发生命周期内至始至终维护一张风险问题清单，随着迭代的前进，根据风险的实时动态变化，首先化解和处理最主要的架构风险，再依次化解和处理次要的架构风险。

架构设计的可视化建模软件架构设计的难度源于软件设计问题本身的复杂性，一个复杂的软件系统往往存在大量复杂的、难于被人类所理解的细节和不确定因素。抽象与建模是人类自诞生以来就已掌握的理解复杂事物的方法，因而人类所从事的软件设计工作本质上也是一个不断建模的过程。我们可以通过各种抽象的模型和视图，从各个不同层次、宏观和微观的角度来理解复杂的软件架构，以保证作出正确和有效的设计。

有人认为：“软件架构就是源代码（source codes）”以及“源代码就是设计”。这种说法其实是片面的。什么是真正的软件？我们知道，最终可以在电脑上执行的真正的软件其实是二进制代码0和1，借助编译器我们把高级编程语言翻译成底层的汇编语言、机器语言等，没有人能直接、完整地看到二进制程序在CPU上的实际运行状况（runtime），人们大多只能通过各种调试工具、窗口视图等方式来间接地动态观察这些真正的软件的运行片段。因此，Java、C#、C++ 等等设计时（design time）源代码在本质上也是一种模型，虽然是一种经处理后可执行的静态模型，但显然它们并不是真实软件和软件架构的全部。可见，源代码模型（有时也叫实现模型）与UML模型其实都是软件架构的一种模型（逻辑反映），差别就在于抽象层次的不同。完整的软件架构（建筑）不仅仅包括源代码（实现模型），还包括了需求模型、分析模型、设计模型、实现模型和测试模型等等许多模型，软件架构本身就是一组模型的集合。

UML、SysML是当前国际上流行的软件/系统架构可视化建模语言。在编写实际的代码之前，利用包图、类图、活动图、交互图、状态图等等各种标准图形符号对软件架构进行建模，探讨和交流各种可行的设计方案，发现潜在的设计问题，保证具体编码实现之前抽象设计的正确性，被实践证明是一种非常有效和高效、敏捷的工作方式。

架构设计的重用重用（Reuse）是在软件工程实践中获得高效率、高质量产品和系统开发的一种基本手段和主要途径，通过有组织的、系统和有效的重用，我们往往可以获得10倍率以上的效率提升。而一个优秀的、有长久生命力的软件架构（比方主流的一些框架软件），其本身或其组件被重用的次数越多，其体现的价值也就越大。

软件重用有各种不同的范围、层次、粒度和类型，从函数重用、类重用、构件/组件重用、库（API）重用，到框架重用、架构重用、模式重用，再到软件设计知识、思想的重用等等，重用的效能和效果各有不同。

软件工程经过几十年的发展，已经积累了大量的软件架构模式和设计模式，它们记载、蕴藏了大量成熟、已经验证的软件设计知识、思想和经验。我们平时对各种基础平台、主流框架和API的应用和调用，本身就是一种最为普遍的重用形式。而一个优秀、成熟的软件研发组织，必然会在日常开发中注意收集各种软件设计知识和经验，建立和维护基于架构模式和设计模式等内容的软件重用知识库，积极主动和频繁地运用各种软件模式来解决实际工程问题。

框架（Framework）是一类具有高可重用度的软件，针对某一类应用或领域，它们具有非常灵活的、高度可扩展的软件架构。那么，如何才能设计出可重用的软件架构或其组件？借助于OOA、OOD等抽象分析和设计技术是一种重要的方法。人们在实践中发现，往往越抽象的东西，其适应面也就越广，可重用度也就越高；相反，越具体的东西，其适应面也就越窄，可重用度也就越低。重用，意味着充分利用现成、既有的东西、成果来解决新问题或重复的问题，以“不变”应“ 万变”。在软件架构设计中，应该主动地区分软件架构中的“不变”与“可变”之处，系统地管理

好这些稳定点和变化点以适应未来的变化，这也是提高软件架构重用度、获得高质量框架设计的一种重要方法。

架构设计的权衡与其它所有工程行业一样，软件工程本质上也是一门讲究权衡的科学和艺术。软件架构设计的最难之处往往在于如何在各种相互竞争、矛盾的制约条件之下，作出巧妙的最佳权衡。软件

架构设计的权衡水平，也是最能体现软件架构师的设计经验、能力和技巧的地方。

在软件开发和软件架构的设计过程中，从选择平台，到选择语言，选择框架，选择设计模式，选择工具…等等，我们无时不刻都需要权衡，对各种候选项作出合理评判。在架构师带领下，软件研发团队往往还需要对近期目标与远期目标、质量与速度和效率、质量与成本、功能与性能、灵活性与复杂性…等等许多彼此矛盾的设计选项、因素和约束进行细致、小心和理性的权衡。

理性权衡意味着科学决策。进行有效的架构设计权衡，离不开科学的方法，也就是如何运用定量分析和定性分析相结合的方法、因果逻辑和根源分析等等技术，找到最终的甜点（Sweet Spot）。许多时候，能否在很短的时间内作出迅速、果断而正确的科学权衡与取舍决策，构成了一个软件研发团队核心竞争能力的一部分。

系统架构设计师:AOP技术应用

17.2 AOP技术应用

面向方面编程（AOP）是面向对象编程（OOP）的一种扩展技术，能够很好的解决横切关注点问题以及相关的设计难题来实现松散耦合。

1)不是对OOP的否定而是扩展.

2)AOP其实不是新的概念

3)动态代理技术它是AOP的基础，InvocationHandler

系统架构设计师:CLRProfiler

8.2.6 CLR Profiler

CLR Profiler 是Microsoft提供的一种内存分析工具，并且可以从MSDN下载。它使您能够查看应用程序进程的托管堆以及调查垃圾回收器的行为。使用该工具，您可以获取有关应用程序的执行、内存分配和内存消耗的有用信息。这些信息可以帮助您了解应用程序的内存使用方式以及如何优化应用程序的内存使用情况。

CLR Profiler 在日志文件中记录内存消耗和垃圾回收器行为信息。然后，您可以使用一些不同的图形视图，通过CLR Profiler 来分析该数据。一些比较重要的视图是：

1)llocation Graph。显示有关对象分配方式的调用堆栈。您可以使用该视图来查看方法进行的每个分配的系统开销，隔离您不希望发生的分配，以及查看方法可能进行的过度分配。

2)sembly, Module, Function, and Class Graph。显示哪些方法造成了哪些程序集、函数、模块或类的加载。

3)ll Graph。使您可以查看哪些方法调用了其他哪些方法以及相应的调用频率。您可以使用该图表来确定库调用的系统开销，以及调用了哪些方法或对特定方法进行了多少个调用。

4)me Line。提供了有关应用程序执行的基于文本的、按时间顺序的层次结构视图。使用该视图可以查看分配了哪些类型以及这些类型的大小。您还可以使用该视图查看方法调用使得哪些程序集被加载，并且分析您不希望发生的分配。您可以分析完成器的使用情况，并且识别尚未实现或调用 Close 或 Dispose 从而导致瓶颈的方法。您可以使用CLR 来识别和隔离与垃圾回收有关的问题。这包括内存消耗问题（例如，过度或未知的分配、内存泄漏、生存期很长的对象）以及在执行垃圾回收时花费的时间的百分比。

8.3第八章小结

要完全实现智能客户端应用程序的潜能，您需要在应用程序的设计阶段仔细考虑性能问题。

通过在早期阶段解决这些性能问题，您可以在应用程序设计过程中控制成本，并减小在开发周期的后期陷入性能问题的可能性。本章分析了许多不同的技术，您可以在规划和设计智能客户端应用程序时使用这些技术，以确保优化它们的性能。本章还考察了您可以用来确定智能客户端应用程序内的性能问题的一些工具和技术。

系统架构设计师:hibernate配置

24.2 hibernate配置

Hibernate同时支持xml 格式的配置文件，以及传统的properties文件配置方式，一般我们采用xml 型配置文件。xml配置文件提供了更易读的结构和更强的配置能力，可以直接对映射文件加以配置.

24.3Hibernate的使用问题

24.3.1标示符

l)Increment

2)Identity

3)Sequence

4)Assign

5)Hilo

24.3.2注意的问题

l)Lazy

2)Inverse

3)Outer-join

4)大数据量删除更新

24.4技术经理和高级程序员如何利用Spring 整合hibernate

l)SessionFactory

2}HibernateDaoSupport 3） HibernateTemplate

系统架构设计师:处理图像

处理图像如果您的应用程序显示大量图像文件（例如，.jpg 和 .gif

文件），则您可以通过以位图格式预先呈现图像来显著改善显示性能。要使用该技术，请首先从文件中加载图像，然后使用PARGB 格式将其呈现为位图。下面的代码示例从磁盘中加载文件，然后使用该类将图像呈现为预乘的、Alpha 混合RGB 格式。例如：

[C#] if ( image != null && image is Bitmap )

{ Bitmap bm = (Bitmap)image。

Bitmap newImage = new Bitmap( , ,

32bppP Argb )。

using ( Graphics g = age( newImage ) )

{

age(

) )。

}

bm, new Rectangle( 0,0, ,

image = newImage。

}

[Visual Basic .NET] If Not(image Is Nothing) AndAlso (TypeOf

image Is Bitmap) Then Dim bm As Bitmap = CType(image, Bitmap)

Dim newImage As New Bitmap(, , _

32bppP Argb)

Using g As Graphics = age(newImage)

age(bm,

))

End Using

image = newImage End If

系统架构设计师:管理可用资源

管理可用资源公共语言运行库(CLR) 使用垃圾回收器来管理对象生存期和内存使用。这意味着无法再访问的对象将被垃圾回收器自动回收，并且自动回收

内存。由于多种原因无法再访问对象。例如，可能没有对该对象的任何引用，或者对该对象的所有引用可能来自其他可作为当前回收周期的一部分进行回收的对象。尽管自动垃圾回收使您的代码不必负责管理对象删除，但这意味着您的代码不再对对象的确切删除时间具有显式控制。请考虑下列原则，以确保您能够有效地管理可用资源：

1)确保在被调用方对象提供 Dispose 方法时该方法得到调用。如果您的代码调用了支持Dispose 方法的对象，则您应该确保在使用完该对象之后立即调用此方法。调用Dispose 方法可以确保抢先释放非托管资源，而不是等到发生垃圾回收。除了提供Dispose 方法以外，某些对象还提供其他管理资源的方法，例如，Close 方法。在这些情况下，您应该参考文档资料以了解如何使用其他方法。例如，对于SqlConnection 对象而言，调用Close 或Dispose 都足可以抢先将数据库连接释放回连接池中。一种可以确保您在对象使用完毕之后立即调用 Dispose 的方法是使用 Visual C# .NET 中的using 语句或Visual

Basic .NET 中的Try/Finally 块。下面的代码片段演示了Dispose 的用New Rectangle(0, 0, ,

法。

C# 中的using 语句示例：

using( StreamReader myFile = new

StreamReader("C:")){

string contents = End()。

//... use the contents of the file } // dispose is called and the

StreamReader’s resources released Visual Basic .NET 中的Try/Finally 块示例：Dim myFile As StreamReader myFile = New

StreamReader("C:")

Try String contents = End()

’... use the contents of the file

Finally

() End Try注：在 C# 和 C++ 中，Finalize 方法是作为析构函数实现的。在Visual Basic .NET 中，Finalize 方法是作为Object 基类上的Finalize 子例程的重写实现的。

2)如果您在客户端调用过程中占据非托管资源，则请提供 Finalize

和 Dispose 方法。如果您在公共或受保护的方法调用中创建访问非托管资源的对象，则应用程序需要控制非托管资源的生存期。在图8.1 中，第一种情况是对非托管资源的调用，在此将打开、获取和关闭资源。在此情况下，您的对象无须提供 Finalize 和 Dispose 方法。在第二种情况下，在方法调用过程中占据非托管资源；因此，您的对象应该提供Finalize 和Dispose 方法，以便客户端在使用完该对象后可以立即显式释放资源。

垃圾回收通常有利于提高总体性能，因为它将速度的重要性置于内存利用率之上。只有当内存资源不足时，才需要删除对象；否则，将使用所有可用的应用程序资源以使您的应用程序受益。但是，如果您的对象保持对非托管资源（例如，窗口句柄、文件、GDI 对象和网络连接）的引用，则程序员通过在这些资源不再使用时显式释放它们可以获得更好的性能。如果您要在客户端方法调用过程中占据非托管资源，则对象应该允许调用方使用IDisposable 接口（它提供

Dispose 方法）显式管理资源。通过实现IDisposable，对象将通知它可被要求明确进行清理，而不是等待垃圾回收。实现IDisposable 的对象的调用方在使用完该对象后将简单地调用Dispose 方法，以便它可以根据需要释放资源。注如果您的可处置对象派生自另一个也实现了IDisposable 接口的对象，则您应该调用基类的Dispose 方法以使其可以清理它的资源。您还应该调用实现了IDisposable 接口的对象所拥有的所有对象上的Dispose。Finalize 方法也使您的对象可以在删除时显式释放其引用的任何资源。由于垃圾回收器所具有的非确定性，在某些情况下，Finalize 方法可能长时间不会被调用。实际上，如果您的应用程序在垃圾回收器删除对象之前终止，则该方法可能永远不会被调用。然而，需要使用Finalize 方法作为一种后备策略，以防调用方没有显式调用 Dispose 方法（Dispose 和 Finalize 方法共享相同的资源清理代码）。通过这种方式，可能在某个时刻释放资源，即使这发生在最佳时刻之后。注要确保 Dispose 和 Finalize 中的清理代码不会被调用两次，您应该调用ssFinalize 以通知垃圾回收器不要调用Finalize 方法。垃圾回收器实现了Collect 方法，该方法强制垃圾回收器删除所有对象挂起删除。不应该从应用程序内调用该方法，因为回收周期在高优先级线程上运行。回收周期可能冻结所有UI

线程，从而使得用户界面停止响应。

系统架构设计师:规范

8.2.5规范

您可以使用许多工具和技术来帮助您对应用程序进行规范，并且生成度量应用程序性能所需的信息。这些工具和技术包括：

1)Event Tracing for Windows (ETW)。该 ETW 子系统提供了一种系统开销较低（与性能日志和警报相比）的手段，用以监控具有负载的系统的性能。这主要用于必须频繁记录事件、错误、警告或审核的服务器应用程序。

2)Enterprise Instrumentation Framework (EIF)。EIF 是一种可扩展且可配置的框架，您可以使用它来对智能客户端应用程序进行规划。它提供了一种可扩展的事件架构和统一的 API - 它使用Windows

中内置的现有事件、日志记录和跟踪机制，包括Windows

Management Instrumentation (WMI)、Windows Event Log 和Windows Event Tracing。它大大简化了发布应用程序事件所需的编码。如果您计划使用EIF，则需要通过使用EIF .msi 在客户计算机上安装 EIF。如果您要在智能客户端应用程序中使用EIF，则需要在决定应用程序的部署方式时考虑这一要求。

3)Windows Management Instrumentation (WMI)。WMI 组件是Windows 操作系统的一部分，并且提供了用于访问企业中的管理信息和控件的编程接口。系统管理员常用它来自动完成管理任务（通过使用调用WMI 组件的脚本）。

4)调试和跟踪类。.NET Framework 在sis 下提供了 Debug 和 Trace 类来对代码进行规范。Debug 类主要用于打印调试信息以及检查是否有断言。Trace 类使您可以对发布版本进行规范，以便在运行时监控应用程序的完好状况。在 Visual Studio .NET 中，默认情况下启用跟踪。在使用命令行版本时，您必须为编译器添加

/d:Trace 标志，或者在 Visual C# .NET 源代码中添加 #define TRACE，以便启用跟踪。对于 Visual Basic .NET 源代码，您必须为命令行编译器添加/d:TRACE=True。

系统架构设计师:规划SOA参考

架构

2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见：

SOA 参考架构 (Reference Architecture) 是一个框架，使各个工程都有一个遵从的依据，借以促进一致性、最佳实践典范，和标准化。参考架构并不受限于目前的IT 现况，而应该针对一个经过深思熟虑的愿景目标，可以说是IT 指导未来所有的新开发工作，借以实现该目标的参考依据。一般来说，2-3 年的规划，是一个比较合适的涵盖范围，既能提供足够的时间来达成面向服务的转型，而又不至于过于长远而虚幻。因此，参考架构提供了一个沟通目标愿景的方法，协助部门和

角色各异的IT 人员，逐渐朝向该目标会合。

高效的SOA 需要采用新的方法来对待IT 基础设施，并且根据个别企业的需求来量身定做，并将服务基础架构、共享的技术服务、安全服务，以及信息／数据、和遗留系统访问服务等，全部定义在内。

为了满足 SOA 的要求，所有公司都需要 SOA 参考架构和路线图，来指导部署一套能随时间演进、而逐渐丰富的工业级服务基础设施，同时指导对面向服务应用的开发和管理。

此外，企业也需要对参与SOA 架构的各个个别系统的设计，进行监管，并在适当的地方，建立通用服务，透过协作来发挥更高的效率。对于这些举措，连接端点的标准化（通过建立定义清晰的契约和接口），是达成IT 系统一致性的先决条件。

SOA 参考架构指导所有实施SOA 的各个工程，能共同朝向企业级服务，和 SOA 基础架构标准方向的集中发展，尽早使企业从中获益。换句

话说，参考架构规划的重点，在于开发一个特定于某个企业需要、切实可行的路线图，以填补当前和愿景目标之间的鸿沟；评估用于开发、部署和管理、监控的现有系统和技术，定义目标状态愿景，目标参考架构模型。

SOA 参考架构可说是指导 SOA 成功的蓝图，其作用包括：

促进IT 与业务的紧密配合：参考架构的制定，以业务驱动力和 IT

目标为出发点，分析 SOA 解决方案能对这些驱动力带来多大的正面影响，进而为从目前IT 现况演化到愿景架构，定出实现架构、相关规范及路线图。参考架构因此提供了从业务和IT 目标，到实现架构间的可跟踪性，是业务与IT 之间进行沟通的重要媒介，是企业实现业务灵活性、可管理性和变更规划的基础。

协助企业向重用、团队协作和资源共享的文化迁移：参考架构确立了 SOA 架构标准和技术部署的最佳实践，为日后各个SOA 的实施工程，订立架构遵从性的度量标准和指标。

参考架构并非一成不变。在一个新的 SOA 策略与规划迭代中，SOA 的参考架构和规范标准，可能需要针对新的业务、IT 情况，和已

实施的SOA 工程中得到的反馈，进行调整，因此，SOA 参考架构不仅是IT 模板，也是也描述SOA 原则和标准的活文档。

我们可以将参考架构的内容，粗分为两大部分：对服务建立一套共同的词汇和做法，包括：

服务的正式定义–例如服务必须由契约(contract)、接口(interface)，和实现(implementation) 所组成服务的分类（核心业务功能服务，数据服务，展现服务等），以及各类服务的设计原则和建议接口标准 (JMS, RMI, HTTP 等)，建议的接口样式（例如：尽量采用粗粒度、异步的服务调用模式），可靠性要求等

需要遵从的WS-* 标准

安全策略服务版本控制策略服务和数据模型采用规范服务生命周期定义

与服务基础设施，例如企业服务总线(ESB)、业务流程管理(BPM)、注册库(Registry)、资产库 (Repository) 等相关的规范，包括：必须支持什么样的部署配置

必须具备什么样的能力各个部件的责任部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务；换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系各个部件应支持那些科技和标准（例如：SCA, SDO…）有哪些安全顾虑需要考虑，如何管理权限

要采用哪些产品由于在规划服务基础设施参考架构时，需要涵盖几类 SOA 参与者和干系人 (stakeholders) 各自不同的顾虑，包括架构师、程序员、和负责部署、运营、监控的IT 人员，我们可以采用一个针对服务基础设施参考架构调整过的4+1 视图（如下），来协助我们分离顾虑，来将不同层面的规范和目标架构一一制定，通过逻辑、实现、部署，和进程等四个视图，配合最佳实践典范和模式，来对参考架构的各个层面，进行描述和规范，如附图。

参考架构的规划过程（如下图），应先起于业务驱动力 (business

drivers) 分析，可有助确保目标架构能够支持业务的发展策略和方向，展现SOA 建设对业务的价值，彰显SOA 投资的正当性，并获得相关

业务部门的经费赞助。以金融行业为例，业务驱动力包括像是：

提升效率

借贷流程优化

呼叫中心优化增长销售额，并显著超越同业

快速灵活地推出创新的金融商品

扩展客户关系，统合客户数据

交叉销售依据关系定价的策略降低成本

这一类的价值驱动。分析业务的价值驱动后，接着考虑各种IT 目标，以及它们如何支持这些业务驱动力；例如：从关注各业务线烟囱／竖井式的应用系统，转向专注于跨系统／业务线的流程／服务

IT 资产重用提高跨部门协作的业务流程的透明度

并且应订立评价标准，作为日后考核实现各价值驱动力的指标。接着下来，我们可以根据业务和IT 驱动力，进一步制定恰当的SOA 策略，考虑采用SOA，将对那些业务线，在那些驱动力方面，产生最大的价值，据以订立实施SOA 工程的优先级别。

√√ 代表SOA 工程能产生很大的正向影响，依此类推。

针对各价值驱动力，我们可以参考附图中的矩阵分析方式，从价值链或业务线中的各个主要的职能（纵向），和各个识别出来的业务和IT 驱动力（横向），对SOA 所可能产生的正面影响力，一一进行评估，进而挑选出面向服务解决方案最能嘉惠的业务能力，作为首期实施SOA 工程的切入点。图中的范例只是一个三万尺高空的起点，在真实的情况下，往往会针对范例中某个或某几个得分较高的业务线，往下展开细化，对该业务线中的各个主要业务能力，进一步进行SOA

价值驱动力分析；换句话说，价值链分析中的各个职能域，应该自粗到细，逐步钻取、drill down 到适当的深度，才能更精准地确定SOA

能对哪些要迫切改善的业务能力，带来最大价值。

依据业务和IT 驱动力，选定了SOA 策略后。接着应根据企业目前的现况，和未来2-3 年的目标，进行差距分析，并根据最佳实践典范(best practices)，制定 SOA 发展的蓝图、路线图和指导规范，完成参考架构的规划。接着便可开始根据路线图中制定的工程，以渐进的

方式，通过一致的服务工程方法，一个接一个工程去执行，并在此过程中，逐渐将蓝图中的服务基础设施搭建起来。

系统架构设计师:考虑用户的观

点

8.2.1.1考虑用户的观点

当您为智能客户端应用程序确定合适的性能目标时，您应该仔细考虑用户的观点。对于智能客户端应用程序而言，性能与可用性和用户感受有关。例如，只要用户能够继续工作并且获得有关操作进度的足够反馈，用户就可以接受漫长的操作。在确定要求时，将应用程序的功能分解为多个使用情景或使用案例通常是有用的。您应该识别对于实现特定性能目标而言关键且必需的使用案例和情景。应该将许多使用案例所共有且经常执行的任务设计得具有较高性能。同样，如果任务要求用户全神贯注并且不允许用户从其切换以执行其他任务，则需要提供优化的且有效的用户体验。如果任务不太经常使用且不会阻止用户执行其他任务，则可能无须进行大量调整。对于您识别的每个性能敏感型任务，您都应该精确地定义用户的操作以及应用程序的响应方式。您还应该确定每个任务使用的网络和客户端资源或组件。该信息将影响性能目标，并且将驱动对性能进行度量的测试。可用性研究提供了非常有价值的信息源，并且可能大大影响性能目标的定义。正式的可用性研究在确定用户如何执行他们的工作、哪些使用情景是共有的以及哪些不是共有的、用户经常执行哪些任务以及从性能观点看来应用程序的哪些特征是重要的等方面可能非常有用。如果您要生成新的应用程序，您应该考虑提供应用程序的原型或模型，以便可以执行基本的可用性测试。

8.2.1.2考虑应用程序操作环境

对应用程序的操作环境进行评估是很重要的，因为这可能对应用程序施加必须在您制定的性能目标中予以反映的约束。位于网络上的服务可能对您的应用程序施加性能约束。例如，您可能需要与您无法控制的Web 服务进行交互。在这种情况下，需要确定该服务的性能，并且确定这是否将对客户端应用程序的性能产生影响。您还应该确定

任何相关服务和组件的性能如何随着时间的变化而变化。某些系统会经受相当稳定的使用，而其他系统则会在一天或一周的特定时间经受变动极大的使用。这些区别可能在关键时间对

应用程序的性能造成不利影响。例如，提供应用程序部署和更新服务的服务可能会在星期一早上9 点缓慢响应，因为所有用户都在此时升级到应用程序的最新版本。另外，还需要准确地对所有相关系统和组件的性能进行建模，以便可以在严格模拟应用程序的实际部署环境的环境中测试您的应用程序。对于每个系统，您都应该确定性能简况以及最低、平均和最高性能特征。然后，您可以在定义应用程序的性能要求时根据需要使用该数据。您还应该仔细考虑用于运行应用程序的硬件。您将需要确定在处理器、内存、图形功能等方面的目标硬件配置，或者至少确定一个如果得不到满足则无法保证性能的最低配置。通常，应用程序的业务操作环境将规定一些更为苛刻的性能要求。例如，执行实时股票交易的应用程序将需要执行这些交易并及时显示所有相关数据。

系统架构设计师:浅谈架构

2009年下半年全国计算机等级考试你准备好了没?考计算机等级考试的朋友,2009年下半年全国计算机等级考试时间是2009年9月19日至23日。

不得不说的就是规范性的东西，我认为规范是个很重要的东西，当然，规范不只是说大家统一用某种形式命名变量，方法等等，这只是对程序员而言的规范，如果这个划做横向规范的话，那么纵向规范就是面对客户的规范。对程序员的规范，我不想多说了，注释，变量，方法，文档。当然未必每个人都做到了这些。我想说的是对客户的规范问题。

对客户的规范有很多中，比如小细节CS系统中的Anchor怎么设置，Dock怎么设置，如何让页面看起来更加让用户舒心，如何做焦点设置。大到如何给客户做培训，如何防止用户看到不友好页面，如何简化用户操作等等，这些都是属于规范性范畴。对于焦点设置，我有深刻体会，前段时间找工作，某网站输入搜索条件以后，按钮回车老

是达不到焦点上去，非要我去移下鼠标点击，很不爽。

第二点，对于一个完善的架构，日志处理机制是必须做好的，日志处理不只是简单的说输出完成这么简单。首先，必须要通过配置控制在什么时候输出，在什么地方输出，如何输出，怎么记录，是记录数据库还是日志文件中。如何灵活让用户控制日志输出方式。

第三点，对于一个完善的架构，异常处理机制也是一个重点。异常怎么处理，如何记录，是记录到系统中，还是异常文件，还是数据库异常表，或者发给技术部邮件等等，如何做异常记录，在产生异常以后更容易让用户，技术人员看到异常产生的原因，这个是一个比较重要的模块。

第四点，对于一个完善的架构，配置文件是必须的，有些工程只是简单的对里加些配置，我认为这根本不够完善，对于配置而言，有很多需要配置的内容，比如系统连接哪种数据库，客户信息，再比如是否记录日志，异常等，是否允许用户注册等等灵活功能的控制完全可以在配置中实现。

第五点，对于一个完善的架构，如何做好权限是很重要的一块内容，比如权限如何控制，怎么处理用户，组，模块，部门等等之间的关系，工作流如何做，如何让权限与工作流做良好匹配，比如某审批人员出差了，如何处理其审批流程等等，虽然这点，我自己也在不断研究，但我想这一块非常重要。

第六点，对于一个完善的架构，流水号生成功能也相当重要，任何一种系统，不管是信息管理系统还是电子商务平台，一定都会要求按一定格式生成某套流水号，流水号也必须有灵活性，这点非常重要。

第七点，对于一个完善的架构，必须要有代码生成功能，比如基础业务类生成，实体类生成，最好可以控制数据库主外键关系等等，这样能减少程序员的很多无趣的工作量。

这是我目前总结的几个重要点，另外当然包括多语言，多皮肤等等，我想这些目前来说还未必非常重要。

当我想到的时候我还会做一些补充。

系统架构设计师:如何成为软件

架构师

2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见：

那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。关于软件学院我接触过不少，其宗旨绝大部分都是造就（or打造）企业需要的软件架构师（or程序员or 人才）。教师来源与企业、学员来源与企业、人才输送到企业是他们办学的手段。尽管各个如雨后春笋般出现的软件学院口号差不多，但恐怕大多只是为了圈钱卖学位了事...

架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考：

1、架构师胚胎（程序员）学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信（通信协议）——学习搭建应用系统所必须的原材料。

2、架构师萌芽（高级程序员）学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice（研究生可以研究网络计算机、高性能并发处理等内容）

3、架构师幼苗（设计师）应该在掌握上述基础之上，结合实际工程经验，透彻领会应用设计模式，内容包括设计模式（c++版本、java版本）、ejb设计模式、J2EE架构、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际工程中的应用以及小组开发、团队管理。

系统架构设计师:软件架构师之

路

2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始

将采用新修编的考试大纲，具体见：

架构师（Architecture）是目前很多软件企业最急需的人才，也是一个软件企业中薪水最高的技术人才。换句话说，架构师是企业的人力资本，与人力资源相比其能够通过架构、创新使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师、架构师的作用、如何定位一个架构师和如何成为一个架构师呢？这是许多企业、许多程序员朋友希望知道的或希望参与讨论的话题内容。

所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。

在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。

与建筑学类似，如果软件系统没有一个好的架构是不可能成为成功的软件系统的。没有图纸的建筑工地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是，软件工程中亦然！

由于国内合格、胜任的软件架构师极为少见，直接导致了我国民族软件产业水平的落后。在未来以信息产业为主导的社会，信息产业水平的低下将直接影响国家核心竞争力。究其原因，

无企业非急功近利、个人缺乏引导。

企业的急功近利是有无法克服的原因的，那就是社会发展总体水平。“生存是第一位的，赚钱是第一位的”，多年来许多客户抱怨国

内的软件公司无法信任、系统工程累做累败、公司越换越差，但因国外不可能给中国做应用系统工程还不得不找国内软件公司做。由于人月费用低、公司开发成本高，软件企业对于应用只能草草了事，拿钱走人（很多公司拿不到后期尾款）。这样的环境下，企业几乎无法投入更多资源培养自己的架构师，加上眼花缭乱的跳槽风气企业更是不愿投入……

系统架构设计师:使用分页和惰

性加载

8.1.7.4使用分页和惰性加载

在大多数情况下，您应该仅在需要时检索或显示数据。如果您的应用程序需要检索和显示大量信息，则您应该考虑将数据分解到多个页面中，并且一次显示一页数据。这可以使用户界面具有更高的性能，因为它无须显示大量数据。此外，这可以提高应用程序的可用性，因为用户不会同时面对大量数据，并且可以更加容易地导航以查找他或她需要的确切数据。例如，如果您的应用程序显示来自大型产品目录的产品数据，则您可以按照字母顺序显示这些项，并且将所有以“A”开头的产品显示在一个页面上，将所有以“B”开头的产品显示在下一个页面上。然后，您可以让用户直接导航到适当的页面，以便他或她无须浏览所有页面就可以获得他或她需要的数据。以这种方式将数据分页还使您可以根据需要获取后台的数据。例如，您可能只需要获取第一页信息以便显示并且让用户与其进行交互。然后，您可以获取后台中的、已经准备好供用户使用的下一页数据。该技术在与数据缓存技术结合使用时可能特别有效。您还可以通过使用惰性加载技术来提高智能客户端应用程序的性能。您无须立即加载可能在将来某个时刻需要的数据或资源，而是可以根据需要加载它们。您可以在构建大型列表或树结构时使用惰性加载来提高用户界面的性能。在此情况下，您可以在用户需要看到数据时（例如，在用户展开树节点时）加载它。

系统架构设计师:事务原则

事务原则事务可以提供重要的支持，以确保不会违反业务规则并维护数据一致性。事务可以确保一组相关任务作为一个单元成功或失

败。您可以使用事务来维护本地数据库和其他资源（包括消息队列的队列）之间的一致性。对于需要在网络连接不可用时使用脱机缓存数据的智能客户端应用程序，您应该将事务性数据排队，并且在网络连接可用时将其与服务器进行同步。您应该避免使用涉及到位于网络上的资源的分布式事务，因为这些情况可能导致与不断变化的网络和资源响应时间有关的性能问题。如果您的应用程序需要在事务中涉及到位于网络上的资源，则应该考虑使用补偿事务，以便使您的应用程序能够在本地事务失败时取消以前的请求。尽管补偿事务在某些情况下可能不适用，但它们使您的应用程序能够按照松耦合方式在事务的上下文内与网络资源交互，从而减少了不在本地计算机控制之下的资源对应用程序的性能造成不利影响的可能性。

系统架构设计师:性能调整过程

8.2.2性能调整过程

对应用程序进行性能调整是一个迭代过程。该过程由一些重复执行直至应用程序满足其性能目标的阶段组成。（请参见图8.2。）正如图8.2 所阐明的，性能调整要求您完成下列过程：

1)建立基准。在您开始针对性能调整应用程序时，您必须具有与性能目标、目标和度量标准有关的定义良好的基准。这可能包括应用程序工作集大小、加载数据（例如，目录）的时间、事务持续时间等等。

2)收集数据。您将需要通过针对您已经定义

的性能目标度量应用程序的性能，来对应用程序性能进行评价。性能目标应该体现特定的且可度量的度量标准，以使您可以在任何时刻量化应用程序的性能。要使您可以收集性能数据，您可能必须对应用程序进行规范，以便可以发布和收集必需的性能数据。下一节将详细讨论您可以用来完成这一工作的一些选项。

3)分析结果。在收集应用程序的性能数据之后，您将能够通过确定哪些应用程序功能要求最多的关注，来区分性能调整工作的轻重缓急。此外，您可以使用该数据来确定任何性能瓶颈的位置。通常，您将只能够通过收集更详细的性能数据来确定瓶颈的确切位置：例如，

通过使用应用程序规范。性能分析工具可能帮助您识别瓶颈。

4)调整应用程序。在已经识别瓶颈之后，您可能需要修改应用程序或其配置，以便尝试解决问题。您应该致力于将更改降低至最低限度，以便可以确定更改对应用程序性能的影响。如果您同时进行多项更改，可能难以确定每项更改对应用程序的总体性能的影响。

5)测试和度量。在更改应用程序或其配置之后，您应该再次测试它以确定更改具有的效果，并且使新的性能数据得以收集。性能工作通常要求进行体系结构或其他具有较高影响的更改，因此彻底的测试是很关键的。您的应用程序测试计划应该针对预料到的所有情况，在配置了适当硬件和软件的客户计算机上演习应用程序所实现的完整范围的功能。如果您的应用程序使用网络资源，则应该加载这些资源，以便您可以获得有关应用程序在此类环境中所具有的性能的准确度量。上述过程将使您可以通过针对特定目标度量应用程序的总体性能，来重点解决特定的性能问题。

系统架构设计师:性能调整和诊

断

8.2性能调整和诊断

在设计和实现阶段处理性能问题是实现应用程序性能目标的最划算的方法。但是，您只有在开发阶段经常且尽早测试应用程序的性能，才能真正有效地优化应用程序的性能。尽管针对性能进行设计和测试都很重要，但在这些早期阶段优化每个组件和所有代码不是有效的资源用法，因此应该予以避免。所以，应用程序可能存在您在设计阶段未预料到的性能问题。例如，您可能遇到由于两个系统或组件之间的无法预料的交互而产生的性能问题，或者您可能使用原来存在的、未按希望的方式执行的代码。在此情况下，您需要追究性能问题的根源，以便您可以适当地解决该问题。本节讨论一些将帮助您诊断性能问题以及调整应用程序以获得最佳性能的工具和技术。

8.2.1制定性能目标

当您设计和规划智能客户端应用程序时，您应该仔细考虑性能方面的要求，并且定义合适的性能目标。在定义这些目标时，请考虑您

将如何度量应用程序的实际性能。您的性能度量标准应该明确体现应用程序的重要性能特征。请努力避免无法准确度量的模糊或不完整的目标，例如，“应用程序必须快速运行”或“应用程序必须快速加载”。您需要了解应用程序的性能和可伸缩性目标，以便您可以设法满足这些目标并且围绕它们来规划您的测试。请确保您的目标是可度量的和可验证的。定义良好的性能度量标准使您可以准确跟踪应用程序的性能，以便您可以确定应用程序是否能够满足它的性能目标。这些度量标准应该包括在应用程序测试计划中，以便可以在应用程序的测试阶段度量它们。本节重点讨论与智能客户端应用程序相关的特定性能目标的定义。如果您还要设计和生成客户端应用程序将消耗的网络服务，则您还需要为这些服务定义适当的性能目标。在此情况下，您应该确保考虑整个系统的性能要求，以及应用程序各个部分的性能与其他部分以及整个系统之间存在怎样的关系。

系统架构设计师:性能工具

8.2.3性能工具

您可以使用许多工具来帮助您收集和分析应用程序的性能数据。本节中介绍的每种工具都具有不同的功能，您可以使用这些功能来度量、分

析和查找应用程序中的性能瓶颈。

注除了这里介绍的工具以外，您还可以使用其他一些选项和第三方工具。

8.2.4使用性能日志和警报

性能日志和警报是作为Windows 操作系统的一部分发行的一种管理性能监控工具。它依靠由各种Windows 组件、子系统和应用程序发布的性能计数器，使您可以跟踪资源使用情况以及针对时间以图形方式绘制它们。您可以使用Performance Logs and Alerts 来监控标准的性能计数器（例如，内存使用情况或处理器使用情况），或者您可以定义您自己的自定义计数器来监控应用程序特定的活动。.NET

CLR 提供了许多有用的性能计数器，它们使您可以洞察应用程序性能的好坏。关系比较大的一些性能对象是：

1).NET CLR 内存。提供有关托管 .NET 应用程序内存使用情况的数据，包括应用程序正在使用的内存数量以及对未使用的对象进行垃圾回收所花费的时间。

2).NET CLR 加载。提供有关应用程序正在使用的类和应用程序域的数量的数据，并且提供有关它们的加载和卸载速率的数据。

3).NET CLR 锁和线程。提供与应用程序内使用的线程有关的性能数据，包括线程个数以及试图同时对受保护的资源进行访问的线程之间的争用率。

4).NET CLR 网络。提供与通过网络发送和接收数据有关的性能计数器，包括每秒发送和接收的字节数以及活动连接的个数。

5).NET CLR 异常。提供有关应用程序所引发和捕获的异常个数的报告。

您的应用程序还可以提供您可以通过使用性能日志和警报轻松监控的、应用程序特定的性能计数器。您可以像以下示例所显示的那样，定义自定义性能计数器：

[C#] PerformanceCounter counter = new

PerformanceCounter( "Category","CounterName", false )。

[Visual Basic .NET]

Dim counter As New PerformanceCounter("Category",

"CounterName", False)

在创建性能计数器对象之后，您可以为您的自定义性能计数器指定类别，并将所有相关计数器保存在一起。PerformanceCounter 类在stics 命名空间中定义，该命名空间中还定义了其他一些可用于读取和定义性能计数器和类别的类。

系统架构设计师:引言

1引言

这里我列了我要讲的提纲，我将就每个论点以实例相结合来阐述系统架构师必须熟知的内容。

1)有矛盾不怕，各种理念共存

2)没有必须和最好，只有合适

3)是一门综合性很强的职业体系，并不是单纯的技术设计问题

4)拥有扎实的基本功，并建立在大量实践经验之上

系统架构师在产品和工程的需求阶段的任务

系统架构设计师:应用实践

17.2.2应用实践

1)简单实用的架构（对网通的例子进行Spring解读）

2)加解密接口

18系统架构师面对轻量级和重量级架构的选择（不限于EJB和Spring）

18.1没有系统级架构的开发

18.2新浪网窄告发布系统分析

l)大并发量

2)高响应率

3)都需要什么（过程）

系统架构设计师:优化显示速度

8.1.7.5优化显示速度

根据您用于显示用户界面控件和应用程序窗体的技术，您可以用多种不同的方式来优化应用程序的显示速度。当您的应用程序启动时，您应

该考虑尽可能地显示简单的用户界面。这将减少启动时间，并且向用户呈现整洁且易于使用的用户界面。而且，您应该努力避免引用类以及在启动时加载任何不会立刻需要的数据。这将减少应用程序和 .NET Framework 初始化时间，并且提高应用程序的显示速度。当您需要显示对话框或窗体时，您应该在它们做好显示准备之前使其保持隐藏状态，以便减少需要的绘制工作量。这将有助于确保窗体仅在初始化之后显示。如果您的应用程序具有的控件含有覆盖整个客户端表面区域的子控件，则您应该考虑将控件背景样式设置为不透明。这可以避免在发生每个绘制事件时重绘控件的背景。您可以通过使用SetStyle 方法来设置控件的样式。使用 枚举可以指定不透明控件样式。您应该避免任何不必要的控件重新绘制操

作。一种方法是在设置控件的属性时隐藏控件。在OnPaint 事件中具有复杂绘图代码的应用程序能够只重绘窗体的无效区域，而不是绘制整个窗体。OnPaint 事件的PaintEventArgs 参数包含一个 ClipRect

结构，它指示窗口的哪个部分无效。这可以减少用户等待查看完整显示的时间。使用标准的绘图优化，例如，剪辑、双缓冲和ClipRectangle。这还将通过防止对不可见或要求重绘的显示部分执行不必要的绘制操作，从而有助于改善智能客户端应用程序的显示性能。

如果您的显示包含动画或者经常更改某个显示元素，则您应该使用双缓冲或多缓冲，在绘制当前图像的过程中准备下一个图像。 命名空间中的ControlStyles 枚举适用于许多控件，并且DoubleBuffer 成员可以帮助防止闪烁。启用DoubleBuffer 样式将使您的控件绘制在离屏缓冲中完成，然后同时绘制到屏幕上。尽管这有助于防止闪烁，但它的确为分配的缓冲区使用了更多内存。

系统架构设计师辅导:IOC技术应

用

17.1 IOC技术应用

1) 我们看看我们常用的配置文件应用（对象级的反转）

2) 在设计模式中，我们已经习惯一种思维编程方式：接口驱动

3) 其实就是javabean的思想，注入和发射思想

17.1.1 IOC的技术结构（面向技术经理和开发人员）

1) XML设置

2) 配置性能和对象还原

3) 反射机制应用方式反射的代价

4) 可配性（替代很多设计模式）

5) 减少硬性编码

DriverManagerDataSource

BasicDataSource JndiObjectFactoryBean

系统架构设计师系:统架构师对

技术的把握

3系统架构师对技术的把握

1)新技术的更新，关注点和深度不同（技术风险）

2)对公司技术实力和技术方向的正确把握

3)不追求最新、不能把架构风险轻易带入系统。注意前期对新技术的测试。

4)设计模式解决了设计可扩展性问题，并不等于解决了性能问题，性能问题要进行瓶颈测试，并对设计和性能的矛盾进行权衡。非功能性问题（并发、网络、事务、操作系统、安全、稳定性、性能）

5)设计原则

系统架构设计师之路:详解面向

过程

2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，

1. 面向过程编程(OPP) 和面向对象编程(OOP)的关系

关于面向过程的编程(OPP)和面向对象的编程(OOP),给出这它们的定义的人很多，您可以从任何资料中找到很专业的解释，但以我的经验来看，讲的相对枯燥一点，不是很直观。除非您已经有了相当的积累，否则说起来还是比较费劲。

我是个老程序员出身，虽然现在的日常工作更多倾向了管理，但至今依然保持编码的习惯，这句话什么意思呢？我跟大家沟通应该没有问题。无论你是在重复我走过的路，或者已经走在了我的前面，大家都会有那么一段相同的经历，都会在思想层面上有一种理解和默契，所以我还是会尽量按照大多数人的常规思维写下去。

面向过程的编程(OPP)产生在前，面向对象的编程(OOP)产生在后，所以面向对象的编程(OOP)一定会继承前者的一些优点，并摒弃前者存在的一些缺点，这是符合人类进步的自然规律。两者在各自的发展和演变过程中，也一定会相互借鉴，互相融合，来吸收对方优点，从而出现在某些方面的趋同性，这些是必然的结果。即使两者有更多的相似点，也不会改变它们本质上的不同，因为它们的出发点就完全是

两种截然不同的思维方式。关于两者的关系，我的观点是这样的：面向对象编程(OOP)在局部上一定是面向过程(OP)的，面向过程的编程(OPP)在整体上应该借鉴面向对象(OO)的思想。这一段说的的确很空洞，而且也一定会有引来争议，不过，我劝您还是在阅读了后面的内容之后，再来评判我观点的正确与否。

像C++、C#、Java等都是面向对象的语言，c,php(暂且这么说，因为php4以后就支持OO)都是面向过程的语言，那么是不是我用C++写的程序一定就是面向对象，用c写的程序一定就是面向过程呢？这种观点显然是没有真正吃透两者的区别。语言永远是一种工具，前辈们每创造出来的一种语言，都是你用来实现想法的利器。我觉得好多人用C#,Java写出来的代码，要是仔细看看，那实际就是用面向对象(OO)的语言写的面向过程(OP)的程序。

所以，即使给关羽一根木棍，给你一杆青龙偃月刀，他照样可以打得你满头是包。你就是扛着个偃月刀，也成不了关羽，因为你缺乏关羽最本质的东西---绝世武功。同样的道理，如果你没有领会OO思想，怎么可能写得出真正的OO程序呢？面向对象(OO)和面向过程(OP)绝对是两种截然不同的思维方式。

那是不是面向过程就不好，也没有存在的必要了？我从来没有这样说过。事实上，面向过程的编程(OPP)已经存在了几十年了，现在依然有很多人在使用。它的优点就是逻辑不复杂的情况下很容易理解，而且运行效率远高于面向对象（OO）编写的程序。所以，系统级的应用或准实时系统中，依然采用面向过程的编程(OPP)。当然，很多编程高手以及大师级的人物，他们由于对于系统整体的掌控能力很强，也喜欢使用面向过程的编程(OPP)，比如像Apache,QMail,PostFix,ICE等等这些比较经典的系统都是OPP的产物。

像php这些脚本语言，主要用于web开发，对于一些业务逻辑相对简单的系统，也常使用面向过程的编程(OPP)，这也是php无法跨入到企业级应用开发的原因之一，不过php5目前已经能够很好的支持OO了。

2.详解面向过程的编程(OPP)

在面向对象出现之前，我们采用的开发方法都是面向过程的编程(OPP)。面向过程的编程中最常用的一个分析方法是“功能分解”。我们会把用户需求先分解成模块，然后把模块分解成大的功能，再把大的功能分解成小的功能，整个需求就是按照这样的方式，最终分解成一个一个的函数。这种解决问题的方式称为“自顶向下”，原则是“先整体后局部”，“先大后小”，也有人喜欢使用“自下向上”的分析方式，先解决局部难点，逐步扩大开来，最后组合出来整个程序。其实，这两种方式殊路同归，最终都能解决问题，但一般情况下采用“自顶向下”的方式还是较为常见，因为这种方式最容易看清问题的本质。

我举个例子来说明面向过程的编程方式:

用户需求：老板让我写个通用计算器。

最终用户就是老板，我作为程序员，任务就是写一个计算器程序。OK，很简单，以下就是用C语言完成的计算器：假定程序的文件名为：main.c。

int main(int argc, char *argv[]){

//变量初始化

int nNum1,nNum2。

char cOpr。

int nResult。

nNum1 = nNum2 = 0。

cOpr = 0。

nResult = 0。

//输入数据printf("Please input the first number:rn")。

scanf("%d",&nNum1)。

printf("Please input the operator:rn")。

scanf("%s",&cOpr)。

printf("Please input the second number:rn")。

scanf("%d",&nNum2)。

//计算结果

if( cOpr == ’+’ ){ nResult = nNum1 + nNum2。

}else if( cOpr == ’-’ ){

nResult = nNum1 - nNum2。

}else{

printf("Unknown operator!")。

return -1。

}

//输出结果printf("The result is %d!",nResult)。

return 0。

} 抛开细节不讲，我想大多数人差不多都会这么实现吧，很清晰，很简单，充分体现了“简单就是美”的原则，面向过程的编程就是这样有条理的按照顺序来逐步实现用户需求。

凡是做过程序的人都知道，用户需求从来都不会是稳定的，最多只能够做到“相对稳定”。用户可能会随时提出加个功能，减个功能的要求，也可能会要求改动一下流程，程序员最烦的就是频繁地变动需求，尤其是程序已经写了大半了，但这种情况是永远无法避免的，也不能完全归罪到客户或者需求分析师。

以我们上面的代码为例，用户可能会提出类似的要求：首先，你程序中实现了“加法”和“减法”，我还想让它也能计算“乘法”、“除法”。

其次，你现在的人机界面太简单了，我还想要个Windows计算器的界面或者Mac计算器的界面。

用户需求开始多了，我得琢磨琢磨该如何去写这段代码了。我今天加了“乘”“除”的运算，明天保不齐又得让我加个“平方”、“立方”的运算，这要是把所有的运算都穷尽了，怎么也得写个千八百行代码吧。还有，用户要求界面能够更换，还得写一大堆界面生成的代码，又得来个千八百行。以后，这么多代码堆在一起，怎么去维护，找个变量得半天，看懂了代码得半天，万一不小心改错了，还得调半天。另外，界面设计我也不擅长，得找个更专业的人来做，做完了之后再加进来吧。这个过程也就是“软件危机”产生的过程。伴随

着软件广泛地应用于各个领域，软件开发的规模变得越来越大，复杂度越来越高，而其用户的需求越来越不稳定。

根据用户提出的两个需求，面向过程的编程该如何去应对呢？想大家都很清楚怎么去改。Very easy，把“计算”和“界面”分开做成两个独立的函数，封装到不同的文件中。

假定程序的文件名为：main.c。

#include "interface.h"

#include "calculate.h"

int main(int argc, char *argv[]){

//变量初始化

int nNum1,nNum2。

char cOpr。

int nResult。

nNum1 = nNum2 = 0。

cOpr = 0。

nResult = 0。

//输入数据if( getParameters(&nNum1,&nNum2,&cOpr) == -1 )

return -1。

//计算结果if( calcMachine(nNum1,nNum2,cOpr,&nResult)

== -1 )

return -1。

//输出结果printf("The result is %d!",nResult)。

return 0。

}

interface.h:

int getParameters(int *nNum1,int * nNum2,char

*cOpr)。

interface.c: int getParameters(int *nNum1,int * nNum2,char

*cOpr){

printf("Please input the first number:rn")。

scanf("%d",nNum1)。

printf("Please input the operator:rn")。

scanf("%s",cOpr)。

printf("Please input the second number:rn")。

scanf("%d",nNum2)。

return 0。

}

calculate.h: int calcMachine(int nNum1,int nNum2,char cOpr,

int *nResult)。

calculate.c: int calcMachine(int nNum1,int nNum2,char

cOpr,int *nResult){

if( cOpr == ’+’ ){ *nResult = nNum1 + nNum2。

}else if( cOp r == ’-’ ){

*nResult = nNum1 - nNum2。

}else{

printf("Unknown operator!")。

return -1。

}。

return 0。

} 面向过程的编程(OPP)就是将用户需求进行“功能分解”。把用户需求先分解成模块(.h,.c)，再把模块(.h,.c)分解成大的功能(function)，然后把大的功能(function)分解成小的功能(function)，如此类推。

功能分解是一项很有技术含量的工作，它不仅需要分解者具有丰富的实战经验，而且需要科学的理论作为指导。如何分解，分解原则是什么，模块粒度多大合适？这些都是架构师的要考虑的问题，也是我们后面要着重讲的内容。

面向过程的编程(OPP)优点是程序顺序执行，流程清晰明了。它的缺点是主控程序承担了太多的任务，各个模块都需要主控程序进行控制和调度，主控和模块之间的承担的任务不均衡。

有的人把面向过程定义为：算法+ 数据结构，我觉得也很准确。面向对象的编程中算法是核心，数据处于从属地位，数据随算法而流动。所以采用面向过程的方式进行编程，一般在动手之前，都要编写一份流程图或是数据流图。

系统架构师J2EE技术分析

12 系统架构师J2EE技术分析

12.1 J2EE的企业级解决方案

12.2 J2EE技术介绍

系统架构师UML如何赋予实

施，用到实处

7 系统架构师UML如何赋予实施，用到实处

1)要让UML指引工程的开发而不是一个装饰品.如何同步你的设计文档和需求文档、类变化

2)以CA用例为例

3)作为交流的一种工具，不需要繁杂的UML 图。

4)各种UML图的实际设计应用

系统架构师处理系统架构与人员

组织的关系

14 系统架构师处理系统架构与人员组织的关系

1) 人员任务分配，应该说是架构体系和软件结构化的发展使开发人员的门槛降低，分分工更加明确，让不同层次的人员都可以参与进来，但对上层人员的要求越来越高。（万金油问题）

15 系统架构师的架构设计思想的平衡问题（不可成为纸上谈兵）