我的梦想是十年内成为架构师，该怎么办？

现在已经有确定的目标了，真不错！很多人连自己的职业目标还没有确定。

架构师这个职位没什么神秘的，简单点儿说就是用户需求转化成技术实现，只是在转化的时候会遇到一系列问题，比如：技术如何选型？ 如何设计才更简洁、更容易实现和扩展？如何满足非功能性需求，如性能、安全、高可用性、审计......

除此之外，还得和客户以及分析人员沟通需求，确保没有跑偏，有时候还得引导一下，去除或者改变那些不可能实现的需求。

和程序员沟通，让大家理解技术选型和设计，顺利开展设计和编码。

软件架构师自身需要是程序员，并且必须一直坚持做一线程序员，还需要承接编程任务，如果不亲身承受因系统设计而带来的麻烦，就体会不到设计不佳所带来的痛苦，接着就会逐渐迷失正确的设计方向。

软件架构师不是一蹴而就的，是一个循序渐进的过程，是一个职责不断扩大的过程。

刨除好奇心和对这个行业的热爱， 我个人认为至少需要在这些方面进行发展：

一、掌握技术的原理

做一个架构师会涉及到很多技术，要求技术的广度，如果掌握了原理，不但对技术认识深刻，学习新的东西就能迅速抓住本质。

计算机的基础知识就不用说了， 网络、操作系统、数据库、编译等， 相对枯燥，最好在大学阶段完成。

你是Java开发方向发展， 至少要掌握这些应用层的东西：

• Kafka
• Mysql
• Tomcat
• Docker
• Spring
• MyBatis
• Nginx
• Netty
• Dubbo
• Redis
• Netty
• Spring cloud
• 分布式
• 高并发
• 性能调优
• 微服务
• .....

真是不少啊，关键是在应用层学习的时候，要多问为什么？ 我建议你用这样的句式： “因为有xxxx的问题，现有的xxx和xxxx解决不了，所有才出现了xxxx这个技术。”

当你在追寻这些技术的本源的时候，对一个技术的思考就会更加深刻，就能超越很多人。

那怎么算把一个原理给掌握了呢？ 我认为标准就是你能用自己的语言给别人讲出来，让别人能理解。

二、获取项目经验和最佳实践

只知道原理，还是纸上谈兵，必须得做很多项目，在项目中去体会它们，应用它们，获取一些最佳的实践。

现在能从头开始设计项目的机会不多了，作为初级程序员，只能从现有项目中去学习，去研究下系统中的网络请求是怎么走的？ 负载均衡是怎么做的，四层还是七层？ 如果做的集群？如何做的复制？ ......

一定要努力地往上看，看到整个系统，看到端到端的流程，不能把自己局限在一亩三分地里， 做一个认领工作，完成工作的HTML填空人员， 那样路子真的就越走越窄了。

同样，要多问为什么， 在你通过自己或者求助别人探寻答案的时候，也许会发现现有设计的问题，这就是你的机会。

当你从局部慢慢走到整体以后，你的机会自然就越来越多，承担的职责越来越大，话语权越来越重，离架构师越来越近。

三、锻炼自己的抽象能力

写程序是一件挺简单的事情，把一个高中生拉来培训一下，就能写得像模像样。

但是想写好程序又是一件非常难的事情，因为系统越来越复杂，通过堆砌代码的方式来实现，很快就干不下去了，难度会成几何级数增长。

解决这个问题的关键就是抽象，架构师得找到系统中那些不变的东西，把他们作为支点来架起整个系统的设计，升华一下就是一些正交、分层等思想。

通过把系统的组件划分到不同维度，不同层次就可以实现封装“变化”的目标。

这些思想从哪里学习？ 怎么内化成自己的能力？

• 一是从项目中来，我相信你的项目肯定有这些思想的体现，只是你去用心去发现。
• 二是阅读书籍，阅读源码，看看牛人们是怎么做的。
• 三是自己要总结思考，总有那么一刻，你会顿悟： 啊，原来如此！

四、要发出自己的声音

做开发的很多都是性格偏内向，喜欢和电脑打交道，但是想发展成架构师，只是闷头干活肯定是不行，必须得在小组内，部门内，公司内发出自己的声音。

例如对于架构，设计，编码，工程实践，技术发展趋势都能提出自己的见解，让别人能信服、尊重你的意见，这样才能成为自然的技术领导。

如果只是靠领导的任命或者威权来领导，那下属可能要造反。

对了，这里的“声音”可以是小组讨论，部门会议，紧急任务处理，技术演讲，博客，客户交流等等。

总之，等到你精通原理，能把基本的思想应用到项目中， 还能看到全局，有足够的项目经验，被别人尊重、信服，那架构师离你就近在咫尺。

有梦想就去追！