一直有个疑问，目前的人都是怎么提升到架构师的，或者说是如何拥有架构师的知识储备的。
都在说，项目用到的在学，用不到的学他干嘛。那岂不是就代表着，只要大厂才能产出架构师，程序员可以了解大厂程序的框架结构，这样就知道大型项目的架构，心里也有个底，后续也有参考价值。
那中小厂的程序员的，文档都不规范，架构更是能跑就行
我实在不理解在中小厂的程序员如何能成为一名架构师，连该学什么都不知道。
53 条回复 • 2024-09-11 11:07:24 +08:00
 |
1
tool2dx 9 天前  5
“都在说，项目用到的在学，用不到的学他干嘛。”
这和健身加负重一个意思。只练基础的，又不上负重，不长肌肉啊。 |
 |
3
memedahui 9 天前
我建议你从两个维度来学习这架构,一个是横向,一个是纵向
|
 |
4
Skifary 9 天前
架构建立在业务的基础上，遇到和解决的问题越多，越懂在后续重构的时候怎么搭建
|
|
5
memedahui 9 天前
横向:就是从用户角度,看看你自己的系统能不能承受百万用户的访问(自己折磨自己,不停的提高上线)
纵向:就是从系统扩展的角度,看看你的系统是不是易于拓展,别让系统变成无限膨胀,系统可维护行强.还要让自己系统的稳定性提高,给自己一个指标,比如系统 2 年内最多宕机 1 次 总结:不停的发现问题,正确的解决问题 |
 |
6
chihiro2014 9 天前
极限优化自己的系统，然后形成自己的一套做事理论
|
 |
7
pkoukk 9 天前 2
吹牛逼
架构师的练成主要靠吹牛逼 再精细点，你在公司发展的过程中，接了一个的系统，这个系统意外的成为了公司非常重要的一部分 这个系统你就是做成一坨狗屎，但只要他还活着，他还重要，只要你能吹，会抱大腿 你就能成架构师 |
 |
8
sagaxu 9 天前 3
跟公司规模关系不大，主要看项目，WhatsApp 月活 4 亿的时候只有 50 名员工，就不需要架构了吗？
成为牛逼架构师，项目要具有一些特性，比如大流量，大数据，业务超复杂，超高实时，超低延迟等等。 其实只要负责过从 0-1 的完整项目，每个人都是架构师，无非是能解决的问题的规模不同罢了。 有些人是从项目中学习，积累经验，然后成为架构师。 有些则是工作前就已经发表过架构方面的论文了，出道就是别人一生触碰不到的高度。 |
 |
9
lymanbernadette6 9 天前
大多数公司的架构师其实就是呆得久了，熟悉业务。
本身不一定是技术原因成为的架构师。 呆过几个公司（规模不小，大几千人的也一样）的架构师技术其实菜到抠脚。 |
 |
10
adoal 9 天前 2
很多架构师都是夹狗屎
|
 |
11
isno 9 天前 6
第一章《云原生技术概论》：先有认知，了解技术的发展的驱动力是什么是，看看微服务、容器、服务网格、devops 等等一系列技术解决了什么问题。对现代的分布式架构/系统有一个基本的认识。
第二章：《构建极致网络服务》，“网络请求”是架构设计的第一步，网络请求都到达不了“双活的”，“两地三中心的”，可用性“99.99999%” 的后端服务器。那这些高可用的形容词，都是“伪”的。 第三章，了解请求进入后端服务器是如何处理的。这一章相当于后续章节的前置，介绍一些高层架构设计中，需要注意的底层技术/原理。 第四章，开始进入分布式系统，主题是可扩展性，目的实现高可用，也就是介绍各类负载均衡技术。 第五章，第六章：前面章节介绍的都是无状态应用的设计。现在开始介绍“有状态应用”的设计，这里面有两个核心的主题：事务、以及共识。事务以及共识影响系统的可用性、容错设计。 第七章，第八章，是介绍容器系统相关的设计，介绍分布式系统中，容器是如何通信、调度、被管理的。但 Kubernetes 的问题是仅仅管理容器，容器内业务的通信治理也是个重要的主题。作为新一代的基础设施，容器以及服务网格的作用：是将系统中非业务逻辑全部解耦，下沉到容器、Sidecar 中。 第九章，解决了“网络请求”、高可用设计（负载均衡），数据一致性（事务、共识），应用负载（容器和服务网格）。那么整个高可用架构“设计阶段”已经解决。现在开始进入系统“运行阶段”。这个阶段要面临：大规模数据的挑战（成本和海量数据分析），系统的稳定性（监控），（各类观测数据的统一处理， 标准和规范） 最后一章，是 devops 的内容，补充应用如何交付、部署。 以上，就是 《深入架构原理与实践》 的主题。 送给你。 https://www.thebyte.com.cn/ |
 |
12
mightybruce 9 天前 2
怎么都在答非所问，架构师运用自己的经验帮团队少走弯路，其次不同团队之间的沟通，以及将技术语言转成领导能听懂的语言。
上面那几个， 谁跟你说架构都是高并发，高可用，你搞高并发，高可用的场景都不匹配，那就是白白浪费钱也没有产出。 如果就是个小公司，建议从可维护性上多入手，良好的抽象可以帮助降低复杂度，并使系统易于修改和适应新的应用场景。 架构难的还不仅仅是经验，难的是人际沟通，v2ex 上参与架构的并不多。 |
 |
13
RandomJoke 9 天前
多经历 0-1 ，多了解各个端的常用实践，了解特定业务用特定领域技术
|
 |
14
niubilewodev 9 天前
主靠吹牛逼。
99%的公司的 99%项目，不需要什么高精尖。 |
 |
15
GeekGao 9 天前
" 那中小厂的程序员的，文档都不规范，架构更是能跑就行 我实在不理解在中小厂的程序员如何能成为一名架构师，连该学什么都不知道。"
难怪。 现实是：中小厂普通码农基本没有成长为合格架构师的可能性。因为绝大部分公司的绝大多数项目都是没有什么挑战性的 CRUD 类应用。 甚至项目连等保、IPO 前合规等重要环节都遇到过。更不要说参与创造几个亿的收入的产品了… |
 |
16
to2false 9 天前
有时候，没有架构师可以省掉很多麻烦，遇见个菜的能添堵添成什么鸟样
|
 |
17
brant2ai 9 天前
@mightybruce 是的，一般的程序员可以解决公司老板、产品经理的业务上的需求，但如果有一天要解决非业务比如：让我们的访问速度更快一些？我们的北京客户要能访问上海的服务器？等等这类非需求问题。这就需要有经验的人来从更高层面处理问题。同时还能给所有人讲清楚讲明白这究竟是怎么一会事。
这些东西 都很难的。需要大量的经验 |
 |
18
yangxin0 9 天前
ppt
|
 |
20
janus77 9 天前
项目用到的在学 这句话有人说
用不到的学他干嘛 这后半句真没人说，程序员就是要不断学习的，我不信有人会对自己不懂的领域一丁点都不沾 |
 |
21
star9029 9 天前
感觉是个伪概念，大家分享的是自己对架构师的定义。架构的到底是啥，管理/技术/资源？
|
 |
22
xingheng 9 天前 2
|
 |
24
xiaobai1213 9 天前 2
一种是 解决方案架构师（ Solution Architect ）： 懂业务会吹牛逼
一种是 技术架构师 (Technical Architect) ： 懂技术选型 |
 |
25
glcolof 9 天前
我的经验是，多写大型项目，以主力的身份，完整参与几个 20 万行代码以上规模项目的实施过程（从设计到开发到后期维护），就具备担任架构师的可能性了。
|
 |
26
dododada 9 天前
我见过这种牛逼人，倒不是架构师，而是部门总监。到公司之后大概 2 年的时间，做了异地多活，两地三中心；做了服务私有化云；还做了大数据中心；
然后后面的两三年就没在公司，移民美国遥控指挥了； 属于业务+吹水+技术型的，干实事居多，当然薪水很高，我估计这个网站上拿工资的兄弟们，没有人拿到过那个钱。 |
|
27
glcolof 9 天前
很多“架构师”并不是因为公司工作而学会当“架构师”的，而是自己业余时间开发的项目，随着时间的积累，代码量不断扩大，期间随着自己技能和见识的增长而多次重构，在这个过程中对大规模软件的架构问题产生多方位多角度的认知的。
|
 |
28
murmur 9 天前
系统挂几次出几次事故，被流量打崩几次就会了
|
 |
29
kk380446 9 天前
像我们就是大项目也有中小项目居多, 平均 1 个月交付一版中小项目, 不同的项目技术选型方案也不同,几百人在线的小项目基本都是多实例单体架构, 大一点的项目 (5 位数在线用户的)优先考虑使用微服务架构; 在就是结合自己的经验根据对需求的理解 选择合适的数据存储服务, 消息中间件, 缓存服务等等, 所以 我觉得作为一名优秀的架构师至少你应该把市面上流行的技术都要了解一遍记住它们的特点能解决什么问题. 当老板安排新项目给你的时候起码你能心中有数这个项目使用哪些技术可以满足需求.
|
 |
30
chaleaochexist 9 天前 1
|
 |
31
me1onsoda 9 天前
架构师就是经验之谈，很难通过一些刻意的练习就能达成。
基本上是从 0 开始带团队成为细分领域独角兽级别能称为架构师，业务不够大，根本没有踩坑的经验。其他中小厂架构师基本是斗蛐蛐玩儿的，只能算懂点通用经验的高级程序员。 |
|
32
isno 9 天前
|
|
33
pkoukk 9 天前
架构和架构师根本就是两码事，关系就像雷锋和雷峰塔一样。
善战者无赫赫之功，你要是架构真的设计的贼牛逼，你反而成不了架构师。 做一坨狗屎架构，今天内存瓶颈，明天 IO 瓶颈，后天一致性瓶颈，全是问题，全是挑战 天天在救火，天天在解决这些看上去的业界难题，就会让你看上去技术很牛逼，很容易成为架构师 |
 |
34
yrj 9 天前
大厂出来的就一定适合做?我觉得不一定，就像御厨，一辈子只调萝卜黄瓜。例子可能极端一些，但就是这个道理，可能他在某个语言某个业务上很精深，但不一定有全局的知识。
|
 |
35
wantstark 9 天前
首先要明确架构的目的是什么；对于不同阶段、不同类型的公司以及产品，架构完全是不同的概念。
|
 |
36
ilucio 9 天前
去考高级软件架构师~
|
 |
37
huage 9 天前
你们说啥呢，我们公司的架构师：1.给领导送礼； 2.给领导拍马屁； 3.请领导吃饭； 4.代码不看； 5.架构图不出，谁要谁写； 6.技术问题各自去百度。
架构师第一位任务是要给领导提供情绪价值，技术都是其次的。 |
 |
38
securityCoding 9 天前
业务骨干+全局视角缺一不可
|
 |
39
NoKey 9 天前
主要是要能搞事，要能吹，会写 ppt
想我们这里有一个，每天访问人数 2 位数顶死的服务，硬要上能顶住万人并发的 各种系统，中间件，各类服务，搞了一大堆 用途是什么呢？ 汇报~ |
 |
40
PopRain 9 天前
说起 CURD 都是一脸不屑，问题是这个世界大部分架构在 CURD 的应用上。。。。
|
 |
41
Leon777 9 天前
99%架构师的工作已经可以被 gpt 替代了
|
 |
42
bthulu 9 天前
为什么都在吹分布式? 架构师跟分布式有毛关系啊. 难道非互联网就不用架构了? 让你做一个 CAD 绘图软件出来, 做个 OFFICE, 做个虚拟机, 分布式能架构出什么来?
|
 |
43
BBCCBB 9 天前
公司可以不用, 但你不能没有.
|
 |
44
asuka321 9 天前
首先架构师是个很模糊的概念，这和问程序员是怎么炼成的是一样的，程序员分类太多没法直接描述。
架构师大了分可以有以下几种 1. 业务架构师（对业务域进行领域抽象，做业务划分，目标是在业务快速变化的同时有良好的业务架构能支持快速迭代） 2. 系统架构师（对不同域应用间的稳定性、依赖、服务能力做抽象建设，目标提升系统稳定性、确定性，对问题/故障快速恢复、定位、应急） 3. 运维架构师（对中间件系统、云资源等做维护、冗余设计，目标是在成本限制下提升底层服务的冗余能力） 这些的要求都各不相同，你对哪块有兴趣就找对应的书籍去看看，以及找人交流，架构师非常吃经验。 |
 |
45
alansfinal 9 天前 3
作为一个呆过中小厂的人，我曾经有类似困惑，尤其找工作面试的时候，所有人都想要高并发大规模分布式系统架构经验:) 想拥有这方面经验就得去大厂核心组或者在中厂等到一个起飞的业务，但是想去这种业务的组就得先有经验，而想有经验就得去这种组...鸡生蛋蛋生鸡似乎是无解的
后来如愿进了世界级大厂但是负责边角料业务，依然无法在自身的工作中得到多少成长，于是决定自学了。把 AWS/Azure 的 well-architected framework 架构文档读一遍，一句一句读，不放过每一个细节，不懂的就去网上搜、找人问、在公司内部搜相关团队约饭约咖啡，同时把 AWS 的 Solution Architect Professional + DevOps Engineer Professional 跟 Big Data specialty 的认证考过了。这时候架构的基础知识跟产品术语就比较清楚了，但还是浮于表面。 接下来就是挑着 AWS/Azure 的架构案例去研究，像刷题一样，刚开始抄答案，再是先自己写一遍然后对比标准答案、思考差距在哪，积累到二十几个常见案例的时候基本已经能忽悠任何人了。 再最后就是实操了，这一步如果想偷懒就直接去看开源项目，尽量找那种有 Terraform 的这样方便快速看它的架构。 |
 |
46
laike9m 9 天前 via Android
“架构师”这个头衔只有在只有中国程序员圈子里才被捧得如此之高
|
 |
47
momo2789 9 天前
架构师=“更好的理解业务”
|
 |
48
lrvy 8 天前
在大厂待了多年，从 0 到 1 也做了不少核心系统/项目，说说我的理解：
1. 对全局负责。一个项目从 idea 到长短期规划、到方案设计、到交付、到运维，都要考虑清楚，并且是可落地的； 2. 解决问题能力。高并发、高吞吐、还是高 SLA 这些都要根据业务场景选择，根据场景选择对应目标，以及在可维护性、迭代速度、稳定性之间取舍最佳方案； 3. 沟通能力。实际项目中，对外要经常跨部门合作，对内要保证系统顺利迭代，不能产生矛盾； 4. 团队建设。复杂系统要多人协同开发，团队技术栈，校/社招新人培养，这些都要 care 。 |
 |
49
cust2008 8 天前
架构师=“更好的理解业务”
|
 |
50
xiaozhaoz 8 天前
架构师是一个随着对技术和业务理解的加深，技术人员自然回到的一个岗位选择。
senior engineer 如果还做技术，最终两条路，一个是深度，一个是广度。 在某个技术做的很深，最后可能会成为技术专家，类似 DE 、PE 岗位。技术专家成为公司内某方面技术的权威。 技术广了，对业务理解的更多了，最后可能成为架构师。架构师要做核心技术选型、子系统边界设计、核心模块边界设计。 所以架构师是开发人员对技术广度和业务理解更深刻后，晋升的一个岗位。 |
 |
51
tudou1514 7 天前
喷出来的
|
 |
52
Pantheoon 7 天前
上面都是从个人技能来说的,但是你会 k8s,懂网络,懂基建,就真的可以成为架构师了吗?非也,你不去负责整个项目,很难成长,但是怎么能够负责整个项目?这就涉及到最最最最核心的问题,如何和你的领导打好交道,如何让领导信任你,如果你的领导是有决策能力帮你上到架构师岗位的,使劲舔吧,如果没有能力,建议再观望几年
|
Select Language