怎么样从后端工程师迈入架构师的门槛，成为一名架构师？求指导方向

同问,蹲个科普,我也遇到楼主的遭遇了

先到公司呆起，都是从开发开始干，等你开发牛逼了，有项目重构了就轮得到你了

为啥要架构师，或者说为啥要新系统，原来的系统运行的好好的加硬件就可以搞定，还不需要数据迁移

你连说服领导重构系统的能力都没有怎么做架构师

大公司里面程序员的发展方向一般是，业务 leader 或者技术专家，架构师好像没有，架构的工作一般高级工程师就干了

1. 技术不要学精，学些皮毛就行，要记住各种技术名词（这个最重要）
2. PPT 和 Visio 之类的工具要擅长
3. 如果在大厂，巴结好领导关系，先在本公司提升职称，升一级就跳另一个大厂反复继续
4. 如果在小厂，多面试其他小厂，就面试架构师职位，唬住就上，上了在向其他同事学

总之就是一点，技术不要学精，只要知道怎么拼凑在 PPT 上，基础职称搞上去

头部大厂+核心组+从 0 到 1 做一个核心项目。 这机会很难找了。

直球说出来现在技术栈的缺点, 自己架构的优点, 然后做出来 demo 去线下 pk, 看那一个架构开发成本, 维护成本, 开发效率是老板能入眼的.

架构不是报菜名, 你现在要学的是累积线上产品的经验, 架构只是踩过够多的坑, 能攒出来一套优点比缺点多的方案而已.

先上一下自己的 Github https://github.com/isno/theByteBook 《深入架构原理与实践》

1. 技术栈没问题，但 2 年经验转架构挺难的（架构师很大程度是一堆失败经验成长起来了）
2. 找这样的职位：SRE 工程师、云架构师、技术 Leader
3. 你失败的经验比较少，我感觉还是挺难的。我知道的几次架构失败，造成大故障，都是负责人走人，我感觉没有领导敢让新人设计方案

我组里接触的架构师就是解决一些难点 做一些预研的工作，但实际开发做的 crud 工作其实也没啥难点。
所以

所以例会上看得出领导其实是对架构师是有一点失望的

人人都是架构师，不开玩笑。。
先把自己那部分代码写漂亮，设计合理在说吧。

国内很多架构师都只能算高级工程师，一过招就露馅。

多往基础知识上学， 然后多争取机会练手，最重要的要有一个练手的机会（这个最难得）。

我理解架构师不是一个单独的方向啊，一个工程师同样也可以是架构师。
当你经历了几个公司，几个 01 或大的项目，不局限于 crud ，能和各上下游团队 battle 的时候，就已经半只脚迈入架构师的门槛了。
在很多公司架构师并不是一个岗位，更类似于某个级别所必须具备的能力。

曾经我的老师，说过他是怎么当上架构师的《把所有人熬走，你就是老大了》。

目前业内没有架构师这个岗位

虽然楼上的各位说的一些招很接地气，但我还想是想问让如何让自己变成一个货真价实的架构师.

架构师主要看天赋，后天努力是在强化这个天赋。

多看书、多看大佬 ppt 、多看大佬分享，当然充值可以让你更快的变强亘古不变

突然想到那个把大象装进冰箱要几步
1. 打开冰箱门(把现在的架构师挤走)
2. 把大象塞进去(任职架构师)
3. 关上冰箱门(把晋升通道堵死)
哈哈

在工作中你只能通过参与项目，特别是从 0 开始的项目来体现你的架构能力，而且要同事认可你。技术什么的没有那么重要

只熟悉某一栈的研发工作，并不能帮你成为架构师

对于架构师来说, 技术恰恰是能力中最不重要的一环

司马懿大家都知道呀 打不过诸葛村夫就熬呗🐶

架构师有点把自己的工作框住了。
我建议 OP 看一下，研究一下如何成为一名伙计工程师（ staff engineer)。你说的架构和设计是他们工作的一部分，但不是全部。staff engineer 的工作范畴要比这个广： https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/

架构师工作的本质是「软件工程」「企业工程」如果你能正确分辨软件工程和计算机科学这两门学科，就理解了一部分架构师的工作。

理论上技术的广度 > 深度。是从企业整体层面综合给「工程方案」，譬如「代码规模」「维护人数」「研发工具」「依赖关系」直接就挂钩「维护成本」「开发协作」「构建速度」「技术债」「项目劣化，大家常说的屎山不是一日建成的」

说直接点就是「提高开发效率」「保证代码质量」「提高复用性」「自动化流程」「团队协作效率」「研发支持，包括工具中台中间件这些」「 devOps 」等等

这里面有很大一部分是需要扎实的技术功底。也有一部分只需要做到「纸上谈兵」「图画得好」「方案讲的好」就行，或者说在「制度」「流程」「管理」「沟通」上面的推进。

简单点的像：
加个阿里编码规约（ AJCG ）插件，静态代码扫描工具和规范像 ESLint 、SonarCube ，给公司搭个 chatGPT ，买个 github copilot 会员给大家用，一键 CICD ，严格规范发版流程制度，配个服务器警告邮件短信通知。
这些玩意你知道了你也能做到。

复杂点的就很吃技术硬实力：
综合给出一整套「架构方案」，就是你背的八股里面大部分理论知识，或者你随便抄的一套网上「微服务开源项目」，让你「自以为你可以胜任」的工作内容。
但是你根本不知道自己为什么要用 Gateway 、Nacos 、Sentinel 、Mongo 、Redis 、Zookeeper 、MyCat 、Kafka 、Nginx 、APISIX 、PLSQL 、Clickhouse 、EMQX 、TDengine 、VUE3 、Tailwind 、TS 、K8S 。你连它们的特点、竞品都不知道，更别说如何横向设计和实施。

随便来点实际问题就问死你：
如果你公司没做 S3 ，你在什么场合下会考虑 MinIO ？
从 SLB 到 api 网关包括鉴权流控黑白名单跨域一整套的负载方案，告诉我从哪走到哪怎么负载有哪些情况处理。
或者做点 infra 基建，搭套 O11Y ，Monitoring 、Logging 、Tracing 。包括你 devOps 里面的 CICD 、制品管理、版本控制。备案证书分发这些都算是简单。K8S 也有很多套版本，什么场合用什么开哪些插件？

至于你说的业务上，服务上的脑残设计，代码逻辑流程这些小玩意。不归架构师管，如果你有本事可以解决点小问题修修 bug 无所谓。但是规范项目目录结构，定时清理 maven 依赖，还一些技术债，降低项目的熵重要性更高。

好消息是哪怕你不会这些玩意，你也能去应聘一名「架构师」
因为这岗位一个萝卜一个坑，小公司面你的基本上是 boss ，对老板会吹牛逼就行，他比你还不懂。
大公司坑多，没硬实力你没办法骗进去的。

我更建议你先应聘「架构部」的普通研发或企业内部转岗，去一些架构部门、中台部门、devOps 部门。虽然不能掌握架构的全貌，起码这些能让一个 Java 或者运维入行，你也有机会接触到真正的架构工作。

你那些自认为的亮点，在我看来是基操，我会的这些基操你却看不懂。

@zzzzzzZ #24

谢谢你能够为我写这么一大段文字。

我承认我写的 highlights 都应该算是基操，这点东西确实我现在也总有一种“这点东西拉过来随便找个人教一个月谁都会”的感觉。

关于你提到的这些复杂的技术与流程，我平时只是稍有一定的了解，你提的问题我也确实难以有一个合适的回答，也要谢谢你的这些例子，让我找到了些许方向，我应该在整个流程上更加深入一点。

我目前只是在一家小公司，说实话这些东西，我也只是业余研究，实际公司业务中用的很少（也有一些 DevOps 组件是在我推动下公司使用的）。

或许我现在更应该考虑的是换一个环境。

就算技术达到顶点也不一定能成为架构师
架构师我觉得只是一个称号
1. 懂的向上管理，情商高，将 ppt 能侃侃而谈，对于 ppt 上提出的问题都能进行回复
2. 不要再有技术思维，要转变业务思维和你的技术相结合（国内现状）
3. 表达得好，架构师不需要写代码，就是做方案的。写代码不如你的
4. 解决问题，技术并不能解决一切，要结合业务，人情世故
5. 不是说技术没用，不必精，但要多，看经验，履历；

软考有两个高级职称“系统架构师”和“系统分析师”，概括了架构师需要掌握的基本知识，掌握了之后剩下的就是踩坑锻炼了，各种问题的解决方案、为了适应业务发展系统架构的演进、看一看各种技术分享会别人家怎么设计怎么演进的等等，自己公司演进的比较慢或架构已经吃透了话，就跳槽去更大的公司去看看。

重构！重构！再重构！然后你发现自己的能力已经超过大多数的架构师了。

看书+实践
https://book.douban.com/subject/35492898/
https://book.douban.com/subject/35487561/
https://book.douban.com/subject/36403511/
https://book.douban.com/subject/30329536/
https://book.douban.com/subject/35246417/

这么多竟然都是友善回复没有阴阳怪气 不容易.
我又对本站充满信心了 - -
==============================
理论知识的话建议搜索关键字 系统设计 github 上有很多系列科普文章.

对技术不是全部也深有同感，所谓“朱泙漫学屠龙于支离益，殚千金之家，三年技成，而无所用其巧”。 很多时候，人际关系大于技术，你要是能跟刘邦打天下，那怕你啥都不会，他安排你做大将军，你就是大将军。

光学架构，网上的文章多如牛毛，没人带你做，学再多也不是架构师

我虽然挂着架构师的 title 但我也不知道一个合格的架构师应该会些什么。我觉得我其实是主程，核心代码是我设计并开发的。
我们开发时连 UML 都不画，根据需求定义一下后端接口、数据库表结构就开始开发了。中间会不停的遇到字段不够或者类型不对等问题而反复修改。
我理想中的架构师是只写一套接口、抽象类和表结构的人，然后交给开发去实现具体方法内容。但我目前做不到，假如让我只写接口之类的定义交给开发，也一定会被开发背地里说水货，因为他们在开发过程中肯定要改不少设计才能实现需求。
我的另一部分工作是技术选型，一些需求如果从零开发成本很大，我会去找开源项目或者商业库。有些需求如果在云服务上有现成的，我也会引入进来。这方面就需要自己经常关心各类技术的新动向，不一定要试用，了解特性和缺点，以后可能会用得上。

你只看到别人的缺点，而没有看到自己的不足。你在一个小公司看到的所谓架构师基本上都是不入流的，具体人家怎么有架构师的头衔，你可以参考你们公司对架构师的定义。至少人家在你们公司看来是有一技之长的，虽然在你看来缺点很多。说完了你的技能是普通技能，在你们公司没有稀缺性，你也没有光鲜的经历。你见的架构师普通技能可能不如你，但是人家有一技之长或者光鲜经历。

我想说大概这几方面, UI/UX, 前端, 后端, 运维, 设计模式, 系统设计, 对上管理, 对下管理, 表达能力, 人情世故.
在之前的一个公司, 直属领导 CTO 是个初代程序员, 四十几岁了, 常常观察他.