从0开始学架构_56_架构师成长之路_华仔放学别走_第4期
你好，我是华仔从零开始学架构。
专栏已经全部更新完毕。
我在专栏里给你讲述了我的完整架构设计。
方法论，包括架构设计的概念、原则、步骤、技巧、模式等。
这些内容是我融合多年来的学习实践思考。
总结得出来的精华，王婆自夸一下专栏呢就相当于一部九阳真经。
你按照武功秘籍的方法去修炼，自然能够比站在村口大树下打木人桩效率要高得多。
然而，要成为高手，光知道招式还远远不够，更重要的是内功和判断，能够一眼看出对手的弱点或者破绽，知道什么时候用什么招式，遇到什么对手，用什么招式更重要。
以架构设计原则的合适原则为例，专栏讲述了架构设计要遵循合适原则，不要过度设计。
这个点非常关键，能够避免架构设计的时候盲目超前设计。
但是我们在具体架构设计的时候，到底什么是合适专栏，也无法给出一个明确的标准，可以放之四海而皆准去套用。
因为合适和很多因素，有关业务发展、团队规模、技术实力、领导的喜好等。
此时到底什么是合适，就依赖架构师的内功了。
很有可能同一个团队。
A架构师认为x方案是合适的。
B架构师认为y方案是合适的，原因就在于不同的架构师内功不一样。
我认为，架构式的内功主要包含三部分，判断力、执行力、创新力。
简单解释一下，判断力是指能够准确判断系统的复杂度在哪里，就像武侠高手一样，能够准确的看出对手的破绽和弱点。
执行力是指能够使用合适的方案解决复杂度问题，就像武侠高手一样，能选择合适的招式或者方法打败对手。
创新力是指能够创造新的解决方案，解决复杂度问题。
就像武侠世界里小一些的创新是创新招式，而武学宗师能够创立新的武学或者新法，例如张三丰创立太极拳一样。
因此要成为一个优秀的架构师，就需要不断的提升自己这几方面的内功。
而这三方面的能力，主要来源于经验、视野，思考设计过的系统越多系统越复杂，架构师的内功也就越强。
不管是成功的架构，还是失败的架构，不管是踩坑的经验，还是填坑的经验，都将成为架构师内功的一部分，这是经验的作用，掌握的知识和技能越多越深，架构师的内功也就越强。
他山之石，可以攻御，站在巨人的肩膀上，会看得更高更远，这是视野的作用。
经验和视野都是外部输入，类似于我们吃的食物，但光吃还不行，还要消化，将其变为我们自己的营养，这就是思考的作用。
思考能够将经验和视野中的模式判断、选择、技巧等提炼出来，为我们所用。
思考也能促使我们产生新的创意和灵感，这是思考的作用。
结合上面的分析，从程序员到架构师的成长之路，总的指导原则是积累经验，拓宽视野，深度思考。
按照这个总的原则为指导。
接下来我们看看从程序员到架构师的成长过程中具体如何实践。
我把程序员到架构师的技术成长之路分为几个典型的阶段，工程师、高级工程师、技术专家、初级架构师、中级架构师、高级架构师。
虽然总的指导原则是一样的，但具体的实践方法有很大差别。
如果在正确的阶段采取了错误的方法，可能会出现事倍功半的问题。
首先来看看工程师成为一个合格的工程师，需要一到三年时间，其典型特征是在别人的指导下完成开发。
这里的别人主要是高级工程师或者技术专家。
通常情况下，高级工程师或者技术专家负责需求分析和讨论，方案设计工程师负责编码，实现高级工程师或者技术专家会指导工程师进行编码，实现工程师阶段是最原始的基础技能。
积累阶段主要积累基础知识，包括编程语言、编程工具，各类系统的基本使用。
以java后端工程师为例，工程师阶段需要积累的经验和技能，有java的语法、基本数据结构的使用。
Eclipse、 IDEA、 maven、 linux、命令行等各种工具数据库、CRUD操作、缓存的基本使用等业务系统的基本流程。
工程师阶段最好的学习方法就是找经典的书籍系统的学习，而不要遇到一个问题，到网上搜搜，然后就解决了事儿。
以java为例，java编程思想java核心技术TCPIP协议。
这类大部头一定要完整的看一遍，即使里面很多内容当前工作暂时用不上，然后是高级工程师，成长为高级工程师，需要两到五年时间。
其典型特征是独立完成开发，包括需求分析、方案设计编码实现。
其中，需求分析和方案设计已经包含了判断和选择，只是范围相对来说小一些，更多是在已有架构下进行设计。
以java后端工程师为例，高级工程师需要完成的工作，包括mysql数据库表如何设计，是设计成两个表还是三个表，是否要用缓存？缓存的key和value如何设计？缓存的更新策略是什么？产品提出的需求是否合理，是否有更好的方式来满足？从普通工程师成长为高级工程师，主要需要积累方案设计经验，简单来说就是业务当前用到的相关技术的设计经验。
以java后端高级工程师为例，包括表设计经验、缓存设计经验、业务流程设计经验、接口设计经验等当接到一个业务需求的时候，高级工程师能够组合这些设计经验，最后完成业务需求。
高级工程师阶段相比工程师阶段有两个典型的差异，第一个是深度。
如果说工程师是要求知道号，那高级工程师就要求知道y了。
例如java的各种数据结构的实现原理。
因为只有深入掌握了这些实现原理，才能对其优缺点和使用场景有深刻理解。
这样在做具体方案设计的时候，才能选择合适的数据结构。
第二个是理论，理论就是前人总结出来的成熟的设计经验，例如数据库表设计的三个范式，面向对象的设计模式、SORID设计原则、缓存设计理论等。
针对技术深度，我的建议还是系统的学习，包括看书和研究源码。
例如研究扎马虚拟机可以看深入理解扎马虚拟机。
研究mysql可以看mysql技术内幕inno DB存储引擎。
研究mam cache可以去看其源码。
针对设计理论，由于涉及的点很多，没有一本书能够涵盖这么多的设计点，因此更多的是依靠自己去网上搜索资料学习。
那我们怎么知道哪些地方会有设计理论呢？简单来说就是假设每个设计环节都有设计理论，然后带着这种假设去搜索验证，看看是否真的有很熟的设计理念。
接下来就是技术专家了。
成长为技术专家需要四到八年时间，其典型的特征是某个领域的专家。
通俗的讲，只要是这个领域的问题，技术专家都可以解决。
例如java开发专家、PHP开发专家、安卓开发专家、ISO开发专家、前端开发专家等。
通常情况下，领域的范围不能太小。
例如，我们可以说java开发专家，但不会说说ava多线线程专家或java JDBC专家。
技术专家与高级工程师的一个典型。
区别就是高级工程师主要是在已有的架构框架下完成设计，而技术专家会根据需要修改扩展优化框架。
例如，同样是java开发高级工程师，关注的是如何优化mysql的查询性能，而技术专家可能就会考虑引入elastic search来完成搜索。
从高级工程师成长为技术专家，主要需要拓展技术宽度，因为一个领域必然会涉及众多的技术面。
以java后端开发为例，要成为一个java开发专家，需要掌握java多线程JDBC、 java虚拟机、面向对象、设计模式、netty、 elasastic、 search name、 cash、 REDISM、 ysql等众多技术。
常见的拓展技术宽度的方法，有学习业界成熟的开源方案。
例如java开发可以去学习REDISMNCHH、 netty等。
安卓开发可以去研究recorrofit、 fresco、 OKHTTP等研究业界的经验分享。
例如，BATFANG等大公司的经验，可以通过参加技术大会等方式去近距离了解。
需要注意的是，拓展技术宽度并不意味着仅仅只是知道一个技术名词，而是要深入去理解每个技术的原理、优缺点、应用场景，否则就会成为传说中的PPT技术专家。
例如，以java开发为例，知道netty是个高性能网络库是远远不够的，还需要学习netty的原理，以及具体如何使用netty来开发高性能系统。
进入架构师阶段。
首先是初级架构师，成长为初级架构师，需要五到十年时间。
其典型特征就是能够独立完成一个系统的架构设计，可以是从零到一设计一个新系统，也可以是将架构从一点零重构到二点零。
初级架构师负责的系统复杂度相对来说不高，例如后台管理系统某个业务下的子系统、一百万PV量级的网站等。
初级架构师和技术专家的典型区别是，架构师是基于完善的架构设计，方法论的指导来进行架构设计。
而技术专家更多的是基于经验进行架构设计。
简单来说，即使是同样一个方案，初级架构师能够清晰的阐述架构设计的理由和原因。
而技术专家可能就是因为自己曾经这样做过，或者看到别人这样做过而选择技术方案。
但在实践工作中，技术专家和初级架构师的区别并不很明显。
事实上，很多技术专家其实就承担了初级架构师的角色。
因为在系统复杂度相对不高的情况下，架构设计的难度不高，用不同的备选方案最终都能够较好的完成系统设计。
例如设计一个日PV一百万的网站，mysql加main cash加spring good,可以很好的完成。
Mango DB加REDIS加enginex加PHP杠FPM,也可以很好的完成备选方案设计和选择并不太难，更多的是看团队熟悉哪个技术，从技术专家成长为初级架构师，最主要的是形成自己的架构设计方法论。
我的架构设计专栏其实就是讲述完整的架构设计方法论，包括架构设计目的、架构设计原则、架构设计步骤、架构设计模式等。
类似的架构设计方法论，还有恰如其分的软件架构。
风险驱动的设计方法和领域驱动设计等，要形成自己的架构设计。
方法论主要的手段有，系统学习架构设计，方法论，包括订阅专栏或者阅读书籍等。
深入研究成熟开源系统的架构设计，这个手段在技术专家阶段也会用到，但关注点不一样。
同样是研究开源系统技术专家阶段，聚焦于如何更好的应用开源项目。
初级架构师阶段，聚焦于学习其架构设计、原理和思想。
例如，卡夫卡的文档中，就有关于消息队列、架构设计的分析和取舍，结合架构设计方法论分析和总结自己团队甚至公司的各种系统的架构设计、优缺点，尝试思考架构重构方案。
如果在这个基础上真的能够推动架构重构，那就更好了。
既能够实践自己的架构设计、方法论，同时积累经验，又能够展现自己的技术实力。
拿到结果。
然后我们来看中体架构师成长为终极架构师，需要八年以上时间。
其典型特征是，能够完成复杂系统的架构设计，包含高性能、高可用、可扩展、海量存储等复杂系统，例如设计一个和卡夫卡性能匹敌的消息队列系统，将业务改造为异地多活，设计一个总共一百人参与开发的业务系统等。
中级架构师与初级架构师的典型区别在于系统复杂度的不同。
中级架构师面对的系统复杂度要高于初级架构师。
以开源系统为例，初级架构师可能引入某个开源项目就可以完成架构设计。
而中级架构师可能发现，其实没有哪个开源项目是合适的，而需要自己开发一个全新的项目。
事实上，很多开源项目就是这样诞生出来的。
从初级架构师成长为中级架构师，最关键的是技术深度和技术理论的积累。
例如技术理论包括CAP base是异地多活的设计理论，基础paxas是分布式一致性的基础算法。
Two PC three PC是分布式事务的基础算法等技术，深度包括卡夫卡用磁盘存储还能做到高效，是因为磁盘顺序写disrupor.高性能是结合CPU预读取机制、缓存行、无锁设计等基础技术storm的高效抑惑确认机制。
Flink的分布式快照算法等很多同学对这点可能有疑问，这些技术理论和技术深度的事情，不应该是高级工程师阶段或者技术专家阶段就应该积累的吗？为何到了终极架构师阶段，反而是成长的关键了呢？主要原因在于高级工程师或者技术专家阶段，即使去学习这些技术，实际上也比较难以理解透彻，更加难以有机会去应用。
更多的时候只是了解有这个技术点而已。
而到了终极架构师阶段，面对高复杂度的系统，很多时候就是几个关键技术，细节决定整个架构设计的成败，或者某个设计方案，理论上就是不可行的。
如果不深刻理解理论和相关的关键技术点，很难设计优秀的架构。
以我做过的异地多国设计方案为例，之前很早我就知道CAP理论了，但也仅仅只是知道几个概念而已。
真正做异地多活的时候，开始的时候还是走了不少弯路，试图做一个完美的异地多活系统，最终发现这其实是不可能的。
某天突然顿悟，其实CAP理论已经明确的指出来了这点，但最初学习CAP理论的时候，很难有这样深刻的理解。
最后来看一下，高级架构师成长为高级架构师，需要十年以上时间。
其典型特征是创造新的架构模式。
例如，谷歌大数据论文创造了分布式存储架构、分布式计算map reduced架构、劣势存储架构，开创了大数据时代。
在有map reduced分布式计算架构的背景下，storm又创造了流式计算架构。
在虚拟机很成熟的背景下，docker创造了容器化的技术潮流。
高级架构师与中级架构师相比，典型区别在于创造性。
高级架构师能够创造新的架构模式，开创新的技术潮流。
坦白的说，对于从中级架构师如何才能成长为高级架构师，我并没有太好的指导。
一个原因是我自我评价。
目前顶多算个中级架构师。
另一个原因是一旦涉及创造性，其实和艺术就比较类似了。
创造性。
实际上是很难学会的，也很难有老师教会，更多是天分或者某种场景下灵感爆发参考技术界几个创造性的架构案例。
我总结出几个可能诞生创造性架构的背景、条件足够复杂的业务场景。
例如，谷歌的大数据、阿里的双十一、facebook的海量用户等业务场景越复杂，给技术带来的挑战更大更有可能产生创造性的技术突破。
足够强大的技术团队，绝大部分创造性的架构都来源于大公司或者知名的研究机构，没有技术实力支撑，想突破也是心有余而力不足，不满足于现状的态度。
例如，虚拟机很成熟，但是资源占用太多，所以发明docker map p reduced难以做到实时运算。
所以创造storm流式运算，尊重技术价值的文化。
创造性的东西往往需要投入大量的人力和时间。
而且刚开始一般都不会很成熟，如果完全结果导向KPI导向创新技术，很可能在萌芽阶段就被否定。
小结一下，关于如何在专业领域内提升有条著名的一万小时定律。
简单来说，要成为某个领域顶尖的专业人才，需要持续不断一万小时的练习，例如小提琴、足球、国际象棋、围棋等领域，无一例外都遵循这个定律。
我认为技术人员成长也基本遵循这个定律。
我在文章中试图提炼一条通用的成长路径供你参考。
但其实最关键的还是技术人员对技术的热情，以及持续不断的投入，包括学习、实践、思考、总结等。
最后，你可以统计一下自己从头到尾认真读过的技术书籍数量，系统研究过的开源项目的数量。
然后自我评估一下自己目前处于哪个层级，看看是否有什么发现。
又到了送福利的时间，二十六到五十七入选竞选留言的同学名单都在文稿中了。
由于人数较多，听音频的同学请点击文稿查看名单。
在这里，我也向你推荐一下微博技术专家胡忠祥的从零开始学微服务专栏，对微服务架构感兴趣的同学不要错过哦。