全站年SVIP
全站1000+试题无限查看
他们很多也是好的大学，计算机科班专业毕业，计算机基础知识技能没有任何问题，工作也足够的努力，但是仍然很多人无法真正成为一个合格的架构师。
从学徒到工匠，从工匠到大师，难的往往就是层层跃迁的质变点。而真正影响这个质变点的，仍然是你个人独立解决问题的能力，思维能力的培养。
我前面经常会举对汽车观察认知的例子。即使大部分人实际并不会去关心汽车内部结构和汽车的运行机理，只需要知道汽车的外部组成，知道如何让汽车动起来就足够了。
这个有没有错?
说实话，这个在大部分场景下并没有发生过。
人的精力是有限的，你不可能对所有的新事物，新问题都去刨根究底，搞清事物内在本质。但是回到你自己的专业领域就不一样的。
当面对你自己的专业领域的时候，一定要从浪漫派转变为古典派，要去挖掘事物内在本质和运作机理。只有这样你才可能抽象普适性的规律，在后续新问题解决中去应用。
当你深入问题内部的时候，自然将专业知识的广度转变为了知识的深度。
而知识深度对你来说才是最有价值的。
一个人能够解决复杂问题，往往仅仅是因为自己见过，而不是因为本身具备了问题分析和匹配的能力。
对于这类人当面临一个全新的领域，全新的问题的时候往往无从下手。
因为没有掌握一种在自己专业领域普适性的问题分析和解决方法。
拿企业的业务流程来说，这些流程千变万化，但是当流程分解后你会发现，所有的流程都是由底层的200到300个原子业务活动组装出来的。对于某一类技术问题同样道理，虽然你面对问题都不相同，但是分解后都是共性的原子能力。
一个问题的解决往往涉及三个方面。
你会发现问题分解并没太多难度，真正的难点是在你原子可复用能力的储备，其二是这些能力究竟应该如何组合。
如何提升这个能力呢?
其一就是每当你解决一个新问题后，你会通过复盘去思考，解决这个问题的方法中应该拆分哪些可复用的经验点。
其二是养成周期性深度复盘的习惯，即定期的会回顾是否出现过类似的场景或问题，这些问题群或问题列表，我会作为一个问题域来研究，去抽象这类问题分析解决的通用思路。找寻问题抽象后的本质属性。
比如我前面谈到过性能问题的解决问题。
当你经常面对业务系统性能问题需要解决的时候，你会发现类似JVM内存模型，查找内存泄漏方法工具，Linux进程和常用分析命令等都需要学习。你也会发现影响到性能了包括了硬件资源，数据库，中间件，应用程序，数据量诸多原因。
通过周期性复盘你才会形成一个通用的性能问题分析和诊断模型。
而不是一遇到性能问题就去重启服务器。
对于软件开发来说，为何经常会强调去研究和学习一些主流开源软件的源代码，也是同样的道理。程序员要走向架构师，一定要从软件开发表象走向内在原理和运作机制的研究，知其然并知其所以然。
很多程序员为何每天都在做简单的CRUD增删改查功能，原因也是相同的。大部分人并不去思考事物的内在运行本质。
一个最简单的CRUD功能也涉及到开发框架和基础类库，那么能否对这些内容进行研究，了解一个软件功能实现出来的内部原理。同样，任何一个CRUD功能也涉及到高可用和高性能，那么能否对相关的数据结构和算法进一步研究等。
在多年前我当项目经理的时候，对团队里面的开发人员进行观察，也是同样的道理。
一个大的业务系统往往分解为了多个业务功能模块，但是大部分人往往只熟悉自己的功能模块，对其它模块一无所知。而少量的人往往是自己花时间去熟悉整个系统，熟悉自己主管的各个模块，并去了解各个模块之间的协同关系。
跳出盒子很多时候不是技术问题，而是思维意识问题。
不是要求所有的人都能够探求事物内在原理和本质，但是如果你要实现技能阶层跃迁，那么必须从外走向内，从现场到本质。
从万物穷尽到能够总结出一套适合自己的规律和方法论。
如果我们说微服务架构框架，你如果原来本身就对Java软件开发熟悉。
那么你可能花1到2周的时间就能够采用开源的SpringCloud搭建好微服务开发框架，并对里面的注册中心，网关，限流熔断，链路监控，安全等都进行自我测试和验证。
当然你也可以将微服务框架应用到你当前开发的小产品中。
那么这样持续2到3年，你能够算对微服务架构精通吗?
显然不能。
其最大的一个原因就是当你的项目没有达到一定规模，实际的业务系统没有达到一定的用户数和并发量的时候，很多架构层面的应用问题你根本就无法遇到。
典型的包括了应用性能问题，复杂Bug的快速定位排查，安全问题，应用本身的高可用问题等。这些内容实际你很难通过理论学习完全掌握。
海量高并发架构设计的书你可能看了很多，即使书里面也会讲到一些关键经验点，但是你原来没有实践遇到过，你并不会产生共鸣，这些书里面的经验总结并不会因为你阅读了书籍就直接转换为了你自己的内在经验。
理论的学习无法转变为你自己的经验，唯有实践。
你只有通过大项目的实践，在实践过程中通过不断地遇到新问题，解决新问题，你的技能和经验才能够不断提升，并最终转换为你自己的经验模式。
没有大项目实践，实际你很难完成这种转变。
没有大项目实践，即使你把所有的微服务技术原理的书全部看了，但是无法在实际项目中应用，最终仍然会逐步遗忘，这些知识并不会转变为你内在经验模式。
所以当你有这种大项目机会的时候一定不要放过，如果在一个企业多年也没有这种机会你也可以考虑是否找 一个新的工作机会去锻炼。
我在前面写过很多私有云PaaS平台，SOA架构设计，平台性能优化，SOA治理方面的文章，这些文章总结本身即来源于大项目实践。
通过大项目实践，你才有机会提升你这块的架构设计能力。要明白架构设计过程本身也是一个迭代演进的过程，没有最优的架构，只有面对当前场景最适用的架构。
就拿我们SOA项目一个接口服务运行实例日志存储。从最开始的数据库分表，再到Solr全文建设，再到转到HBase的分布式存储库，本身就是基于场景不断演进的过程。
架构设计一定不是你懂搭建某个技术框架，这不能叫架构。
真正的架构是你面对业务场景和问题领域的时候采用最佳技术方案去解决问题的能力。
要做到这点。
总结为一句话就是模式应用能力，即当你面对不同的业务场景和问题域的时候，应该采用什么最合适的技术来解决。你需要的是这种匹配能力。
真正的实践过程就是不断地去提炼这种可复用的匹配能力。
为什么大部分程序员都无法成为架构师
他们很多也是好的大学，计算机科班专业毕业，计算机基础知识技能没有任何问题，工作也足够的努力，但是仍然很多人无法真正成为一个合格的架构师。
从学徒到工匠，从工匠到大师，难的往往就是层层跃迁的质变点。而真正影响这个质变点的，仍然是你个人独立解决问题的能力，思维能力的培养。
认知升级-从外到内，从现象到抽象
我前面经常会举对汽车观察认知的例子。即使大部分人实际并不会去关心汽车内部结构和汽车的运行机理，只需要知道汽车的外部组成，知道如何让汽车动起来就足够了。
这个有没有错?
说实话，这个在大部分场景下并没有发生过。
人的精力是有限的，你不可能对所有的新事物，新问题都去刨根究底，搞清事物内在本质。但是回到你自己的专业领域就不一样的。
当面对你自己的专业领域的时候，一定要从浪漫派转变为古典派，要去挖掘事物内在本质和运作机理。只有这样你才可能抽象普适性的规律，在后续新问题解决中去应用。
当你深入问题内部的时候，自然将专业知识的广度转变为了知识的深度。
而知识深度对你来说才是最有价值的。
一个人能够解决复杂问题，往往仅仅是因为自己见过，而不是因为本身具备了问题分析和匹配的能力。
对于这类人当面临一个全新的领域，全新的问题的时候往往无从下手。
因为没有掌握一种在自己专业领域普适性的问题分析和解决方法。
拿企业的业务流程来说，这些流程千变万化，但是当流程分解后你会发现，所有的流程都是由底层的200到300个原子业务活动组装出来的。对于某一类技术问题同样道理，虽然你面对问题都不相同，但是分解后都是共性的原子能力。
一个问题的解决往往涉及三个方面。
你会发现问题分解并没太多难度，真正的难点是在你原子可复用能力的储备，其二是这些能力究竟应该如何组合。
如何提升这个能力呢?
其一就是每当你解决一个新问题后，你会通过复盘去思考，解决这个问题的方法中应该拆分哪些可复用的经验点。
其二是养成周期性深度复盘的习惯，即定期的会回顾是否出现过类似的场景或问题，这些问题群或问题列表，我会作为一个问题域来研究，去抽象这类问题分析解决的通用思路。找寻问题抽象后的本质属性。
比如我前面谈到过性能问题的解决问题。
当你经常面对业务系统性能问题需要解决的时候，你会发现类似JVM内存模型，查找内存泄漏方法工具，Linux进程和常用分析命令等都需要学习。你也会发现影响到性能了包括了硬件资源，数据库，中间件，应用程序，数据量诸多原因。
通过周期性复盘你才会形成一个通用的性能问题分析和诊断模型。
而不是一遇到性能问题就去重启服务器。
对于软件开发来说，为何经常会强调去研究和学习一些主流开源软件的源代码，也是同样的道理。程序员要走向架构师，一定要从软件开发表象走向内在原理和运作机制的研究，知其然并知其所以然。
很多程序员为何每天都在做简单的CRUD增删改查功能，原因也是相同的。大部分人并不去思考事物的内在运行本质。
一个最简单的CRUD功能也涉及到开发框架和基础类库，那么能否对这些内容进行研究，了解一个软件功能实现出来的内部原理。同样，任何一个CRUD功能也涉及到高可用和高性能，那么能否对相关的数据结构和算法进一步研究等。
在多年前我当项目经理的时候，对团队里面的开发人员进行观察，也是同样的道理。
一个大的业务系统往往分解为了多个业务功能模块，但是大部分人往往只熟悉自己的功能模块，对其它模块一无所知。而少量的人往往是自己花时间去熟悉整个系统，熟悉自己主管的各个模块，并去了解各个模块之间的协同关系。
跳出盒子很多时候不是技术问题，而是思维意识问题。
不是要求所有的人都能够探求事物内在原理和本质，但是如果你要实现技能阶层跃迁，那么必须从外走向内，从现场到本质。
从万物穷尽到能够总结出一套适合自己的规律和方法论。
大项目实践的机会，可遇不可求
如果我们说微服务架构框架，你如果原来本身就对Java软件开发熟悉。
那么你可能花1到2周的时间就能够采用开源的SpringCloud搭建好微服务开发框架，并对里面的注册中心，网关，限流熔断，链路监控，安全等都进行自我测试和验证。
当然你也可以将微服务框架应用到你当前开发的小产品中。
那么这样持续2到3年，你能够算对微服务架构精通吗?
显然不能。
其最大的一个原因就是当你的项目没有达到一定规模，实际的业务系统没有达到一定的用户数和并发量的时候，很多架构层面的应用问题你根本就无法遇到。
典型的包括了应用性能问题，复杂Bug的快速定位排查，安全问题，应用本身的高可用问题等。这些内容实际你很难通过理论学习完全掌握。
海量高并发架构设计的书你可能看了很多，即使书里面也会讲到一些关键经验点，但是你原来没有实践遇到过，你并不会产生共鸣，这些书里面的经验总结并不会因为你阅读了书籍就直接转换为了你自己的内在经验。
理论的学习无法转变为你自己的经验，唯有实践。
你只有通过大项目的实践，在实践过程中通过不断地遇到新问题，解决新问题，你的技能和经验才能够不断提升，并最终转换为你自己的经验模式。
没有大项目实践，实际你很难完成这种转变。
没有大项目实践，即使你把所有的微服务技术原理的书全部看了，但是无法在实际项目中应用，最终仍然会逐步遗忘，这些知识并不会转变为你内在经验模式。
所以当你有这种大项目机会的时候一定不要放过，如果在一个企业多年也没有这种机会你也可以考虑是否找 一个新的工作机会去锻炼。
我在前面写过很多私有云PaaS平台，SOA架构设计，平台性能优化，SOA治理方面的文章，这些文章总结本身即来源于大项目实践。
通过大项目实践，你才有机会提升你这块的架构设计能力。要明白架构设计过程本身也是一个迭代演进的过程，没有最优的架构，只有面对当前场景最适用的架构。
就拿我们SOA项目一个接口服务运行实例日志存储。从最开始的数据库分表，再到Solr全文建设，再到转到HBase的分布式存储库，本身就是基于场景不断演进的过程。
架构设计一定不是你懂搭建某个技术框架，这不能叫架构。
真正的架构是你面对业务场景和问题领域的时候采用最佳技术方案去解决问题的能力。
要做到这点。
总结为一句话就是模式应用能力，即当你面对不同的业务场景和问题域的时候，应该采用什么最合适的技术来解决。你需要的是这种匹配能力。
真正的实践过程就是不断地去提炼这种可复用的匹配能力。