最近几天一直在思考是否要成为架构师，如何成为一个架构师的问题。于是上网搜集了一些关于架构师的文章，细细读了之后，里面的内容不仅广阔了我的视野，有些以前知道的知识又有了更深一层的感悟，感觉大有所获，至少对于我目前思考的问题是有很大帮助的，在此谢谢各位网上的前辈们。读完他们的文章之后，需要自己再思考一下，最近2天写一下关于架构师的一些思考。
1.为什么要成为架构师
这篇谈谈第一部分，为什么要成为架构师。首先“架构”这个词就显得很高端，架子、结构、顶层设计，这些事在工程领域来说，比如对一幢大楼、一套系统来说是非常重要，骨架不好，虽能凑合着用，但是经不起大风的考验。能做这件事的人是顶着“光环”的，是令人向往的角色。架构师是公司的“金领”，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，沉淀一些基础技术解决方案，形成“强者愈强”的良性循环。
而对于大多数程序员来说，工作到一定时间，coding到一定程度，ctrl-c 和ctrl-v也更加纯熟，这时会到达一个瓶颈，毕竟很多年轻的后辈们过一段时间就可以达到这个地方，你如果想突破瓶颈，就要开始考虑自己的未来到底向哪个方向发展。在中国，程序员的最终的归途无外乎两条：一是转向技术管理
，它的终点是CTO；二是继续深入，它的终点是首席架构师。如果程序员的沟通能力强过技术能力，在补充一定的项目管理知识后，可以向技术管理的方向转型；如果其对技术很感兴趣，而沟通能力也不弱，则可以试着进一步加强技术修养，以期向架构师的方向发展，最终“修成正果”。
2.架构师的技能
架构师需要广泛的知识，是一个“杂家”，“博学家”，但是我觉得架构师必须有1，2个自己特别精通的领域，很多架构师就是从专家过来的。架构师需要什么技能呢，我们需要先看看架构师的职责。
2.1 架构师的职责
我觉得《架构师之路》（王泽宾）之中的有一段描述很好，直接拿过来分享一下。
”架构师这个称呼不是拍脑袋想出来的，是有国际标准（ISO/IEC 42010）可查的。架构师是软件开发活动中的众多角色之一，它可能是一个人、一个小组，也可能是一个团队。微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、
特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。微软的这个分类是按照架构师专注的领域不同而划分的。
EA的职责是决定整个公司的技术路线和技术发展方向；IA的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一；特定技术架构师TSA，他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作；SA的工作则专于解决方案的规划和设计，把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。
大公司会把各种类型的架构师分得很清楚，小公司一般就不那么讲究了，架构师多数是是IA+TSA+SA，一人包打天下，所以说大公司出专才，小公司出全才。
实际工作中，我们也经常会见到另一种比较简单的分类方式，把架构师分为软件架构师和系统架构师。软件架构师基本上是TSA+IA，这也是程序员最容易突破，最可能走上的一条道路，比如JAVA架构师、DotNet架构师、LAPM架构师等等，我后面所讲的内容都是与软件架构师的相关的话题。系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。系统架构师要求通晓软、硬件两方面的知识，所以它的知识体系相对庞杂。“
架构师需要参与到软件项目开发的整个过程，需求分析，架构设计，开发实现，测试联调和发布部署。负责对整个项目的技术指导和协调。
1、需求分析
架构师需要和产品经理经常沟通，把需求明确下来，并且对需求能否实现进行评估，反复进行，确保需求的完整性和需求的可实现性，以及实现的难度。
2.系统分解
在确定完需求之后，就要对完成需求的系统进行架构设计。把完整的系统分解为多个子系统，各个子系统的功能职责；不仅要进行横向的分解，还要进行纵向的分解，系统分层，以及每个层之间数据接口，层与层之间的关系。这时候就有很多设计思想体现出来，也有很多架构模型，领域模式、AOP等等。
3.技术选型
确定完系统的架构之后，就要根据架构进行技术的选择，架构过程其实也是一个个的决策过程，需要分析各个选择的优劣。比如选择服务器是选择windows还是unix？数据库是ms sql server 还是mysql？服务接口是采用 WCF还是restfull api？网站是用asp.net form 还是 asp.net mvc开发？ 缓存服务器选择什么？是否需要图片服务器？还有更详细的选择，比如数据库ORM框架使用哪种？网站前端使用什么JS框架，JQuery还是zepto？这些都要看架构设计的详细程度，如果这些方面开发团队有较高的水平，可以让他们做出较为合适的选择。
同时这些技术的选择，架构是没有最终的选择权，架构师提供建议并分析实现难度以及工作量，项目经理根据项目预算、人力资源、时间进度等进行评估，和架构师一起做出较为合适的选择。
4. 制定技术规格说明
架构师需要和开发人员进行积极的沟通，在开发过程中是否按照架构设计进行实现和一些新的情况需要做出修改的地方，但是架构师没有过多的时间精力时时关注。这时需要一个技术规格说明书，一方面对开发实现进行指导和规范，另一方面也可以节省沟通成本。
一个技术规格说明书，需要包括系统背景介绍、用例图、时序图、架构图等，也可以保证开发者能够从不同角度去观察、理解各自承担的子系统或者模块。
2.2架构师需要的基本技能
从大的方面说，架构师需要有良好的软件技术知识，包括深度和广度；良好的沟通能力；抽象思维分析能力；领导能力。
进行软件架构设计，面向对象的思想和设计模式的知识是必须的。面向对象的思想OO，是经过漫长的软件开发历程和很多人的实际经验总结，发展而来的软件设计开发的一种指导思想。这种思想相对于面向过程(OP)的思想，有许多好处，比如说开发效率高，由于其高内聚、低耦合的目标，使得软件系统的个子系统、模块可以分解并行开发，也可以使用以前开发的模块快速开发；软件系统的可维护性和可扩展性也在抽象和封装下使得修改和扩展更加局部化。但是并不是说面向过程的编程没有优于OO的地方，在效率要求很高的系统级的应用或准实时系统中，依然采用面向过程的编程。
架构师在设计系统的时候，会综合考虑系统的性能、可靠性、可维护性、可扩展性，做出均衡的选择。
2.3 互联网架构师必须掌握的知识
1. 网络知识
不仅仅是互联网系统，很多软件也不只是单机运行的，越来越多的需要网络功能。网络知识不仅仅包括tcp/ip，http等常用的协议，也包括网络规划，比如解决不同用户离服务器距离不同产生的访问速度问题的CDN(Content Delivery Network内容分发网络)，解决电信和网通网络访问速度问题的“双线”机房方案。
2.硬件知识
了解硬件的极限以及最新的硬件会对程序的运行造成的影响。
3.软件知识
软件知识包括很多内容，这也是软件架构师知识体系的很重要的一块。像操作系统、数据库、应用服务器等方面的知识。操作系统的兼容性、性能等；数据库的分库以及分表、日志、性能优化等；虚拟主机和非虚拟主机对程序的影响等。
4.其他知识
分布式系统、负载均衡、网络安全、运维监控等知识也要有所了解，包括最新的产品是什么，运用更广泛的技术什么，有什么优缺点？
3.架构师之路
成为架构师是一个慢慢积累的过程，所需要的知识体系比较庞大，但是如果你在coding了一段时间之后，多少会接触到这些知识。而你如果在编程的过程中，经常思考程序的可靠性、性能、可维护性、可扩展性，再学习下面向对象、设计模式的知识，并在编程的过程中试着运用这些知识；当你试着考虑系统应该分成几个子系统，系统运用哪些框架更能提高性能和可维护性，系统应该有数据库，数据库表如何设计才能更优，如何分布式部署这些系统的时候，你已经走上了架构师之路......
