如何才能真正的提高自己，成为一名出色的架构师？
2. 从小事做起：仅仅从狭隘的软件系统架构来说，全部出自于实践和对每一个细微环节的设计：小的设计组成大的架构，而这些小的设计有很多模式可以帮助你（设计模式）。因此即便你只是编写一个计算器，也最好花精力去分析，设计。
3. 架构不是大而空的：面试的时候很多面试者都认为软件三层架构就是架构了，实际上这很片面。架构实际上是由需求，团队能力，开发周期（资金支持），版权限制等一系列因素叠加影响的，没有万能架构，只有针对一个具体项目的架构，因此应当从以上的诸多方面去分析，我需要什么样子的设计。
举个例子吧（当然，仍是相当笼统）。我有一个小的项目，就是一个基于 Web 的加减乘除计算器。首先这个需求很简单，操作非常有限（10个左右），开发人员可能1-2个，今后可能追加其他操作，但是这些其他操作和现有操作关系不大。5天之内完成上线。
（1）那么我会基于这些因素采用事务脚本的设计（请参见P of EAA）：
（1.1）这种设计的优点就是简洁，开发速度快。容易处理这种数量不多，耦合不强的需求。这正适合我们。
（1.2）其缺点是在需求不断增多的情况下容易产生冗余代码，由于我们对今后的需求和现阶段的功能有所估计（数量有限，耦合不强），认为这个问题对此项目影响不大，于是这样足以。
（2）而对于事物脚本的每一个操作，可以采用命令模式（Command Pattern）进行详细设计。
（3）我的团队开发人员均熟悉 .NET 下的开发，那么我们从语言上选择 C#， Framework 上可以选择 http://ASP.NET MVC。
（4）这个项目的数据存储要求非常有限，我们可以选择用 MySQL 或者 SQLite 作为解决方案。
View(JQuery-UI, JQuery-UI mobile)
---------(JSON)-------
Controller (事务脚本支持->命令模式)
---------(http://ADO.NET Provider)---
Storage(MySQL, SQLite)
这个例子的每一个部分都可以再详细划分，最终形成一个整体的决策。
总之，请不要灰心浮躁，不论多大（多小）的软件，每一个部分都影响着架构设计。设计好软件的每一个部分即可。架构师是一个充满挑战的职业，知识面的宽窄往往决定着一个架构师的架构能力，所以在这一点上我比较赞成你的学习方式，就是要阅读大量的技术书籍，但我希望你不要仅限于软件相关的书籍，经常泡技术论坛，一方面可以结交朋友，一方面可以增加自己的知识面。
公司的大小往往决定了所做的项目规模，一般的大项目不太可能直接总包给小公司去做，但这并不妨碍小公司可以分包到大项目的一部分。在做小项目的同时也可以积累丰富的经验，我自己就是一个这样的例子。
我在小公司混迹了5年多，其中也偶尔有1两个大公司，比如大唐电信，但是基本上都是小公司，从基层的程序要到公司的开发总监都做过，甚至自己还设计过包括LED显示屏，密码键盘在内的收费系统，自己联系厂家OEM，当然这些今天已经广泛应用了，当时我们的客户用上之后还是非常震撼的。
知识面的宽广对于一名出色的架构师来说是必不可少的技能，也许很多人对架构的理解还停留在设计模式，重构，SOA等等的软件层面，然而这仅仅是非常基本的东西，架构师的脑子里不光需要知道让软件如何高效的运行，还需要知道如何去结合网络，存储，甚至一些文件系统的特性，比如GFS，NFS，XFS，NTFS等等，而且架构师还需要知道一些编程语言的特性，C，C++，Java，PHP，Python，Lisp，JS等等，现在是一个混合编程的时代，只了解一种语言，即使再精通也会使你在架构系统的时候受到很大的局限性。
再有一点，架构师需要对数据库技术有深刻的认识，因为现今是一个信息时代，大量的信息都是需要存储并检索的，数据库设计的不好，将会严重影响系统的性能，而这一点往往会被我们的设计人员忽略，他们只知道遵守那些范式而不会结合数据的特性去设计数据库。
看你的编程情况，你好像做PHP开发比较多，PHP比较适合B/S结构的应用开发，这会限制一个架构师的思路，我建议你再学习一门适合做C/S开发的语言，拓宽自己的视野。
从一个程序员到架构师是一个很大的变化，架构师需要从大的方面考虑，而不只是考虑这个模块该用哪种设计模式去开发。不能急于求成，也许是我自己变化的比较慢，我用了10年的时间，这10年里，我使用超过一年的编程语言包括了delphi，C++，Java，python，使用的数据库包括了oracle，infomix，sybase，sqlserver，mysql，javadb，sqlite等等，使用过大型机，小型机，服务器。unix，linux，windows都至少做过两年以上的开发，这些使用和开发的经历会大大增强一个人在做架构师这个职业时的技术素养。
总之，想要成为架构师，需要有耐心，不断学习，拓宽自己的视野，不仅仅局限于自己眼前的项目，关注开源技术，关注热门技术社区的新动向。06年写的如何循序渐进向dotnet架构师发展，可参考：
微软的DotNet开发绝对是属于那种入门容易提高难的技术。而要能够成为DotNet架构师没有三年或更长时间的编码积累基本上是不可能的。特别是在大 型软件项目中，架构师是项目核心成员，承上启下，因此RUP方法论也认同以架构为核心，体现4+1视图在整个软件开发过程中的重要作用。架构人员既要精通 技术，又要熟悉业务，而且基本对软件生命周期各阶段的相关技术都需要有相关的积累和知识储备，而这些不经过多年的磨练是很难达到这个高度的。
要成为一个合格的架构师首先必须是一个合格或优秀的编码人员，对于开发来讲编码始终都是最重要的一项技能，在编码过程中只要自己善于去思考和分析问题，就 可以多学到很多相关的知识和技术。所以我们在开发过程中一定要注意新知识和新技术的学习，前人经验和成果的学习。编码过程中应该去思考的一些问题有：
1.在编码过程中自己是否做单元测试，是否使用相关工具做单元测试，如果没有的话是什么原因无法把单元测试做起来？
2.自己编码的泄露率情况，编码泄露的BUG的原因分析
3.是否有意识的对代码进行重构，重构过程中是否引入了相关设计模式的思想？
4.是否对C#语言的一些高级特性进行学习，如反射调用，异步处理等。
5.是否对Remoting和WebService两种分布式技术做过研究和对比分析？
6.是否经常研究开源项目和开源代码，如Duwamish，PetShop，NUnit,Enterprise Library，Nant等
7.是否对对象持久化机制和O/R Mapping等相关技术做过相关的研究
8.平时在编码过程中是否注重公用组件和公用类的复用和抽取
9.自己在平时工作和学习中是否经常开发些小工具提高工作效率，巩固学习知识
设计和编码其实是密切而不可分的，对于严格将设计和编码分开的瀑布模型一般也仅仅在大型项目中应用。而及时编码和设计分离，也不是将编码人员不需要思考， 编码活动始终是一项创造性的劳动，如果否定这个观点那就代表编码过程完全不需要人员介入而可以完全自动化。因此在这里谈设计主要还是指设计人员的系统化思 维能力，设计人员应该比开发人员站高一个层次来分析和思考问题。设计人员最重要的一个技能就是现实->抽象的转换，而这个就需要谈到方法论的问题 了，技术人员需要积累面对对象分析和设计或结构化分析知识的积累，需要有较强的数据库分析和设计能力。一个设计能否成为很好的架构师关键就在这种积累的深 度和广度上面了。
因此在设计过程中应该考虑的问题有：
1.你现在分析和设计能力能否胜任大中型的应用系统还是只是独立功能分析和设计？
2.设计过程中是否有意识的考虑到组件的复用和相关接口设计准则。是否能够很自然的将分析模式，设计模式的相关内容应用到自己的设计过程中。
3.是否对XP，RUP，面向对象，结构化等方法论都有过较系统化的学习和思考。
4.是否真正理解系统功能需求和非功能需求对系统设计的不同的指导作用。
5.对自己设计的功能是否会根据后期的变更来反思自己的设计为何不能很好的适应变更？
6.是否在设计过程中经常自己开发些原型来对自己的设计思路进行验证？
7.是否专注技术的同时开始专业业务流程的分析，关注业务建模？
如果我们在设计和开发过程中经常关注这些知识和技能的话，成为一个合格的架构师是早晚的事情。平时能够胜任工作开发用到的知识和技能是微不足道的，如果自 己不是有意识的去学习这些知识的话，那技能是很难得到进一步提高的。我参加过两次微软的架构师培训，在北京的微软架构峰会上也有机会专门参加了 P&P Workshop的学习，培训老师是微软总部SmartClient Architecture and Design Guide一书的作者Edward A.Jezieski，让我感受最深是老外深刻的技术底蕴，对程序开发的执著。
对于DotNet架构经常用到的知识和技能储备有
1.RUP方法论，4+1视图。用例驱动业务建模->分析模型->设计模型
2.用例模式->分析模式->设计模式
3.常用的分布式技术
4.对安全，异常，日志，性能等非功能性需求的关注
5.对应用系统整体业务的关注
相关的一些参考书籍(微软网站和电驴都可以下载到)
微软网站提供的参考书籍
Enterprise Solution Patterns Using Microsoft .NET
.NET Data AccessArchitecture Guide
Application Architecture for .NET:Designing Applications and Services
Caching Architecture Guide for .NET Framework Applications
Designing Application-Managed Authorization
Smart Client Architecture and Design Guide
其它架构方面的参考书籍
Software Architecture In Practice
Pattern-Oriented Software Architecture
The Art Of Software Architecture
Beyond Software Architecture
模式方面的书籍
Analysis Patterns
Design Patterns - Elements of Reusable Object-Oriented Software
Applying UML and Patterns
Design Patterns Explained
===================================================
2015年8月，增加架构设计和概要设计的区别
架构设计
架构设计包括了功能性架构和技术架构设计两个部分的内容，功能性架构解决业务流程和功能问题，而技术架构解决非功能性需求等问题。两种架构都包括了动态和静态两个方面的内容，对于功能性架构中动态部分为业务流程驱动全局用例，用例驱动的用例实现等；对于技术架构中动态部分为架构运行机制，而静态部分为框架，分层等方面的内容。
功能性架构包括了全局用例设计，这个本身是用例分析和设计的一个延续，而全局用例分析建议的思路仍然是业务流程，业务用例建模到系统用例建模的过程。全局用例分析清楚后可以开始考虑子系统和模块的划分，形成系统的功能架构图，当然在划分过程中一定要考虑到通过CRUD矩阵等分析方法来分析模块如何划分合理，如何保证模块本身高内聚和松耦合。
在全局用例分析完成后涉及到数据模型的设计，数据建模仍然从业务驱动，从最初的业务对象和单据入手，到最终的数据概念模型和逻辑模型等。架构设计中全局数据模型不一定覆盖所有的数据对象和数据表；但是核心的主数据，核心业务单据数据一定要覆盖到，模型到的层次到逻辑模型即可。如果用面向对象的分析方法，这里需要出的是UML建模中的概念模型和逻辑模型，体现核心对象和类，核心对象和类之间的关系。
将全局用例分析和数据模型建立融合在一起，可以看到这两者结合起来会形成一个系统完成的领域模型层。一直认为领域模型思路应该引入架构设计，只有领域模型才是真正关注功能性架构，而不用马上关注到具体的技术分层和技术实现。
前面两者做完后可以看到一个大系统被分解为了多个子系统或模块，那么接着要考虑的就是模块间的集成架构，分析完集成架构模块间的接口基本就出来了。接口设计应该是架构设计的另外一个核心内容。要明白架构设计一个重要作用就是架构设计完成后各个模块可以并行开始概要设计，详细设计和开发工作。只要大家都遵循架构设计约定的接口规则即可以了。
集成架构考虑完另外一个核心内容就是公共可复用组件的抽取和识别，包括了功能组件和技术组件，需要识别出来哪些是可复用的，如何进行复用。对于复用层次本身又包括了数据层复用，逻辑层组件复用，界面层UI组件的复用等。复用是架构价值体现的的另外一个关键点。
这些都做完后，接着一个步骤应该在架构设计阶段做的就是对架构输出成功进行模拟验证，前面完成了分解动作，必须通过模拟验证来看看后续分解内容能否很好的集成和组装。很多时候我们做架构设计的时候往往不做这块内容，导致架构设计一些内容变成空中楼阁，无法落地。
再回来看技术架构设计，首先谈下静态部分的内容。这里面就包括了软件开发的分层架构，开发框架等内容，包括开发规范约定，技术平台和语言的选择，使用的规约等都需要考虑。很多时候我们看到谈架构的时候说到的三层或多层架构，仅仅是完整架构设计里面很小的一部分内容。
除了分层架构外，接着考虑的就是各种非功能性需要，我们在架构上需要如何设计。这里面包括了事务，缓存，异常，日志，安全，性能，可用性，容错能力等。这些逐个点都要在架构设计中说清楚如何考虑，由于这些本身就属于一个应用系统中技术平台要考虑的内容，因此应该设计为较为公用的技术组件供上层的业务组件使用。要明白很多时候为何谈到AOP或可插拔架构，只有这样去考虑问题，才会考虑真正的功能性架构设计和功能实现和非功能性技术架构这块充分解耦，实现进一步的灵活装配。
再回到架构设计视图层面，还需要考虑的就是整个应用系统的部署架构，部署架构本身也包括了逻辑视图和物理视图，应用最终开发出来了如何进行部署，这涉及到了IT基础架构方面的细化，也需要考虑清楚。
概要设计
概要设计首先要明白的是根据架构设计的内容进一步对某个模块的设计进一步细化。架构设计在系统级，而概要设计在子系统或模块级。拿建筑来比喻，架构设计是把一个建筑的框架结构全部定清楚，包括地基要挖多深，核心框架和承重结构如何，每一层的结构图如何，应该分为几个大套间这些内容都应该定下来。每个大套间的水，电，气等管道接入点在哪里等。而概要设计要做的是拿着一个套间，来考虑这个套间内部该如何设计，如何划分功能区域，如何将水电气接入点进一步在房间内延伸，哪些地方需要进一步增加非承重的隔断等。
基于以上思路我们看到在架构设计的时候，除了很少部分的核心用例我们会谈到具体的用例实现完，大多数功能我们都不会谈到具体的用例实现层面。而到了概要设计则需要进一步的分解我这块模块究竟需要实现哪些功能点，具体的每个功能点究竟如何实现都必须要考虑到。
严格的概要设计，我们希望是到了概要设计的某个功能模块，模块所涉及到的核心的类全部会出来，类关系图全部会出来。数据库设计也进一步细化到该模块的数据库物理模型。对于用例进行用例实现分析，在实现分析过程中可以看到每个类核心的public方法全部会分析识别出来。
拿着架构设计的接口，概要设计也需要进一步细化，细化出接口具体的输入输出和使用方法，包括模块应该使用哪些外部接口，模块本身又提供哪些接口出去都必须细化清楚。做概要设计的时候一定要清楚当前做的这个模块在整个应用系统架构中的位置，和外部的集成和交互点。
概要设计不用到详细设计这么细化，包括类里面的私有方法，public方法的具体实现步骤和逻辑，伪代码等。但是我们要看到概要设计里面对于核心的业务逻辑必须要设计清楚如何实现，实现的机制和方法。很多时候我们到了概要设计画uml的时序图，很多时候一看没有任何意义，全是跨层的简单的交互和调用。这个应该在架构设计的架构运行机制说清楚即可。设计到多个业务类间的交互调用才是重点，一个简单的功能增删改查，完全没有必要画什么时序图。
其次架构设计中给出了各种安全，性能，缓存的设计。那么在概要设计中出来另外一个问题，即架构给出的各种实现方案和技术，我们在概要设计中如何选择，如何使用。不是所有功能都需要缓存，那就要说清楚哪些功能根据分析需要缓存，需要缓存哪些对象，缓存本身的时效性如何设置等问题。
概要设计作为我们要达到一个目的，就是不论是谁拿走概要设计来做，最终实现出来的功能模块不会走样，功能模块最终实现出来可能有性能，易用性等方面的问题，但是整个功能实现的大框架一定是定了的。
============================================================
2015-10月更新，架构思考
组件划分和服务接口
组件化开发思路在很早以前就已经提出，只是当时的组件间交互更多的谈接口而非服务，同时也没太关心单个组件本身的全生命周期管理。谈组件的时候一定不要先谈开发和技术框架，而是真正从业务架构和应用架构出发去考虑整个业务系统的组件划分，其中包括了业务组件和技术组件，各自应该暴露业务和技术服务能力。业务能力组件化和组件能力服务化也是一直强调的SOA核心思想。
在组件划分清楚后，需要优先考虑组件间的交互而需要暴露出来的服务接口，即组件之间只能通过服务进行协同以进一步实现组件间的松耦合。其次才是考虑单个组件在实现的时候，结合分层开发技术框架涉及到分层，在这里可以进一步参考领域模型驱动和设计的思路，否则很容易实现为数据库表驱动功能而不关心领域模型设计和领域逻辑的实现，即虽然技术框架分层了但是职责不清，逻辑混乱并多处实现。
组件内部的实现一个重点就是应用层和领域层之间的关系，即在应用和领域层之间增加了一个服务层，服务层重点是服务接口和服务的组合等工作，而具体业务规则和数据处理的逻辑在仓储类和规则类里面来实现。注意对于组件内部应用层和领域层交互的服务并不一定要做为分布式的Service服务，也可以直接使用内部的API服务接口即可。将服务层服务接口具体的逻辑实现分离的一个重点就是在后期很容易将服务接口发布为一个供其它组件远程调用的服务方法。
开源组件和技术
对于单一的技术往往很难满足互联网业务场景下不同的功能需求和非功能性需求，对于不同的功能或技术实现往往都需要选择大量的开源组件或技术进行集成。但是这些独立的技术组件如何集成为一个高效的整体就变得相当重要。任何技术的选择都必须为了业务需求服务，模式分析是选择技术的一个重点，即在什么样的业务场景下，面对什么问题我们究竟应该选择什么样的开源技术来实现最合适。
首先是开发技术框架层面的，即常说的基于MVC模式的多层框架，用的最多的估计还是SSH框架，其中在数据库层面又有Hibernate或iBatis多种实现，在控制层本身又有struts和spring mvc多种实现。在展现层相关的技术点更多，包括了一些前端基于javascript和jquery的框架引入，Ajax实现，包括当前互联网各种前端响应式框架，Html5技术等。技术框架的选择看似和业务无关，但是却需要进行业务场景分析，包括当前开发的应用是否需要同时支撑web端和移动app端，是否存在和外部集成和服务接口暴露，在业务交互和易用性层面有哪些要求，这些都需要考虑进去。
其次是实现核心技术能力的技术组件，其中包括了缓存，消息，流程引擎，搜索，安全，任务，日志等诸多内容，这些当前往往都有现成比较成熟的开源技术来实现。如通过memcached或redis来实现缓存，通过rabbitMQ或zeroMQ来实现消息和事件管理，基于lucence的全文检索引擎，开源的ETL技术实现数据集成，开源的jbpm流程集成等。在选择这些技术的时候要注意和前面整体技术框架的集成，技术组件应该保持其高内聚和独立性，仅仅技术组件的能力通过服务暴露出去实现和上层应用的集成。要做到这一点往往就需要对开源组件进一步进行封装和定制，以和技术框架形成一个完整的整体，同时又不要把底层技术组件的复杂度暴露给业务功能的开发过程中。还有就是互联网应用还涉及到外部技术服务能力的引入，如外部的邮件通知服务能力，地图能力，支付能力，各个外部开放平台开发的各种内容提供服务能力引入等。对于外部服务能力的引入建议是要在技术平台层单独进行管理和封装，即在技术能力层有独立和统一的服务代理。
最后是数据库和持久化层，包括常见的关系数据库，半结构化和基于key-value的redis，mongoDB等数据库，还有就是完全基于hdfs的非结构化文件存储能力。对于不同的业务场景和业务对象，往往需要底层不同的数据和存储能力进行支撑，如何形成一个完整能力的数据库服务能力层是架构设计时候需要考虑的。
去IOE化
对于去IOE化是这两年互联网架构设计谈得最多的问题，即去掉小型机，集中存储和商用数据库。如果简单来说下去IOE化的核心就是基于开源的类似Mysql数据库和集群技术，通过X86服务器硬件资源来实现和原来使用IOE架构时候同样的性能和高可用性。在之前淘宝有开源的corba基于mysql数据库来实现分布式数据库和集群，现在有开源的MyCat来实现，核心就是提供一个DaaS服务层和封装，来实现高性能和高可用的数据库中间件产品。
对于去IOE的热度在当前已经有所下降，这里面有两个原因一个是本身技术成熟度和CAP原则约束，一个方面的原因就是在去IOE和引入DaaS数据库中间件后本身是增加了架构复杂度和应用开发难度。一个方面是由于DaaS层引入导入的分布式事务问题和对于跨库查询和Sql语句本身的约束增加。一个是在架构设计中就需要考虑前端业务如何进行组件化，业务对于的数据存储如何进行分区和分片，究竟如何进行水平拆分和垂直拆分。
可以讲在架构设计中的去IOE设计和前面讲到的组件化和服务化设计思路密不可分，同时在去IOE下的组件化是彻底的组件化，即组件本身对应的数据库也是独立的，组件可以拥有完全独立的硬件资源和全生命周期管理。因此如果组件没有划分，在后期业务功能实现中就可能导致大量的跨库操作和分布式事务问题。这些都应该在架构设计阶段就思考清楚并制定清晰的架构设计约束，任何架构设计都不会有普适性的通用架构存在，架构约束定义是一个架构要发挥其高效能力的关键。
去中心化
首先来看一个最简单的场景，即客户和请求端是A，服务提供端是B，对于服务提供端已经实现为了分布式集群即(B1,B2,B3...Bn)，在这种场景下可以看到对于请求会转发不同的集群节点进行处理。但是对于这种分布式架构来看，集群是可以完全平滑弹性扩展的，但是问题关键点在于A的请求究竟应该转发到哪个B节点去处理，这里面就有一个控制层或管理节点，而对于大多数分布式应用来讲管理节点本身是很难集群化扩展的。及时当前很多分布式架构实现过程中已经实现了消息请求和数据传输的分离，但是仍然存在对于管理节点无法水平扩展的问题。
对于水平弹性扩展问题的解决，往往会引入集群技术和硬件负载均衡，但是这不是一个完全意义上的去中心化架构，当前我们说的去中心化架构都是没有统一的管理节点，完全分布式，只有在这种架构下才是完全的去中心化。要做到去中心化就涉及到几个关键点的引入，一个是请求通过sdk包在客户端的植入进行前移，即客户端发起请求的时候就已经判断清楚；其次是对于管理职责后移，即管理端后续重点是从各个集群节点准实时采集数据再进行分析。要实现第二点往往又涉及到高性能的消息中间件的引入。技术人员，最大的通病，就是就技术而技术，这个在初级阶段很实用，也高效，但是，想真正做好架构师这个职位，一定要清楚产品，甚至如何运营，一个好的架构，一定是符合当下并可以在一定时间内不用重构的架构（最少为半年，互联网的特点，不可能不重构，twitter之前披露的资料显示他们平均半年重构一次架构）。
关于混合语言的问题。这个问题我觉得要辩证的看，混合不一定好，也不一定不好，关键是要看团队的接受能力，单一语言的特点是整个团队的执行效率高，维护成本低；混合语言的特点是软件整体优，但维护成本和整个团队的执行成本就会很高，架构师也应该有这方面的考虑。
学习，保持好奇心，按着“1000”考虑问题，按着“1024”设计架构，总有一天，会成长起来的从楼主题目里描述的背景出发，我的建议是这样的：
- 对计算机这种工程学科，自学不一定不科学，但是要保持大量的实践。
- 为一个成型的产品Troubleshooting是进入架构领域的好办法。有一点必须强调：它不一定得是优秀的成熟产品。对善于总结的人来说，烂产品提供的反面教材从某种角度上看更加珍贵。
- 无论Troubleshooting经验如何丰富，最终我们必须要得到自己设计的机会。这是从经验积累落实到架构能力的唯一方法。如果条件许可，参与开源产品其实是个很好的机会（当然有的公司明令员工除非特许否则禁止参与开源项目，比如微软）。
还有一点必须指出的是，尽管我也认同架构的重要性，但从楼主自己说的自学内容（目前属于自学，设计模式，算法导论，编译原理，UML2.0等都在看）来看，我感觉楼主还没搞明白架构师究竟是什么。如今业界人人都在讲架构，但所谓架构师细分起来实际上有很多种，即便只是算软件行业经常要打交道的（也就是说芯片架构师不算），我见过的情况就包括如下：
- 网站基础设施设计师。比如一个能承受百万级访问量的网站该如何配置服务器等。这种架构师关注的是如何配置异地服务器，如何分流请求，如果做负载均衡、备份和同步等等。
- IT基础设施设计师。这种架构师和网站基础设施的架构师有一定交集，除此之外经常还需要考虑跟硬件有关的话题，比如机房空调温度，UPS，带宽升级等等。
- 软件设施设计师。这种架构师经常要负责对软件系统使用的部件做选择，比如安全系统上使用的是Kerbero还是SSH，图形系统选择本地UI还是跨平台库，网络协议或文件格式使用公开的标准还是自己设计等等。此类人往往还关心许多诸如性能、兼容性等方面的话题。
- 框架狂热综合症患者。此类“架构师”最喜欢的就是在一个项目里搞个所谓的类库，里面写上一堆抽象类和接口，然后到处宣称其类库设计极其便于扩展云云并强迫同事负责实现其具体功能。另外，此类人的一个显著特征是对各种新框架或语言特性异乎寻常地热衷，却从不屑于实现一个真正具有能用功能的部件。
当然了，要做第四种显然最容易，哈哈。个人意见：作为一个“架构师”，最重要的两点：
第一，也是最重要的一点是深刻理解业务规则和业务特点。忽略了这一点，做不出好软件。
其次，是技术视野必须要宽，宽度甚至比深度更重要。不是用某种你谙熟的技术去解决业务问题，而是根据业务问题选择合适的技术。个人觉得，有些方面的能力是天生的。
如果你想成为一个好的架构师，不是看几本书，读几年书就能成为的。
我觉得好的架构师需要2个根本的，比较天生的能力（相对比较天生，但也是日积月累出来的）。
1、在项目的开发过程中，能很快的感觉到问题会发生在哪个环节。
当然，要做到这点，最主要靠的是经验，其次才是意识，这个能力是必须的。不管什么项目，对于进度影响最大的其实就是当问题突然的出现。我们或许规避不了问题，但我们可以有准备，在前期编码，或下层代码的开发过程中，针对可能出现的问题，做一些预备工作。
2、对于每个项目的责任心。
或许，这个是做任何事情都需要的一种，人身上必须要有的要素。
当问题发生时，第一时间，和同事一起去找问题，而不是推卸自身的责任。当你的同事，在架构内，开发进度缓慢、bug数量增加、经常抱怨时，你是否需要去询问一下问题，分析一下是否是架构导致以上原因。
当然，架构师必须的当然是，写上N年的代码，这个谁都知道，就不必多说了。其他的，以上几位已经讲的很多了。
笨人拙见，祝我们一起奔向自己的未来。
一句话概括的话，就是得犯过足够多、足够深刻的错误才行
稍微具体而言的话，架构设计一般有两个层次
- 设计性能不敏感、或是低计算量的应用：这是个初级层级，在这个层次上的普遍思路是分解问题，然后通过组合各种“solver”来解决。架构师可以随便翩翩起舞，使用各种“框架”、“类库”，借鉴各种“模式”，发明各种“概念”（这些全部都是solver）。由于计算量低，所以最后总能“条条大路通罗马”
- 性能极端敏感，计算密集的应用：这时候初级层次的很多经验反而起反作用了。因为组合“solver”只能解决计算正确性目标，但不能解决性能目标。所以架构师需要能“脑内模拟”业务需要的必要数据流，然后充分利用（exploit）数据流的特性来尽可能地削减计算、避免瓶颈。这时算法功底就尤为重要，很多第三方的“框架”、“库”只有拆解以后“白盒利用”的意义。性能设计要优先于“代码的封装性”、“可读性”、“可测试性”、“可管理性”以及“团队可分工/协作性”（基本上软件工程里的原则都要让位于性能设计）
首先，你要付出你所有的业余时间，用在阅读大量书籍和钻研最新技术上面，你要去掉你80%的兴趣爱好，因为架构师是一个和世界IT新技术赛跑的疯狂的职业。如果你每天下班后用于研究技术的时间少于2小时，那么你必然无法成为一个优秀的架构师。先有了这个觉悟，至于后面具体学习些什么，学习的顺序，那都是次要的问题，上面各位说的都很全面了。
其次，你现在最需要做的就是找一个女朋友。因为如果你走上架构师这条路，你很可能没有时间找女朋友了。好的架构师除了自身技术能力外，眼光更加重要。对于创业公司而言，架构师需要能准确看到公司业务核心需要解决的问题，比如我们公司业务价值在于资讯和行情的速度，那么最开始做架构的时候就花了非常大的精力去提升系统的实时性，比如投入人员去自动化整个信息发布流程，比如使用WebSocket代替有延迟的轮询方案，同时又对低端设备准备好降级的替代方案等。而对于一般架构中比较重要的用户系统，其实我们是等到公司开始涉及金融交易业务时才去将这一块完善的。
个人愚见是，没有什么架构能解决所有问题，大公司的架构也未必能适合创业公司用，如果我们一开始就花精力去做用户，去规划分表分库，系统本身固然会得到更好的扩展性，但是公司的发展速度却会受阻。我总结创业公司做架构优先考虑的应该是用较低的成本满足当前需求，并且保证一定的前瞻性就够了。勤膜拜，勤学习，勤思考，勤动手，脚踏实地，一步一步来，始终可以成为高手的。这是我在另外一个问题中的回答：
架构师的路到底怎么走？ - 刘欣的回答
自己经验总结一下，优秀架构师应该从“四度”进行学习和提升，同时这也是优秀架构师应该具备的能力。
一、广度
广度指的是架构师应该对所在领域的主流技术体系有一个全面清晰的认识，每一种技术不需要很深入的了解，但必须知道每种技术的3W：
1，Why：每种技术的由来，为什么会出现这种技术，这个技术是用来解决什么问题的？
2，What：每种技术是什么？技术的基本组成部分是什么？
3，Which：解决同一问题的相同技术各自的优缺点是什么，更适合哪种场景？比如，ORM框架（Hibernate与IBatis），MVC框架（Struts与SpringMVC），大数据技术（Hadoop与Spark）它们各自的优缺点是什么，只有清晰认识同一类型技术的优缺点，才能在技术选型时能够使用更加合理的技术。
广度的学习方法：对各主流技术一一通过搜索引擎了解其3W的内容。
二、高度
高度指的是架构师应具备对客观事物的“拔高”能力，能够从纷繁杂乱的信息中建立秩序，也就是我们一般所说的抽象能力。抽象能力包括：
1，业务抽象：能够软件和产品的复杂的需求中抽象核心业务实体，并给各业务实体建立合理的关系；
2，技术抽象：能够对复杂的技术架构进行分层抽象、服务抽象（微服务抽象）、组件抽象，并为各层和各服务之间的调用建立合理的“关系”；
高度的学习方法：深入理解和学习面向对象、设计模式，琢磨优秀开源框架的设计原理和设计思想。
三、深度
深度指的是架构师能对主流技术有较为深入的理解，主要包括：
1，可以不了解源代码，但对主流技术的原理，运作机理有一个基本的理解；
2，至少对一种技术有深入的认识，是这种技术的专家，熟悉其源代码
以上2点，1为必须，2为非必须
深度的学习方法：上文已说。
四、宽度
宽度指的是架构师能够熟知当前的技术前沿和热点，能够使用新的技术解决问题。比如，微服务、大数据、云计算、人工智能等。
宽度的学习方法：可以使用手机订阅相关的技术资讯了解，定期了解即可，对于跟所负责工作相关的技术进行进一步的了解。
小结：
广度决定了系统架构技术选型的合理性；
高度决定了系统架构设计的合理性；
深度决定了系统架构的优化能力；
宽度决定了系统架构的领先性，不至于三五年被淘汰
以上，四度缺一不可。
有点文
2017-1-7
这是个非常好的问题。
我想说，题主的心态已经保证了其已经成功了一半。
剩下的，我不想去抄各个教程书籍里面的大堆定义，因为以我的体验来说，基本没什么用，例如什么系统架构师，什么需求分析师，什么模块、组件、接口等等，都是政治正确的废话。
都正确，但是看了也白看，完全没有帮助。
所以，我基于我的经验给些建议吧。
第一、知识面要广
其实我认为做架构师的，从来都是CTO储备，因为需要涉及的能力太广。
做架构，其实最简单的理解就是一句话，就是在有各种限制的情况下想办法解决问题。
所谓的限制就是性能、稳定性、开发效率、可维护性等因素。
例如，百度贴吧这种应用场景，每天可能有几十亿次的访问，几千万甚至上亿次的写入。肯定是性能要求为先，可能为了做性能的提升牺牲一部分开发的效率。
再如，银行的应用场景，不是非常在意用户的体验和访问延迟，但是对于数据的安全性和一致性非常非常重视。这种时候，肯定是安全和稳定优先，性能后面考虑。
在限制中做权衡，也就是意味着要做大量的选择。但做选择那首先你得知道有哪些选择。
所谓的性能和安全，除了这几个字之外，具体的技术实施上，总得知道都有哪些方案吧。
1.例如java体系、php体系、c体系、还有python/nodejs/golang等，各自有各自的优势劣势，你总得有过相关开发经验才能做出正确的选择吧。道听途说是没有发言权的。
2.虽然现在数据库用的最多的是mysql，但是oracle/pgsql也都有其优势。
3.现在项目几乎没有不用到大数据的，那么大数据的算法至少得有些理解吧，大数据的平台得有些经验吧。
4.玩转整体项目还有许多许多的点，例如代码如何管理、上线部署，如何测试保证bug率，系统的监控，服务器部署，灰度发布等等。
不要听那些一提架构师就好像多么高大上，做的都是些设计师类似的工作，系统设计、软件设计等。那些都是人云亦云YY出来的。
没有哪个互联网公司让你去专门做设计，因为互联网公司领导们统统无一例外需要都是功能的实现，战略战术想法的实现。
所有的大型系统架构，全部都是基于面临的问题一步一步解决迭代出来的。没有场景会让人一步到位(甚至哪怕提前一段提前量)去设计一套牛逼系统的，因为世界变化太快，项目如果不赶紧实现，明天可能就挂了，哪有那些闲心去给未来几年做设计。
所以，做架构师最关键的是对整个项目的把控能力，可以让项目高效率的运转。
第二、卓越的代码能力
想要成为架构师，首先得是一个优秀的程序员。怎么样才算优秀的程序员呢？
光写代码不思考、不学习肯定是不行的。
最明确的，就是得深入掌握各类数据结构、各类设计模式、计算机网络、操作系统、各种常见的架构模式等。这些提的非常多，但是能做到深入理解的我感觉可能没几个人。
包括我自己，当年刚开始看设计模式的时候，1个多月就感觉已经全部理解了。但是之后每次或者复习的时候，或者看到写的非常好的代码的时候，重新去温故此方面的知识，都能感到有新的收获、都会有更深的领悟。
而且，理解也仅仅是开始。如何完完全全的融入自己的代码中，才是关键。
写代码经常也同样充斥着架构设计的感觉。其实我认为，程序员写代码叫编码或coding，而架构师写代码就叫架构设计。
因为两者写代码时考虑问题的角度完全不同。程序员可能更多考虑的是如何实现功能，而优秀的程序员才可能会考虑的例如性能、可读性、可维护性的问题。
而这些对于架构师来说则是必须考虑的，考虑的纬度经常还会更多一些。
所以，不要想着一步到位的跳过优秀程序员而直接成为架构师。不现实。
第三、对某些相关领域要有深度
刚才讲了技术的广度，但是如果什么都知道，但是什么也不善长，没有什么精通的。那依然只能做个程序员。
那么哪些领域算是关键的领域呢？
到此基本就由业务方向的不同而区分不同的架构师了。
例如金融领域的架构师，可能需要金融知识。
例如大数据领域，可能对hadoop/spark/hive之类的大数据领域知识要求深一些。
再如高并发领域，可能对整个系统的性能优化，分布式系统设计等更深入一些。
第四、要有技术洞见
这个技术洞见是借用《重新定义公司》里的词。换个易理解的词，就是技术上的远见卓识。
以事后诸葛亮的方式举几个例子：
1.当年的京东如果选用的不是windows平台，可能发展比现在好不少。
2.百度如果不是李XX的目光短浅，总是比市场慢几拍，现在也不致于被AT远远甩开。
这种事太多太多。
不要感觉好像很虚幻，如果你现在身为一个创业公司的架构师，你现在的一个貌似正确的决策可能直接导致未来公司的大量损失，甚至倒闭。
第五、管理能力
架构师少有不带项目、不带人的，所以管理能力肯定也是必须。
但管理能力是个很大的主题，这里就不多说了。
这些就是我多年架构经验的一些总结。谢谢。
————————————————————————
2017-7-19补充
回头看看，其实我写的也都是些方向性的东西。
但是由于架构师职业的特殊性，真的很难给出一条具体的道路，只要按照这个道路走下去就能成为优秀的架构师。
但有些原则性的方法还是有的：
我说过，作为架构师，其实所谓的设计能力并非关键，因为一个项目完全凭空设计的机会很少，而且也都可以基于当时情况的权衡，直接使用别人们的设计方案的组合。
这就是为什么看架构师相关的帖子看多了，就会发现所谓的分布式架构、大型网站架构，基本来来回回就那么几种。导致是个人出来都能喊两句架构怎样怎样。
那么关键的是什么？是项目的把控能力，以及面对具体问题的解决能力。
而要锻炼项目的把控能力和解决一些具体问题的能力，有时候光靠公司里的项目是不够的。
因为公司项目中你往往只是其中的一员，只是干某个具体的工作，例如前端js、app、后端业务等。项目整体的运转情况你一般是了解不到的。即使运气好，项目负责人对此的把控很到位，而且还愿意全部讲解给你听，但毕竟很多环境你没动手做出，光凭别人说是不大可能有深刻的理解的。
那怎么办？你应该自己抽空全新做一个自己的项目，例如一个BBS网站、一个有后台的app等。网站或app本身不重要，重要是你要自己开发、自己搞定上线系统、搞定监控系统、搞定发布系统、搞定测试系统等等。
就是像一个正式公司的正式产品一样对待这个自己的项目。
这样几个回合下来之后，你就会发现，你对整个项目的感知度提高极大。不再像以前那样，对项目除了自己负责的部分，其它都是迷迷糊糊的。
提升实力从点赞开始。
架构是已经解决的问题
各个栈都是，架构不是玄学，而是套路。所以与其说架构“设计”，不如说套路“运用”。
比方说LAMP就是架构，做web后端的不会不知道，变化一下LNMP，无非Apache换Nginx，都是套路，有限的变换带来的适应性，“靠谱性”。A和N这样有限的变换够了，不用自己搞出来X，Y，Z，那是Geek和CS高材生的事，不是架构师的事。
MySQL你觉得太简单，好，主从，双主，分引擎，分库，上NoSQL，NewSQL，上OO数据库，上分布式数据库，上为写入优化的数据库，Casandra，Riak，上AWS DynamoDB，Big Table和其他一堆名字 ...
Linux你觉得太简单，好，集群，分流，分层，安全维护，同步管理，上Puppet/Chef，监控，警告，上Nagios，Fail Over，Load Balancing，上各种第三方DevOp工具，内核定制（我乱说的） ....
Apache, Nginx 你觉得简单，好，集群，分流，分层，外包给Serverless服务，快速部署，统一维护，安全维护，监控，反向代理 ... 上各种工具 ...
PHP觉得简单，好，依赖管理，单元测试，回归测试，安全审核，Profiling，日志监控，持续集成，分层，复用，MicroService化，队列，缓存（文件，Memcache，Redis或者什么东西），SSO ...
还是觉得简单，跨机房部署，多数据中心，智能DNS，CDN，分流，分层，SAAS，PAAS，DBAAS，各种AAS ...
有时候砸个钱加个机器，也是架构工具的一种，“钱”就是架构，无招胜有招，只要你老板肯批。
没什么神秘的，都是套路。
架构师是什么
架构师就是这样的角色：
- 理解问题（到底是什么），知道什么时候需要什么，（可以）用什么，（该）用什么，（不该）用什么，套路
- 明了设计原则，什么是好，什么是坏，什么看上去好实际不好，什么现在好以后可能不好，根据设计原则持续改善系统运行（各种）效率，降低（各种）成本，创造（各种）价值
- 顶层设计，整个系统完了要达到什么形状，什么目的，怎么用套路达到这些目的
- 接口设计，这一大坨（子系统）达到什么目的，那一大坨（子系统）达到什么目的，这一大坨（子系统）和那一大坨怎么接起来
架构师“不是”什么
- 陶醉局部“设计”，把自己当“技术美学家”，其实就是偷懒，不想面对真实问题
- 迷醉所谓“底层“，把“底层”当银弹，觉得“底层”洞穴插着釜底抽薪的神器，其实就是偷懒，不想面对真实问题
- “干（粑粑的干）”玩儿“技术”，爱表演，爱参加兴趣小组，其实就是偷懒，不想面对真实问题
- 不知道技术品位是什么东西，所以“Apache上跑PHP留言板 === LOW”，因为现在“nginx才是真爸爸”，其实就是偷懒，不想面对真实问题
- 从代码开始到代码结束，“茴香豆的茴800种写法”，其实还是偷懒，不想面对真实问题
- 无边际的开放思维空间，假设“一切皆有可能”，不想承认约束，其实就是偷懒，不想面对真实问题
- 标准答案，非黑即白，其实就是偷懒，不想面对真实问题
- 算命，其实就是偷懒，不想面对真实问题
怎样成为出色的架构师
- 转意识，明白解决问题适应变化是核心，一切技术都是这个核心的外部工具，语言，数据库，环境，其他什么东西，都是外部系统，是工具
- 找机会，做各种系统，不同场景，不同应用，不同体量，让自己成为杂食动物，让自己有九个胃，一个栈上的蔬菜水果都吃一遍，彻底反刍消化
- 学套路，旧套路，新套路，理解从问题到套路的思维过程，旧套路如何解决问题，新套路如何解决问题，套路的好套路的不好，经验与直觉无非就是这么回事
架构“思维”与每天工作的关系
关注程序设计，“运用”架构思维，而不是停留在做功能，明白两者的区别。
因为分离，分流，分层的理念无处不在，现在写程序，你不想看到Service这个词都很难。程序设计多数时候不需要上升到“模式”这个高度，也不需要等到“干大事”这些才有用，架构师的基本思维习惯，还得从程序设计的训练中来，干小事和干大事的区别，有时候也不过把一个类的一堆数据库语句换成一个外部REST Service。
架构师是可遇不可求的职业
中小型公司根本不设这个title，你想干也没有（即使有也没什么可乐的，勾引你的），大公司估计轮不到你，坑都被占了。
所以很多人说“我想成为架构师”就和现在女人说，我想要一个“身高一米八，长得像韩星，有房有车，房子写我的名字，存款500万，聪明体贴，坚强又脆弱，幽默又严肃，包容我一切，永远对我好，还会七十二变的男人”，就是不知道自己在说什么的“疯狂癔症”而已。
有些东西就是可遇不可求，有买家没卖家。
但是，没有title，也可以架构
没有架构师的title，也可以“架构”。架构从你意识到问题的紧迫与有趣，“值得解决”，想着如何让实现更“简洁明白跑起来更快更省电费小白秒懂以后一行不改只要填个空就行”的时候就已经上路了。
架构就是思考，实践，验证，沟通，实事求是地给个靠谱的解决方案。
架构就是有追求。
正文开始：
架构应该包括了功能性架构和非功能性架构两个方面的内容。我们常说的JEE，DotNet标准架构框架更多的是非功能性架构的范畴；而谈的子系统，组件划分，接口设计，复用等内容涉及到功能性架构的内容。JEE架构的标准模板很容易找到和借用，但是并不代表你是一个合格的架构师，架构师必须深入到功能性架构中，真正的做好需求和实现中间的桥梁。正如现在好的PPT模板一大堆，但是并不代表你能够做出好的PPT来，PPT的模板仅仅是术，而PPT内容和思维才是王道，而这里又是我们经常讲到的模式的问题，即根据我们的目标如何选择相应的图表和模板来最合理，最简单的展现我们的内容。
从静态分析的角度来考虑，架构的核心即是分解和集成。我们面对的现实业务和需求可能太庞大了，如果不去分解我们的构建根本都无法下手，我们就无法真正理解业务细节。因此子系统和组件划分是分解重要内容，分解重要原则又是高内聚，松耦合。由于分解产生了组件间的交互，因此需要根据关注接口的分析和设计，架构师的一个关键职能就是要屏蔽系统本身复杂性，将复杂性作为一个黑盒控制在自己手里，对外只需要暴露尽可能简单的接口。而在分解的时候又必须要考虑集成，架构师在自己脑海里面已经有了目标系统的样子，他们会很有信心分解的组件能够通过当初定义的接口很好的集成在一起。正如汽车制造一样，所有的零备件都出来了却发现它们根本无法组装成一台汽车。这对架构师是最大的悲哀，系统都还没有出来，而架构师就能够游刃有余的做这些事情，靠的不仅仅是多年的设计和开发实践，更多的则是在实践过程中的抽象思维和模式总结。
从动态分析的角度来考虑，现实世界中的原始需求进入，最终出来的则是满足需求的功能实现。在这个过程中涉及到一系列的内部程序流转流程，前台界面，业务逻辑，数据访问，数据实体，公用组件等。这些层次之间应该怎样去交互是在架构设计中必须要考虑清楚的问题，在这方面我喜欢用架构机制这个词语，机制往往并不是静态词汇，因为要深究机制就必须要搞清楚事件触发，功能调用，访问顺序等一系列问题。简单的讲，架构机制要回答一个重要的问题，即你设计出的分布式框架如何能够满足输入的需求变成最终输出的功能，中间究竟经历了哪些步骤？安全性如何保证？性能如何保证？可扩展性又如何保证？要回答这些问题你都必须给出这些问题的解决方案的运行机制，而只有大家认可了运行机制，或者新出来的模块已经在新架构上运行验证了，才能够讲从架构框架上基本上已经成熟了。
架构本身不是目标，而简单实用并且支持灵活扩展的系统才是我们追求的目标。架构师思维意识里面更加重要的是实用性和经济性而非理想化，由于业务域和问题域的不同没有完全可以照搬的架构，在架构设计上追求一定的可扩展性。要杜绝过度架构和架构理想化的问题，就如何建造一个建筑，如果我们最终得不到一个实用的的建筑物，你再怎么向客户吹嘘你的设计图纸和建造框架如何合理都是徒劳的。
看完后，大家想相互交流的可以加一下架构师交流群246721028相互沟通交流学习一下哦。顺便点个赞哈，嘻嘻(#^.^#)
每个程序员心中都有一个成为架构师的梦想，梦想是美好的，但道路是曲折的。
@李运华 （华仔）是InfoQ的金牌签约作者，资深技术专家，两个孩子的爸爸，勤奋的思考者，快乐的写作者。
从06年开始接触架构设计、花费8年时间掌握精髓成为老司机，他的从业道路，是非常典型的从普通程序员到优秀架构师的成长之路。不久前，他在极客时间开设了付费专栏，分享原创的架构设计经验，订阅数已经突破22000+，现在分享给你这篇文章，希望对成为架构师的你有所启发。
我大概在2006年开始参与架构设计，原本以为学习架构设计就像学习一门编程语言一样，先学习一下基本的语法，再研究一下细节和原理，然后实践一下就能够快速掌握。但真正实践后才发现，架构设计的难度和复杂度要高很多，从最早开始接触架构设计，到自我感觉初步完整掌握架构设计，至少花费了6年时间。等到自我感觉彻底掌握架构设计的精髓，至少花费了8年的时间（当然，这个过程中我不是一直在做架构设计）。
我曾经以为是自己天资愚笨才会这样，后来我带了团队，看到几乎每个程序员在尝试架构设计的时候，都面临着我曾经遇到过的各种困惑和瓶颈。特别是我作为职业等级晋升评委的时候，发现很多同学技术能力很强，业务也很不错，但却卡在了架构设计这部分。我意识到这应该不是个人天资的问题，而是架构设计本身的一些特性导致的。
我总结几个架构设计相关的特性：
1、架构设计的思维和程序设计的思维差异很大。
架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。很多程序员在转换为架构师后，很难一开始就意识到这个差异，还是按照写代码的方式去思考架构，会导致很多困惑。
2、架构设计没有体系化的培训和训练机制。
大学的课程几乎没有架构设计相关的课程，架构设计的书籍更多的也只是关注某个架构设计点，没有体系化的架构设计书籍，导致程序员在学习上没有明确指导，只能自己慢慢摸索，效率低，容易踩坑。
3、程序员对架构设计的理解存在很多误区。
例如：要成为架构师必须要有很强的技术天分；架构师必须有很强的创造力；架构设计必须要高大上才能体现架构师能力；架构一定要具备高可用、高性能……这些似是而非的误区让很多技术人员望而生畏，还没尝试就已经放弃了。
得益于移动互联网技术的快速发展，我在加入UC后有很多的机会直接参与架构设计，这些架构背后的业务形形色色，包括社交、电商、游戏、中间件、内部运营系统；用到的技术栈差异也比较大，包括PHP，Java、C++等。虽然每次架构设计对我来说都是一个新的挑战，但正好也提供了非常好的机会，让我亲身体验不同的架构设计。在这个过程中，我不断学习、思考、实践、总结、改进、交流，逐步形成了自己的一套架构设计方法论。
有了这套方法论后，首先，我自己在做架构设计的时候游刃有余，不管什么样的业务，不管什么样的技术，按照这套方法论都能够设计出优秀的架构。在职业等级面评的时候，就算我之前从来没有接触过对方的业务，也能快速理解对方描述的架构和发现其中做得好或者做得不好的地方；其次，在指导其他同事的时候效果明显。原来对架构设计比较迷茫的同学，通过几次结合案例进行的方法论培训，都能够很快地掌握这套方法论并在实践中应用。甚至有很多其他业务线的同学，遇到架构设计的困惑，也来找我交流和指导。
我是一个很喜欢分享的人，经常在InfoQ写文章、在知乎写回答，当看到别人在经过我的指导后恍然大悟甚至醍醐灌顶的那种神态，或者发自内心由衷感谢的时候，我自己也会很有成就感。我在极客时间的专栏《从0开始学架构》，将与你分享我的架构设计方法论，希望能够帮助更多怀揣架构师梦想的同学早日实现自己的梦想。
这个专栏涵盖了我的整套架构设计方法论和架构实践，主要包括以下内容。
- 架构基础：我会先介绍架构设计的本质、历史背景和目的，然后从复杂度来源以及架构设计的原则和流程来详细介绍架构基础。
- 高性能架构模式：我会从存储高性能、计算高性能方面，介绍几种设计方案的典型特征和应用场景。
- 高可用架构模式：我会介绍CAP原理、FMEA分析方法，分析常见的高可用存储架构和高可用计算架构，并给出一些设计方法和技巧。
- 可扩展架构模式：我会介绍可扩展模式及其基本思想，分析一些常见架构模式。
- 架构实战：我会将理论和案例结合，帮助你落地前面提到的架构原则、架构流程和架构模式。
通过本专栏的学习，你会收获：
- 清楚地理解架构设计相关的概念、本质、目的，避免架构师在实践过程中把握不住重点、分不清主次，眉毛胡子一把抓，导致架构设计变形或者“四不像”。
- 掌握通用的架构设计原则，无论是何种业务或技术，架构师在判断和选择的时候有一套方法论可以参考，避免架构设计举棋不定，或者拍脑袋式设计。
- 掌握标准的架构设计流程，即使是刚开始做架构设计的新手，也能够按照步骤一步一步设计出合适的架构，避免某些步骤缺失导致错误的架构设计。
- 深入理解已有的架构模式，做到能够根据架构特点快速挑选合适的模式完成架构设计，或者在已有的模式上进行创新，或者将已有的模式组合出新的架构。
- 掌握架构演进和开源系统使用的一些技巧。
本文摘自李运华的专栏《从0开始学架构》，极客时间版权所有，戳此点击试读文章，查看原文。
附上华仔总结的架构师技能图谱，欢迎下载保存：
http://t.cn/RdIcSEn (二维码自动识别)
高清版原图请戳此下载：@ 极客时间微博
对于一名如何才能真正的提高自己，成为一名出色的架构师？在这有一些看法希望能帮助到有需要的朋友，同时可以关注下专栏：
java架构技术交流里面有大量batj面试题集锦，还有各种技术干货文章分享，大家可以同时关注下我以后会不停更新更多精选文章！
对工作多年的程序员而言，日后的职业发展无非是专精技术，转型管理，晋升架构师三种选择。成为一名优秀的架构师，是大多数技术人的追求。
想要做架构，空有一身技术是远远不够的，知识的深度和广度，往往会决定一个架构师的架构能力。而这些知识，从你踏入 IT 行业那一刻起，甚至更早就应该开始储备了。
那么到底什么是架构师？如果有一天把你丢到架构师的位置上你会怎么做？ 做什么呢？以下来具体阐述下一些看法和建议！
一、两种架构师
工作五年以上的童鞋，或多或少都会有这样的经历：
在小团队或者项目中承担非明确的架构师职责，我们做
- 项目或者产品的关键设计和实施；
- 负责产品基础设施；
- 引入新的理念，框架；
- 解决团队中的复杂问题；
- 在团队成员中享有较高的声誉；
- 被老板认为是团队的关键人物。
如果有一天我们决定（或者其他原因）去做一个专职架构师，那么这两者会有什么区别呢？是否只是之前的方式的延续就足够？
我把第一种状态称之为“兼职架构师”，因为处于这种状态下的同学大部分的时候担当开发人员、PM的角色，只有在小部分时间承担了架构师的部分角色。做的绝大部分事情是自己可控的，自己做架构自己做实施或者在小团队中推行。
而后一种“专职架构师”则面临的是：他们不负责具体的业务系统，而又对所有的系统负责，他们也很少直接负责项目，但是职责却要求他们必须对项目要有提前把控，他们面对的是更大的团队，更大的问题域。
当然每一个人对是否应该存在“专职架构师或团队”都有自己的想法，从阿里的历史来看单独的架构团队也是分分合合。在这里不去探讨，我们关心的是如果有，可以怎么做。
二、专职架构师的职责
首先要弄清楚的是专职架构师的职责到底是什么？
微软对架构师有一个分类：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。这个分类是按照架构师专注的领域不同而划分。
在阿里除了EA之外的领域大家可能会同时涉及到，只是不同的时期偏重点不一样。比如前面说的“兼职架构师”可能偏重SA？专职架构师偏向IA+TSA。另外一个角度专职架构师更多考虑问题域和相应的系统架构，而“兼职架构师”更多的是产品的系统架构，具体来说我认为专职架构师重要的职责如下：
职责一：全局的技术规划
架构师第一个最重要的职责是技术规划，架构师最重要的产出是架构，架构就是蓝图，就是阿里常说的一张图。画蓝图就是做“全局的技术规划”，这张图上有什么？ 没有什么？什么时候有？什么时候没有？当你尝试去画图的时候一连串的问题拷打着你。对于一个架构师的心力和体力都是很大的考验。只有这张图非常清晰明确才能指引整个团队在同一个时间向同一个方向前进。
为了这张图你必须和业务紧密沟通，你必须有对应的技术深度和广度，在选型上有自己的方法论，敢于做出判断和决策。
另外一个重点是全局。全局我的理解是全面+格局，全面就是你的技术规划包含各个方面的，在所有的领域都有明确的指引，所以这张图本质是一系列的图的集合；格局上不要只关注短期利益，更多关注长期利益。不止关注团队利益，更多从公司角度出发，只有这样长期才能为团队带来更多的成长。
职责二：统一的方法&规范&机制
架构师第二个重要的职责，我们不仅仅要提供蓝图，还要提供配套的方法论&规范&机制来保障有序进行。蓝图确保整个团队在同一个时间向同一个方向前进。规范确保前进是有序的。为了有序，你必须拆解你的图，纵向、横向、功能内聚等等纬度拆解到权责清晰对等。这是一项相对复杂且繁琐的过程。
职责三：完备的基础构建
除了蓝图确保整个团队在同一个时间向同一个方向前进、规范确保前进的有序的、我们还需要提供强大的武器库，基础构建的完备程度决定你的团队装备是小米+步枪，还是飞机+大炮。完备的基础构建是否全部作为实际架构的职责，可以因情况而定，比如是否有实体的架构组。但是架构对此应当负责。
职责四：落地的规划才是架构
如果规划不能落地就是传说中的PPT架构师，我甚至觉得这是对专职架构师最大的挑战，前面的几个职责更加偏向硬实力，而这一个更多的是软实力的体现。专职的架构师如果不去关注落地的话慢慢就会架空，变成PPT架构师，那差不多就game over了。
三、专职架构师的权利
正如前面说到对架构师最大的挑战是落地层面，实际上“完备的基础构建”已经涉及到落地层面的事情，但是和完备的基础构建不同的是整体架构的落地涉及到方方面面，面临是更多影响因素：和业务的关系、组织结构、权责定义等等。
所以有人从“架构师的权利和职责”的角度出发推论谁合适做架构师。得出的结论是一个组织的领导者。因为只有他才能调动、协调组织。也有人认为架构师既不能完全负责技术团队，也不能完全游离在技术团队之外。因为负责容易屁股决定脑袋，游离就只能靠个人声望值吃饭了。
如正架构分类中EA的存在，很多领导者也确实身体力行的践行架构师的职责，然而精力终有限。实际上更多是平衡的过程。当然最高境界是影响力。
四、专职架构师的考核
针对前面的职责怎么考核？或者怎么设定自己目标？虽然说在不同的团队阶段，不同外在环境，不同的权责情况下不一样，但是在结果导向的背景下落地肯定是架构师重要的考核指标之一。
考核一：全局的技术规划
相比其他几项这一项是最重要又最难评价的，技术规划的好坏、全面性、前瞻性都是定性的描述，如何指引我们做出一个理性的评价呢？回归到本质上“技术规划”只是一个指路灯，团队中每一个人能不能看到“指路灯”就到达目的地是指路灯价值的体现。所以无论是唯价值论还是唯口碑论衡量的其实是同一个东西。
考核二：统一的方法&规范&机制
这一项的考核就相对容易多了，无论是业界还是每一个架构师本身都有自己的一套方法，所以只需关注这些东西对应的产出。
考核三：完备的基础构建
我认为在大公司，大部分重量级的基础构建已经是非常完备，对于架构师来说更难的不是从0到1，而是克制、边界和从1到2的过程。对于架构师也好、技术团队也好“从0到1”总是充满了吸引力，加上技术人的特征，大公司技术史上永远不缺少重复的轮子，创建这些轮子成就了一代一代的同学，拆除这些轮子再成就了一代的同学，所以克制尤为重要；有了克制跨团队的合作就尤为重要，对应的有两个点一是清晰边界，二是共建。
考核四：落地的规划才是架构
虽然说落地是非常不控的事情，但是考核却很容易的：做到就是做到、没有就是没有、质量好就是质量好，标准非常清晰。过程中只需要紧跟拆解的事情结合实际的组织和业务情况做出决策。
五、实施的一些想法
对现阶段团队的情况来说，我认为第一是建立“架构语言”，有了语言才有沟通协作的基础，所谓的“架构语言”并不是什么新的东西，而是产品的业务架构，用例和领域模型；研发的应用架构，组件和时序图； 运维的部署架构等等。
第二是建立“认同体”，无论是通过技术能力、知识传递、领域组织等各种方式逐渐形成“认同体”，且在其中形成架构体系对应的人员体系。
第三永远做服务者，架构师对应的客户是团队的每一个成员，必须始终保持客户第一的心态。架构师存在的目的是成就研发团队每一个同学，我们提供必要的平台、服务和空间，然后彼此成就。
六、Java架构技术体系
（作为一名java学习者给出的一些学习方向，希望能帮助到那些在Java开发路上努力的朋友有个明确的方向）
以上的一切都是让你具有前沿的“架构思维”，完备的架构技术体系才能使这些具体的架构思维不仅仅是个空壳。下面这图是由前阿里架构师韩飞龙带领的团队整理出来的，现在分享给大家，以便大家有一个大的努力方向。
（更多的细小知识点模块图解分析和资源可私信我“架构导图”免费获取）
最后借用一句话：从无到有的是架构；从表到里的是抽象；从粗到细的是设计。大家对架构师有哪些看法，也欢迎在留言区留言，我们一起交流讨论。 喜欢的朋友可以关注下专栏：
java架构技术交流里面有大量batj面试题集锦，还有各种技术干货文章分享，大家可以同时关注下我以后会不停更新更多精选文章
谈到架构师，这个高仿大气上档次的高级职位，是大部分软件工程师奋斗的目标，也是工程师的高级职位之一。
工程师发展的高级职位有“技术方向的架构师”、“管理方向的项目经理”，架构师主要负责的项目中的技术部分，项目经理主要负责项目人员调度和项目进程。
看了一篇文章中有详细的讲架构师，很不错，推荐转载一下（转载信息在文末）：
Hi，好久不更新，今天，咱们来聊一聊IT行业薪酬最高的职位——“架构师”。
说起架构师，很多人纷纷举手，表示有话说：什么是架构？架构师是干啥的？怎样才能成为架构师？
好了，下面针对这些问题，我来为大家一一解答。
Q1：什么是架构？
架构这个词，生活中比较常见，一个公司、一幢楼房，都有其架构。
考过二级建造师的童鞋都知道，在“建筑”这门课里，施工结束后，一幢楼房仅有一套“空壳子”构造，还不能称之为“架构”。
真正赋予建筑“灵魂”的功能，都在“机电”这门课里。从排水管道、通风空调，到消防，甚至智能化，这些才能体现一幢建筑的架构实现。
架构亦是如此。一句话来概括架构的定义就是：架构=组件+交互。
它主要由3个要素组成：组件、连接件和约束。具体到软件工程中，涉及到的东西就多了，比如：
- 组件：类似应用服务，独立模块、数据库、nginx等；
- 连接件：分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系；
- 约束规范：定规则做限制，例如设计原则、编码规范等等。
晕了没？不要慌...
架构的本质其实就是——对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。
Q2：常见的架构视图有哪些？
经典的当属“4+1”视图模型：
- 逻辑视图：
一般针对客户、用户、业务人员、开发组织，主要从系统的功能元素、以及它们的接口、职责、交互维度入手。
主要元素包括系统、子系统、功能模块、子功能模块、接口等。 - 开发视图：
一般针对开发和测试相关人员，主要描述系统如何开发实现。
主要元素包括描述系统的分层、分区、框架、系统通用服务、业务通用服务、类和接口、系统平台和大基础框架。用途是指导开发设计和实现。 - 物理视图：
一般针对系统运维人员、集成人员，它是系统逻辑组件到物理节点的映射，节点与节点间的物理网络配置等，主要关注非功能性需求，诸如性能（吞吐量）、可伸缩性、可靠性，可用性等，从而得出相关的物理部署结构图。 - 场景视图
- 过程视图
4+1视图提出后，业界也有其它的观点提出，诸如：
- SEI（模块视图、组建和连接件视图、分配视图）
- 西门子4种视图（概念、模块、代码、执行视图）
- RM-ODP（企业视图、信息视图、计算视图、工程师图）
Q3：架构分为哪些类型？
架构可细分为业务架构、应用架构、 部署架构、技术架构、代码架构。
我们常见的架构基本都是业务架构（忽悠客户和领导的），只有项目团队实际开发才会涉及到代码架构，应用和部署架构分别适用于产品经理和实施交付工程师。
好了好了，架构我知道了，那么架构图怎么画呢？
容我刷一波架构图先~
- 阿里云机器学习PAI的架构：
- eBay的架构：
- 网易云的架构：
- 微信的架构：
- 美团的架构：
- 微博的架构：
是不是又有点晕，在此就不一一赘述了......内行看个门道，外行听我讲个热闹~
首先，我们了解一下架构的演进，大致如下：
- 初始阶段：LAMP，部署在一台服务器
- 应用服务器和数据服务器分离
- 使用缓存改善性能
- 使用集群改善并发
- 数据库地读写分离
- 使用反向代理和cdn加速
- 使用分布式文件和分布式数据库
- 业务拆分
- 分布式服务
其次，我们了解一下架构的模式：
- 横向分层：应用层，服务层，数据层——这三块基本上是架构图必备的，也是业务架构图常见的结构。
- 纵向分割：拆分功能和服务，各个模块单元要求高内聚、低耦合。
最后，架构图除了横向分层（应用、服务、数据）和纵向模块分割之外，还必须体现架构的5个核心要素：
- 高性能：性能测试+各种优化
- 可用性：数据备份+灰度发布+监控报警
- 伸缩性：建集群+负载均衡
- 可扩展性：事件驱动架构+分布式服务
- 安全性：SQL注入+SSL+Web防火墙漏洞防护
Q4：架构师是干啥的？
- 架构师的定义
百度百科的定义：
系统架构师是一个既需要掌控整体，又需要洞悉局部瓶颈，并依据具体的业务场景，给出解决方案的团队领导任务。
- 架构师的职责
架构师的职责涉及到软件开发的各个过程：
- 需求阶段：
软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和 可测试性等等，此外，架构师还要经常审查和客户及市场人员所提出的需求，确认开发 团队所提出的设计 - 设计阶段：
架构师负责对整个系统架构设计，制定开发规范、开发计划，指导整个开发团队完成这个计划 - 开发阶段：
架构师则成为详细设计者和代码编写者的顾问，并且经常性地要举行一些技术研讨会、技术培训班等 - 测试和交付阶段：
协调做好相关测试和部署 - 维护阶段：
软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策
- 架构师的分类
中小公司很多架构师都是全能的，通常公司规模和体系越大，分工会越细。
- 解决方案架构师：
与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。比如阿里云针对大客户都有解决方案架构师。
- 系统架构师：
也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范，为研发工作澄清技术细节并扫清技术障碍。服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用。
- 平台架构师：
包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个是基础平台，是专门负责搭建基础技术平台。
- 业务架构师：
业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。
其实这个职位的未来也就是CIO了，主要内容：理解业务，梳理模型，设计模式，接口，数据交互。
- 网络架构师：
一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。
比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
- 移动架构师：
移动架构师既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性，如下图所示：
摘自《程序员必读之软件架构》
- 前端架构师：
这里的前端特指网站开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/…），跨浏览器设计等等。
- 大数据架构师：
比如某些公司做大数据处理，需要理解业务，并通过大数据相关技术来实现。
Q5：架构师对能力有什么要求？
- 架构师的知识基础：
这里有一个专业技能表Checklist，大家可以对照下，哪里不会补哪里。
1、基础知识
- 计算基础
- 计算机原理
- 数据结构和常用算法
- 操作系统：进程,线程,内存
- 网络
- TCP/IP协议
- TCP/IP网络模型
- HTTP协议原理
- 网络IO模型
- Socket网络编程
2、编程语言
- java
- java基础类库、异常
- JVM原理和调优《深入理解java虚拟机》《java性能优化权威指南》
- 框架
- 并发《java并发编程实战》
- 多线程
- php
- php基础
- 常用框架
- 异常处理机制
- 深入php内核
3、程序设计
- 高质量编码能力:
- 重用性
- 低耦合
- 可扩展性
- 可维护性
- 高性能
- 安全性高
- 面向对象编程:
- MVC编程思想
- 掌握建模语言和建模工具：UML
- 面向对象思想
- 设计模式:
- 基础设计模式和设计原则:单一职责、开放封闭原则等.
- 常用设计模式
- 重构
4、研发能力
- 瀑布模型：需求->需求分析->设计->开发->测试->上线->运维/运营
- 调试和解决问题能力
- 敏捷思想：快速迭代，任务细分，wiki更新
5、安全知识
- web安全：xss，sql注入，ddos攻击
- 安全维度：漏洞，风险，事件
- https协议
- 安全书：
《黑客攻防技术宝典（Web实战篇）》
《白帽子讲Web安全》
《Web前端黑客技术揭秘》
《Web之困》
《SQL注入攻击与防御》
6、Linux知识
7、运维能力
- 监控
- 持续集成：jenkins
- 自动化运维工具：ansible，saltstack
- 虚拟化：kvm,vm
- 容器docker
- 云技术openstack
- DevOps
8、数据库
- 基础理论
- 数据库设计的三大范式
- MySQL原理
- MySQL优化
- mysql引擎：
- InnoDB
- MyISAM
- NoSQL：redis/mongo
9、常用应用软件
- Web server:
- Nginx
- OpenResty
- Apache Httpd
- Tomcat:架构原理,调优方案
- Jetty
- 消息队列:
- RabbitMQ
- RocketMQ
- ActiveMQ
- Kafka
- Redis 消息推送
- ZeroMQ
- RPC:
- Dubbo
- Thrift
- gRPC
- 数据库中间件:
- DBproxy
- Haproxy
- 软件负载均衡:
- 几种负载均衡算法： 轮询、权重、负载、最少连接、QoS
- DNS负载均衡
- Nginx
- LVS+Keepalived实现负载均衡
- HAProxy
- Haproxy+Keepalived+MySQL实现读均衡负载
9、性能
- 性能优化方法论
- 容量评估
- CDN 网络
- 连接池
- 性能调优
10、大数据
- Hadoop
- Storm
- Kafka Stream
11、工程化
- maven
- git
- jenkins
还是那句话，不要慌，功夫不是一天练成的。多注意平时积累，即可水到渠成。
我们继续讲~
- 架构师的能力要求：
- 简单来说，架构师需要具备的能力有：
技术能力、抽象建模能力、系统分析与设计、编程的四门功课（需求分析、设计实现、测试验证、调试纠错）
- 具体来说，分如下几个方面：
1、了解相关领域的技术知识（广阔的知识领域）
在你想要成为架构师的相关技术领域，必须具备扎实的专业知识和过人的本领。
2、超强的分析、设计能力（多方位的思考分析能力）
不管怎样，具备很强的分析和设计能力都是必杀技。另外就是能够运用设计模式方式解决各种各样的问题。
3、编码与验证性测试（POC）
- 熟悉该组织整个技术栈，并能使用各层的技术熟练地编码。
- 能快速实现验证性测试。
4、架构设计的实力
- 能为原始需求提供架构方案。
- 考虑周全：工具和框架的采用、安全性、性能和扩展性、依赖关系、集成、效益。
- 熟悉软件开发生命周期（SDLC）：需求、分析、设计、测试、打包、部署。
5、建模语言或工具
能使用不同的建模语言或工具，向其他架构师、开发者、项目经理等人，阐述架构。
6、架构框架
- 能证明架构的可行性，包括其业务、应用、数据、基础设置方面。
- 了解TOGAF和ZACHMAN框架。
7、沟通能力与自我表达
能与开发人员、测试人员、商业分析师、上级经理沟通无阻，无论在口头上和书面上。
8、布道（有一定的魄力和感染力）
- 能讲解该行业的市场、技术知识。
- 能为全队提供培训课程。
9、销售、售前
能参与售前工作（尤其对于软件服务业）：制定技术方案、使用各种预算工具估计方案的规模和成本、与销售对象互动。
10、演讲技巧
优秀的演讲技巧，有助于以下活动：华丽的计划书和技术文档、PPT演讲、布道。
本文转载自公众号“夜孤城壹号”
作者：夜孤城壹号
原文链接：https://mp.weixin.qq.com/s/bu8cP_MMBGWYMjAhXKp1Eg
了解架构师后，再学习架构师，如果你对架构师还不了解，可以看看十几年经验的java架构师是怎么理解架构师的。
以下是动力节点高级教学团队（团队成员前身都是“架构师”、“项目经理”），走访考察一线大厂历时半年精心打造的架构师课程:
架构师学习路线图！一共七大专题：
架构师除了具备过硬的技术能力外，架构思维的培养也尤为重要。因此课程设置上我们兼顾软硬实力的培养，让学员边学技术边修炼思维，实现双向提升，才可以真正胜任架构师岗位工作。
7大专题课程，覆盖当下热门刚需技术
目前，架构师公开课已开始，其课程安排如下，若感兴趣可到官网咨询听课资格：
