9 个软件架构面试问题及答案

软件架构师是软件专家，负责制定高层设计方案并制定技术标准，包括软件编码标准、工具和平台。软件架构指的是软件系统的高层结构、创建此类结构的规程以及这些结构的文档。

最初发表于FullStack.Cafe - 让你的技术面试不再失败

Q1：“针对接口编程，而不是针对实现编程”是什么意思？

主题：设计模式
难度：⭐⭐⭐

针对接口进行编码意味着客户端代码始终持有由工厂提供的接口对象。

工厂返回的任何实例都将是接口类型，任何工厂候选类都必须实现该类型。这样，客户端程序就无需担心实现问题，接口签名决定了所有可以执行的操作。

这种方法可以用来在运行时改变程序的行为。从维护的角度来看，它还能帮助你编写更好的程序。

🔗资料来源： tutorialspoint.com

Q2：持续集成、持续交付、持续部署有什么区别？

主题：DevOps
难度：⭐⭐⭐

• 实践持续集成的开发人员会尽可能频繁地将更改合并回主分支。这样做可以避免人们等到发布日才将更改合并到发布分支时经常发生的集成困境。
• 持续交付是持续集成的扩展，旨在确保您能够以可持续的方式快速向客户发布新的变更。这意味着，除了自动化测试之外，您还可以自动化发布流程，并且只需单击按钮即可随时部署应用程序。
• 持续部署比持续交付更进一步。通过这种实践，所有通过生产流程各个阶段的变更都会发布给客户。无需人工干预，只有测试失败才会阻止新的变更部署到生产环境中。

🔗资料来源： atlassian.com

问题3：SOLID 代表什么？它的原理是什么？

主题：软件架构
难度：⭐⭐⭐

SOLID是罗伯特·C·马丁 (Robert C. Martin) 提出的前五个面向对象设计 (OOD) 原则的首字母缩写词。

• S -单一职责原则。一个类应该有且仅有一个改变的理由，也就是说一个类应该只有一项工作。
• O -开放封闭原则。对象或实体应该对扩展开放，但对修改关闭。
• L -里氏替换原则。设 q(x) 是关于类型 T 的 x 对象可证明的属性。那么，q(y) 应该对于类型 S 的对象 y 可证明，其中 S 是 T 的子类型。
• I -接口隔离原则。客户端不应该被强制实现它不使用的接口，也不应该被强制依赖它不使用的方法。
• D -依赖倒置原则。实体必须依赖于抽象，而非具体。它规定高级模块不能依赖于低级模块，而应该依赖于抽象。

🔗来源： scotch.io

Q4：系统的BASE属性是什么？

主题：软件架构
难度：⭐⭐⭐⭐

BASE属性是近期发展起来的 NoSQL 数据库的常见属性。根据 CAP 定理，BASE 系统不保证一致性。这是一个人为的缩写，根据 CAP 定理，它对应到系统的以下属性：

• 基本可用表示系统保证可用
• 软状态是指系统状态可能随时间变化，甚至在没有输入的情况下也会发生变化。这主要得益于最终一致性模型。
• 最终一致性表示系统将随着时间的推移变得一致，前提是系统在此期间没有接收到输入。

🔗资料来源： fromdev.com

Q5：什么是CAP定理？

主题：软件架构
难度：⭐⭐⭐⭐⭐

分布式计算的 CAP 定理由Eric Brewer 提出。该定理指出，分布式计算机系统不可能同时提供以下三个保证：

1. 一致性（即使同时进行并发更新，所有节点也能看到相同的数据）
2. 可用性（保证每个请求都会收到关于其成功或失败的响应）
3. 分区容错性（即使出现任意消息丢失或系统部分故障，系统仍可继续运行）

CAP 的首字母缩写对应着这三个保证。该定理为现代分布式计算方法奠定了基础。世界上大多数高流量公司（例如亚马逊、谷歌、Facebook）都以此为基础来决定其应用程序架构。重要的是要理解，一个系统只能保证满足这三个条件中的两个。

🔗资料来源： fromdev.com

Q6：您熟悉十二要素应用原则吗？

主题：软件架构
难度：⭐⭐⭐⭐⭐

十二要素应用方法论是一种构建软件即服务 (SaaS) 应用的方法。这些最佳实践旨在使应用程序在部署到 Web 时具有可移植性和弹性。

• 代码库- 已部署的服务应该只有一个代码库，并且该代码库可用于许多部署。
• 依赖项- 应声明所有依赖项，并且不隐式依赖系统工具或库。
• 配置——部署之间变化的配置应该存储在环境中。
• 支持服务所有支持服务都被视为附加资源，并由执行环境附加和分离。
• 构建、发布、运行——交付管道应严格由构建、发布、运行组成。
• 进程- 应用程序应部署为一个或多个无状态进程，并将持久数据存储在支持服务上。
• 端口绑定——自包含服务应该通过指定的端口向其他服务提供自己。
• 并发性——通过扩展单个进程来提倡并发性。
• 可处置性——提倡快速启动和关闭，以实现更强大、更有弹性的系统。
• 开发/生产奇偶校验- 所有环境应尽可能相似。
• 日志——应用程序应将日志作为事件流生成，并让执行环境进行聚合。
• 管理流程- 任何需要的管理任务都应保存在源代码控制中并与应用程序打包在一起。

🔗来源： 12factor.net

Q7：什么是启发式异常？

主题：软件架构
难度：⭐⭐⭐⭐⭐

启发式异常是指交易参与者在未获得交易管理器的共识的情况下单方面采取某些行动的决定，通常是由于参与者和交易管理器之间发生某种灾难性故障造成的。

在分布式环境中，通信故障可能发生。如果事务管理器与可恢复资源之间长时间无法通信，可恢复资源可能会决定单方面提交或回滚在事务上下文中完成的更改。这种决策称为启发式决策。它是事务系统中可能发生的最严重错误之一，因为它可能导致事务的某些部分被提交，而其他部分被回滚，从而违反事务的原子性，并可能导致数据完整性损坏。

由于启发式异常的危险性，做出启发式决策的可恢复资源必须将有关该决策的所有信息保存在稳定存储中，直到事务管理器通知其放弃该启发式决策。保存在稳定存储中的有关启发式决策的实际数据取决于可恢复资源的类型，并且并非标准化的。这样做的目的是，系统管理员可以查看这些数据，并可能编辑该资源以纠正任何数据完整性问题。

🔗来源： jboss.org

问题 8：什么是无共享架构？它如何扩展？

主题：软件架构
难度：⭐⭐⭐⭐⭐

无共享架构 (SN)是一种分布式计算方法，其中每个节点都是独立且自给自足的，并且整个系统不需要单点争用。

• 这意味着节点之间不共享任何资源（没有共享内存，没有共享文件存储）
• 节点能够独立工作，无需相互依赖即可完成任何工作。
• 一个节点的故障仅影响该节点的用户，但其他节点仍可继续工作而不会中断。

这种方法具有高度的可扩展性，因为它避免了系统中存在单一瓶颈。由于其线性可扩展性，无共享架构最近在 Web 开发中变得流行起来。Google 已经使用了很长时间。

理论上，无共享系统只需添加廉价机器形式的节点即可实现几乎无限的扩展。

🔗资料来源： fromdev.com

Q9：最终一致性是什么意思？

主题：软件架构
难度：⭐⭐⭐⭐⭐

与关系数据库的严格一致性不同，系统的最终一致性确保任何事务最终（而非立即）都会使数据库从一个有效状态转换为另一个有效状态。这意味着多个节点之间可能存在不一致的中间状态。

最终一致性系统在绝对一致性不重要的场景下非常有用。例如，在 Twitter 状态更新的情况下，如果系统中的某些用户看不到特定用户的最新状态，这对系统的影响可能并不大。

最终一致性系统不适用于需要绝对/严格一致性的用例。例如，银行交易系统就不能使用最终一致性，因为它必须在任何时间点始终保持交易状态。您的账户余额不应该在不同的 ATM 机上显示不同的金额。

🔗资料来源： fromdev.com

感谢🙌的阅读，祝你面试顺利！
更多 FullStack 面试问答，请访问👉 www.fullstack.cafe