简介这份PDF文档围绕企业总体架构展开面向架构师、技术负责人及中高级研发人员系统讲解业务架构、应用架构、数据架构与技术架构四大领域的定位与协作关系。作者以曾任职公司为案例还原200人研发团队、200余台服务器、5地8机房的真实场景剖析系统频繁故障、运维责任错位等问题的根源并给出从架构现状梳理到中远期规划、领域建模的完整思路。资源包内含1个PDF文件约615KB内容涵盖商务模型、功能与应用架构、E-R图与数据状态图、物理部署、SOA与分层规划等模块目录结构清晰便于按章节查阅。目前已有3434人学习下载适合需要理解企业级架构全貌、撰写架构文档或推动系统改造的读者参考借鉴。1. 四层架构不是PPT上的四个框从一次线上故障说起业务架构、应用架构、数据架构和技术架构这四个词几乎出现在每一份技术规划文档里但真正能把它们拆清楚、落到代码和配置上的人并不多。我见过太多团队把四张图画得漂漂亮亮结果一次订单重复提交的故障就暴露了业务架构里没定义幂等边界应用架构里服务拆分过细导致事务跨了三个服务数据架构里没有唯一约束兜底技术架构里的消息队列重试策略又是默认值。四个架构各画各的线上出事时谁也说不清该改哪一层。这篇文章面向的是需要把架构从文档落到工程实践的人——可能是刚接手系统重构的后端负责人也可能是要从零搭建一套业务系统的全栈开发者。我会按“每层架构解决什么问题、产出什么制品、怎么验证它真的生效”这条线把四层架构串成一套可操作的方法而不是停留在名词解释。读完之后你应该能判断自己手头的系统在哪一层欠了债以及补债的最小动作是什么。2. 业务架构先画价值流再谈领域边界2.1 业务架构的产出不是组织架构图很多团队把业务架构等同于“公司有哪些部门”这是最常见的翻车起点。业务架构的核心是回答钱和物从谁手里出发经过哪些价值交换环节最终交付给谁。它描述的是业务活动的流转不是行政汇报关系。我一般会先让业务方用动词短语列出核心价值流比如“客户提交需求→需求被评估→报价生成→合同签署→履约交付→回款核销”。每个动词短语就是一个业务活动活动之间的箭头代表信息或实物的转移。这张图不涉及任何技术选型纯粹是业务语言。产出物通常是一张价值流图和一份业务能力清单。业务能力清单的写法有讲究用“名词动词”结构比如“订单创建能力”“库存锁定能力”而不是“订单管理”这种模糊词。能力清单的粒度决定了后续应用架构的拆分粒度——能力拆得太粗应用会变成单体拆得太细分布式事务会教你做人。2.2 用事件风暴对齐业务语义事件风暴是我用过最有效的业务架构对齐手段。具体做法是找一面墙或一块在线白板用橙色便签写“领域事件”已发生的事实过去时用蓝色便签写“命令”触发事件的意图用黄色便签写“聚合”命令和事件之间的业务实体。一个可操作的步骤是先让业务方按时间顺序贴出所有“已发生的事实”比如“订单已创建”“支付已完成”“库存已扣减”。针对每个事件追问“是什么命令触发了它”把命令便签贴在事件左侧。再追问“这个命令作用于哪个业务实体”把聚合便签贴在命令左侧。最后用连线标出聚合之间的引用关系。这个过程会暴露出大量业务语义分歧。比如“库存已扣减”这个事件业务方可能认为下单时就扣减技术方可能认为支付成功后才扣减。这种分歧如果不提前对齐到了应用架构阶段就会变成服务之间的扯皮。提示事件风暴的产出物是业务架构的输入不是应用架构的输入。不要在这一步讨论用 Spring Cloud 还是 Dubbo那是后面的事。2.3 业务架构的验证方法用场景走查代替评审会业务架构图最容易犯的错是“画完就挂墙上”。我的做法是组织场景走查挑三个典型业务场景正常流程、异常流程、边界流程让业务方和技术方一起在图上“走”一遍。走查时只问三个问题这个场景下价值流是否完整每个业务活动的输入输出是否明确异常分支是否被覆盖如果走查中发现某个活动没有明确的输出物说明业务架构在这一块是空的需要补。走查记录要落成文档每个场景一行标注“已覆盖”“有歧义”“缺失”。这份记录就是后续应用架构拆分的验收标准之一。3. 应用架构从业务能力到服务边界3.1 服务拆分的依据是业务能力不是技术分层应用架构最常见的错误是按技术分层拆服务Controller 一层、Service 一层、DAO 一层然后每层独立部署。这种拆法在业务简单时没问题一旦业务变复杂一个业务变更要改三个服务联调成本指数上升。正确的做法是按业务能力拆服务。业务架构阶段产出的能力清单每一个能力对应一个候选服务。比如“订单创建能力”对应订单服务“库存锁定能力”对应库存服务。服务之间的调用关系应该与价值流图中的活动依赖关系一致。一个可落地的判断标准是如果一个业务变更只需要修改一个服务且不需要跨服务事务那这个拆分粒度就是合适的。如果每次变更都要改三个以上服务说明拆得太细如果一个服务里塞了五个以上不相关的业务能力说明拆得太粗。3.2 用契约测试锁定服务边界服务边界定下来之后最大的风险是边界被悄悄侵蚀。比如订单服务直接查了库存服务的数据库或者库存服务反向调用了订单服务的内部接口。这种侵蚀在代码评审时很难发现因为代码本身能跑通。我的做法是引入契约测试。每个服务对外暴露的接口HTTP 或 RPC都要有一份契约文件契约里定义请求和响应的结构、错误码、超时时间。契约文件放在独立的仓库里服务提供方和消费方都依赖这份契约。# 订单服务对外契约示例order-contract.yaml service: order-service version: 1.2.0 endpoints: - path: /api/order/create method: POST request: contentType: application/json schema: customerId: string (required) items: array (required, minItems: 1) idempotencyKey: string (required) response: success: code: 200 schema: orderId: string status: string (enum: CREATED, PAID, CANCELLED) errors: - code: 409 reason: DUPLICATE_ORDER description: 幂等键重复返回已有订单 timeoutMs: 3000契约文件写好后用 Pact 或 Spring Cloud Contract 生成消费方和提供方的测试桩。消费方测试时用桩模拟提供方提供方测试时验证自己的实现是否符合契约。这样任何一方想偷偷改接口契约测试会先红。参数说明idempotencyKey是必填项由消费方生成通常用 UUID。timeoutMs设 3000 是经验值超过这个时间订单创建接口的失败率会显著上升需要检查数据库锁或下游依赖。3.3 应用架构的部署单元划分服务拆完之后部署单元怎么划我的原则是一个部署单元可以包含多个服务但必须满足“同时发布、同时回滚”的条件。如果两个服务必须一起发布才能保证兼容那它们就应该在同一个部署单元里。具体操作时我会画一张部署矩阵行是服务列是环境开发、测试、预发、生产单元格里填部署包名称和版本号。如果发现某个服务在四个环境里的版本号总是不一致说明它的发布流程有问题需要收拢到统一的流水线里。注意不要为了“微服务”而把每个服务都独立部署。独立部署带来的运维成本是实打实的如果业务量没到那个规模合并部署是更务实的选择。4. 数据架构一致性边界比表结构更重要4.1 先定一致性边界再设计表数据架构最容易陷入的误区是上来就画 ER 图。ER 图很重要但它解决的是“数据长什么样”不解决“数据在哪个边界内保持一致”。我一般先定一致性边界哪些数据必须强一致哪些可以最终一致。强一致的数据放在同一个数据库实例里用本地事务保证。最终一致的数据可以跨库用消息队列或定时对账保证。这个边界一旦定下来表结构设计才有意义。举个例子订单和订单明细必须强一致放在同一个库。订单和库存扣减记录可以最终一致因为库存扣减失败可以通过补偿机制回滚。如果把订单和库存放在同一个库用本地事务虽然简单但库存服务的写入压力会拖垮订单库。4.2 用幂等表解决重复提交重复提交是数据架构里最经典的坑。用户点两次按钮、消息队列重试、网络超时后客户端重发都会导致同一条业务数据被创建两次。解决方案不是让前端禁用按钮而是在数据层加幂等约束。-- 幂等表结构 CREATE TABLE idempotency_record ( idempotency_key VARCHAR(64) NOT NULL, business_type VARCHAR(32) NOT NULL, business_id VARCHAR(64) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (idempotency_key, business_type), UNIQUE KEY uk_business (business_type, business_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 插入幂等记录如果冲突则返回已有记录 INSERT INTO idempotency_record (idempotency_key, business_type, business_id) VALUES (req-uuid-001, ORDER_CREATE, order-123) ON DUPLICATE KEY UPDATE business_id business_id;逻辑说明idempotency_key由客户端生成每次请求唯一。business_type区分不同业务场景。business_id是实际创建的业务实体 ID。当重复请求到达时ON DUPLICATE KEY UPDATE不会报错但也不会插入新记录。应用层在插入后查询一次如果business_id与本次请求生成的不一致说明是重复请求直接返回已有记录。参数说明idempotency_key长度设 64 足够容纳 UUID。business_type用枚举值不要用中文。唯一键uk_business保证同一业务实体不会被创建两次。4.3 数据架构的验证对账任务不是事后补救很多团队把对账任务当成出问题后的排查工具这是本末倒置。对账任务应该是数据架构的常规验证手段每天跑一次发现不一致就告警。对账任务的写法从两个数据源分别拉取同一时间窗口的数据按业务主键做全外连接找出只在左边、只在右边、两边都有但字段不一致的记录。差异记录写入对账差异表由人工或自动补偿处理。# 对账任务核心逻辑伪代码 def reconcile(start_time, end_time): left_records query_order_db(start_time, end_time) right_records query_stock_db(start_time, end_time) left_map {r.order_id: r for r in left_records} right_map {r.order_id: r for r in right_records} all_keys set(left_map.keys()) | set(right_map.keys()) diffs [] for key in all_keys: if key not in left_map: diffs.append((ONLY_RIGHT, key)) elif key not in right_map: diffs.append((ONLY_LEFT, key)) elif left_map[key].amount ! right_map[key].amount: diffs.append((AMOUNT_MISMATCH, key)) save_diffs(diffs) if len(diffs) THRESHOLD: alert(diffs)参数说明start_time和end_time建议按小时窗口避免全量扫描。THRESHOLD根据业务量设一般设为总记录数的 0.1%。差异记录保留 30 天用于追溯。5. 技术架构选型是最后一步不是第一步5.1 技术架构的输入是前三层的约束技术架构不是“我们用什么中间件”而是“前三层架构对技术提出了哪些约束我们用什么技术满足这些约束”。约束包括一致性要求、吞吐量要求、延迟要求、可用性要求、成本要求。比如业务架构要求订单创建必须幂等应用架构要求订单服务独立部署数据架构要求订单和库存最终一致。这些约束翻译到技术架构就是需要分布式锁或幂等表、需要服务注册发现、需要消息队列。技术选型是在这些约束明确之后才发生的。5.2 用容量估算驱动技术选型技术选型最怕拍脑袋。我一般先做容量估算日活用户数、峰值 QPS、平均响应时间、数据增长量。这些数字不需要精确但必须有依据。指标估算值依据日活用户10 万业务方提供的推广计划峰值 QPS500日活 × 人均请求数 / 峰值集中系数平均响应时间200ms用户体验要求日增数据量5GB单条记录大小 × 日增记录数数据保留周期3 年合规要求有了这张表技术选型就有了边界。500 QPS 不需要分库分表单库加读写分离足够。5GB 日增数据量3 年就是 5.4TB需要考虑冷热分离。这些结论直接决定了数据库选型和存储方案。5.3 技术架构的验证混沌工程不是大厂专利技术架构的假设比如“消息队列不会丢消息”“数据库主从切换在 30 秒内完成”需要被验证。混沌工程就是主动注入故障观察系统行为。小团队可以从最简单的开始在测试环境随机杀掉一个服务实例观察是否自动恢复在消息队列里注入延迟观察消费方是否堆积把数据库主库只读观察应用是否报错。# 用 tc 模拟网络延迟测试环境 tc qdisc add dev eth0 root netem delay 200ms # 用 kill -9 模拟服务崩溃 kill -9 $(pgrep -f order-service) # 观察指标错误率、恢复时间、日志中的异常堆栈参数说明delay 200ms模拟跨机房延迟用于验证超时设置是否合理。kill -9模拟进程崩溃用于验证服务注册发现是否及时剔除节点。这些操作只在测试环境做生产环境需要更精细的故障注入工具。6. 四层架构的避坑清单五个血泪教训6.1 业务架构缺失导致应用架构反复重构现象系统上线半年内订单服务被拆了又合、合了又拆每次业务调整都要改服务边界。原因业务架构阶段没有对齐价值流业务方和技术方对“订单”的理解不一致。业务方认为订单从询价开始技术方认为订单从支付开始。解决回到事件风暴把“询价”“报价”“订单创建”“支付”四个事件的边界重新对齐。对齐后重新划分服务边界这次拆分后至少稳定了一年。6.2 应用架构的分布式事务滥用现象订单创建接口平均响应时间 2 秒超时率 5%。原因订单服务、库存服务、优惠券服务用了 Seata 的 AT 模式做分布式事务三个服务串行执行任何一个慢都会拖垮整体。解决把强一致改为最终一致。订单创建只写订单库然后发消息给库存和优惠券服务异步处理。订单状态先设为“处理中”收到两个服务的确认消息后改为“已创建”。响应时间降到 200ms超时率降到 0.1%。6.3 数据架构的索引缺失拖垮查询现象订单列表接口在数据量到 100 万后从 50ms 恶化到 3 秒。原因查询条件用了customer_id和created_at但索引只建了customer_id。数据量小的时候全表扫描也快数据量大了就暴露了。解决建联合索引idx_customer_created (customer_id, created_at)。建索引时用ONLINE DDL避免锁表。建完后用EXPLAIN验证执行计划确认type从ALL变成range。6.4 技术架构的中间件版本不一致现象预发环境正常生产环境消息消费延迟高。原因预发环境的消息队列是 4.8 版本生产环境是 4.3 版本。4.3 版本的消费线程模型有差异在高并发下表现不同。解决统一中间件版本用配置管理工具锁定版本号。所有环境用同一份部署脚本版本号从配置中心读取不允许手工指定。6.5 四层架构文档不同步现象新人接手后按应用架构图改代码结果改坏了数据架构的一致性约束。原因业务架构、应用架构、数据架构、技术架构四份文档分别维护变更时只更新了其中一份。解决把四层架构的变更纳入同一个变更流程。任何一层变更必须评估对其他三层的影响并在文档中标注变更记录。文档用 Git 管理每次变更提交一个 PRPR 描述里必须填写影响范围。注意架构文档不是写完就完了它需要和代码一样有版本、有评审、有回滚机制。没有变更管理的架构文档三个月后就是废纸。7. 用架构决策记录把四层架构钉在代码库里架构决策记录是我坚持了最久的一个习惯。每次做架构决策时写一份 Markdown 文件放在代码库的docs/adr/目录下。文件内容包括决策背景、决策选项、最终选择、理由、影响范围。文件名用ADR-序号-短标题.md比如ADR-001-订单服务拆分粒度.md。这个习惯的好处是半年后有人问“为什么订单服务不拆得更细”不需要翻聊天记录直接看 ADR。新人接手时按时间顺序读一遍 ADR就能理解系统演进的脉络。我一般会在 ADR 里加一个“验证方式”字段写明这个决策怎么验证是否生效。比如“订单服务拆分粒度”的验证方式是统计每次业务变更涉及的服务数量如果连续三个月平均超过两个说明拆分粒度需要调整。最后一个技巧把 ADR 和契约测试、对账任务、混沌实验关联起来。每个 ADR 至少对应一个自动化验证手段。没有验证手段的 ADR 只是空想有验证手段的 ADR 才是工程实践。我自己踩过最大的坑是早期觉得 ADR 是形式主义懒得写。结果一年后系统出了故障排查时发现三个架构决策互相矛盾但谁也说不清当初为什么这么定。从那以后我要求团队里每个架构变更必须配一份 ADR不写 ADR 的 PR 直接打回。这个习惯坚持了三年系统的可维护性明显提升新人上手时间从两周缩短到三天。希望帮到你。本文还有配套的精品资源点击获取