在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等等，此外，架构师还要经常审查客户及市场人员所提出的需求，确认开发团队所提出的设计；
在中国不缺程序员，缺的是高级架构师，先来看看两者的薪酬对比，就知道两者间的差距：
但为什么在如此庞大的基数下，架构师的数量这么少，中间差了什么？对于普通程序员来说，成为高级架构师的门槛主要有以下几点：
3、对编程的认知。顶级程序员和平庸程序员，本质区别是遇到问题时的思考方式，这就是所谓的顶级程序员思维，一种高效解决问题的思维方式。这种思维方式，不是读几本Java书能学到的，而需要经过大量项目实战，才能总结提炼出来。
4、差的学习环境。很多程序员的学习环境很差，在公司经常加班，工作几年后，发现自己除了更熟悉公司业务外，能力没有得到半点提升，或周末基本不学习，而是出去玩。这么差的自制力和学习环境，很难让能力提到大的提升。
上面四点，每一点都非常难做到，也正因为这样，才会出现平庸的程序员很多，架构师却凤毛麟角的现象。
那如何才能克服上面四点，成为一名合格的Java架构师呢？
俗话说“没有见过好程序，怎么可能写出好程序”，同样，也可以说“不了解架构师的能力、工作，怎么可能成为架构师”，如果没有接触过顶级架构师，那你怎么知道自己要往哪个方向努力？所以，最好的方法是找个顶级架构师，去教你“高效的学习方法”、“完整的知识体系”和“对编程正确的认知”，让他去督促你学习，为你营造出“良好的学习环境”。
大牛不多，不太可能每个团队都有技术大牛，只能说团队里面会有比你水平高的人，即使他每天给你开小灶，最终你也只能提升到他的水平；而如果是跨团队的技术大牛，由于工作安排和分配的原因，直接请教和辅导的机会是比较少的，单凭参加几次大牛的培训，是不太可能就成为技术大牛的。
既然java架构师，首先你要是一个高级java工程师，熟练使用各种框架，并知道它们实现的原理。
熟练使用linux操作系统，必备。
那成为架构师所需要具备哪些技能？
架构师思考的是全局的东西，是如何组织你的系统，以达到业务要求，性能要求，具备可扩展性（scalability），可拓展性（extendability），前后兼容性等。可能涉及到的东西包括了从硬件到软件的方方面面。
一个合格的架构师要耐得住寂寞，在同事不停的在打荣耀而你只能不停的学习，是踩着坑上位的，是无数次推翻之前自己设计的“狗屎”架构，无数次日日夜夜加班而炼成的。
架构师不仅要上知技术实现细节，而且还要会项目管理、设计理论、性能优化、熟练使用各种工具，为公司各种业务提供技术支持，从前端到后台再到数据库、运维，哪里需要去哪里，还要一副好口才能睡服领导同事。
现在的架构师还要懂微服务、不会点分布式、大数据技术、机器学习也会被鄙视的。
想成为架构师不是懂了一大堆技术就可以了，这些是解决问题的基础、是工具，如果这些技术问题不懂怎样做到，如何能够找到解决方案呢？这是成为架构师的必要条件。架构师还要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格，人家一个几百人用户的系统，访问量不大，数据量小，你给人家上集群、上分布式存储、上高端服务器，为了架构而架构，这是不可取的，所以总结两点：架构师的作用就是第一满足业务需求，第二最低的硬件网络成本和技术维护成本。如果想要成为一名优秀的架构师还需要根据业务发展情况，提前预见发展到下一个阶段系统架构的解决方案，并且设计当前架构时将架构的升级扩展考虑进去，做到易于升级;否则等系统瓶颈来了，出问题了再去出方案，或现有架构无法扩展直接扔掉重做，或扩展麻烦问题一大堆，这会对企业造成损失。
大厂的大神还有如下的几个建议：
首先是要多读一些书，其中最基础的是类似于重构和设计模式这种书，你需要知道很多小尺度级别上的问题解决技巧（如果你要做导演，你首先要做得是能熟练地把一个句子翻译为一组镜头），以及这些作者梳理问题的方式，反过来问一下自己，如果让你来写设计模式这本书，你有哪些知识点可以写？你如何组织这些知识点？如何让大家接受你的观点。
看完这两本书之后，非常推荐你看一下MartinFowler写的《企业应用架构模式》和EricEvans的《领域驱动设计》这类书，他能扩大你的视野，专注于更有意义的问题，而不是设计模式究竟有多少种这种缺乏意义的问题。有一句话叫，“如果要成功，就要远离那些廉价的娱乐”。类似的，对于软件工程师来讲，要想让自己更强，就要远离那些廉价的争论（vimvsemacs,linuxvsunix,redhatvsdebian,这些争论其实并没有太大的价值）。
那如何学习呢？
例如：
1）Learning
这个是第一阶段，看书、google、看视频、看别人的博客都可以，但要注意一点是“系统化”，特别是一些基础性的东西，例如JVM原理、Java编程、网络编程，HTTP协议等等，这些基础技术不能只通过google或者博客学习，我的做法一般是先完整的看完一本书全面的了解，然后再通过google、视频、博客去有针对性的查找一些有疑问的地方，或者一些技巧。
2）Trying
这个步骤就是解答前面提到的很多同学的疑惑的关键点，形象来说就是“自己动手丰衣足食”，也就是自己去尝试搭建一些模拟环境，自己写一些测试程序。例如：
还有很多方法，这里就不一一列举，简单来说，就是要将学到的东西真正试试，才能理解更加深刻，印第安人有一句谚语：IhearandIforget.IseeandIremember.IdoandIunderstand，而且“试试”其实可以比较简单，很多时候我们都可以自己动手做。
当然，如果能够在实际工作中使用，效果会更好，毕竟实际的线上环境和业务复杂度不是我们写个模拟程序就能够模拟的，但这样的机会可遇不可求，大部分情况我们还真的只能靠自己模拟，然后等到真正业务要用的时候，能够信手拈来。
3）Teaching
一般来说，经过Learning和Trying，能掌握70%左右，但要真正掌握，我觉得一定要做到能够跟别人讲清楚。因为在讲的时候，我们既需要将一个知识点系统化，也需要考虑各种细节，这会促使我们进一步思考和学习。同时，讲出来后看或者听的人可以有不同的理解，或者有新的补充，这相当于继续完善了整个知识技能体系。
这样的例子很多，包括我自己写博客的时候经常遇到，本来我觉得自己已经掌握很全面了，但一写就发现很多点没考虑到；组内培训的时候也经常看到，有的同学写了PPT，但是讲的时候，大家一问，或者一讨论，就会发现很多点还没有讲清楚，或者有的点其实是理解错了。写PPT、讲PPT、讨论PPT，这个流程全部走一遍，基本上对一个知识点掌握就比较全面了。
最后撒点鸡汤，所谓学而时习之，温故而知新，即使是架构师也需要不停的学习、思考，新的技术层出不穷，不变的是那颗不甘安逸的心。