经验谈：系统架构师的修炼[转]
最近应聘系统架构师，面试回答一些问题，加上之前做的一些功课，搜索到一些文章，感觉有必要总结一下，到底如何做一个成功的系统架构师呢？
首先，何谓系统架构师？
IBM工程师的说明是：
架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功中文Wiki上的说明是： 系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单
这两个解释，加起来基本说明了系统架构师的定义。
JAVA系统架构师应该看的几本书
ThinkinginJava
Effective JavaUML基础、案例与应用 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能力），已经相当具备了。但是对技术资讯的全面接受和选择性深入了解能力，并且做出正确的判断，那些技术无非是厂家的噱头，而那些技术是真正可以用到项目，提高项目质量的好技术，这种能力确实至关重要的。
原文链接:http://www.javadby.com/html/news/20080119/5048.html