软件架构：总体设计师

 

      软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。

架构师就是继分析师分析出需求后根据需求整体规划项目，然后由软件工程师或者程序员去实现，在实现过程中和实现以后，有测试师（好比质监局的）不停的找茬，我们软件工程师（程序员）和测试师就是矛和盾！当然，整个项目中，项目经理是带头大哥.

如果把程序员比作民工的话，架构师就是划图纸的人。

网站架构设计师，网上的解释是准确定位网站目标群体，设定网站整体架构，规划、设计网站栏目及其内容，制定网站开发流程及顺序，以最大限度地进行高效资源分配与管理的人员。

任何一个机构都不需要一个全职的软件架构师。一旦建模完成之后，真正需要全职工作的是编码和测试。这个项目一旦开始实施，每个月100个小时的工作量就足以让任何设计师满足全部正在进行的项目的大多数需求。

　　在企业IT部门或者在商业软件公司工作的人员可能非常熟悉建造软件与建造楼房之间的区别。也就是说设计师设计楼房，软件开发人员建造这个楼房。有时候有相当于结构工程师的人员，但是在大多数时间是有区别的。

　　最重要的区别仍然是前面没有适当的架构。你的大楼可能存在垮塌的风险。然而，没有人讨论的这个区别是工程师在大楼建造的整个过程中都在现场，而设计师开始的时候有80%的时间在现场工作，然后在建设开始的时候提供不断的评估。

　　一般的承包商如何处理这个问题呢?他们雇用建筑公司执行设计和评估的功能。机构如何处理软件功能方面的问题呢?他们雇用全职的软件架构师。然而，软件架构师的困境就是在不需要设计新楼房的时候他做什么工作呢?

　　此外，大多数机构在危机发生之前都利用工程师制作软件以及上述结构，从而产生这样的答案：“让我们在这里雇佣一个设计师吧。”这里的想法是设计师能够节省时间，保证正在建设的全部楼房满足编码标准和消除未来的担心。这样就不会把这个漏洞毁掉和从头开始。

　　设计师做出的“你需要重新开始并且把这个事情做正确”的回答经常会遭到拒绝并且使设计师面临敌意。而且，工程师将提出一些修改意见让建设工作继续实施。这样就使全职设计师成为为非常昂贵的资源。在遇到问题时，设计师不能提出任何简单的答案。而工资仅是设计师一半的工程师却能给出答案。

     软件架构师实际上就是软件的总体设计师。首席设计师就是总设计师，打个通俗的比方：邓爷爷是中国改革开放的总设计师，我们用现在的说法可以讲，邓爷爷是中国改革开放的首席架构师。架构师的形成一定是在实践中积累起来的，而并非上了几次培训班，读了几本书就可以成功的，架构师是在工程实践中培养出来的！

首席架构师 企业一个最高的技术决策者。
岗位职责:
1. 负责公司软件产品或实施项目的技术路线制订和技术架构设计，并进行实施指导；
2. 负责公司软件产品或实施项目的系统架构测试设计；
3. 剩下的就要看董事会如何安排其职权范围了。

例如：现在，微软公司的这个决策者就是比尔?盖茨，微软的“首席架构师”。设立这个特殊职位是因为，无论在微软还是在其他公司，首席执行官根本没有时间管技术，而很多所谓的“首席技术官”却都是没有实权的科学家，决定不了技术发展方向。但是，在一个技术主导的行业里，一个企业没有技术方向的最高决策者是不行的。

作为首席架构师，比尔?盖茨的工作是制定公司的长期技术路线图，并确认公司每一个行政部门的科研计划是互补而不是重叠的。因此，他要求公司的每一个产品和技术部门都向他做技术汇报，这些汇报大多是“头脑风暴”式的讨论会议。做这样的汇报，除了可以得到比尔?盖茨的回馈之外，每个项目团队还可以在准备过程中受益匪浅。因为，项目团队为了准备回答比尔可能问到的各种问题，必须在报告前彻底调研市场、技术、竞争对手等信息，也因此避免了闭门造车的风险。

      架构师也并非是万能的。架构师是客户需求和开发者之间的桥梁。在软件行业中，一般提到的架构师是技术架构师，而忽略了领域架构师或者讲是领域工程师的概念。一个好的领域专家一定是业务领域的架构师，他能够给出某一个业务领域的架构，我们可以称为业务架构，只有技术架构和业务架构紧密结合才有可能真正创造出一个好的系统！

      架构师，首先让我想起的是高楼大厦的设计人员，通常一座大厦在建之前,都先由设计师将蓝图描绘出来，包括其形状、结构、尺寸、材料等等，然后建筑工程师带领工人们按照蓝图将大厦一层一层地建起来。

      近年来，软件领域也渐渐地流行起架构师的角色，特别是对一些大型软件产品或项目的开发，这一角色显得很关键，因为缺乏好的软件架构师而导致项目失败的例子不胜枚举，一个没有经验和能力的架构师也会使项目失败的速度加快。

软件架构师的重要作用

      软件架构师在整个软件开发过程中都起着重要的作用，并随着开发进程的推进而其职责或关注点不断地变化，在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等等，此外，架构师还要经常审查和客户及市场人员所提出的需求，确认开发团队所提出的设计；在需求越来越明确后，架构师的关注点开始转移到组织开发团队成员和开发过程定义上；在软件设计阶段，架构师负责对整个软件体系结构、关键构件、接口和开发政策的设计；在编码阶段，架构师则成为详细设计者和代码编写者的顾问，并且经常性地要举行一些技术研讨会、技术培训班等；随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点；在软件维护开始时，软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策。

如何成为优秀的软件架构师

      显而易见，在软件开发过程中，一个优秀软件架构师的重要性是不应低估的。那么如何成为优秀的软件架构师呢？

      首先必须具有丰富的软件设计与开发经验，这有助于理解并解释所进行的设计是如何映射到实现中去。

      其次要具有领导能力与团队协作技能，软件架构师必须是一个得到承认的技术领导，能在关键时候对技术的选择作出及时、有效的决定。

      第三是具有很强的沟通能力，呵呵，其时这一点好象什么鬼角色都最好具备，软件架构师需要与各路人马经常打交道，客户、市场人员、开发人员、测试人员、项目经理、网络管理员、数据库工程师等等，而且在很多角色之间还要起沟通者的作用。在技术能力方面，软件架构师最重要也是最需求掌握的知识是构件通信机制方面的知识，比如远程过程调用、JAVARMI、CORBA、COM/DCOM、各种标准的通信协议、网络服务、面对对象数据库、关系数据库等等，另外，架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法。开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。当然，行业的业务知识对软件架构师也是很重要的，有助于设计

      出一个满足客户需求的体系结构，优秀的软件架构师常常因为要尽快获得对行业业务的理解而必须快速学习并且进行敏锐的观察。

      上面的描述是枯燥乏味的，但作为一个软件架构师，在整个软件系统的开发过程中是乐趣无穷的，因为这个角色很具有挑战性，有时需要左右逢源八面玲珑，有时又需要果断坚定不留情面。在国内，较少软件企业拥有独立的架构师，通常一个软件高手身兼数职，既是项目经理，又是软件架构师，还是软件开发者，有时还要客串一个测试人员，这对软件的开发周期和产品质量是不利的，有时一个人的观点立场是很片面的，而且繁重的工作、沉重的压力会影响一个人的情绪，情绪会影响决策，决策影响结果，所以值得我们三思而后行。

构架师自我培养过程

      构架师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。总结构架师自我培养过程大致如下，仅供参考。

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

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

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

      4、软件构架师的正是成型在于机遇、个人努力和天赋软件构架师其实是一种职位，但一个程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为一体的精英人才这可不是每个人都能够遇上的馅饼……

软件构架师职场概况

      如果您今天有幸同全球首富比尔·盖茨交换名片，您会注意到他的头衔是微软公司首席软件架构师。同样假如您得到中国首富丁磊的名片，您也会看到他的头衔是网易公司首席架构师。悄然间，架构师已经成为职场上最让人羡慕的职位。

      在我国，随着软件业规模的不断扩大，软件人才结构性矛盾将更加突出。国家人事部门预计到2005年我国软件产业的规模将达到2500亿元，全国计算机应用专业人才的需求每年将增加百万人左右。其中，架构师这样的专业高级人才每年培养人数全国不过数百名，缺口非常之大，而其中尤其以Java架构师缺口最为明显。

      众所周知，Java是当前最热门的软件开发语言，它具有跨平台、面向对象、强大的网络功能等特性。你不仅能在电脑上使用Java程序，还能在手机、PDA、家用电器上使用Java程序，甚至举世瞩目的火星车也全部采用Java技术。Java在不到10年时间内已经变成最流行的软件开发平台，最新的企业级Java 2.0版本（简称：J2EE）也成为企业应用系统上最受欢迎的开发标准。

      事实上，全世界范围内的J2EE架构师都是紧缺的人才，只是中国更加明显而已。在英国，有经验的J2EE架构师，目前平均年薪已经飙涨到七万至十万英镑。全球著名的电子商务平台提供商SilverStream软件公司的技术服务总监Mark Ashton对J2EE人才的短缺深有感受，他表示许多求职者的履历表上都有把J2EE列进去，但是仔细查看或是面试之后就会发现大多数人只是听过J2EE，并没有真正用过这些技术。信息产业部电子信息产品管理司副司长丁文武近期也表示，目前我国Java人才还远远不够，至少短缺20万。特别是随着大量软件外包业务进入中国，许多外资或中资软件企业也开始面临着高级Java人才奇缺的问题，尤其是熟悉J2EE又能掌握一门相应外语的人才成为了众多大公司争抢的对象。

      作为Java的发明者和Java开发标准的主要制定者——美国Sun公司对从事Java开发的技术人员提供了三级认证体系，即初级的程序员认证（SCJP）、中级的开发员认证（SCJD和SCWD）和高级的架构师认证（SCEA）。这也是软件行业中最权威的国际认证之一。目前国内已经有针对美国Sun公司认证体系的培训，但绝大多数主要针对初级的程序员认证，只有极少数专业培训机构能够提供三层完整培训。国家信息化教育示范基地——上海文华学院（www.wenhua.org）是上海仅有的一家拥有Java自上而下、由浅入深的完善的培训及认证体系的学院。作为Sun华东区最佳培训中心，上海文华学院的“对外J2EE国际软件工程师就业班”课程除了由浅入深，完整地教授整个J2EE体系外，还详尽地教授开发企业级应用软件所必须掌握的知识体系，如：操作系统、UML、数据库、项目管理、软件测试等。因此，即使你没有任何软件开发知识，也能完成这门课程的学习。课程采用项目教学，并培训计算机英语和第二外语。学员考试通过后，可以获得美国Sun公司的最高级别国际认证：Sun认证企业级Java 2架构师（SCEA），还推荐就业。学员入学前还可参加免费的“软件开发潜质测试”，评估自己是否适合开发软件。

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

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

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

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

　　4、软件架构师的正式成型在于机遇、个人努力和天赋，软件架构师其实是一种职位，但一个程序员在充分掌握软架构师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理架构、如何不断的抽象和归纳自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才这可不是每个人都能够遇上的馅饼……

　然而学海无涯，精力有限，个人如何能够很快将这些所谓的架构师知识掌握?这是秘密，每个人都有自己的独门家传秘笈就不敢一一暴露了。不过有一点就是广泛学习的基础之上一定要根据个人兴趣、从事领域确定一条自己的主线来努力。

　　如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。

什么是软件架构师?

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

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

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

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

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

架构的目标是什么

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

·可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

·可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

·可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

·可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

·客户体验（Customer Experience）。软件系统必须易于使用。

·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

架构的种类

根据我们关注的角度不同，可以将架构分成三种：

·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

·物理架构、软件元件是怎样放到硬件上的。

比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。

根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

构架描述

为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。

构架视图

我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

典型的构架视图集

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。
逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。
实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。
进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。
配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。
构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

构架重点

虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：

模型的结构，即组织模式，例如分层。
基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。
几个关键场景，它们表示了整个系统的主要控制流程。
记录模块度、可选特征、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：

系统演进，即进入下一个开发周期。
在产品线环境下复用构架或构架的一部分。
评估补充质量，例如性能、可用性、可移植性和安全性。
向团队或分包商分配开发工作。
决定是否包括市售构件。
插入范围更广的系统。

构架模式

构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。

构架设计图
构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：

逻辑视图：类图、状态机和对象图。
进程视图：类图与对象图（包括任务 - 进程与线程）。
实施视图：构件图。
部署视图：配置图。
用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。

架构师

软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。

这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。

但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

大型项目的经验
    中国有多少架构师，不在于有多少人通过了什么考试培训，而在于中国大型项目的数量。
    问：你这个项目的架构是什么？一口回答：Spring+Struts+Hibernate。这位很可能就不是架构师了，因为这仅仅是技术Stack，项目规模不大时Spring+Struts+Hibernate才会成为架构的重点。
    除了亲自担任大型项目的架构师，如果了解这些项目为了满足怎样的功能与非功能需求而把架构设计成这样子也一样的。所以，尽量多读一下公司项目的设计文档，愉快的接受其他项目组架构评审会的邀请。

二、基本能力
完整的软件开发生命周期经验
    这个不用说了，幸好中国的架构师什么脏活累活都做过，甚至跟着市场人员跑去做演示这些国外架构师不一定有的经验我们都有了，差别只在于一些理论知识--RUP + CMMI3 + 敏捷原则的细节掌握程度。

精通一两种主流开发语言、保持当下架构的开发体验
    国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师则在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。

    水王的设计一般会层次过高，与实现之间有断层，与开发人员沟通困难，自己哗啦啦编个验证原型的日子更是一去不返。更痛苦的是，人过三十之后学习能力下降，手艺一旦放下了想重新上手还很难:(

    但是，也不必要挽起袖子每月编码若干行，很可能你的"亲自出手"因为时间安排不来反而拖了大家的进度，但一定要保持一个体验。

宏观上的，广度优先的了解当前主流的技术与产品

     架构师如果连Tuxedo与IBM MQ都分不清，一句"这里搞个异步调用的middleware，有commercial support的"，同样是层次太高了。架构师对各大公司的完整产品线和著名的开源项目应该有宏观上的了解，最好在Wiki里编个索引。

     但同时也要抵制成为某项技术专家如Oracle启动参数优化专家的诱惑，技术细节掌握到业务职责需要的程度就刚好了。除非如Spring Framework进一步了解能带来天大好处。
与业务域开发域人员沟通的能力及其他领导能力

   IT 架构师处在客户和开发人员之间，必须能够使用各种媒体（代码、模型、文档、PowerPoint以及谈话和讲座），与技术和非技术的干系人进行沟通。另外，架构师好歹也是个半大不小的官，其他领导必要的能力就不列了。

到底什么是架构师呢？所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。

            什么是架构师最具价值的技能呢？就是要了解不同的知识，做一个“杂家”或者说“博学家”。当然，如果你的数据库技术非常棒，或者你在工作流引擎方面具有不可超越的专家知识，那也是很不错的。好的架构师有好多都是从专家成长过来的。但是，这不是架构师应该做的事情，架构师应该做的是了解所有的东西，既了解技术的宏观面，又了解技术的细节。真正的架构师不仅仅要了解软件，也要了解硬件，在关键的部位使用合适的硬件来取代软件，可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例，向大家讲解作为架构师应该具备的知识。

      互联网行业是当前最激动人心的行业之一，很多的创新都来自于这个行业，而每一个大型的网站如Google，Yahoo，Myspace等都需要解决一个非常复杂的问题，就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题，需要最优秀的架构师对业务进行剖析，利用软硬件将网站进行重构，甚至根据业务研发相应的分布式技术，解决网站复杂的分布式计算的问题。如果你想在这个行业中成为一名架构师的话，需要至少掌握网络知识，硬件，软件，网站优化等方方面面的知识：

软件架构的十大错误

不能界定项目范围。“在这种情况发生时，一个简单的出差登记系统结果变成内建了完整的花费报销管理系统，项目费用、时间跨度和质量都留下不可避免的烂摊子……除了简单的登录真的不需要安全措施了？用户登录系统后真的不能够执行任何系统操作吗？”

网撒得不够宽。“我们都曾经犯过的一个错误是，只关注系统所有利益相关者中的一两方——通常受让人（为系统出钱的人）和最终用户得到了全部的关注。”

只关注功能。“……除非系统表现出了全面的高质量（诸如性能、安全、可维护性等等），否则不太可能成功。”

用方框和线条来描述。“[一个无所不包的]巨大的Visio图无法成为有效的架构描述，有两个原因：第一，它试图在单一表示中呈现太多信息；第二，没人真正清楚地知道你画的各种符号到底表示什么意思。”

忘了需要培养的过程。“在建造系统的时候常常需要小心的事物包括：开发者和测试者没法真正理解设计，他们不热衷或者没时间学习技术，以及还没有很好的工具支持的新技术，或者新技术会强迫人们以新的不熟悉的方式工作。”

平台定义不精确。“光用‘需要Unix和Oracle’来描述你的平台是不足够的。你需要精确地说明每一部分具体的版本和配置，才能保证得到你所需的平台。不然如果有人好心为平台的某一部分升级了一个库，就可能导致某些东西停止运作。精确定义平台你才能在部署中避免这样的情形。”

对性能和伸缩能力想当然。“及早开始考虑性能和伸缩性，构建性能模型尝试预测关键的性能指标并定位瓶颈，在设计逐渐成型的同时投入到一些实际的验证性工作中去。这会帮助你提高对设计中不存在严重性能和伸缩性缺陷的信心。”

自己发明安全技术。“多年来许多系统所犯的一个错误是试图加入自己发明的安全技术来提高系统安全性。比如定制的加密算法，开发者自己编写的审核系统，甚至完全DIY的访问控制系统。自家开发的安全方案基本上都是不明智的。虽然很多人都以为自己可以马上搞出一些聪明的安全技术，但通常都只是自作聪明。”

没有灾难恢复。“要想得到资源来实现系统的灾难恢复机制，其关键在于在若干真实的场景中，具体衡量系统不可用所导致的损失。如果你还能估算这些场景发生的概率，你就可以用这两组数据去说服人们灾难恢复的重要性，并获得合理的预算去实现它。”

没有撤退计划。“确保无论在系统部署或升级的过程中发生任何事，你都有一份书面的、经过审查的、一致同意的撤退计划，允许你将整个环境恢复到部署之前的状态。”

什么是架构?
   软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解，以下是一些主流的标准观点。
　　ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。
　　Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。Garlan & Shaw模型[1]的基本思想是：软件体系结构={构件(component),连接件(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的模块；也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。
　　关于架构的定义还有很多其他观点，比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是构件、连接件及其约束（或者连接语义），这些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。

    什么是模式?
   模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域，Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文）,指模式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）。他提出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已被软件界广为接受。

        架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的 Pattern。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同，从高到低，模式分为3个层次：架构模式(Architectural Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern).架构模式是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，[GOF95][2]总结的23个基本设计模式——Factory Pattern, Observer Pattern等等。实现模式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；异常处理的规则等等。

来自：http://dev.yesky.com/378/2012378.shtml

   由于[GOF95]是论述软件模式的著作的第一本，也是OO设计理论著作中最流行的一本，因此有些人常常使用设计模式（Design Pattern）一词来指所有直接处理软件的架构、设计、程序实现的任何种类的模式。另外一些人则强调要划分三种不同层次的模式：架构模式 (Architectural Pattern)、设计模式(Design Pattern)、成例(Idiom)。成例有时称为代码模式(Coding Pattern)。

　　这三者之间的区别在于三种不同的模式存在于它们各自的抽象层次和具体层次上。架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。

　　1、代码模式或成例(Coding Pattern 或 Idiom)
　　代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
　　较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等。

　　2、设计模式(Design Pattern)
　　一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
　　设计模式常常划分成不同的种类，常见的种类有：
　　创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
　　结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等
　　行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
        以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等
　　设计模式在特定的编程语言中实现的时候，常常会用到代码模式。比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。

　　3、架构模式(Architectural Pattern)
　　一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。有些作者把这种架构模式叫做系统模式[STELTING02]。
　　一个架构模式常常可以分解成很多个设计模式的联合使用。显然，MVC模式就是属于这一种模式。MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
　　此外，常见的架构模式还有：
　　·Layers（分层）模式，有时也称Tiers模式
　　·Blackboard（黑板）模式
　　·Broker（中介）模式
　　·Distributed Process（分散过程）模式
　　·Microkernel（微核）模式
　　架构模式常常划分成如下的几种：
　　一）、 From Mud to Structure型。帮助架构师将系统合理划分，避免形成一个对象的海洋（A sea of objects）。包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
　　二）、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
　　三）、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
　　四）、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection（反射）模式、Microkernel（微核）模式等。

来自：http://fanqiang.chinaunix.net/program/project/2005-06-16/3316.shtml

Layers架构模式
　　在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多"板块"。划分的方式通常有两种，一种是横向的划分，一种是纵向划分。
　　横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。
　　纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:
　　一、网页，也就是用户界面，负责显示数据、接受用户输入；
　　二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；
　　三、数据库，负责存储数据，按照查询要求提供所存储的数据。
　　四、操作系统层，比如Windows NT或者Solaris等
　　五、硬件层，比如SUN E450服务器等
　　有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。
　　Layers架构模式的好处是：
　　第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。
　　第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术

【Kiki】由于我只接触过这种，其他（Facade架构模式、Mediator架构模式和Interpreter架构模式）就不转载了。

来自：http://java.ccidnet.com/art/3749/20060511/550769_1.html

如何成为一个出色的网站架构师
一个具有一定知名度的网站，面对的问题无非是：稳定的性能、海量访问、海量数据。

   优秀的website architecture应该良好的解决上述问题，那么Terry认为应该熟悉或了解下面的技术：

开发语言架构：应该至少熟悉一种web开发语言，包括java、web、python、ror等，然后采用比较稳健的、成熟的开发语言架构
单点登陆
自建session server,类似discuz的passport的方案
目前常用的是cas sso解决方案
web服务器集群：
负载均衡：软件比如keepalived,ultramokey.硬件如四层交换机；
web服务器集群方案:常用lvs
web服务器选型:apache、Nginx、lighttpd
其他服务器－如java 应用服务器的集群部署；
利用缓存：
页面静态化规则，页面缓存；缓存软件：squid,oscache,等
常用数据缓存解决方案，缓存数据命中率
如果采用ORM,考虑采用二级缓存
ajax：避免页面全局刷新，提高用户体验；合理使用，避免泛滥。
数据库
集群数据库
如果数据库采用mysql,那么一般是master-slave，对master进行写入或更新数据，对slave进行数据的查询。如果使用hibernate那么，使用native sql太动态绑定不同的数据库表。复杂一些可以研究一下Hibernate Shards,这是google捐献给hibernate的项目的。
oracle数据库集群，可以采用磁盘阵列方式，oracle部署在几个服务器上，表和数据文件放在磁盘阵列上
做好备份策略
分清不同数据的生命周期。根据不同的生命周期，做好数据的归档/转存的工作
商业数据存储首选大型商业数据库，其他数据可以用mysql等开源数据库。
搜索引擎：
常用的技术选型是lucene ,另外有ferret，Sphinx。
分布式存储和分布式查询
中文分词
网络蜘蛛：
知道如何抓取别人网站的网页
懂得如何屏蔽未知或部分蜘蛛访问你的网站
seo
关注互联网业内的情况
facebook的f8是啥回事
google的产品和api,了解Google Maps API、OpenSocial API、Google Apps等等
找到sns,blog,wiki等web2.0的技术表现形式
guice、google toolkit、Android
关注新冒出来一些网站的情况
研究和分析知名网站的架构
跟踪一些知名技术专家的文章或blog
适当的参加一些技术或互联网聚会和话题讨论
了解比较新的一些技术概念，如soa、esb、云计算、MapReduce、BigTable、Google
“隔河观景的心态应该尽量避免”

架构高负载，高并发的网站的根本和趋势就是负载均衡，或者叫做分布式，利用多个小型的服务器来替代单一的大型的服务器。在WEB服务器方面的负载均衡很简单，复杂的是如何在数据库方面做负载均衡，现在大部分公司的做法还是使用传统的数据库集群或者简单的库表散列。在这里给大家提供一种新的思路：借助成熟数据库产品的一个分布式数据库中间件， 把数百台机器组织起来，既有库表散列，又有负载均衡，最终达到高性能，高扩展性，高可用性。

最便宜的高负载网站架构
1， LVS做前端四层均衡负载
基于IP虚拟分发的规则,不同于apache,squid这些7层基于http协议的反向代理软件, LVS在性能上往往能得到更好的保证！

2，squid 做前端反向代理加缓存
squid 是业内公认的优秀代理服务器，其缓存能力更让许多高负载网站青睐！（比如新浪，网易等）
使用他, 配合ESI做WEB动态内容及图片缓存，最合适不过了

3，apache 用来处理php或静态html，图片
apache是业内主流http服务器，稳定性与性能都能得到良好保证!

4，JBOSS 用来处理含复杂的业务逻辑的请求
JBOSS是red hat旗下的优秀中间件产品，在java开源领域小有名气，并且完全支持j2ee规范的，功能非常强大
使用他，既能保证业务流程的规范性，又可以节省开支（免费的）

5，mysql数据库
使用mysql数据库，达到百万级别的数据存储，及快速响应，应该是没问题的

6，memcache作为分布式缓存
缓存应用数据，或通过squid解析esi后，作为数据载体

                             LVS
        squid + jboss        squid + jboss        squid + apache ....

                                       mysql + memcache