架构师都是怎样炼成的

一直有个疑问，目前的人都是怎么提升到架构师的，或者说是如何拥有架构师的知识储备的。

都在说，项目用到的在学，用不到的学他干嘛。那岂不是就代表着，只要大厂才能产出架构师，程序员可以了解大厂程序的框架结构，这样就知道大型项目的架构，心里也有个底，后续也有参考价值。

那中小厂的程序员的，文档都不规范，架构更是能跑就行

我实在不理解在中小厂的程序员如何能成为一名架构师，连该学什么都不知道。

tool2dx

127 天前

“都在说，项目用到的在学，用不到的学他干嘛。”

这和健身加负重一个意思。只练基础的，又不上负重，不长肌肉啊。

coollest

127 天前

@tool2dx 类比确实形象

memedahui

127 天前

我建议你从两个维度来学习这架构,一个是横向,一个是纵向

Skifary

127 天前

架构建立在业务的基础上，遇到和解决的问题越多，越懂在后续重构的时候怎么搭建

memedahui

127 天前

横向:就是从用户角度,看看你自己的系统能不能承受百万用户的访问(自己折磨自己,不停的提高上线)
纵向:就是从系统扩展的角度,看看你的系统是不是易于拓展,别让系统变成无限膨胀,系统可维护行强.还要让自己系统的稳定性提高,给自己一个指标,比如系统 2 年内最多宕机 1 次
总结:不停的发现问题,正确的解决问题

chihiro2014

127 天前

极限优化自己的系统，然后形成自己的一套做事理论

pkoukk

127 天前

吹牛逼
架构师的练成主要靠吹牛逼
再精细点，你在公司发展的过程中，接了一个的系统，这个系统意外的成为了公司非常重要的一部分
这个系统你就是做成一坨狗屎，但只要他还活着，他还重要，只要你能吹，会抱大腿
你就能成架构师

sagaxu

127 天前

跟公司规模关系不大，主要看项目，WhatsApp 月活 4 亿的时候只有 50 名员工，就不需要架构了吗？
成为牛逼架构师，项目要具有一些特性，比如大流量，大数据，业务超复杂，超高实时，超低延迟等等。
其实只要负责过从 0-1 的完整项目，每个人都是架构师，无非是能解决的问题的规模不同罢了。

有些人是从项目中学习，积累经验，然后成为架构师。
有些则是工作前就已经发表过架构方面的论文了，出道就是别人一生触碰不到的高度。

lymanbernadette6

127 天前

大多数公司的架构师其实就是呆得久了，熟悉业务。
本身不一定是技术原因成为的架构师。
呆过几个公司（规模不小，大几千人的也一样）的架构师技术其实菜到抠脚。

adoal

127 天前

很多架构师都是夹狗屎

isno

127 天前

第一章《云原生技术概论》：先有认知，了解技术的发展的驱动力是什么是，看看微服务、容器、服务网格、devops 等等一系列技术解决了什么问题。对现代的分布式架构/系统有一个基本的认识。
第二章：《构建极致网络服务》，“网络请求”是架构设计的第一步，网络请求都到达不了“双活的”，“两地三中心的”，可用性“99.99999%” 的后端服务器。那这些高可用的形容词，都是“伪”的。
第三章，了解请求进入后端服务器是如何处理的。这一章相当于后续章节的前置，介绍一些高层架构设计中，需要注意的底层技术/原理。

第四章，开始进入分布式系统，主题是可扩展性，目的实现高可用，也就是介绍各类负载均衡技术。

第五章，第六章：前面章节介绍的都是无状态应用的设计。现在开始介绍“有状态应用”的设计，这里面有两个核心的主题：事务、以及共识。事务以及共识影响系统的可用性、容错设计。

第七章，第八章，是介绍容器系统相关的设计，介绍分布式系统中，容器是如何通信、调度、被管理的。但 Kubernetes 的问题是仅仅管理容器，容器内业务的通信治理也是个重要的主题。作为新一代的基础设施，容器以及服务网格的作用：是将系统中非业务逻辑全部解耦，下沉到容器、Sidecar 中。

第九章，解决了“网络请求”、高可用设计（负载均衡），数据一致性（事务、共识），应用负载（容器和服务网格）。那么整个高可用架构“设计阶段”已经解决。现在开始进入系统“运行阶段”。这个阶段要面临：大规模数据的挑战（成本和海量数据分析），系统的稳定性（监控），（各类观测数据的统一处理，标准和规范）

最后一章，是 devops 的内容，补充应用如何交付、部署。

以上，就是《深入架构原理与实践》的主题。

送给你。 https://www.thebyte.com.cn/

mightybruce

127 天前

怎么都在答非所问，架构师运用自己的经验帮团队少走弯路，其次不同团队之间的沟通，以及将技术语言转成领导能听懂的语言。

上面那几个，谁跟你说架构都是高并发，高可用，你搞高并发，高可用的场景都不匹配，那就是白白浪费钱也没有产出。

如果就是个小公司，建议从可维护性上多入手，良好的抽象可以帮助降低复杂度，并使系统易于修改和适应新的应用场景。

架构难的还不仅仅是经验，难的是人际沟通，v2ex 上参与架构的并不多。

RandomJoke

127 天前

多经历 0-1 ，多了解各个端的常用实践，了解特定业务用特定领域技术

niubilewodev

127 天前

主靠吹牛逼。
99%的公司的 99%项目，不需要什么高精尖。

GeekGao

127 天前

" 那中小厂的程序员的，文档都不规范，架构更是能跑就行我实在不理解在中小厂的程序员如何能成为一名架构师，连该学什么都不知道。"

难怪。现实是：中小厂普通码农基本没有成长为合格架构师的可能性。因为绝大部分公司的绝大多数项目都是没有什么挑战性的 CRUD 类应用。
甚至项目连等保、IPO 前合规等重要环节都遇到过。更不要说参与创造几个亿的收入的产品了…

to2false

127 天前

有时候，没有架构师可以省掉很多麻烦，遇见个菜的能添堵添成什么鸟样

brant2ai

127 天前

@mightybruce 是的，一般的程序员可以解决公司老板、产品经理的业务上的需求，但如果有一天要解决非业务比如：让我们的访问速度更快一些？我们的北京客户要能访问上海的服务器？等等这类非需求问题。这就需要有经验的人来从更高层面处理问题。同时还能给所有人讲清楚讲明白这究竟是怎么一会事。
这些东西都很难的。需要大量的经验