在软件开发圈，“架构师”是一个受万人追捧的头衔，架构师给人的感觉是站在软件系统后面指点江山的诸葛亮，一个系统的如何运作、运作得如何，架构师都能提前设想出来，重构系统的时候，架构师也能像军师一样作出各种策略，并最终决策，在最低风险和损失的情况下让系统重生。

想当架构师的开发就像想当将军的士兵一样，多。不管具体负责软件工程中的哪一个环节，运维、测试、DBA，还是实际写业务逻辑的一线工程师或者其它，大家都热衷于谈论“软件架构”；并且不论是刚接触开发的大学生还是经验丰富的开发者，都会思考“如何才能成长为一名合格的架构师？”

对于系统该怎么去架构、负责设计软件架构的架构师职责是什么、需要些什么能力等这些具体的问题，大多数开发者是困惑的，并且多半也无从着手去体会。

基于此，我们策划了一期“技术人员如何成长为架构师？”的线上问答，邀请了专家与大家进行交流，并整理出此文，希望给读者一些启发。

嘉宾是李运华，互联网资深技术专家，专注于系统分析、架构设计等领域，对互联网技术的特点和发展趋势有较深入的研究，在系统解耦、高性能与高可用架构方面有丰富的经验。

架构与架构师

软件架构是什么？

李运华：架构是指系统顶层结构，架构设计主要是为了设计方案解决系统的复杂性。

架构是考虑得粗放一些，还是细致一些？

李运华：架构本身的定义是“系统的顶层结构”，系统有大有小，系统越小，架构师对技术深度会关注越多；系统越大，架构师对技术广度关注越多。

多大的项目才需要考虑架构呢？

李运华：任何系统都需要考虑架构设计，系统大小只是决定架构本身的复杂程度不同而已。

架构师与技术总监的区别是什么？

李运华：架构师主要关注业务和技术，技术总监关注团队、技术、业务。技术这部分可能更多依赖架构师。

架构师的日常职责，除了项目初始的需要，后续在项目中扮演的角色是什么？

李运华：架构师通常只在架构初创或者架构重构的时候参与项目，日常的功能开发不需要参与太多，基本参与评审即可，防止开发同学不小心破坏了架构的一致性和完整性。

架构师有偏向么，比如我们业务是 WAF/IDS 类型，对于云、大数据这方面就没怎么接触到。也就是说如果想成为一名架构师，是否需要涉及到所有的技术方向，还是说针对某一类型的业务架构即可？

李运华：有偏向。架构师也是和领域相关的，不同领域有不同的复杂度和模式，例如业务架构师、中间件架构师、大数据架构师、Windows 也有架构师。跨领域不是说不可能，但难度很大，可以先成为某个领域厉害的架构师。

是不是也有运维架构师？

李运华：是的，运维也有架构师。

APP 开发如何转型架构师？

李运华：APP 也有架构，可以尝试做 APP 架构师。但 APP 架构师不要局限于 Android 或者 iOS，而是要从用户体验的角度来设计 APP，涵盖 Android、H5、人工智能与 AR 等。
架构的相关概念与架构师的职责，通过上边几个回合的问答，可以有一些初步的了解。而另一个更为切实的问题是：需要哪些能力才能匹配“架构”的工作，当一名架构师？

关于这个问题，李运华有一个概括。他认为架构师的能力主要包含三部分：判断力、执行力与创新力。

李运华解释，判断力是指能够准确判断系统的复杂度在哪里，执行力是能够使用合适的方案解决复杂度问题，创新力是指创造新的解决方案去解决复杂度问题的能力。

而这三种能力从哪里来？他认为主要来源于经验、视野和思考。

经验：设计过的系统数量、系统的复杂程度，都影响着架构师的成长。这其中不管架构是成功了还是失败了，不管是踩坑还是填坑，这些经验都将成为架构师能力的一部分。

视野：掌握的知识和技能越多、越深，架构师的能力也就越强。

思考：经验和视野都是外部输入，但是输入不进行有效的转化并没有太大意义，而转化输入就需要架构师的思考。思考能够将经验和视野中的模式、判断、选择与技巧等提炼出来，化为自己的能力并运用到不同场合，同时它也促使产生新的创意和灵感。

再进一步具体到开发人员要学习哪些技能、如何学习才能成为架构师，下边李运华也都一一作了回复。

架构师需要的能力

对源码层面没有深入研究能成为架构师吗？

李运华：最好还是要研究源码，因为架构师不能简单地只负责画图，还要把握关键技术的实现，否则就会成“PPT架构师”。

需要具备很强的源码能力吗?

李运华：很强不一定，但至少要知道关键的技术如何实现的，例如 Redis 的快照在代码层面的实现其实关键就是 fork 和 COW 技术。

如何学习源码呢？

首先，需要树立正确的观念：不管你是什么身份，都可以从开源项目中学到很多东西。

例如，要理解 Redis 的网络模型，我们不需要成为 Redis 的开发者，也不需要一定要用到 Redis，只要具备一定的网络编程基础，再通过阅读 Redis 的源码，都可以学习 Redis 这种单进程的 Reactor 模型。

其次，不要只盯着数据结构和算法，事实上这两点在学习开源项目的时候并没有那么重要。

例如，Nginx 使用红黑树来管理定时器，对于绝大部分人来说，只要知道这点就够了，并不需要去研究 Nginx 实现红黑树的源码是如何写的，除非你需要修改这部分，但我认为极少人会有这个需求。

第三，采取自顶向下的学习方法，源码不是第一步，而是最后一步。

不要一上来就去看源码，而是要基本掌握了功能、原理、关键设计之后再去看源码，看源码的主要目的是为了学习其代码的写法，以及关键技术的实现。

例如，Redis 的 RDB 持久化模式“会将当前内存中的数据库快照保存到磁盘文件中”，那这里所谓的“数据库快照”到底是怎么做的呢？在 Linux 平台上其实就是 fork 一个子进程来保存就可以了；那为何 fork 子进程就生成了数据库快照了呢？这又和 Linux 的父子进程机制以及 copy-on-write 技术相关了。

通过这种方式，既能够快速掌握系统设计的关键点（Redis 的 RDB 模式），又能够掌握具体的编程技巧（内存快照）。

成为一名架构师需要对技术细节了解到什么程度？

李运华：需要掌握关键的技术原理和优缺点，例如 JVM、epoll、CAP、BASE 与 Paxos 等。

架构师需要了解到多底层，一定需要具有开发中间件的能力么？

李运华：不一定必须开发中间件，中间件主要的复杂性是高性能和高可用，业务系统最主要的复杂性是可扩展，但如果有中间件的经验当然更好了。简单来说，如果什么系统你都能应对自如，那就说明架构设计的水平很高。

架构师是不是除了了解业务和设计架构、搭建架构之外，还得懂得开发，从前端到维护到架构搭建到架构维护都得会？

李运华：架构师都是从开发做上来的，但并不需要样样精通，如果你是后端架构师，只需要大概了解前端的基本原理就差不多了；如果你是设计整体架构包括前后端，那就要求对前端也有一定深度的了解。

作为一名学生，如果未来想要成为一名架构师，有什么是可以先准备的么？

李运华：把学校的基础课程学好：操作系统、数据库、网络、软件工程、编程语言、算法和数据结构等。

架构师需不需要运维方面的知识？

李运华：需要一定程度的运维知识，包括：中国的网络基本布局（例如三大运营商）、CDN、机房的基本情况（交换机、供电与散热等）与架构的基本物理结构等。

做架构大致都需要了解哪些方面的内容？

李运华：这个问题有点大，我只能提炼几个关键点：1）领域知识；2）基础技术；3）架构设计的技术；4）综合能力：沟通、表达与项目管理等。

近几年来小游戏很火，请问实时对战类游戏构架需要了解哪些知识点？如果从 Java、NodeJS 和 Python 中选择您推荐使用哪种呢？

李运华：推荐 Node + Java，Java 负责后端，Node 负责与游戏交互。关键架构包含几部分：玩家匹配、平台与游戏交互、游戏引擎。

应该赋予架构师什么样的职责？因为碰到过架构师和部门 leader 分工，导致架构师不能深入业务，研究出的东西，业务小组也不愿执行，最终成了摆设。

李运华：架构师不能脱离业务谈技术，例如同样做电商，不能说把淘宝的架构搬过来就了事，而需要根据自己公司的电商特点和业务规模等设计合理的架构。

架构师是否需要精通多种技术语言？

李运华：不同架构师要求不一样，例如数据库架构师可能并不需要掌握多种语言，业务系统架构师就最好熟悉多种语言。

现在互联网公司基本都在使用敏捷，需求都是小步迭代。在这种情况下架构师还有必要学习 UML 吗？

李运华：如果架构师 UML 都不懂，很难跟开发人员交流呀。
此外，问答中还有一些在架构设计中需要关注的问题：

架构设计值得关注的点

对于接手的 n 手项目，怎么搞架构？

李运华：先搞清楚再做决定，不要上来就觉得这里垃圾那里不行，很多时候是我们不熟悉各种坑爹的历史情况 ：）

对于”善变”的产品规划，架构该怎么应对?

李运华：设计可扩展的系统架构。

做架构设计的时候，往往要考虑高内聚低耦合，但是高内聚就意味着高耦合，低耦合就意味着低内聚。这就矛盾了，难道只能满足其中的一种吗？请问如何解决这种问题？

李运华：高内聚和低耦合本身其实是一个平衡的问题，有四种模式：

高内聚高耦合：例如一个类只有一个方法，内聚非常高，但同时类之间的耦合也会非常高
低内聚低耦合：例如所有方法都在一个类里面，就不存在耦合了，但这样的类也没法用
高内聚低耦合：同时做到高内聚和低耦合，理想形式
低内聚高耦合：设计灾难
在我的第一本书《面向对象葵花宝典》中有深入的探讨，简单来说就是需要在内聚和耦合中找到平衡。

一些开源软件对于消息重复消费和一致性等问题都是直接跳过去不进行处理，但是这些部分才是最为关键的，而公司也没有真实的项目可以去练习，那就根本无法体会到真实的场景，可以怎么办呢？

李运华：找文档齐全的优秀开源项目学习，例如 Kafka 就写了它的具体实现：

https://kafka.apache.org/documentation/#design。
还有 Disruptor 的设计文档：

https://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf

架构这个事情是否需要很多一线开发的经验？例如我可以从书中学习架构的方法躲避坑，而不用特别在一线开发体验。

李运华：不能完全靠书，也不能完全靠踩坑，知行合一吧。