架构师都是怎样炼成的

[KJH]

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

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

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

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

[tool2dx]

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

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

[coollest]

@tool2dx 类比确实形象

[memedahui]

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

[Skifary]

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

[memedahui]

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

[chihiro2014]

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

[pkoukk]

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

[sagaxu]

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

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

[lymanbernadette6]

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

[adoal]

很多架构师都是夹狗屎

[isno]

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

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

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

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

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

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


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

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

[mightybruce]

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

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

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

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

[RandomJoke]

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

[niubilewodev]

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

[GeekGao]

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

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

[to2false]

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

[brant2ai]

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

[yangxin0]

ppt

[azhong123]

@pkoukk 这才是真话,

[janus77]

项目用到的在学 这句话有人说
用不到的学他干嘛 这后半句真没人说，程序员就是要不断学习的，我不信有人会对自己不懂的领域一丁点都不沾