架构设计面试经验总结

文章收录在网站：http://hardyfish.top/

在这里插入图片描述

学习架构设计知识的思路总结为以下几点：

想要学习架构设计知识，可以从自己熟知的领域出发，这样你才有不断的正反馈，从而更有信心，容易理解新的知识。

形成知识网络图谱：

如今技术错综复杂，各种技术又相互耦合，确实无法简单划分层次，建议你把自己的核心知识梳理出一个脉络清晰的结构图。
然后结合已有知识，再逐步将零散的知识点补充到这张网络图谱之上，这样你就拥有了核心知识和扩展知识。

养成对技术判断力：

针对同一问题有不同方法，不同维度、不同角度的分析和对比。
这是为了提升你今后在工作中对技术的领悟力。

分布式理论

CAP分布式理论

在分布式系统中，由于网络问题导致的网络分区是常态。

也就是说出现网络分区时，根据 CAP 理论，需要在 A 和 C 中进行取舍，即要么保证系统的可用性，要么保证数据一致性。

但实际情况是，在绝大多数时间里并不存在网络分区（网络不会经常出现问题）。

那么还要进行三选二吗（CP 或者 AP）？

其实，不同的分布式系统要根据业务场景和业务需求在 CAP 三者中进行权衡。

CAP 理论用于指导在系统设计时需要衡量的因素，而非进行绝对地选择。

当网络没有出现分区时，CAP 理论并没有给出衡量 A 和 C 的因素。

但如果做过实际的分布式系统设计，一定会发现系统数据同步的时延（Latency）。

此时就不会有绝对的 AP 模型还是 CP 模型了，而是源于对实际业务场景的综合考量。

BASE理论

BASE 是 Basically Available（基本可用）、Soft State（软状态）和 Eventually Consistent（最终一致性）。

作用是保证系统的可用性，然后通过最终一致性来代替强一致性，它是目前分布式系统设计中最具指导意义的经验总结。

BASE 中的基本可用指的是保障核心功能的基本可用，比如：

服务降级：
电商网站在双十一大促等访问压力较大的时候，关闭商品排行榜等次要功能的展示，从而保证商品交易主流程的可用性

流量削峰：
为了错开双十一高峰期，电商网站会将预售商品的支付时间延后十到二十分钟

延迟队列：
在你抢购商品的时候，往往会在队列中等待处理

软状态和最终一致性指的是允许系统中的数据存在中间状态。

这同样是为了系统可用性而牺牲一段时间窗内的数据一致性，从而保证最终的数据一致性的做法。

最经典的例子是在用户下单的时候不需要真正地扣减库存，而是仅在前台计个数，然后通过异步任务在后台批量处理。

回答问题的逻辑建议：

先充分理解理论原理，不能仅浮在概念上

其次需要有自己的思考，表现出你思考能力的不同

然后将理论结合于实践，讨论实际中处理问题时的思考逻辑

从三个层面回答：

展示理论深度：

可以从一个熟知的知识点出发，深入浅出地回答，比如它的工作原理、优劣势、适用场景等

结合落地经验：

你不能仅停留在理论理解，还要结合落地方案的技术实现，这样才能体现你的技术闭环思维

展示知识体系：

知识体系和技术判断力则体现了你是否达到架构师的能力边界

亿级商品存储

面试官会通过海量数据的存储设计问题考察候选人对分布式系统技术的掌握情况。

而回答好基于 Hash 取模、一致性 Hash 实现分库分表的解决方案。

当你掌握了常规的 Hash 取模分片方式后，面试官会引入一个场景问题（如大促热点问题）来考察你解决架构设计问题的思路。

因为分布式系统架构设计离不开系统可用性与一致性之间的权衡。

如果面试官满意你的表现，会进一步考察你算法原理，所以对于分布式系统中的一致性共识算法。

分布式一致性

主要强调这样几个重点：

基于 MQ 的可靠消息投递的考核点是可落地性，所以回答时要抓住双向确认的核心原则。
只要能实现生产端和消费端的双向确认，这个方案就是可落地了。
又因为基于 MQ 来实现，所以天生具有业务解耦合流量削峰的优势。

基于 2PC 的实现方案很少有实际的场景，但还是要掌握它的实现原理和存在的问题。
因为面试不同于实际工作，有些问题的回答是为了告诉面试官：我有这个能力，尽管它在实际工作中并不适用。

在实际工作中，并不是所有的业务对事务一致性的要求都那么高。

因为更高的要求意味着更多的成本，这也是很多架构复杂度来源之一。

所以要尽可能地站在业务实际场景的立足点来回答分布式事务问题。

锁实现原理

对于分布式锁，要从解决可用性、死锁、脑裂等问题为出发点来展开回答各分布式锁的实现方案的优缺点和适用场景。

在设计分布式锁的时候，为了解决可用性、死锁、脑裂等问题，一般还会再考虑一下锁的四种设计原则：

互斥性：
即在分布式系统环境下，对于某一共享资源，需要保证在同一时间只能一个线程或进程对该资源进行操作。

高可用：
可靠性：
锁服务不能有单点风险，要保证分布式锁系统是集群的，并且某一台机器锁不能提供服务了，其他机器仍然可以提供锁服务。

锁释放：
具备锁失效机制，防止死锁。
即使出现进程在持有锁的期间崩溃或者解锁失败的情况，也能被动解锁，保证后续其他进程可以获得锁。

可重入：
一个节点获取了锁之后，还可以再次获取整个锁资源。

造轮子能力

程序员一定要具备造轮子的能力，目的是突破技术栈瓶颈，因为技术只有动手实践过，才能有更加全面和深入的思考。

建议你阅读一些成熟的 RPC 框架的源代码，比如阿里开源的 Dubbo，或 Google 的 GRPC。

当然在实际工作中，一个产品级别的 RPC 框架的开发，除了要具备网络通信、序列化和反序列化、协议等基础的功能之外。

还要具备如连接管理、负载均衡、请求路由、熔断降级、优雅关闭等高级功能的设计。

虽然这些内容在面试中不要求你掌握，但是如果你了解是可以作为加分项的，例如连接管理就会涉及连接数的维护与服务心跳检测。

消息队列问题

如何确保消息不会丢失？

你要知道一条消息从发送到消费的每个阶段，是否存在丢消息，以及如何监控消息是否丢失，最后才是如何解决问题。

如何保证消息不被重复消费？

在进行消息补偿的时候，一定会存在重复消息的情况，那么如何实现消费端的幂等性就这道题的考点。

如何处理消息积压问题？

这道题的考点就是如何通过 MQ 实现真正的高性能，回答的思路是，本着解决线上异常为最高优先级。
然后通过监控和日志进行排查并优化业务逻辑，最后是扩容消费端和分片的数量。

在回答问题的时候，你需要特别注意的是：

让面试官了解到你的思维过程，这种解决问题的能力是面试官更为看中的，比你直接回答一道面试题更有价值。

另外，如果你应聘的部门是基础架构部，还要掌握消息中间件的其他知识体系，如：

如何选型消息中间件？
消息中间件中的队列模型与发布订阅模型的区别？
为什么消息队列能实现高吞吐？
序列化、传输协议，以及内存管理等问题

系统高可用

为了确保线上服务的稳定运行，在设计监控系统时，要考虑三个核心点，基础设施监控、系统应用监控，以及存储服务监控。

故障处理是研发工程师在进阶过程中必须经历的，而故障处理能力也是面试官最为看重的能力之一。

所以对于怎么处理各类故障，你要形成一套体系化的知识框架。

高性能架构设计

技术行业发展到今天，很多技术上的问题都不存在挑战了，所谓的高性能架构设计，也仅仅变成了一种标准化的应对流程。

你要做的就是将业务问题，抽象成一个技术问题，比如具体到数据库设计、缓存设计、队列设计、线程设计等技术细节。

而对于面试，答题思路应该是这样的：

先落实到技术上，比如结合业务场景，识别系统最关键的服务，然后针对性地为关键服务进行性能设计与测试，确保关键服务没有问题，然后为非关键服务提供降级和熔断处理方案。
再深化自己对于技术的理解，你要记住，任何复杂问题都可以按时间（系统建设周期）和空间（系统设计分层）拆解为简单的问题，然后逐一攻克，这样你才能有的放矢，这其中体现出来的思维能力才是每一个技术人的安身立命之本。