最近应聘系统架构师，面试回答一些问题，加上之前做的一些功课，搜索到一些文章，感觉有必要总结一下，到底如何做一个成功的系统架构师呢？
首先，何谓系统架构师？
IBM工程师的说明是：
架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功
中文Wiki上的说明是：
系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单
这两个解释，加起来基本说明了系统架构师的定义。
JAVA系统架构师应该看的几本书
Thinking in Java
Effective Java
UML基础、案例与应用
UML入门提高
软件工匠
设计模式——可复用面向对象软件的基础
重构-改善既有代码的设计
敏捷软件开发-原则、模式、实践
企业应用架构模式
Expert One-on-One J2EE Development without EJB
软件工程——实践者的研究方法
软件领导－－成功开发软件的指导准则
后面的两本书，其实已经有点属于项目经理的范畴了，不过还不是很深入，看看对做成功的系统架构师是很有好处。
企业应用的系统架构师应该关注的几个方面
数据持久层的设计
在Spring和Hibernate，ibatis出来以前，几乎每家公司都有自己的一套方法和架构，而架构师的50％的精力也会集中到这上面，EJB只是增加架构师的负担。在Spring出来以后，基本上，大多数的架构师都从重复设计这个轮子的无用功中解脱出来了。Rod的轮子太好用了，基本上，大家只要套上去就行了，或者，剩下最重要的事情，是选择一个合适的数据库连接池的开源项目吧
MVC架构的具体设计
MVC只是个概要的概念，具体如何实现的具体技术很多，根据项目设计最恰当的架构
大并发性访问
使用缓存，在数据量达到一定程度时，使用集群技术，优先考虑利用服务器的集群，其次是硬件集群，最后才是应用本身加入集群功能
超大数据量返回结果
尽量使用分页，优化SQL语句，循环处理数据时尽可能共用对象，只保留关键数据，及时释放内存占用
超大文件的读取和生成
尽可能快的读取大文件，并进行分析。写入大文件时，如何及时释放内存。学会适当利用操作系统的命令行资源来更快完成任务。
多线程的应用和管理
线程池的管理和监控，线程的启动（包括定时启动），结束，回收，线程资源的释放
用户界面可用性设计
平衡速度和可用性，恰当的使用异步和同步技术，展现关键数据为重点
分布式的数据交流和集成
选择恰当的数据交互方式，从最泛滥低效的Web Service到最实用的文件共享
群集系统的管理
如何确保缓存的同步？如何确保对象唯一性？如何保证各台机器的同步？
是否采用EJB?如何利用J2EE的特性（例如JNDI)
复杂的业务规则
规则引擎和工作流引擎场景和应用
其实，作为一个真正的系统架构师，不应该局限于企业应用的系统，这种系统往往有数据库的局限性，有时候，应该考虑是否可以横向跨越，直接对其它系统做一些架构考虑，在没有丰富的实战经验的前提下，而只是看了其它人的系统和代码，就能够给出有效的设计指导。
例如对于一个下载软件，可以有如下考虑：
1. 未明和非法url的检验，已经下载失败的容许，信息记录
2. 多线程下载一个文件,文件的切分和拼合，部分切片丢失的拼合可能性
3. 下载线程管理
4. 服务器或者P2P的机器之间的通讯协议
5. 速度监控和限制
6. 下载进度的监控和显示
作为一个在线播放软件,可以做如下考虑
1. 播放速度的保证
机器的问题基本不存在了，关键是网络问题。如何在检测网络速度，根据影片的质量，并缓冲足够多的内容，保证播放一直尽可能顺利的完成。
2. 播放质量的保证
如何利用DirectX等技术,最快的进行渲染,是自己写底层,还是利用已有的API
由于没做过类似的项目，可以写的东西还是少很多了。
系统架构师应该有的素质：
1、 实际的编程经验
最少2年吧，多了就不说了，其实从大学就开始钻研的话，
2、 书面表达能力和口头交流能力
综合利用架构图，UML图，文字和代码片断，表达自己设计思想，至于是Word还是ppt，应该通吃
在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。
3、 自觉主动;积极解决设计问题
架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。
4、 抽象思维能力和总结能力
架构师，顾名思义，在系统未搭建好之前，就要能够有一个草图在心。而如果是对现有系统的改造，那么能在看过系统的文档（如果有的话）和代码后，就能总结出系统的架构特点。
架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。
开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。
5、 全面的技术资讯吸收能力和选择鉴别能力
作为开发人员出身，对于某一个具体问题的研究能力（虽然很多人总结为google能力），已经相当具备了。但是对技术资讯的全面接受和选择性深入了解能力，并且做出正确的判断，那些技术无非是厂家的噱头，而那些技术是真正可以用到项目，提高项目质量的好技术，这种能力确实至关重要的。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
系统架构师是许多程序员的梦想职业。今天的你也许已经掌握了各种开发工具，并且能够使用各种平台进行开发，但作为一个架构师的要求，也许还有很长的道路。邢波涛先生在LAMP架构上的造诣，让我邀请他撰写本文，也许这位架构师的建议能让你在未来的架构师之路上节省一点时间。
一个产品的经典开发步骤通常需要经过系统需求调研、系统分析、系统设计、开发、测试、部署实施等一系列的步骤，如下图所示：
而系统架构师，则在这个过程中，起到了承上（面对业务专家/系统分析员）和启下（面对软件工程师）的作用。所以说，系统架构师，在整个产品开发周期内是一个核心角色。如果说市场和销售决定一个产品是否好卖的话，系统架构师则直接决定着这个产品的开发是否成功。从某种意义上说，这也是众多程序员未来的梦想职业。
要想成为一个优秀的系统架构师，并非一朝一夕之功所能达到的，“冰冻三尺，非一日之寒”，除了要有很深的专业技能外，还需技术全面、成熟练达、洞察力强、经验丰富，具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。如果说系统分析员、业务专家只需要对一个产品的业务负责，可以不关心一个产品软件开发语言的话，而一个优秀的职业系统架构师，不仅要对产品背景和产品背后的业务逻辑熟悉，而且要对所用的软件开发语言（例如Java/C#/C/C++/J2EE），也要非常熟悉才可以，两者缺一不可。否则就起不到承上启下的作用，当然也设计不出良好的软件架构。在美国，一个合格的系统架构师的薪水甚至比部门经理或产品经理要高很多，这也是美国为什么三四十岁甚至五十岁的程序员也很常见的原因。
事实上，软件开发中碰到的很多问题，归结起来都可能和当初的架构设计有关，所以架构师要想不成为众矢之的，决不是件容易的事情。基于此，我认为，要想成为合格的系统架构师，首先要从程序员做起，只有有了多年的一线软件开发经验，深刻体会到了程序员的艰辛与不容易，才能设计出易于扩展、易于修改、易于维护、“不难为”程序员的架构出来。一个系统架构师，首先要能做出能够“自圆其说”的原型，才能跟程序员进行有效的沟通，而不是只是设计出来一个架构，就完全交给程序员来做了，这样，后期开发出来的产品风险很大。以我现在参与开发的产品为例，这个产品只是公司核心战略产品的很小的一部分，当然，虽然小，却是核心中的核心。这个产品配了3个系统架构师（年龄都在40岁以上，有数十年的软件开发经验），6个程序员、5个测试，还有一个负责产品打包的工程师。这3个系统架构师也都参与核心代码编写。
其次，合格的系统架构师，对所要开发的产品的业务背景，也要相当的熟悉才好，否则，设计出来的产品就不是客户想要的产品，当然也就不是成功的产品。还是以我现在参与的产品为例，这个产品是SCA规范的一个实现，3个系统架构师的其中一个，就是SCA标准规范的参与者与制定者，对SOA/SCA标准，有着相当的功底，否则，做出来的产品，就只能围着大公司，在他们屁股后面天天追了，别人做什么，自己也做什么，别人标准修改了，自己也赶快跟着修改。
第三，作为系统架构师，要经常阅读一些关于产品背景资料和系统架构设计方面的最新书籍。虽然现在技术方面的书籍，出得太滥，精品极少，大部分是从网上抄袭一些资料攒出来的，但是经常阅读一些国外大师的一些精品图书，还是能给自己带来一些新的思路和设计理念的。
第四，作为系统架构师，一定要有自信，既不要保守，也不要人云亦云，千万不要迷信于大师和大侠。别人说J2EE好，自己的产品就基于J2EE开发；别人说.NET容易开发，开发成本低，就转做.NET；别人说Ruby很敏捷，自己就说自己的产品是基于ROR开发的。一定要结合公司、市场和项目的实际情况，采用合适于自己的开发语言，设计出合适于自己的架构。比如，《J2EEWithoutEJB》那本书，提出了著名的“不要造新轮子”原则。如果大家都不要造轮子，都利用别人现有的框架和产品，怎么可能有技术的进步和百花齐放、欣欣向荣的景象呢？Spring的作者还不是看到经典J2EEEJB框架的诟病，才设计出来自己的Spring轮子了吗，为什么自己有了Spring轮子，就劝别人不要另造轮子了呢？GavinKing造出来了Hibenate这个轮子，为什么又参与EJB3.0的制定呢？并又参与设计出Seam这个轮子？我个人觉得，一个系统架构师，一定要造出自己的轮子，才算是真正的系统架构师，而不是拿着一大堆开源框架进行拼凑。
第五，对于开源的架构设计，要批判性地继承。要多阅读这些框架的源代码。以J2EE和Eclipse插件开发为例（因为我专注于这两个方面的开发），从前些年流行EJB,再到Struts→J2EEwithoutEJB→Spring/Hibernate→AJAX，每一个框架的流行，都有其深刻的历史背景，有一些现有框架解决不了的难题在里面，这些框架都是为了解决一些问题而出现的。我们经常阅读这些大师的源代码，精神上是一种享受，对锤炼自己的功底，也是大有好处的。例如，在做Eclipse插件开发的时候，常常会遇到一个问题，怎么才能监听到用户保存的事件，虽然Eclipse提供了资源变化监听机制，但是直接利用其机制，是很原始的，任何资源的变化，比如，添加/删除/移动一个图形，都会引起这个事件的调用，而我只想监听用户存盘的一刹那那个事件，以前在做项目的时候，想尽各种办法也没解决好。后来，在另外一个产品的源代码中，就看到了别人很好的解决方案，自己看到那段源代码，真的是领悟到很多。有时候，Eclipse的源代码和J2EE的源代码，在架构上是可以互相借鉴和补充的。比如，Eclipse的Adapter扩展机制和事件、资源监听机制，我们一样可以拿到J2EE框架中来，作为设计自己产品的设计模式蓝图。
第六，优秀的系统架构师还要拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目组成员的信任。一个系统架构师设计出一个良好的框架后，如果不能跟程序员进行有效的沟通，不能对程序员进行良好的指导，则这个良好的框架就不能很好的贯彻到产品开发的每个环节中去。有的程序员可能还是按照老经验对程序中的一些关键环节进行处理，等到这个架构师发现问题时，可能已经很晚了，说服、教育、培训和处罚到那时已经没有意义了。另外，如果一个系统架构师不能赢得项目组成员信任的话，那么他设计出来的架构就不具备说服力，程序员遇到困难，就会抱怨系统架构师设计的框架有问题，不能充分调动起来程序员的责任感和主观能动性。所以说，一个优秀的系统架构师，无论在精神上，还是技能上，都是一个程序员良好的导师。
第七，系统架构师要分清自己和系统分析员、项目经理或产品经理之间的角色和关系，不能负责一切，也不能只负责技术架构。由于系统架构师在整个产品开发周期内处于承上启下的中间地位，和程序员打交道的时间比系统分析员面向程序员的时间要长，有时候甚至比项目经理和程序员之间还熟悉，使得程序员很容易认为系统架构师对所有的需求和架构都负责，容易造成系统架构师职责过重。
成为优秀系统架构师的路，是一条漫长而任重道远的路。在这条道路上，要不断说服自己，不断抵制各种诱惑，要能在深夜无人的时候，挑灯阅读别人的源代码，还要有承受住各种压力的能力，能跟项目经理一起抵制住老板的无理工期要求，还要在困难的时候，鼓励项目组成员一起渡过难关。总之一句话，要想成为系统架构师，不是很容易。“路漫漫其修远兮，吾将上下而求索”。