简介这是一份源自高校《大型软件系统构造》课程大作业的完整设计文档围绕图书资料管理系统的架构设计展开适合软件工程、系统架构方向的初学者参考。内容涵盖需求分析、业务领域建模、逻辑架构、开发架构、数据架构、运行架构与物理架构并配有数据流图、用例图、类图、E-R图和部署图等关键设计视图能够帮助读者理解从需求到架构落地的完整思路。资源包内共1个doc文档约1.2MB除正文外还附有设计心得与人员分工说明适合作为课程设计、毕业设计或架构文档撰写的参考资料。目前已有136人学习浏览文档结构清晰模块划分明确对想要系统梳理架构设计流程的读者具有较好的借鉴价值。1. 一个图书资料管理系统怎么撑得住“大型软件系统架构”这顶帽子很多团队把“图书资料管理系统”当成练手的 CRUD 项目一张 book 表、一套 Spring Boot 就交差了。但项目标题里既然把“大型软件系统架构”放在“图书资料管理系统”前面说的就不是那种单机 demo而是当数据量过百万、检索条件组合翻倍、编目与借阅流程跨多个部门协同、甚至要对接第三方数据库和数字资源时系统的结构该怎么设计。本文要解决的正是“图书资料管理系统在大型架构语境下如何分层、建模、扩展与验证”这件事。适合正在做中后台管理系统重构、需要把单体往模块化方向拆的工程师也适合想用一个熟悉业务把架构知识落地的读者。我的做法是先立边界再补容量最后用监控和验证保证架构不腐烂。2. 图书管理系统的分层架构设计先从边界划分说起“图书资料管理系统”这个名词听起来简单拆开看业务面很宽采编、典藏、流通、检索、读者管理、统计分析每个域都有自己的生命周期。如果一开始就按页面去组织代码控制器会膨胀业务规则会散落在各个 Service 里。常见做法是先把系统按“域”划分再在域内部做分层。2.1 分层不是三层包壳而是依赖方向的治理教科书上说的三层架构——表现层、业务层、数据层——在大型系统里只算起点。真正重要的是依赖方向上层依赖下层下层不反向依赖上层同层之间不互相 import跨层访问必须走接口。这样做的直接好处是将来把检索从数据库迁到 Elasticsearch或者把借阅记录从 MySQL 迁到 Cassandra都只需要替换最底层的实现上层代码不用动。我一般把一个业务域内部切成五层层次职责典型目录接口层接收请求、参数校验、响应包装controller应用层用例编排、事务边界、权限校验service领域层业务规则、状态流转、领域服务domain仓储层持久化抽象、缓存抽象repository基础设施层数据库、消息队列、ES 客户端infrastructure注意领域层不依赖基础设施层。图书的“可借状态”判断是领域逻辑至于这个状态放在 MySQL 还是 Redis 里领域层不关心只依赖仓储接口。2.2 用接口把“域”和“技术”切开以图书借阅为例领域层定义仓储接口基础设施层提供实现。下面是一段典型的借阅用例代码技术选型以 Spring Boot MyBatis 为例但结构本身不绑定框架public class BorrowService { private final BookItemRepository bookItemRepository; private final BorrowRecordRepository borrowRecordRepository; Transactional public BorrowResult borrow(String readerId, String barcode) { BookItem item bookItemRepository.findByBarcode(barcode); // 领域判断图书条目是否可借、读者是否违规、是否已达借阅上限 item.borrow(readerId); bookItemRepository.save(item); BorrowRecord record new BorrowRecord(readerId, barcode); borrowRecordRepository.save(record); return BorrowResult.success(record.getId()); } }这里的bookItemRepository是接口borrow(readerId)是领域方法把“状态是否允许借出”的判断放在 BookItem 内部而不是在 Service 里写一堆 if。这样做的意义在于当借阅规则从“每人 5 本”变成“分类型限额文艺类 3 本、科技类 5 本”时改的是领域层Service 和 Controller 都不动。仓储接口长这样public interface BookItemRepository { BookItem findByBarcode(String barcode); void save(BookItem item); }基础设施层用一个MyBatisBookItemRepository去实现里面写 SQL 或走 MyBatis-Plus。注意一点接口方法名要面向业务不要直接叫selectById、insert否则上面换存储的时候接口语义就跟着崩了。2.3 跨层调用的红线与异常处理策略分层设计里最容易出问题的不是分层本身而是绕过层的调用。我看到不少系统为了“快速上线”让 Controller 直接 new 一个 DAO 去查数据库还振振有词说“这个查询比较简单不值得走 Service”。当这种绕过一多事务边界就乱了缓存逻辑也丢了最后 Service 变成空壳。实际做法是立三条规矩请求必须从接口层进不能直接调用 Repository。领域层抛出的业务异常由接口层的全局异常处理器统一转换技术异常比如数据库连接失败不暴露给前端只记录日志。事务只开在应用层。领域方法不标Transactional因为领域方法可能被多个用例复用事务粒度不好控制。异常处理上我习惯定义一套业务异常码例如BORROW_QUOTA_EXCEEDED、BOOK_ITEM_UNAVAILABLE前端根据异常码做文案映射。不要用异常的 class name 做判断也不要让后端把堆栈直接塞进响应体。3. 图书资料核心模块的数据建模与检索实现检索是图书资料管理系统的主场景也是架构设计里最容易先做错的部分——先用 LIKE 凑合等数据量上来再换搜索引擎却发现自己根本没留出扩展位。这一章先讲数据建模再讲检索路径怎么从 SQL 平滑过渡到倒排索引。3.1 图书资料核心表结构从 book 到 item 的拆分“图书”这个概念在业务里其实有两层一层是书目book记录的是“这本书叫什么、作者是谁、ISBN 是什么”另一层是馆藏book_item记录的是“这一本具体的书在哪个馆、什么位置、当前是否被借走”。如果不拆把册信息直接挂在书目上那么“全馆有 12 本《TCP/IP 详解》其中 3 本借出”这种查询就得把 12 条记录的每个字段都查一遍冗余和一致性都会出问题。下面是经过拆分的核心表结构属于这个系统最基础的骨架CREATE TABLE book ( id BIGINT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL, title VARCHAR(255) NOT NULL, author VARCHAR(255), publisher VARCHAR(255), publish_year SMALLINT, category_code VARCHAR(20), metadata_json JSON, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_isbn (isbn), KEY idx_category (category_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE book_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, book_id BIGINT NOT NULL, barcode VARCHAR(64) NOT NULL, location_code VARCHAR(64), status TINYINT NOT NULL DEFAULT 0 COMMENT 0-在架, 1-借出, 2-预约中, 3-下架, borrowed_by BIGINT, due_date DATE, UNIQUE KEY uk_barcode (barcode), KEY idx_book_id (book_id), KEY idx_status (status), CONSTRAINT fk_item_book FOREIGN KEY (book_id) REFERENCES book(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个字段值得说明metadata_json存的是可变元数据比如“译作者”“丛书名”“开本”这些不是每本书都有的属性。用 JSON 列比建一堆 nullable 字段干净MySQL 5.7 的 JSON 类型支持函数索引查询时可以用JSON_EXTRACT。book_item.status用 TINYINT 而不是字符串枚举省空间、比较快枚举映射放在领域层做。barcode是物理条码每本书一本一码它才是借阅操作真正锁定的对象不是book_id。3.2 元数据多版本与多值字段的建模策略图书资料的元数据有一个特点多版本、多值。比如一本书有“正题名”和“并列题名”有“第一作者”和“其他作者”有些图书馆还会给同一本书做多个编目版本。如果按传统关系表硬压每个版本都要改主表历史痕迹就丢了。常见做法是把“编目记录”拆成独立实体一个book对应多个catalog_record每个 record 有自己的版本号和生效状态。查询当前版本走active 1的记录要做编目历史回溯就直接查 version 链。这样设计后编目员的修改、审核、发布流程才能支撑起来否则“谁改的、改了什么、之前是什么样”的审计需求根本没法做。多值字段的存储上我推荐在 MySQL 中用 JSON 数组例如{authors: [库克, 王某某], translators: [李某某], subjects: [计算机网络, TCP/IP]}但要注意JSON 字段只适合“存储时一次写入、读取时整体解析”的场景。如果业务里有“按作者查全部图书”的高频需求必须建辅助表或生成列不能依赖JSON_CONTAINS去大海捞针。3.3 从 LIKE 到倒排索引检索路径的选型图书检索的需求很典型书名模糊匹配、作者精确匹配、分类过滤、出版年份范围过滤再叠加一个相关性排序。数据量在 10 万条以下时MySQL 的 LIKE 加上联合索引还能撑到 50 万条以上%关键词%这种前模糊查询只能全表扫响应时间会涨到几百毫秒甚至秒级。业界最成熟的方案是引入 Elasticsearch把图书的主索引数据同步进 ES用倒排索引支撑搜索。检索链路变成请求先打 ES 拿命中的 book_id 列表再到 MySQL 查明细或者干脆把列表页需要的字段都冗余进 ES只在详情页回表。下面是一个简化的索引映射{ mappings: { properties: { book_id: { type: integer }, title: { type: text, analyzer: ik_max_word, fields: { keyword: { type: keyword } } }, author: { type: text, analyzer: ik_smart, fields: { keyword: { type: keyword } } }, category_code: { type: keyword }, publish_year: { type: short }, status: { type: byte } } } }参数说明title用ik_max_word做细粒度分词适合中文书名ik_smart粒度粗适合人名和短语匹配。category_code选keyword不做分词确保“TP316”这个分类码不被拆成 “TP” 和 “316” 两个词否则查到一堆不该出现的结果。status用byte类型是因为这个字段只有几个离散值节省索引空间。同步方式我一般用监听 MySQL binlog 或定时增量任务。刚开始的时候定时任务性价比最高五分钟同步一次足够等检索命中率成为核心指标再考虑上 Canal 做实时同步没必要一开始就上分水岭方案。3.4 检索参数与排序规则如何定ES 查询参数里最容易踩坑的是minimum_should_match和排序规则。书名搜索“计算机网络基础”如果默认should匹配会把只命中“基础”二字的书也捞出来第一页全是无关结果。我常用的检索 DSL 分两段先过滤后查询。filter处理分类、状态、出版年份这些精确条件不走打分should里放标题、作者、关键词的匹配用boost控制权重。排序上默认用_score降序只对分类浏览场景按“出版年份 desc 书名 asc”排不要在用户输入关键词时用字段排序否则相关性排序就废了。过滤器可以这样写{ query: { bool: { filter: [ { term: { category_code: TP316 } }, { term: { status: 0 } }, { range: { publish_year: { gte: 2015 } } } ], must: [ { match: { title: { query: 计算机网络基础, minimum_should_match: 60% } } } ] } }, size: 20, from: 0 }minimum_should_match设成60%意思是分词后至少匹配 60% 的词元才算命中能有效过滤掉只沾一个词的长尾结果。from和size是分页游标服务端页码别超过 100 页否则深分页的from size机制会让 ES 内存暴涨正确做法是改用search_after。4. 借阅状态机与高并发扩展从“能用”到“能扛”图书资料管理系统一旦上线到高校或公共图书馆并发压力比想象中大得多开学季选课参考书集中借出、预约到书集中取书、还书高峰期一个热门书目的请求会在几分钟内打满单库连接。这一章把重心放在两个核心扩展点上状态流的正确性、热点数据的隔离。4.1 借阅状态机的建模把业务规则变成可配置的转移表book_item.status不是随意跳变的。“借出”不能直接回“在架”中间得经过“还书登记”“预约中”的书也不能被别人直接借走。把这些规则写在代码的 if else 里是最差的做法因为状态多了以后根本没人能说清全量路径。正确做法是建一个状态转移表由领域层统一管理public enum BookItemState { AVAILABLE, BORROWED, RESERVED, ONSHELF_OFF; private static final MapBookItemState, SetBookItemState TRANSITIONS Map.of( AVAILABLE, Set.of(BORROWED, RESERVED, ONSHELF_OFF), BORROWED, Set.of(AVAILABLE, RESERVED), RESERVED, Set.of(AVAILABLE, BORROWED), ONSHELF_OFF, Set.of(AVAILABLE) ); public boolean canTransitionTo(BookItemState target) { return TRANSITIONS.getOrDefault(this, Set.of()).contains(target); } }转移表的好处是把所有合法路径放在一个地方任何新成员都能看懂加状态时只需要加枚举值和对应的转移集合不需要去翻散落的 if。真正执行变更时仓储层要加一个条件更新UPDATE book_item SET status ?, borrowed_by ?, due_date ? WHERE id ? AND status ?把更新时的旧状态放进 WHERE 条件既能防止并发下两个请求同时把同一本书借给不同读者覆盖状态又避免了先查后改的经典竞态。这就是“乐观锁 状态机”组合的典型落地。4.2 热点图书的高并发处理Redis 缓存预约库存热门书目在秒杀式的预约场景下数据库行锁会瞬间成为瓶颈。比如某馆藏只有 3 本《操作系统概念》新学期 200 人同时预约直接怼数据库的后果是 MySQL 的行锁竞争和死锁日志刷屏。我的方案是把热门书目的剩余可借数量缓存进 Redis用 Lua 脚本做原子扣减。扣减成功才允许写预约流水扣减失败直接返回“已被约满”。实现上先加载一个页面级的锚点脚本-- KEYS[1] 库存 key例如 stock:book:1001 -- ARGV[1] 扣减数量 local stock tonumber(redis.call(GET, KEYS[1])) if not stock or stock tonumber(ARGV[1]) then return -1 end redis.call(DECRBY, KEYS[1], ARGV[1]) return stock - tonumber(ARGV[1])调用方是 Java 侧的一个借阅服务组件public boolean tryAcquire(String bookId, int acquireCount) { DefaultRedisScriptLong script new DefaultRedisScript(); script.setScriptText(LUA_SCRIPT); script.setResultType(Long.class); Long result redisTemplate.execute(script, List.of(stock:book: bookId), acquireCount ); return result ! null result 0; }参数说明第一个传入的参数是 Redis key按 book_id 维度隔离第二、三个参数是扣减数。这里必须用 Lua不是get后再decr因为两个命令分开发送会引入竞态窗口。库存预热建议在每天开馆前批量把数据库里的可借数量同步进 Redis闭馆后再把剩余数回写数据库。注意Redis 只能是前置拦截器最终的一致性以数据库流水为准。4.3 读写分离与分库分表阈值什么时候动手不是所有系统都该一上来就分库分表。我的经验阈值很明确单实例 MySQLbook_item表超过 2000 万行或写 QPS 超过 2000才考虑分库在此之前先把读流量从主库剥走更划算。图书资料管理系统的读写比通常接近 8:2检索和列表页是大头。所以第一步永远是做读写分离主库处理借还事务从库扛检索查询。落地时注意两点一是主从延迟要在业务层兜底比如借书成功后 5 秒内不让读者立刻查到新状态用“强制走主库”的标记处理二是从库要多配几个按分类或按馆区做读流量的分组。真正要分表时建议按book_id哈希分不要按时间分。按时间分会导致热数据全部砸在最近一个分区上“当年的新书”集中写一个物理表热点完全没解决。分表之后全库查询成了禁忌必须把“按分类查”“按出版社查”的维度提前设计成索引表或 ES这才是分表方案成立的前提。4.4 消息队列削峰借阅流水异步落库借阅高峰期流水写库不必同步完成。借出动作的核心是“改图书条目的状态、登记借阅关系”。其中“生成流水记录”和“更新读者借阅历史”都可以异步做因为读者端感知不到这 50 毫秒的差异。我一般会把借阅主流程压缩成以下三步同步状态机校验 Redis 扣减 更新 book_item 状态。立即异步把借阅记录消息发给 MQ消费者写流水表。延迟异步更新读者的借阅统计和推荐位数据这步失败不影响主流程。消息结构只带必要字段不要带整个对象public class BorrowEvent { private String borrowRecordId; private String bookId; private String bookItemId; private String readerId; private Long timestamp; }消费端要做幂等用borrowRecordId作为唯一业务键重复消费时直接跳过。消息队列的引入时机我建议在数据库连接池已经出现排队时再上不用提前三个月预演。过度设计同样是架构风险。5. 部署、监控与架构验证如何证明“大架构”真的立得住架构设计得再完备没有监控和验证就成了纸上谈兵。最后一章讲落地时怎么证明分层、缓存、异步这套组合生效了以及如何保证架构在迭代中不腐化。5.1 架构指标先证明系统没坏再谈优化我每次接手一个系统先不急着优化先统一可观测口径。图书资料管理系统至少要有三层指标层级核心指标预警阈值基础资源CPU 使用率、内存、磁盘 IOCPU 持续 70%磁盘 80%应用层P99 响应时间、错误率P99 500ms错误率 0.5%业务层借出成功率、检索命中率、预约转化率成功率 99.9% 告警监控只是第一步关键是把“慢”和“错”归因到具体逻辑层。比如检索接口 P99 变长先看是 ES 查询慢了还是回表 MySQL 慢了两者优化方向完全不同。ES 慢就调分片或查_profileAPIMySQL 慢就抓慢查询日志。5.2 用压力测试验证架构假设如果没有压测就上线大改那跟赌博没有区别。我习惯在改动上线前把核心路径压一遍主要看三个指标在并发上涨时的表现曲线借出接口 QPS、检索接口延迟、数据库连接池占用。压测工具用 wrk 或者 ab 均可只要量级能拉到生产业务的 3 到 5 倍即可。wrk -t8 -c200 -d60s --latency http://localhost:8080/api/search?keyword计算机网络参数说明-t8开 8 个线程-c200保持 200 个并发连接-d60s持续压 60 秒--latency输出延迟分布。压测前先把缓存预热否则测出来的结果混合了缓存冷启的冷热数据参考价值低。当 QPS 已经达到预期而延迟还在可接受范围时说明当前的架构容量是正确的如果连接池先打满那就是连接池参数和池大小不匹配需要先调参再看分库。5.3 架构保鲜三板斧最后三个具体动作能让架构设计在演进过程里保持有效。一是把分层红线写进 CI 检查比如用 ArchUnit 拒绝 Controller 直接依赖 Repository架构规范变成机器检查的硬约束。二是保留架构决策记录比如“为什么检索用 ES 而不用 MySQL 全文索引”三个月后有人提“要不要换 Solr”时翻记录能看到当时的取舍前提不会轻易反复。三是每个迭代结束后做一个“防腐层清单”哪些接口被外部系统绕过、哪些 SQL 绕过 ES 直接查库、哪些缓存没有设过期时间逐条消解宁可慢一点也不能让技术债无限积压。架构不是画完一张图就结束了图书资料管理系统恰恰因为业务边界清晰适合作为验证架构思想的实验场。当你把状态机、缓存原子扣减、异步削峰这些手段叠加上去并看着监控面板上的指标平稳滑过那个“大型软件系统架构”才算真正落地。本文还有配套的精品资源点击获取