架构说明

编写人：刘洋

系统：行政协同平台 V1.2

试点规模：一个办公点，420 名员工

日期：0000-00-00

一、建设目标

架构服务于员工在浏览器中独立完成会议室预订、请假、访客登记和用品申领，主管完成请假审批，行政完成访客确认和库存核对。试点办公点 420 人，工作时间可用率目标 99.5%，主路径页面响应目标在 300 毫秒以内。账号使用公司统一账号，办结消息走企业微信。刘洋负责服务划分和部署，陈静确认模块与页面入口一致。

二、逻辑结构

请求从浏览器进入网关，再到达四项业务服务。业务服务写入关系数据库，会议室占用额外写入缓存。通知单独成服务，避免审批接口等待外部消息通道。

三、服务职责

四、数据与缓存

业务数据存放在一套关系数据库中，库名 admin_coop，每日 02:10 全量备份，保留 14 天。会议室当日占用写入缓存，键为房间加日期，过期时间 26 小时，预订成功后同时更新数据库和缓存。缓存不可用时，查询直接读数据库，9月18日演练中该降级路径平均耗时 40 毫秒。请假、访客和用品不走缓存，以数据库状态为准。

五、部署方式

测试与试点各使用两台应用机，每项服务各 2 个实例，网关按轮询转发。
数据库为一主一备，主库承担读写，备库用于备份和故障切换演练。
缓存为单节点，容量 2 GB，当前占用约 180 MB。
发布时先更新一个实例并做健康检查，通过后再更新第二个实例，窗口约 20 分钟。

六、容量与可用性

按每日预订 80 张、请假 30 张估算，峰值出现在周一 9 时至 10 时，预订写入约 30 次每分钟。9月22日压测以 2 倍峰值运行 15 分钟，错误率为 0，预订接口 P95 为 210 毫秒。网关对单账号限流为每分钟 60 次。工作时间健康检查失败时，刘洋在 10 分钟内收到告警。试点期间目标为工作时间可用率 99.5%，由每日成功请求占比统计。

四项业务与网关、通知使用同一条发布流水线，构建产物按版本号保留最近 5 个。数据库地址、缓存地址和模板编号按环境分开存放。刘洋于 9月20日核对试点配置，与测试环境的差别为域名和库名。9月11日架构评审通过，出席人刘洋、张伟、陈静，结论是浏览器只访问网关。健康检查连续失败 3 次后，网关摘除该实例，恢复后再加入轮询。