下面是一个 Java 架构师岗位的招聘要求，可以作为一个参考：
工作职责 ：
- 独立进行系统或产品的设计、优化和重构；
- 全流程业务分析、抽象、建模；
- 能带领 10 人以上团队，研发过程管理，任务拆分与分配，跟进解决各种复杂技术问题；
- 技术选型，指导项目研发全过程；
- 负责核心代码编写，主导代码 Review；
- 负责系统性能优化，保证平台安全、稳定、快速运行。
任职要求 ：
- 本科及以上学历，8 年以上 Java 开发工作经验，有金融相关行业背景优先；
- 具备丰富的系统设计经验，熟悉常见的设计模式和面向对象的设计思想；
- 主导过 10 人以上团队参与的软件开发经验，并主导架构设计和整体技术规划；
- 最近一年有一线写代码的经历；
- 具有深厚的技术功底、广阔的技术视野、精通至少某一个技术领域；
- 有大规模系统重构经验者优先考虑；
- 有金融理财相关工作经验者优先考虑；
通过这个招聘可以看到架构师的要求还是很高的，可以说需要掌握十八般武艺。
不过岗位描述并不能百分之百代表真实的岗位要求 ，要知道有的公司的岗位要求是直接从其他地方复制过来的。
分享几位架构师
下面介绍我在职场上遇到的几位架构师。
架构师 A
我并没有见过本人，却给我留下了很深的印象。原因有几个：
- 留下的代码很多，基本每个系统的基础代码都是他写的；
- 代码质量很高，可以比拟 Spring 源代码，代码中对类、方法、变量的命名都精益求精，设计模式也用得非常好；
- 团队的项目开发基本都是在他写的框架下进行扩展，同事的代码风格受他影响很大。
架构师 B
能写码、能架构的技术工匠，目前在某中厂做首席架构师。虽然没有见过他写的代码，但我对他有一些了解：
- 学历背景和职场背景都非常好；
- 技术深度和广度都很好，经常给公司做一些技术分享，听了之后感觉收获颇多；
- 沟通能力强，有很强的引导力和说服力；
- 学习能力强，接收新东西快。
架构师 C
展现的技术能力比较少，但是职场背景和行业经验丰富，谈谈我和同事们对他的几点认识：
- 沟通能力比较强，不仅体现在日常沟通，遇到扯皮撕逼甩锅的事情，能够很好地应对；
- 善于项目管理，PPT 能力很强；
- 一线技术能力有点退化，基本已经脱离编码；
- 架构设计、技术选型都能胜任，不过有时感觉设计的东西有点不接地气。
架构师 D
目前是一线大厂的高 P，因为并不负责实际的项目，所以并不好评价他的能力：
- 文档能力强，经常在公司分享架构文档；
- 每个项目组的设计基本都是高开在做，所以大家认为他的产出并不高，但是这并不能说明他能力弱。产出不高并不能代表能力不强，这很有可能跟公司的体制有关系，有可能是公司没有给他产出的机会。
- 大厂的 P 级也能一定程度上说明他的能力。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
架构师到底做什么
上面我列举了 4 位自己遇到过的架构师，也是比较典型的架构师。那架构师工作内容到底是什么呢？
架构设计
架构设计是多数架构师会有的工作内容，架构设计的方向也很多，比如应用系统架构、网络架构、安全架构、系统架构等。这些工作内容都需要对技术基础和系统有较好的认识，不然很难胜任。
业务梳理
有的公司是有业务架构师的，业务架构师对技术要求可能不会太高，但是对业务能力要求非常高，好多公司要求有 10 年以上本领域的工作经验。在大规模系统群的团队里，业务架构师显得非常重要，重要程度甚至超过技术大牛，要知道，一个大型项目，系统抽象的前提是已经做了很好的业务梳理和业务抽象。
技术选型和分享
技术选型工作对于新技术的引入非常关键，比如注册中心怎么选择、分布式数据库选什么技术、缓存选什么技术、消息队列选什么技术。要做出正确的选择，就必须不仅熟悉这些技术的优缺点、还是熟悉当前公司和团队的情况，比如业务场景和流量、团队规模和团队技术水平、当前团队内使用到的技术等。
对自己的选型结果，需要在公司内部做技术分享。优势也需要就公司的系统对外做技术分享。
代码编写
曾经有一个争论很久的问题，架构师要不要写代码 。我见过代码能力很强的架构师，也见过不写一行代码只会坐而论道的架构师。
架构师可以不写代码，但绝对不能失去写码能力。只有写代码的过程才会感受到交付的压力和架构落地的痛点，才能在设计的时候考虑一线程序员的苦。
如果只是在一个高层次上把控架构，很容易不接地气，很容易做出鸡肋的设计，让一线程序员苦不堪言。
技术管理
有些公司要求架构师带团队和带项目，这时候就需要架构师具备管理能力了。
管理是一门大学问，方向也很多，比如项目管理、团队建设，这对一直钻研技术的架构师们绝对是一个挑战。
沟通协调
沟通协调是一门软实力，对架构师来说非常重要。比如下面的三个场景：
- 自己设计的架构和方案要说服团队成员使用；
- 团队成员因为一个设计发生了分歧，谁都说服不了谁；
- 一个团队成员非要引入一个技术，但是这个技术很可能对系统整体有影响。
学习提高
架构师需要不断提高自己，最好能做到某一技术领域或业务领域的专家级别，这样才更容易建立自己的影响力。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
必要的准备
技术提升
要走向架构师，首当其冲就是提升自己的技术能力。但同时也要注意到，一个人不可能精通所有的技术。社会上能招一个同时精通前端和后端的候选人都很难。
不过最好有一两门自己精通的技术，最好是能达到源码级别，比如 Kafka、RocketMQ。对自己负责的系统，技术必须熟练掌握，至少不能有盲区。
技术不是最重要，但技术好一些能被吐槽的少点。
提升技术视野，多跟身边的朋友交流，看看其他公司的技术选型和系统建设，给自己一些参考和启发。
建立影响力
影响力太重要了，有的大佬通过影响力被推荐去做架构师。我们可以从下面几个方面尝试打造自己的影响力：
- 优秀开源项目作者、贡献者、优秀布道师；
- 公司高级职位，比如大厂高 P；
- 优秀博客主或技术自媒体人；
- 行业内资深人士，比如某领域 10 年以上从业者；
- 创业获得过投资。
软技能
程序员每天钻研技术，很容易忽略了自己的软实力，包括沟通协调能力、项目推动能力、建立信任的能力、技术分享能力、说服力。这些能力可以在平时刻意地练习。
曾经有一个架构师看了我写的代码说最好别这样,但是当我反问为什么别这样时他没能说出所以然，我也只是出于礼貌做出了修改，假如我是一个杠精，那后果会怎样 。
技术上说服别人很难，往往公说公有理婆说婆有理，但尝试从下面几个方向说服对方呢？
- 不遵守设计原则：你的代码违背了里氏替换原则；
- 这一块儿代码有点乱，这是一个 xxx 场景，用 xxx 设计模式优化一下会更清晰；
- 不符合编码规范，阿里巴巴 P3C 规范有一条是这么写的；
- 代码耦合了，订单服务的业务耦合到了库存服务；
- 这样写会有效率问题，你可以使用 xxx tps 压测一下；
- 这里多线程修改一个变量会不会有并发问题，是不是应该用并发集合类。
薪资对标
这个也是必要条件，如果一个公司招聘架构师起薪是 80 万，而你目前的薪资只有 30 万，就算你技术再好，也不可能对标上去啊。
职场中兢兢业业的态度是好的，但是如果要考虑走上架构师岗位，也要关注自己的薪资，及时作出调整和选择。千万不要一味地做老黄牛。
架构经验
我面试过很多人，竟然有不少候选人工作 10 年都没有参与过从 0 到 1 的系统建设，这是非常被动的。好多公司招架构师会要求主导过从 0 到 1 的系统设计或者主导过大规模重构。
Title
在职场上，Title 是个奇怪的东西，有时候不重要，有时候又很重要。有的公司招架构师去了其实是做高级开发，有的公司招高级开发去了实际是做架构师。
Title 的作用会体现在招聘过程中。比如公司招一名架构师，在薪资能对标的情况下，候选人的简历中当前职位是高级还是架构可能会对结果有一定影响。所以如果有机会选择 Offer，其他条件差不不大的情况下 Tile 也是一个值得关注的点。
拓宽人脉
多结交圈内的朋友，靠朋友推荐很靠谱，一方面自己不容易跳到坑里，另一方面公司也很乐意接收推荐的的人才。
写在最后
刚毕业几年，觉得架构师是神一样的存在。但工作久了，我遇到过不能写代码的架构师、遇到过技术和业务都很一般的架构师、遇到顶着架构师的 Title 做项目管理的同事、也遇到过所谓的 PPT 架构师。
想成为架构师，首先要知道架构师具体在做什么，每家公司可能不尽相同，同时必须清楚自己想做的工作内容，业务方向和技术方向选一个还是都要。
最后，我分享几点心得：
- 架构师岗位远远没有想象的那么光鲜亮丽；
- 做架构师很难，你的设计很可能会被不断地 diss、吐槽，磨炼耐操的能力；
- 经常回顾和总结，看看自己的阶段性产出，如果觉得不满意，考虑下是自己的问题还是公司平台问题；
- 已经进入公司就不要太在意 Title 了，经常跟领导沟通，对齐期待，不要跑偏；
- 保持学习成长和社交。
