第13课:架构师面试题分析

第13课:架构师面试题分析

架构师面试技巧

本课程结合我多年的架构师面试和被面试经验,总结三条最核心的架构师面试技巧,分别是原理、引导和自圆其说。

  • 原理

对于面试而言,原理是关键。在现实开发过程中,我们用到的是实践技能,但面试则完全不一样。很多实践技能很难通过面试的方式展现出来,大多数公司面试的内容会比较偏向与理论和原理分析,这点在大型公司的面试过程中表现的尤为明显。实际上,当你进入很多大型公司之后,你会发现你所具备的实践技能是足够应对工作内容的,但前提是你能够进得去这些公司,这就需要我们从原理性的内容入手把握各项知识体系、工具和框架的本质。

  • 引导

面试是一个互动的过程,架构师在面试过程中千万不能演变成单向的、被动应答式的过程,这就需要架构师有一定的引导技巧。当面试官抛出问题时,如果有比较明确的回答思路,那就往自己的思路上引导,引导面试官朝自己擅长的领域去发问。如果自己的思路不清晰,则应该尽快切换话题。

  • 自圆其说

自圆其说是面试的最终技巧。自圆其说表现在很多方面,首先体现在简历上。对于简历而言,为了突出自身的卖点,做一些包装无可厚非,但切忌把自己都说不清楚的内容放到简历上,这样一旦面试官的风格是按照简历的内容来提问,那么效果只会适得其反。其次,面试的过程是一个高压力、高强度的过程,难免会紧张。如果引导的不好,可能会面对很多自己并不擅长的内容,这个时候我们就要充分发挥在第10篇《论技术体系的相通性》中提到的技术体系相通性,把已经掌握的知识点应用到未知的领域中去,做到自圆其说。

本篇接下来的内容重点是我在阿里、网易、滴滴、蘑菇街、贝贝网等国内大型互联网架构师岗位的面试之后对面试过程进行总结和思考的一些经验,这些面试题包括技术架构和技术管理两大部分。我们对面试题的分析也将包括两个维度,即:

  • 关键思路

对于每道面试题而言,我们认为每个架构师都应该有自己的解题思路。同一个知识点、同一个工具或框架在不同公司的问法可能是不一样的,但把握其中的基本原理都是回答问题的切入点。当我们对问题的原理有了明确的认识,就可以梳理自己的思路,也就能达到前面提到的“自圆其说”的面试效果。

  • 参考内容

在部分面试题中,我们会给出该面试题与本课程其他文章中所介绍内容的相关性,从而方便读者对本课程做全方位的贯穿性学习。

架构师技术架构面试题分析

1. 微服务架构基本理念和原则,为什么会在团队中使用微服务架构,实行微服务架构过程中碰到的问题及其解决方案。

关键思路

对于微服务架构而言,服务建模、服务拆分和服务集成是基本的设计理念,而 RPC、RESTful、API 网关、分布式配置中心等基础组件以及服务可用性和数据最终一致性等关键要素也是重点内容。至于引入微服务架构的原因和碰到的困难,团队业务发展特点和组织架构、微服务粒度和边界等都是回答该问题的切入点。为了实现微服务架构,我们可以引入 Spring Cloud 等相对完善的技术实现体系,也可以使用 Dubbo 作为我们的基础微服务架构。

参考内容

微服务架构设计是一个非常综合的概念,本课程中的很多内容都可以作为参考,包括第4篇《领域建模——架构设计的第一步(上)》、第5篇《领域建模——架构设计的第一步(下)》、第6篇《RPC——一切架构的基础》、第7篇《分布式服务架构——最核心的架构》和第8篇《微服务——最热门的架构》。

2. RPC 的概念及其包含的核心组件和主流实现技术,如何实现一个自定义的 RPC 框架。

关键思路

该面试题相对容易回答,RPC 是分布式系统的基础,从思路上我们应该理解它是由网络通信、序列化、传输协议、服务调用等组件所构成。同时,对业界主流 RPC 的实现技术也要有足够的了解,如 Alibaba Dubbo、Google gRPC、Facebook Thrift 等。

参考内容

本课程的第6篇《RPC——一切架构的基础》对 RPC 架构做了详细介绍,在第10篇《论技术体系的相通性》中也提交了 RPC 架构在 Hadoop 中的应用。

3. Dubbo 框架的原理和设计架构,涉及协议、内部基础框架、SPI 扩展性原理等。

关键思路

Dubbo 是目前非常流行的分布式服务框架,也是架构师面试的常见内容。对于 Dubbo 而言,从设计原理上,我们需要掌握微内核架构和 SPI 这两项内容,并能够对 Dubbo 整体架构和实现原理做到自圆其说。这些内容相对都比较明确和固定,只要事先做好准备,基本没有问题。

参考内容

本课程中没有对 Dubbo 做专门的讨论,但第6篇《RPC——一切架构的基础》和第7篇《分布式服务架构——最核心的架构》都与 Dubbo 关系密切。读者也可以参考本课程的配套书籍《系统架构设计--程序员向架构师转型之路》,在该书中对 Dubbo 的实现原理有详细的分析。

4. Zookeeper 的用途和主要应用场景,基本结构和组件,Leader 选举的过程和实现算法,分布式锁的实现方案。

关键思路

Zookeeper 的定位是一种分布式协调工具,在分布式系统中应用非常广泛。Zookeeper 基本概念和用法、Zxid、临时节点、Watcher 机制等是常见的面试点。同时,我们也要掌握分布式协调机制、配置管理、分布式锁等具体应用的场景以及实现方式。最后,实现 Leader 选举过程的 Zab 协议以及其中的各个角色和过程也是面试重点。

参考内容

关于 Zookeeper 的基本概念和典型应用可以参考第10篇《论技术体系的相通性》中内容,我们基于技术体系的相通性对 Zookeeper 的应用列举了几个典型场景并给出了示例。

5. NIO、AIO 等相关概念,Reactor 模式的原理,操作系统实现 Reactor 模式的各种技术以及各自的优缺点,Netty 等主流 NIO 框架的基本架构。

关键思路

对于 IO 模型而言,重点要掌握各种 IO 模型基本理论、操作系统多路复用以及 Reactor 模式。这些内容一般也偏向与固定而明确的解法,面试过程相对也比较容易把握。

参考内容

我们在第6篇《RPC——一切架构的基础》中提交了各种 IO 模型。在第10篇《论技术体系的相通性》中稍微提到了 Reactor 模型,关于 Reactor 模型以及其他常见的架构风格和架构模式也可以参考《系统架构设计--程序员向架构师转型之路》

6. 使用过的消息中间件介绍,涉及 JMS 规范,场景,集群等,主流几种 MOM 如 ActiveMQ、Kafka、RocketMQ 的比较,Zero-Copy 等细节问题。

关键思路

对于消息中间件,我们首先需要明确消息中间件的各项需求,比如 At Least Once、At Most Once、Exactly Once 等消息传递语义以及顺序消费、消费者幂等性等场景性需求。其次,对于主流的几种消息传递规范以及这些规范的基本原理都是面试的常见切入点,JMS 规范和 AMQP 规范是主流的消息中间件规范。最后,针对这些规范,我们也需要了解各种代表性的实现方式以及各个实现方式下的细节。该面试题涉及面可以很广,从“引导”和“自圆其说”的面试技巧上讲,我们重点突破一种消息中间件,这里给出的建议是 Kafka。尽管 Kafka 没有遵循特定的规范,但很多设计理念和思想都是很不错的,比方说默认情况下 Kafka 实现了 At Least Once 的消息传递语义并提供了 High Level Consumer 和 Low Level Consumer 两种消费者,可以通过 Low Level Consumer 手工控制消费 Offset 来实现 Exactly Once。至于 Zero-Copy等细节问题需要大家在平时进行积累。

参考内容

关于消息传递系统可以参考第9篇《消息传递:可解耦的架构》,当然还需要大家参考相关资料做进一步了解。

7. 缓存系统,Memcached 和 Redis 的选型和特性比较,针对 Redis 的业务场景数据结构建模,lazy-expiration 等细节问题。

关键思路

缓存相关的面试题重点在于几个缓存工具的特性和核心用法。比方说 Redis 和 Memcached,这两种工具在数据结构、内部架构和实现原理上存在较大差异,尤其是它们完全不同的分布式架构。这类面试题相对也比较明确,但需要预防一些比较冷门的知识点,比方说题中的用于处理过期键的 lazy-expiration 以及类似于 Gossip 协议这样的分布式集群构建方法。

参考内容

在第10篇中我们提到了 Gossip 协议,而其他关于缓存的讨论可以参考《系统架构设计--程序员向架构师转型之路》

8. NoSQL 几种模式和代表性实现技术,批量离线数据处理,实时流式数据处理的基本思路。

关键思路

NoSQL 相关内容经常被提起,主要包括 NoSQL 的几种分类以及代表性的实现技术。这块内容和大数据知识体系有较大关联,而像 Elastic Search 这样的垂直化搜索引擎的内容也属于这一范畴。从思路上讲,如果我们碰到以前没有接触过的 NoSQL 工具和框架,可以从集群、分片、复制等 NoSQL 的基本需求和特征出发进行引申。另一方面,NoSQL 与大数据处理关系密切,面试过程中需要架构师对批量处理、流式处理有一定的了解。

参考内容

关于 Redis 和 Memcached 参考上题,其他关于 NoSQL 的更多讨论以及批量处理的方式和工具同样可以参考《系统架构设计--程序员向架构师转型之路》

9. CAP 理论/BASE 思想的含义以及在分布式系统设计中的具体体现。

关键思路

CAP 理论和 BASE 思想是比较典型的纯理论型面试题,主要考察架构师对分布式设计理论的掌握。这方面的概念和思想相对也比较明确,需要架构师在理解概念的基础上能够用自己的语言和案例对它们进行包装,从而形成自己的方法论。CAP 理论/BASE 思想在应用上主要体现为分布式环境下的数据最终一致性,关于如何实现最终一致性的设计模式也需要有一定的了解,如常见的可靠事件模式、补偿模式、TCC 模式和最大努力通知模式等。

参考内容

关于 CAP 理论和 BASE 思想本课程中没有具体展开,大家可以参考我刚出版的另一本书籍:《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

10. 高并发场景的应对思路和技术。

关键思路

对于架构设计而言高并发是一个常见问题,一般也有很多可以展开的地方,比方说拆分和服务化、集群、消息队列、缓存、并行化计算等都是合理的解答内容。从解答思路上讲,这个问题的难点在于形成一套比较完整的知识体系,并且能够以自身的经历和实践作为辅助。很多人在面试过程中可能缺少实践和案例,那么就需要在面试之前做比较多的准备工作,确保能够做到“自圆其说”。

参考内容

本课程中的第6篇《RPC——一切架构的基础》、第7篇《分布式服务架构——最核心的架构》、第8篇《微服务——最热门的架构》、第9篇《消息传递——可解耦的架构》和第10篇《论技术体系的相通性》中的内容或多或少都与高并发相关,其他诸如缓存、高性能服务器等内容可以参考《系统架构设计--程序员向架构师转型之路》

11. 服务高可用性设计思路和实现方案。

关键思路

对于服务提供者而言,如果一旦自身服务发生错误,那么应该快速返回合理的处理结果;对于服务消费者而言,则重点关注不要被服务提供者所产生的错误影响到自身服务的可用性,这是服务高可用性的设计思路。而从实现手段上讲,服务的高可用性可以采用超时和重试、集群容错、服务隔离、服务降级和服务限流等五大策略。如果能够把这些设计思想和实现策略都能理清楚,那这个问题还是比较容易回答的。

参考内容

在第7篇《分布式服务架构——最核心的架构》和第8篇《微服务——最热门的架构》中提到了一部分关于集群方面的内容,而第9篇《消息传递——可解耦的架构》中的消息中间件解耦也是实现服务可用性的一种思路。更多关于服务可用性方面的讨论可参考:《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

12. HTTPS 和 OAuth 协议的特点和工作流程。

关键思路

关于安全性,一般会考察加密、认证、授权等通用安全性技术,其中安全性协议是重点。这里列举了两个主要的安全性协议 HTTPS 和 OAuth,一方面这些协议都需要依赖加密、认证、授权等通用安全性技术,另一方面每个协议有其明显的特征和应用场景,这些特征和应用场景往往是面试时问的比较多的地方。例如对于 HTTPS 协议重点关注该协议的工作流程,而对于 OAuth 协议在关注工作流程的同时还需要明确各种授权方式的运行机制。

参考内容

关于安全性的更多讨论可以参考《系统架构设计--程序员向架构师转型之路》中的相关内容。

13. 列举 Spring Cloud 的核心组件和基本实现原理。

关键思路

Spring Cloud 是微服务架构的代表性实现框架,涉及基础框架 Spring Boot、Spring Cloud Netflix Eureka 与服务治理、Spring Cloud Netflix Ribbon 与负载均衡、Spring Cloud Netflix Hystrix 与服务容错、Spring Cloud Netflix Zuul 与 API 网关、Spring Cloud Config 与配置中心等诸多内容。在面试过程中,面试官的主要切入点还是围绕这些框架的原理进行展开,所以还是需要对服务治理、负载均衡、服务容错、分布式配置等基础性概念有足够的认识,然后再与 Spring Cloud 进行整合。

参考内容

第8篇《微服务——最热门的架构》简要介绍了 Spring Cloud 框架,Spring Cloud 中的很多内容实际上与分布式服务框架都是一致的,所以第6篇《RPC——一切架构的基础》和第7篇《分布式服务架构——最核心的架构》也可以做一定参考。更多内容推荐大家一本书:《Spring Cloud 微服务实战》。我目前也正在写一本关于微服务设计和架构方面的书籍,敬请期待。

架构师技术管理面试题分析

现在越来越多的公司把架构师定位为一名技术管理者,在面试过程中也会抛出很多技术管理方面的话题。由于篇幅有限,关于架构师技术管理方面的内容本课程讨论的不多,但我对这块内容做了非常多的总结和探讨,并出版了新书《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》。在本篇中,我们将列举几个典型的技术管理方面的面试题,供大家参考。

1.团队建设方面:如团队规模如何规划,团队成员构成方式,绩效相关工作的开展等。

关键思路

从组织管理角度讲,团队建设属于向下管理的范畴。首先,架构师可以从团队组织结构、工作分析、选择人员、培训人员等角度出发展开这一话题,这是比较容易的一个切入点。其次,需要展现架构师自身的领导力和激励能力,这里面可以提到马斯洛需求层次理论、麦格雷戈的 X-Y 理论、赫茨伯格的双因素理论等主流的激励理论,并结合一定的案例展示自己对团队成员成长和管理上的具体措施。最后,可以结合平时与 HRBP 这边的协作简要介绍绩效管理的要点和实践方法。

参考内容

本课程第12篇《架构师的软能力模型》中提到了部分向下管理的内容,关于向下管理的各个方面的详细讨论请读者参考《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

2.研发过程管理方面:过程资产建设的含义和实践方式,如何应用工具和流程进行研发知识分享和积累,如何开展 Code Review 和重构等。

关键思路

研发过程体系建设是一个非常大的主题,一方面需要对目前主流的研发过程管理方法论有明确的认识,另一方面对具体如何应用这些方法论要有裁剪的意识。敏捷方法是当下流行的过程方法论,但敏捷中也有很多派系,例如 Scrum 与过程管理、精益与消除浪费、看板方法与流程管理、极限编程与工程实践等。同时,过程管理很大程度上要实施过程改进,那么就需要对传统CMMI中的过程改进以及敏捷中的过程改进都有一定的了解。最后,作为技术管理者通常还需要开展过程资产建设、过程裁剪以及建设符合自身团队的轻量级过程模型。

参考内容

关于研发过程体系建设在第11篇《架构设计中的系统工程》中有一定的介绍,更多关于敏捷方法论、过程改进和过程裁剪等研发过程管理各个方面的讨论请读者参考《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

3.主流方法论方面:对 Scrum、XP、CMMI、PMP、IPD 等研发过程及其改进模型的认识以及应用情况。

关键思路

主流技术管理方法论包括很多分类,每个分类的关注点有所不同,例如 Scrum 和 XP 属于敏捷方法论,CMMI 是一种过程改进模型,PMP 关注于项目管理,而 IPD 则适合与大型团队的产品研发过程。一般在架构师面试中,这些方法论都不会问的太深,主要还是考察基本的概念,如果在基本概念的基础上能够辅助一些具体的案例那基本上就不会有什么问题。

参考内容

关于各种主流技术管理方法论的讨论请读者参考《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

4.项目和产品管理方面:项目生命周期管理,项目和产品的规划和演进过程把控,结合主流方法论进行实施过程中的裁剪等。

关键思路

项目管理同样范围很广,针对架构师工作而言,常见的项目管理维度包括需求管理、计划管理、质量管理、风险管理、交付管理等。这些维度一方面可以是考察项目管理的核心理念,另一方面也会与技术因素进行结合。有些维度比较通用,但有些维度还是要体现出架构师自身一定的理解和实践能力,例如交付管理就需要结合具体的工具、框架以及设计合理的工作流程。

参考内容

关于项目管理在第11篇《架构设计中的系统工程》中有一定的介绍,关于项目管理的更多内容请读者参考《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

5. 个人总结方面:对组织级别的贡献,主导某件事情的过程和体会,个人管理风格、优势劣势分析等。

关键思路

从组织管理角度讲,个人总结属于个人管理的范畴,这也是架构师经常忽略的一个管理维度。个人管理首先体现在个人风格的建设上,可以从 DISC 模型出发探讨如何进行个人分析。更常见的问法是考察架构师处理事情的方式方法,对如何安排事情的优先级、如何进行时间管理、如何开展沟通管理等方面可做进一步展开。

参考内容

关于个人管理在第12篇《架构师的软能力模型》中有一定的介绍,更多关于个人管理的讨论请读者参考《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》

上一篇
下一篇
目录