架构面试题（一）

什么是4A架构，4A架构面试的时候怎么去进行拓展？

在当今的数字化时代，4A架构已经成为企业信息化建设和数字化转型的重要基石。4A架构不仅涵盖了业务架构、应用架构、数据架构和技术架构四个核心组成部分，还涉及了身份认证、授权、审计和可用性四个关键要素

业务架构（Business Architecture）

业务架构是4A架构的起点，它关注企业的价值流和业务目标，为后续的应用架构、数据架构和技术架构提供指导。在业务架构阶段，企业需要明确战略定位，识别核心业务流程，并优化组织结构，以确保数字化转型与业务目标相契合。通过业务架构，企业能够更好地理解自身业务，为后续的架构设计打下坚实基础。

简历：项目的描述

京东 电商 -- 自营电商 电商-----仓储----物流 ---售后 （）

淘宝 电商 -- B-C 让天下没有难做的生意 交易的保证 菜鸟网络

下单操作

用户----- 首页------ 商品详情-------加入购物车----- 生成订单 -----库存-----支付----订单

应用架构（Application Architecture）

服务拆分 架构分层 可拓展性 定义业务的边界 订单的模块的业务边界

通过用户的id去找到你所有的当前的id的订单 getOrdersByUserId 查找的信息来划分模块

应用架构将业务架构转化为具体的技术功能模块，实现业务目标。在设计应用架构时，企业应关注系统的可扩展性、可维护性和安全性。采用微服务、容器化等先进技术，可以提升系统的灵活性和稳定性。同时，应用架构需要与业务架构高度匹配，以满足业务需求的变化。通过应用架构，企业能够将业务需求转化为可操作的技术实现，推动数字化转型的顺利进行。

数据架构（Data Architecture）

数据架构是数字化转型的核心。它关注数据的内在结构、相互关联以及流动路径，建立统一的数据标准和管理规范，实现数据的集中存储、共享和互通。通过数据挖掘、分析和可视化等技术，企业能够挖掘数据价值，为业务决策提供有力支持。此外，数据架构还需关注数据安全和隐私保护，确保数据的安全性和合规性。通过数据架构，企业能够建立起一套高效、可靠的数据管理体系，推动数据驱动的决策模式。

数据的存储 数据流 业务流

用户token---解析用户id-----商品的详情信息+token ------商品id ----- 生成临时订单id---临时订单的id返回-----主订单库 数据模型 （对象） 临时对象 永久对象

技术架构（Technology Architecture）

技术架构为整个4A架构提供底层支撑。它关注硬件选型、软件部署、网络安全保障以及开发运维流程等全方位技术配置。通过选择合适的技术平台和基础设施，企业能够确保系统的稳定运行。同时，技术架构还需关注新技术的引入和应用，如云计算、大数据、人工智能等，以提升系统的性能和效率。通过技术架构，企业能够建立起一套稳定、高效、可扩展的技术体系，为数字化转型提供坚实的技术支撑。

此外，4A架构还可以指代另一种含义，即身份认证（Authentication）、授权（Authorization）、审计（Audit）和可用性（Availability）四个关键要素。这四个要素共同构成了现代软件架构的重要组成部分，特别是在云计算与微服务的时代。

• 身份认证（Authentication）：确保用户的身份是合法的，例如使用用户名和密码、手机验证码等方式进行身份验证。

• 授权（Authorization）：确认用户是否有权访问特定的资源，例如通过角色或者权限管理来控制资源的访问权限。

• 审计（Audit）：记录用户的操作，对用户行为进行监控和追踪以便后期分析。审计功能有助于企业发现潜在的安全问题和违规行为。 -可用性（Availability）：确保系统在用户需要的时候能够持续运行，并具备良好的性能。通过负载均衡和容错机制等策略，企业可以提升系统的可用性和稳定性。

一般面试的时候问的都是第一种，因为这个是架构设计综合能力的体现，面试不可能把所有的点都明确聊到，但是大致的判断出一个人的水准。

业务架构设计需要考虑哪些问题

DDD 领域驱动设计 项目 划分成为几个领域的模块 逻辑概念 确定你的边界 子域 微服务

展示域 交易域 数分域 物流域 营销域 用户域

秒杀 限时拼团 优惠规则子域 营销订单子域 交易的保证子域 服务划分的规则

头脑风暴法 8-15之间

业务架构实际上是你业务的核心抽取，也就是你的核心愿景，你这个业务是干啥的，怎么把你的业务拆分成为领域，拆分成为领域之后怎么确定业务的边界，确定了业务的边界之后怎么根据你的项目制定业务流程以及业务规则。因为业务需求通常复杂且多变，涉及多个业务领域和利益相关者。如何准确理解业务需求，并将其抽象为可执行的架构设计，是业务架构设计的首要挑战。

第一件事，业务的理解以及抽象

那么怎么跟DDD结合到一起，怎么跟业务专家（运营，产品）合作，深入理解业务流程。

第二件事，业务与技术的平衡

因为业务架构设计需要在满足业务需求的同时，考虑技术实现的可行性和成本。如何在业务灵活性和技术约束之间找到平衡点，是一个常见的难题。 30天 半年 单体架构 --- 集群架构 微服务架构 +中间件

比如，要不要使用微服务，要不要用分层架构，将业务逻辑与技术实现分离。要不要使用微服务架构，提高系统的灵活性和可扩展性。要不要引入敏捷开发方法，快速响应业务变化。因为这些说白了，都是消耗，或者说，都是代价，一定是你的项目遇到了问题，不这么做项目就走不下去才会引入这些技术方案

第三件事，系统的可扩展性与可维护性

业务需求的变化和增长要求系统具有良好的可扩展性和可维护性。如何在设计阶段预见未来的需求变化，并做出相应的架构设计

• 采用模块化设计，将系统划分为高内聚、低耦合的模块。

• 使用设计模式和架构风格，提高代码的可复用性和可维护性。

• 引入持续集成和持续交付（CI/CD）流程，确保系统的快速迭代和部署。

第四件事，数据一致性与完整性

在分布式系统中，保证数据的一致性和完整性是一个复杂的问题。如何在业务架构设计中考虑数据一致性问题，并选择合适的解决方案

• 使用分布式事务或最终一致性方案，保证数据一致性。

• 引入事件驱动架构，通过事件溯源和CQRS模式处理数据一致性问题。

• 设计合理的数据分片和复制策略，提高数据的可用性和可靠性。

第五件事，安全性与合规性

业务架构设计需要满足各种安全性和合规性要求，如数据隐私保护、访问控制、审计日志等。如何在设计中充分考虑这些要求，并确保系统的安全性。

• 采用安全设计原则，如最小权限原则、防御性编程等。

• 引入身份认证和授权机制，如OAuth2.0、JWT等。

• 设计完善的审计和监控系统，确保系统的合规性。

第六件事，性能与效率

业务架构设计需要在高性能和高效率和高成本之间找到平衡。如何在满足业务需求的同时，优化系统的性能和资源利用率，

• 使用缓存技术，如Redis、Memcached等，提高系统的响应速度。

• 设计合理的数据库索引和查询优化策略，提高数据访问效率。

• 引入负载均衡和自动扩展机制，应对高并发场景。

当然 这里只是列举了6个比较主要的业务架构的问题，还会有一些比较宽松的问题，比如跨团队协作与沟通以及技术债务与架构调整，这个都是代价比较大的动作，所以一般不聊这块。但是也是有手段以及方案的。

很多的同学其实觉得架构就是所谓的技术方案，这个是错误的认知

实际上，不同业务架构的关注点和设计目标存在本质差异，但许多企业在实际设计中容易混淆概念，甚至将架构设计简化为"技术方案说明书"，导致回答模板化。以下是 区分四大架构的核心逻辑 ，以及如何针对不同架构给出差异化回答的框架：

1. 四大架构的本质区别

架构类型	核心问题	设计目标	典型输出物
业务架构	业务如何运转？	对齐战略，优化业务流程	业务流程图、价值链模型、领域模型
应用架构	系统如何分工协作？	支撑业务流程，定义应用边界	应用组件图、服务划分、接口规范
数据架构	数据如何流动与存储？	确保数据可用、可信、可分析	数据模型、数据流图、数据治理规范
技术架构	技术如何实现需求？	保障系统高性能、高可用、可扩展	技术栈选型（技术架构图）、部署拓扑（网络拓扑图）、容灾方案

（1）业务架构：聚焦业务价值流

"我们的业务架构以客户旅程 为核心，通过梳理订单履约、库存管理、支付结算等关键业务流程，识别了核心领域（如商品中心、交易中心、用户中心），并抽象出 领域模型 （如订单聚合根、库存实体）。通过划分限界上下文（Bounded Context），解决了业务部门间协作的摩擦点，例如将促销活动和商品管理解耦，提升业务响应速度。"

核心要点 ：

• 强调业务目标（如降本增效、用户体验）

• 使用领域驱动设计（DDD）方法论

• 输出业务流程图、领域模型

---

**（2）应用架构：聚焦系统协作

"应用架构采用前后端分离+微服务化 设计，前端通过API网关聚合后端服务（如商品服务、订单服务），服务间通过事件驱动（Event-Driven）实现松耦合。例如，订单服务下单后发布 OrderCreated事件，库存服务监听该事件完成库存扣减。同时通过**服务网格（Service Mesh）**统一管理服务通信、熔断和监控。"**

核心要点 ：

• 强调系统分层（如前端/中台/后台）

• 服务拆分原则（如按业务能力划分微服务）

• 交互模式（同步调用 vs 异步消息）

---

**（3）数据架构：聚焦数据全生命周期

"数据架构设计遵循湖仓一体（Lakehouse） 理念，原始数据入湖（S3/HDFS）后，通过批流一体处理（Spark+Flink）生成分层数据（ODS->DWD->DWS）。为支持实时风控，引入Kafka+ClickHouse构建实时数仓，同时通过**数据血缘（Data Lineage）**工具追踪数据来源，确保合规性（如GDPR）。"**

核心要点 ：

• 数据分层（原始层、明细层、汇总层）

• 数据治理（质量、安全、血缘）

• 技术选型（OLAP引擎、实时处理框架）

---

**（4）技术架构：聚焦技术实现与运维

"技术架构基于云原生设计，容器化（K8s）部署保障弹性伸缩，服务网格（Istio）实现灰度发布和流量治理。数据库采用读写分离（MySQL主从）+分库分表（ShardingSphere），缓存层用Redis Cluster抗高并发。通过Prometheus+ELK实现全链路监控，并设计多AZ容灾（异地多活）应对区域性故障。"**

核心要点 ：

• 基础设施（云/混合云/裸金属）

• 关键技术选型（数据库、中间件、运维工具）

• 非功能需求（性能、容灾、可观测性）

简历上如何体现你的架构相关的职责

（1）结构化表达：用"问题-方案-结果"框架 个人职责

• 业务架构 ：解决业务协作低效 → 领域模型划分 → 业务响应速度提升30%

• 技术架构 ：解决系统性能瓶颈 → 引入Redis分片+异步化 → QPS从1k提升至10k

（2）用具体案例体现差异

• 业务架构案例 ：某电商通过梳理用户旅程，发现"购物车弃购率过高"，重构为"一键加购+实时库存显示"。

• 技术架构案例 ：某支付系统因数据库性能瓶颈，迁移至TiDB分布式数据库，TPS提升5倍。 留白

（3）可视化工具辅助说明

• 业务架构 ：用价值链图（Value Stream Mapping）**展示端到端业务流。

• 技术架构 ：用部署拓扑图展示多机房容灾设计。

项目：项目名称 项目周期 项目中的角色

项目描述：业务描述

技术栈的罗列

个人职责（最重要的）：

一份改造过的简历（个人职责部分）：

简历改造前：

简历改造之后：

高工简历怎么写：

修改前的简历：

1、使用多线程操作三方接口并设置信号量保证接口稳定，用kafka接收消息并入库，使用redis记录操作结果；

2、使用redis加锁并通过Lua脚本确保了锁的获取和释放操作的原子性；

3、 根据所选地市找出所有设备后筛出设备编码并组装后。调用三分接口，将返回数据按时间从新组装后返回设置缓存时间；

4、市区班组单位树查询并缓存结果；

修改后：

1.采用了信号量+多线程的方式控制三方接口并发量（QPS稳定提升10%）

2.基于kafka异步的削峰处理消息（日均处理1W+）配合Redis操作结果，实现99.9%接口可用

3.自研Lua脚本实现了分布式锁的原子性操作，解决了集群环境下并发

4.设计了设备编码动态路由算法，实现了1W+设备数据毫秒级检测

5.设计研发了多级缓存架构（Redis+Caffeine），市区班组单位树查询响应时间从2.3S提升到200ms以内