gitbook/面试现场/docs/86198.md

06 | 考官面对面：我们是如何面试架构师的？

你好，我是者文明，目前就职于京东，负责京东物流技术架构、创新等工作。研究生毕业后，我以一个程序员的身份混入IT圈，转眼已17年，期间参加过不少面试，也面试过不少程序员、架构师和管理者。最近7年的面试主要以架构师为主，所以想简单聊聊我面试架构师的思路。

经过多年的积累，我们构建了一套自己的架构师面试体系，包括三个部分：能力模型、面试地图和面试题库。

• 能力模型是我们对架构师的能力要求，或者说是考查的职责描述；

• 面试地图考查的是具体的知识和能力图谱；

• 面试题库是我们的宝藏，是整个架构师团队在实际工作中提炼和积累出来的，大部分都是网上找不到的。

简单来说，能力模型是指导原则，面试地图是操作手册，面试题库是我们的资产。

先说说能力模型，我们的架构师能力模型包括三个部分：一个核心两个基本能力。一个核心指的是德，这个是最基本的要求，主要包括诚信、担当和品格，两个基本能力指的是硬实力和软能力，二者的比重七三开（7:3）。

硬实力是架构师的本钱，生存技能，是能力模型中最为重要的部分，架构师一定要做到“精于此道，以此为生”，在面试过程中这部分的考查花的时间也是最多的。

一个优秀的架构师，在硬实力的基础上还需要具备软能力。前几年我还认为架构师只要技术好就行，到现在我越来越觉得架构师的软能力也非常之重要，因为架构师在研发团队中会同时扮演技术大咖和老师的角色。作为老师，你要让别人能很容易地听懂你的观点和思路，要形成技术影响力，这就需要具备较强的表达和展现能力。同时架构师在日常工作中需要和研发同学紧密协作，保证技术轨道的有序与目标达成，所以协作能力也是至关重要的。

面试地图就是供面试官参考的一个知识和技能图谱，基本涵盖了作为一个架构师需要掌握或者具备的知识和技能，主要包括基础技术能力、架构能力和发展能力。

面试是在能力模型的指导下，参考面试地图进行的。不过，我个人习惯上并不是按照能力模型一项一项去考查的，我习惯从简历开始，先让候选人做个简单介绍，然后从他最近参与的项目或者说是他认为做得最好的项目出发，让他介绍下项目情况、架构方案以及项目的技术难点和解决思路。

介绍架构方案时，我会要求他边讲边画架构图，这样做有几方面考虑：一是有助于自己理解；二是能比较好地考查他的架构理解力、逻辑性、条理性、结构化思维和表达能力；再就是有了架构图，接下来可以结合图考查更细的技术点。

了解了项目情况，又有了架构图，接下来我会围绕整个架构方案，结合我们的面试地图一块一块深入挖掘了解候选人的技术能力。

先从OSI模型的应用层开始，通过负载均衡方案考查他对CDN、DNS、VIP、HTTP、LVS、HAProxy、Keepalived、Apache、Nginx的理解和熟练程度，中间也可以穿插问几个技术细节来考查他的理解深度，比如Nginx高并发的技术原理、Nginx和LVS分别工作在TCP/IP协议栈的第几层，等等。

接下来可以根据各功能模块展开考查Java基础技术。Java基础技术涉及面就广了，每次面试中不可能面面俱到，但是一些关键技术点必须考查，比如容器、JVM、数据结构、序列化、异常处理、Socket、多线程/并发、NIO等等。在Java体系中，JVM是最基础也是最重要的考查点，我们的系统最常出现的OOM异常都跟JVM有关，架构师必须深入了解JVM的内存模型、字节码、垃圾回收（GC）策略等原理，才能去优化JVM相关的性能问题，才能快速定位OOM类异常。除了Java基础技术，常用框架和相关概念也是需要考查的，比如Spring、SpringMVC、Mybatis、ORM、IOC/DI、AOP等。

以上提到的Java基础和常用框架都是实现层面的技术，接下来要结合候选人提到的某个功能模块，考查他在面向对象上的设计能力和建模能力。面向对象设计主要考查的是设计思想。类与类之间的关系是我比较喜欢问的，因为这是最基本的概念，如果他对这些概念都很清楚，我会追问聚合和组合的区别，一般能答上来的都是对面向对象理解比较深入的。

有了面向对象的概念和思想，还可以结合候选人的项目，让他详细说说某个功能模块的设计，画画UML设计图，这样能考查他对面向对象的理解程度和领域建模能力。领域建模能力对于架构师而言至关重要，业务域抽象得是否合理，是否高内聚，领域边界是否清晰，这些都是影响系统可扩展能力的关键要素。除了这些，我也会结合项目考查几个比较常用的设计模式，比如单例模式、工厂模式、策略模式、模板模式，等等。

以上都是基于应用层展开的一些技术点，接下来可以围绕存储层去展开。存储层主要考查存储架构、数据库选型、数据库调优等。存储架构要看候选人是否能根据系统的并发量和数据量的需求设计适当的存储架构，是否需要做数据库分片，分片的原则和技术方案，是否需要引入KV引擎，是否需要做读写分离，是否需要做缓存，缓存需要做几层等等，这些都是基本的存储架构问题。

数据库选型也是和具体的数据量和并发量有关，是用关系型数据库还是用KV引擎，还是要二者结合，等等。考虑到我们的系统大多还需要强依赖关系型数据库，所以一般都会考查一些关系型数据库的基础技术点，比如MySQL的架构、存储引擎、索引的数据结构、事务隔离级别、索引最左前缀原则等。

还有就是要考查一些数据库端的性能优化技巧，比如Explain的用法、索引优化、SQL语法优化、参数配置优化、数据模型优化、缓存优化等等。

**在我们的架构师能力模型中，除了基础技术能力，还包括架构理解和发展能力部分。**架构理解部分也是有别于程序员的部分，这部分可以根据候选人提供的架构方案，重点考查高并发和高可用设计、服务设计、服务治理、缓存设计等方面。

系统的高并发设计涉及系统的应用层、存储层和网络层。从网络IO到数据库IO、数据库服务器的负载，CPU和内存使用情况，再到应用层的负载均衡、反向代理、缓存、事务和锁、并发防重，以及应用服务器的负载，CPU和内存使用情况等等，都是高并发设计的知识点。

高可用设计方面，重点考查他对负载均衡、SOA、微服务、服务治理的理解，所设计的服务接口其粒度、依赖、位置是否合理，服务是否设计了分组、动态管理、限流、降级和监控，整个架构方案中各模块之间的强依赖是否有降级方案等。

上面关于硬实力部分的考查，都是基于候选人的架构方案去展开挖掘的，所有的关键技术点都是随着方案的展开一点点带出来的。在整个过程中，我们可以通过候选人对一些开源组件的理解程度判断其对技术的热爱程度，一般对技术敏感、挚爱且有追求的架构师往往喜欢研究开源技术，时刻关注新技术并去实践，有的还会持续为开源社区贡献代码，这样的架构师是我们所喜爱的。

此外，优秀的架构师应有自己的时间任务管理心得，懂得识别风险、控制范围、估算时间和成本、把控质量，以及擅长多任务并发的管理与执行。

最后，架构师还需要有一个清晰的自我认知和职业规划，十分清楚地认识到自己的优势和不足，能充分发挥自身优势，不断补齐不足，知道自己追求的“和”不那么重要的，认识到为了达成目标的关键路径应该如何管理。

聊了这么多，能力模型中的软能力和核心部分还未提及。其实在以上面试过程中，候选人的沟通、表达能力基本上已经能判断出来，在他描述方案和回答提问的过程中，逻辑是否清晰，思路是否闭环，结构化思维是否完整，根据这些基本能判断出来。

对于协作能力，我一般会设计一些场景让候选人回答，比如他自己所负责的线上系统出现故障之后作为架构师应该如何处理，性能测试团队测试出系统某功能性能无法满足需求该如何处理，等等。面对这样的问题，对于有协作精神、有担当的架构师，一定会回答主动去分析原因，分析原因过程中主动协同开发和测试同学，找到原因之后设计出解决方案，并指导开发同学实施落地，最终从根本上解决问题，而不是将问题甩给开发或者测试。

**最后要回归到能力模型中的核心：诚信、担当、品格。在我看来，这是本质，硬实力和软能力再好，没有核心也是达不到我们的要求的。**任何一个人，品格有问题，工作一定好不了。对于核心的考查在面试过程中捎带就考查了，比如当问到一个候选人不是很了解的技术点时，如果是支支吾吾，想方设法找各种理由，那我认为他在诚信上是存在问题的，我更喜欢不懂就不装懂，坦诚、谦虚的人。对于品格，可以从候选人的言谈、举止，或者一些细节之处窥得一斑，也可以通过HR面试等环节得到补充。

好了，总结一下今天的内容。这篇文章中，我主要从自己最近几年来的工作经验出发，和你聊了聊我们面试架构师的一些思路。我们在面试过程中构建了一套自己的架构师面试体系，包括能力模型、面试地图和面试题库这三个部分，然后我又分别深入讲解了面试架构师时的一些考查项和考查思路。希望今天的文章能够给你一些启发，也欢迎把它分享给你的朋友，一起探讨。