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

目前现状 Highlights
- 2 年经验，目前工作是 Java 后端，熟悉了解多种语言后端构建（ Golang/Python/Rust/TS ）
- 了解 k8s 与主流的容器化技术（ podman 、docker 、buildah ，etc ）
- 数据库 MySQL+Postgre+Mongo
- 熟悉 DevOps 流程，熟悉 Linux 运维
- Spring Cloud Alibaba 系的微服务构建

为什么想要当架构师？

- 遇到过很多挂着架构师名号的 sb ，被脑残的设计恶心到要似
- 这群 sb 导致了很多问题，搞得大家团团转
- 觉得自己能比他们更优秀，想拿到话语权，决定更多设计上的问题

想问的问题

1. 我目前的技术栈，如果转架构，还需要学习什么？
2. 架构师怎么找工作？投简历对应的岗位名称就是架构师？还是高级后端工程师之类的？
3. 如果有机会的话，怎么说服领导让自己从 Java 后端升格为架构师？

谢谢大家

flamingooo

323 天前

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

txy3000

323 天前

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

dayeye2006199

323 天前

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

zzzzzzZ

323 天前

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

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

说直接点就是「提高开发效率」「保证代码质量」「提高复用性」「自动化流程」「团队协作效率」「研发支持，包括工具中台中间件这些」「 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 或者运维入行，你也有机会接触到真正的架构工作。

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

Masoud2023

323 天前

@zzzzzzZ #24

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

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

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

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

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

hui9000

323 天前

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

hooych

323 天前

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

xuanbg

322 天前

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

yangzhezjgs

322 天前

看书+实践
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/

chaleaochexist

322 天前

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

feng950704

322 天前

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

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

neetrorschach

320 天前

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