架构师成长之路(3)--如何成为架构师（方法）
前言：
0.能力等级定义
心理学家德雷福斯经过了大量的调查研究，将人分成了五个等级，构建了“德雷福斯等级模型”。五个等级分别为：新手、进阶新手、胜任者、精熟者以及专家。简单列举一下每个等级的特点，方便我们定位自己在哪个等级。参考《卓越密码：如何成为专家》。
1、新手：新手一般是初入职场1~3年的员工。他们的特点是严格遵照规定，不会有太多自己的想法，因此不会出大的错误也不会有太大的成绩。
2、进阶新手：工作几年后，新手开始学会细分任务，慢慢地对工作有了自己的想法。这个时候，已经能达到进阶新手的阶段。
3、胜任者：第三个阶段是胜任者。胜任者顾名思义，在工作岗位上能够保质保量地完成任务，而且能够制定计划和按情况处理任务。
4、精熟者：与胜任者相比，精熟者开始能发现工作中出现的问题，并对问题有着自己的思考。此时，精熟者开始建立了自己工作的大局观和整体观，处理问题的时候也更加灵活。
5、专家：最后一个阶段就是专家，专家的过人之处在于其“无招胜有招”。因为专家工作已经不需要具体的方法和规则，他们的工作就是从现在已有的工作方式中去探寻更个性化、有创造力的解决问题的方法。
我们研发人员发展的技术路径(仅供参考)：
一、初级工程师
具备技能:学习的知识是语言基础、计算机基础理论、网络基础，操作系统等相关基础知识等，应该在大学完成。
二、高级/资深程序员（管理自己）：
成长阶段：工作3-5年后，熟悉分布式系统、高性能系统搭建。精通某种开发语言，掌握架构设计能力和业务理解能力。熟练掌握各种设计模式以及具备一定运维能力。
技术能力:
1、负责核心复杂功能的实现方案设计、编码实现 。
2、负责疑难BUG分析诊断、攻关解决
资深程序员：高级工程师是在技术深度上精通，资深需要在广度上扩大知识面，熟悉多种开发语言。同时具备团队管理经验。
具备独立设计一个业务模块的能力，并且能够独立设计数据库表以及UML画图，利用部分设计模式以及懂得算法和效率的高质量代码。
三、技术经理/研发Leader（管理一个团队）
成长阶段：技术经理本身就是从资深工程师发展而来，很多公司的技术经理根本没有从一线研发做起，大部分就是一个项目经理，带带项目为主，根本无法胜任真正意义上的“技术经理”的工作。
具备能力:
1、技术能力：
1）首先需要具备核心模块代码编程的能力，从设计方案到核心编码，再到后期的代码review，这方面是药能完全胜任的，能识别开发风险。
2）代码模板研发与推广、最佳实践规范总结与推广、自动化研发生产工具研发与推广
2、团队管理能力：
任务管理：开发工作量评估、开发任务分配，
团队效率：能够帮助团队人员提升能力，以及推动更加合理的考核机制。
团队专业力：招聘面试、新人指导、领导复盘总结改进
3、沟通协调能力：此外，还需要具备协调的能力，以及与人打交道的能力。与平级部门、产品、设计、测试、运营打交道的能力。
三、技术总监（管理多个团队leader）：
成长阶段：一般需要工作8至10年以上，首先，技术经理的工作能够做的非常好，再加上公司的发展需要，需要能够同时带领多条业务线或者多个团队共同协作的时候，基本就是技术总监了。
从管理的层级，技术总监同时管理多个技术经理，管理从业务线划分的团队。
从技术的层级，能胜任架构师这个级别，也就是技术专家。
具备能力:
1、从业务线和团队的角度，需要具备组建研发部、搭建公共技术平台、方便上面各条产品线开发。
2、通过技术平台、通过高一层的职权，管理和协调各个产品线组。现在每个产品线都应该有合格的研发Leader和高级程序员了。
四、架构师（专注某个平台的技术架构规划）
成长阶段：
能称得上“架构师”的，工作年限至少也要在5至8年以上，具体还要看个人的学习能力、领悟能力和成长速度。
之所以有架构师这个称谓，主要是由于公司发展壮大之后，需要专注于技术的人才做专业的事；所以，架构师也可以理解为技术专家，以攻克公司技术难题为主。
需要分离管理族和专业族。整个研发团队可能已经超过100来人了，需要有人专注来做架构规划、设计、日常维护。不能让研发总监和研发Leader又做管理又做技术一股脑都扔给他们。
具备能力：
1、架构分析：从功能性需求中识别出需要增加的非功能性需求，好满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新。并且识别完非功能型需求，还要做技术选型、技术架构风险识别、技术实现工作量评估
2、架构设计与实现：非功能性模块的架构设计、接口设计、代码实现。所以需要的是有代码实现能力还要有架构思维的工程师，不需要画PPT的工程师
3、业务架构设计与实现：需要对跨系统的接口进行识别、实现、维护，需要对能写成公共代码类库的进行分析、识别、接口设计、实现、变更维护。
4、重构：架构师需要经常做Bug分析、非模板性和公共类库代码检查，以发现代码腐烂程度，以发现还有哪些代码没有做很好的架构与精心的代码设计。所以重构是经常性维护发生的，不是攒到某一刻动大手术，甚至推翻重做，那就不叫重构了。
五、CTO (软件产品和技术是统一管理的.是商业、产品、技术、管理、团队相平衡的综合统管)。
成长阶段：CTO的要求是最高的，不是每一个人都胜任CTO，好的CTO在国内非常少，非常稀有。
可能不少同学会认为CTO只是专注于技术，或者进入一些小公司，挂职某某CTO就认为达到了这个级别，其实这是错误的。
CTO是一个系统的成长轨迹，不是一朝一夕可以练成的，需要后天的巨大“自我改进”能力。
CTO，是集软件、产品、技术、管理等诸多能力为一体的，CTO做的事情，是商业、产品、技术、管理、团队相平衡的综合统管。
具备能力:
1、业绩达成：洞察客户需求，捕捉商业机会，规划技术产品，通过技术产品领导业务增长，有清晰的战略规划、主攻方向，带领团队实现组织目标
2、前沿与平台：到这个研发规模规模级别了，一定要有专门的团队做技术应用创新探索和前沿技术预研。而且要和技术平台团队、应用研发团队形成很好的联动作用，让创新原型试点能够很平滑的融入商业平台再让应用研发线规模化的使用起来。大量的前沿探索都死在了内部，做完试点就停滞了，这就需要CTO做好整体的衔接推动工作。
3、研发过程管理：站在全局立场来端到端改进业务流程，为业务增长提供方便
4、组织与人才建设：公司文化和价值观的传承；研发专业族团队梯队建制建设、研发管理族团队梯队建制建设；创建创新激发机制，激发研发人创新向前发展，激发黑马人脱颖而出
软件架构师的正式成型在于机遇、个人努力和天赋 软件构架师其实是一种职位，但一个 程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为
一体的精英人才这可不是每个人都能够遇上的馅饼。
我们找好路径以后，看看我们如何做? 《卓越密码：如何成为专家》这本书里面，介绍的方法是：
学习能力：确定方向目标，选择高质量学习内容、学习元认知，持续精进学习。
不断实践：实践检验理论，解决问题，总结提炼。
思维能力：擅长思考、深度思考：学会归纳、概括，概念，推理。掌握结构化、抽象、系统性、框架等思维。
1、走正确的路：高效地学习
如果想成为一个架构师，就必须走正确的路，否则离目标越来越远，正在辛苦工作的程序员们，你们有没有下面几种感觉？
一、我的工作就是按时完成领导交给我的任务，至于代码写的怎样，知道有改进空间，但没时间去改进，关键是领导也不给时间啊。
二、我发现我的水平总是跟不上技术的进步，有太多想学的东西要学，Jquery用的人最近比较多啊，听说最近MVC比较火，还有LINQ，听说微软又有Silverlight了……
三、 我发现虽然我工作几年了，除了不停的coding，Ctrl+c和Ctrl+V更熟练了，但编码水平并没有提高，还是一个普通程序员，但有人已经做到架构师了。
四、工作好几年了，想跳槽换个工作，结果面试的考官都问了一些什么数据结构，什么垃圾回收，什么设计模式之类的东西，虽然看过，但是平时用不着，看了也忘记了，回答不上来，结果考官说我基础太差。。。
有没有，如果没有，接下来就不用看了，你一定是大拿了，或者已经明白其中之道了，呵呵。
如果有，恭喜你，你进入学习误区了，如果想在技术上前进的话，就不能一直的coding，为了完成需求而工作，必须在coding的同时，让我们的思维，水平也在不停的提高。
写代码要经历下面几个阶段：
一 、你必须学习面向对象的基础知识，如果连这个都忘了，那你的编程之路注定是在做原始初级的重复！
很多程序员都知道类、方法、抽象类、接口等概念，但是为什么要面向对象，好处在哪里，要解决什么问题？只是明白概念，就是表达不清楚，然后在实际工作中也用不上，过了一段时间，面向对象的东西又模糊了，结果是大多数程序员用着面向对象的语言做着面向过程的工作，因此要学习面向对象，首先应该明白面向对象的目的是什么？
面向对象的目的是什么？
开发语言在不断发展，从机器语言，到汇编，到高级语言，再到第四代语言;软件开发方法在不断发展，从面向过程，面向对象，到面向方面等。虽然这些都在不断发展，但其所追求的目标却一直没变，这些目标就是：
1.降低软件开发的复杂度
2.提高软件开发的效率
3.提高软件质量：可维护性，可扩展性，可重用性等。
其中语言的发展，开发方法的发展在1,2两条上面取得了极大的进步，但对于第3条，我们不能光指望开发方法本身来解决。
提高软件质量：可维护性，可扩展性，可重用性等，再具体点，就是高内聚、低耦合，面向对象就是为了解决第3条的问题。因此要成为一个好的程序员，最绕不开的就是面向对象了。
二、 要想学好面向对象，就必须学习设计模式。
假定我们了解了面向对象的目的，概念了，但是我们coding过程中却发现，我们的面向对象的知识似乎一直派不上用场，其实道理很简单，是因为我们不知道怎么去用，就像游泳一样，我们已经明白了游泳的好处，以及游泳的几种姿势，狗刨、仰泳、蛙泳、*泳，但是我们依然不会游泳。。。。
因此有了这些基本原则是不行的，我们必须有一些更细的原则去知道我们的设计，这就有了更基础的面向对象的五大原则，而把这几种原则更详细的应用到实际中来，解决实际的问题，这就是设计模式，因此要学好OO，必须要学习设计模式，学习设计模式，按大师的话说，就是在人类努力解决的许多领域的成功方案都来源于各种模式，教育的一个重要目标就是把知识的模式一代一代传下去。
因此学习设计模式，就像我们在看世界*的游泳比赛，我们为之疯狂，为之着迷。
三 学习设计模式
正像我们并不想只是看别人表演，我们要自己学会游泳，这才是我们的目的所在。
当我们看完几篇设计模式后，我们为之精神振奋，在新的coding的时候，我们总是想努力的用上学到的设计模式，但是经常在误用模式，折腾半天发现是在脱裤子抓痒。。。
当学完设计模式之后，我们又很困惑，感觉这些模式简直太像了，很多时候我们分不清这些模式之间到底有什么区别，而且明白了设计过程中的一个致命的东西--过度设计，因为设计模式要求我们高扩展性，高重用性，但是在需求提出之初，我们都不是神，除了依靠过去的经验来判断外，我们不知道哪些地方要扩展，哪些地方要重用，而且过去的经验就一定是正确的吗？所以我们甚至不敢再轻易用设计模式，而是还一直在用面向过程的方法在实现需求。
四 学习重构
精彩的代码是怎么想出来的，比看到精彩的代码更加令人期待，于是我们开始思考，这些大师们莫非不用工作，需求来了没有领导规定完成时间，只以设计精彩的代码为标准来开展工作？这样的工作太爽了，也不可能，老板不愿意啊。就算这些理想的条件他都有，他就一开始就设计出完美的代码来了？也不可能啊，除非他是神，一开始就预料到未来的所有需求，那既然这些条件都没有，他们如何写出的精彩代码？
Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书）中明白地指出：在设计前期使用模式常常导致过度工程（over-engineering)。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，而「实用」是软件压倒一切的要素。
在《重构-改善既有的代码的设计》一书中提到，通过重构（refactoring），你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，你可以学习如何强化设计；其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。
总结起来就是说，我们在设计前期就使用设计模式，往往导致设计过度，因此应该在整个开发过程，整个需求变更过程中不断的重构现在的代码，才能让程序一直保持良好的设计，由此可见，开发过程中需要一直重构，否则无论当初设计多么的好，随着需求的改变，都会变成一堆烂代码，难以维护，难以扩展。所谓重构是这样一个过程：「在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构」。重构的目标，就是设计模式，更本质的讲就是使程序的架构更趋合理，从而提高软件的可维护性，可扩展性，可重用性。
《重构-改善既有的代码的设计》一书也是Martin Fowler等大师的作品，软件工程领域的超级经典巨著，与另一巨著《设计模式》并称"软工双雄"，不可不读啊。
五 开始通往优秀软件设计师的路上
通过设计模式和重构，我们的所学和我们工作的coding终于结合上了，我们可以在工作中用面向对象的思维去考虑问题，并开始学习重构了，这就像游泳一样，我们看完了各种*的游泳比赛，明白各种规则，名人使用的方法和技巧，现在是时候回家去村旁边的小河里练练了，练习也是需要有教练的，推荐另一本经典书叫《重构与模式》，引用他开篇的介绍，本书开创性地深入揭示了重构与模式这两种软件开发关键技术之间的联系，说明了通过重构实现模式改善既有的设计，往往优于在新的设计早期使用模式。本书不仅展示了一种应用模式和重构的创新方法，而且有助于读者结合实战深入理解重构和模式。
这本书正是我们需要的教练，值得一读。
六 没有终点，只有坚持不懈的专研和努力。
经过了几年的坚持，终于学会了灵活的运用各种模式，我们不需要去刻意的想用什么模式，怎么重构。程序的目标，就是可维护性，可扩展性，可重用性，都已经成了一种编程习惯，一种思维习惯，就像我们联系了几年游泳之后，我们不用再刻意的去考虑，如何让自己能在水上漂起来，仰泳和蛙泳的区别..... 而是跳进水里，就自然的游了起来，朝对岸游去。但是要和大师比起来，嘿嘿，我们还有很长的路要走，最终也可能成不了大师，但无论能不能成为大师，我们已经走在了成为大师的正确的路上，我们和别的程序员已经开始不一样，因为他们无论再过多少年，他们的水平不会变，只是在重复造*，唯一比你快的，就是ctrl+c和ctrl+v。
正确的路上，只要坚持，就离目标越来越近，未来就一定会是一个优秀的架构师，和优秀架构师的区别，可能只是时间问题。
2、大牛的法宝：不断实践总结
原文：http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html，
接下来我们就要往这个方向努力。然而如唐僧去西天取经一样，要历经种种磨难，一路上打败各种妖魔鬼怪才能继续前行，所以唐僧取经，第一件事，就是招徒弟，遇见妖魔鬼怪就让技术高超的徒弟打败它，徒弟不听话就念紧箍咒，徒弟也搞不定的妖怪，就请观音菩萨搞定，这就是唐僧成功的法宝，没法宝上路，看来我们会死的比较惨啊，哈哈。
我们在通往架构师的路上，同样会遇到各种各样的问题，但不幸的是，没有菩萨在暗中相助，要是有牛人相助你，那老兄你太幸运了，成功几率大大增加。但我们没有牛人帮助，更没有技术高超的徒弟一路保驾护航，关键招徒弟得开工资啊，我们还穷的自己还养不活呢，怎么办呢？干脆自己动手，找几件护身法宝，留着路上除妖之用。
问题是从哪找呢？百思不得其解，俗话说思索不如搜索，干脆百度一把，看看牛人都是怎么炼成的，找来找去，还真总结出几个牛人身上的通用法宝，当然独门绝技之类的就不拿了，太多那不动，呵呵。拿着这些法宝上路，嘿嘿，那我们就不是骑着白龙马去西天了，我们骑着摩托去西天，那速度可要快多了。
法宝一：牛人爱惜自己的时间。
时间就是金钱，时间就是生命，时间如同健康一样，如果时间都没有，那成功也就是浮云了。所以牛人总是很爱惜自己的时间，总是在想办法提高自己的做事效率。我突然想了起来，我QQ里有几个牛人，问问他们点经验，结果大大出乎意料，个个不在线，好不容易发现个牛人在线，当然关系还不错的，至少不会不给面子吧？于是就QQ说一句客气话，“老兄，好久不见啊，最近在忙什么呢？”，消息发出去石沉大海，到第二天上QQ才收到一句回复，“不好意思，昨忙，有事直接打电话”，言简意赅，效率奇高，再想想我们这些普通人的时间真多，一聊天就是半天，搞不好还有N个QQ群在不停的弹窗……
偶然看到一本书，《时间管理：小强升职记》，顺便打开看下，第一句话这么说的，“前一种人用20%的时间完成了后一种人用80%的时间才能完成的事情，因此前一种人忙着考虑如何打发闲暇时间，后一种人则忙着煮方便面和熬夜。
假设上面说的真的，我初略算了算，如果一天工作时间8个小时，则牛人的效率，可能就1，2个小时就干完了，这么一算，牛人忙和一年，则等于普通人忙和了4，5年啊！法宝，这绝对是牛人致胜的第一大法宝，俗话说，唯有以快制慢，方能笑傲江湖，没错，东方不败牛就牛在，速度快，快到你还没出招就搞定你了。强大啊，这个法宝一定要随身携带，哈哈。
所以看了这本书后，我做的第一件事就是QQ关了，动不动就一闪一闪的，思路一直被打断，这不是在浪费自己最大的资本--时间吗？关了几天，发现效率果然出奇的高多了，QQ真是害人不浅啊，当然爱惜时间，还有很多经验，建议有空看看相关的书，受益不浅啊，嘿嘿。
法宝二：牛人善于总结
算了算我记得的牛人，包括古代的，孔子，老子，孙子，曹雪芹，鲁迅。。。我想了一下，为什么能记住他们呢，几千年前来，轰动一时的人物应该年年有，代代有，但我们为什么只记住了这些人？很容易想明白了，他们有个共同的特征，就是总结自己的思想，写成了书，并把这种思想传承了下来，而那些身怀绝技但是秘而不传，或者只传近亲的绝技，都在历史的长河中慢慢消失了。
再看看IT界的，苏杰，写了本《人人都是产品经理》，程杰，写了本《大话设计模式》......，除了写之外，他们还经常出没于各大论坛，讲座，想躲也躲不开啊......。
看来牛人之所以牛，自己懂的多是一个因素之外，更重要的是把自己的知识总结下来，并努力推广了。
所以日常总结，随身笔记一定是要做的，总结就是理解它，并且理解了还不要忘记它，时不时还翻回来看看，否则很多知识学习了又忘记了。总结这个法宝，一定要随身携带。
法宝三：牛人懂得专注
有句古语是这么说的：能够到达金字塔顶端的动物只有两种，一种是苍鹰，一种是蜗牛。苍鹰之所以能够到达是因为它们拥有傲人的翅膀；而慢吞吞的蜗牛能够爬上去就是认准了自己的方向，并且一直沿着这个方向努力。对人类而言，能够于众生中脱颖而出者实属少数，这些人也可以看到：一种是资质优越、天生异禀，本就是成就大事的种子，这样的人是少之又少，而且有些这样的人还因不知学习而沦落了；另外一种人就是蜗牛一样的人物了，早早就知道自己是常人，却仍然立下鸿鹄之志，凭借后天的坚忍和努力，同样做出常人难以想象的成就。它是一种素质，更是一种能力。
IT领域需要懂的太多了，运维、DBA，各种操作系统，各种语言......如果什么都想学好，结果必然是什么都略懂，但什么都拿不出手，所以注定无所建树，成不了牛人，而牛人是深刻明白这个道理，所以他们会选择某一点最感兴趣的地方，然后持之以恒的深专下去，最后达到了别人从未达到的高度，我们做IT编程的大部分人都是这也学那也学，简历上写的什么都是精通，其实这样的人，却不敢深问，深问了什么都不懂，因此专注某一个技术领域，是走向成功的铁定法则。
法宝四：牛人注重动手能力
“纸上得来终觉浅，绝知此事要躬行”。
看来牛人并不是坐在屋子里成牛人的，而是在不断的动手，在实战中造就了牛人，也充分的说明了学习的终极目的--学以致用。所以我们学习时，一定要动手做，只学习不动手，是成不了牛人的啊。
拿着这四件法宝去取经，就为成功增加了强有力的保障，并能达到事半功倍的效果。当然在路上多捡几件随身携带，那功力就会更强了，像007一样，口袋里总是需要什么有什么。法宝之重要，犹如练武的找到了降龙十八掌，乾坤大挪移之类的秘籍一样，拿到手了就会成为武林至尊！
3、架构师都要懂哪些知识
Web架构师究竟都要学些什么？具备哪些能力呢？先网上查查架构师的大概的定义，参见架构师修炼之道这篇文章，写的还不错，再查查公司招聘Web架构师的要求。 总结起来大概有下面几点技能要求：
一、 架构师有优秀的编码能力，解决开发人员无法解决的难题。
二、 架构师对系统的大数据容量高性能高并发高容错的网站有架构设计和开发经验。
三、 架构师对操作系统、数据库、服务器各种软件使用的配置比较了解，比如Linux、Web负载均衡、反向代理、数据库集群、容灾等比较了解。
四、 架构师对软件开发过程有清晰明确的认识，也就是对软件工程有有明确的认识，并能把需求进行分析、建模。
五、 架构师学习能力很强、接触知识面要很宽广、喜欢关注和接触各种新的技术。
六、 架构师沟通能力很强。
七、 架构师对从事的行业的业务要有深刻的了解。
换个角度看看这些要求把：
第一条要求你是个优秀的程序员。
第二、第三条要求你要懂DBA，运维都需要懂的知识。
第四条要求你是个项目经理。
第五条要求你是个技术全才，不仅学的要深，还要学的广。
第六条、第七条要求你熟悉公司业务人员、产品人员要懂的知识。
这个要求太高了，架构师就相当于战争中的司令员的位置，是整个团队的核心和灵魂，这种技术要求甚至技术总监和CEO都不具备，唯一要求少点的就是管理能力，如果再具备管理能力，那就甚至能超过技术总监和CTO了，而中国不乏管理人才，怪不得有人总结说，中国没有合格的架构师呢，也难怪，大概算一算，这种要求相当于一个人学6个人的知识，并且都能达到专业的水平，这就意味着你的领悟能力和学习能力，要高于常人几倍！所以说，成为架构师确实需要天分啊。
成为优秀程序员，需要学好的知识：
1、 面向对象编程、UML画图、设计模式、代码重构
2、 常用ORM工具
3、 MVC,WCF,XMl, JQuery ，SQL以及性能优化
4、 FrameWork一些深入的知识
5、 高性能代码，比如静态化，MemCached等手段。
6、 最好也了解一些其他语言，比如Java，PHP等。
成为DBA，需要学好的知识：
1、 常用数据库，MSSQL、MySQL、Oracle，性能调优熟练，备份、负载均衡、集群、容灾熟练
2、 大数据量处理熟练
3、 各种数据库监控软件
成为运维，需要学好的知识：
1、 各种Web负载均衡的硬件，比如F5，软件，比如Nginx等原理和配置
2、 反向代理加速，比如SquID等
3、 操作系统，Linux是必须懂的，各种好的工具都在Linux下。
4、 各种性能监控软件。
成为产品和业务以及项目经理，需要学好的知识：
1、 沟通和理解能力。
2、 该行业和本公司的业务逻辑。
3、 软件工程的知识。
4、 质量控制、进度控制、人员组织等。
看来想成为合格的Web架构师，需要学太多东西了，只有一条路可走--持续不断的修炼和学习。
另外学习中，采用先深后广的策略是明智的选择，一门学深了，其他知识可能都会融会贯通，那样比较的学起来会很快。否则可能陷入知识的海洋里，没准淹死了。
总体的看来，Web架构，分为服务器架构和程序架构两个方面的架构，一般的Web架构师还是偏向程序架构，因此学好语言，程序架构是基础，学好了这些，做一个合格的架构师没大问题，毕竟DBA，运维的东西在公司都有专业的人在干。
所以深度还是要深入学习编程的知识、软件架构知识，有了这个基础后，Web架构师应该在大数据量、高并发、高负载、以及高容错方向再有所了解和涉及，再返过来促进我们对软件架构的思考，这种深-广-深-广的模式是我们学习的方法，只要坚持不懈努力几年，做真正合格的Web架构师是没大问题的。
另外由于学东西太多，在学习中也要和其他架构师多交流、共同进步，多参考其他架构师的杰作，是很明智的选择。
上一篇： zipkin分布式追踪系统原理与实现
下一篇： CSS清除浮动