资金服务独立模块实践：账户、流水、幂等与对账机制

去年年中我们团队的代码仓库里第一次出现了一个叫 financial-services 的模块。这个名字听着覆盖面极宽但实际落到代码里它是整个线上资金流转的中枢账户开立、余额变更、交易流水、记账对账全都要从它身上过。当时我们内部讨论过好几次到底要不要把它做成一个独立服务还是像之前的做法那样继续在业务单体里塞一个子目录。后来上线跑了半年多我可以明确地说幸好选了独立服务这条路线。这篇文章就把这个模块从设计到上线的完整过程捋一遍重点讲清楚我们为什么那样选型、核心模型是怎么设计的、以及踩过的那些坑。如果你是做支付、清结算、账务中间件或者任何强资金属性的后端系统这篇内容应该能帮你少走不少弯路。1. 为什么 financial-services 必须独立成模块而不是塞进业务主程序先说结论资金域代码天然不适合跟普通业务代码混在同一个工程里。这个结论不是从架构书上看来的是我们被真实事故教育之后得出的。把资金逻辑放进业务主程序早期确实方便一个订单一个事务全搞定开发和联调都快。但从长期维护的角度看资金域代码有几个特征让它很难跟普通业务代码和平共处这几个特征我总结成了三个“不能忍”。第一个特征是变更频率差异大。业务侧的活动、页面、促销规则可能一天上线两三次而资金逻辑的每一次改动都直接影响资金安全必须走更严格的需求评审、代码评审和测试流程。把它们放在同一个工程里就意味着每次业务发版都要带着资金模块一起做回归成本极高而且容易在某个不起眼的活动需求里误改到与资金相关的代码。我们之前就出过一次事故一个同学改营销活动的优惠券计算逻辑顺手动了一个公共的金额工具类结果支付链路的金额校验被影响线上出现了整整十五分钟的错误扣款提示最后全靠日志回放才定位到问题。第二个特征是权限边界不一样。能碰交易流水的人和能碰用户标签的人通常不应该是同一拨人。代码一旦放一个工程Git权限很难做到文件级隔离最后只能靠口头约定“大家别动那个目录”这种约定长期来看基本守不住。尤其是团队扩张之后新人很容易在搜索代码时误改到资金相关方法review也不一定能看出来。与其依赖人的自觉不如从物理层面分开让想改资金代码的人必须经过额外的权限申请和发布流程。第三个特征是故障爆炸半径。业务模块出问题顶多挂一个页面资金模块出问题就可能引发重复扣款、少记一笔、对账不平这类事故影响面会顺着资金链路传导到所有依赖它的业务。所以我们要尽量把它和普通业务物理隔离开哪怕服务的机器挂了也不至于因为一个边缘业务的高频调用而拖垮整个资金域。综合这三点我们确定 financial-services 不能是一个普通子模块必须是独立部署的服务有自己的存储、自己的发布节奏、自己的监控告警。1.1 我们对“独立服务”的理解物理隔离 数据自治 对外只开放API独立服务不是简单把一个目录拆出来它要满足三个硬性条件少一个都不算真正的隔离。第一是物理隔离它的进程、资源、数据库都独享一份不跟业务主程序共用连接池避免互相影响。我们见过不少团队硬拆微服务拆完之后服务确实独立了但数据库还是共用同一个实例业务侧一条 SQL 就能连到资金表上做查询资源竞争和安全隐患一点没少。第二是数据自治资金相关的表只能由 financial-services 自己读写其他任何服务不允许直连它的数据库。所有数据访问必须通过服务提供的 API 或者内部消息事件不允许在别的项目里引入资金表的 Mapper。我们甚至在建库时给资金库单独建了账号用数据库层面的权限控制来兜底防止某个开发在代码里手滑写错连接串直接连到了生产资金库。第三是对外只开放 API所有业务方对资金的操作都走我们定义的接口契约参数要校验、权限要校验、幂等要处理。这样即使将来接口内部逻辑大改只要契约稳定调用方基本无感。这个设计思路也反映在我们的目录结构上。服务内部按端口适配器模式组织领域层不依赖任何具体框架或数据库infrastructure 层才放真实的 DAO 实现和消息客户端。第一次这么写的人可能会觉得多此一举但它的回报在后期维护时特别明显换数据库、升级框架、加中间件都不会污染核心资金逻辑。我们后来从 MySQL 5.7 升到 8.0只改了 infrastructure 层的数据源配置领域层一行代码没动。2. 核心模型账户、流水、台账是怎么落库的2.1 账户模型不该用“余额”字段来记账刚开始接手资金模块的人第一反应往往是设计一张 account 表里面放一个 balance 余额字段每次扣款就update account set balance balance - ? where id ?。这种设计在并发和账务一致性上都有隐患。余额是可变状态每次变更都要锁行一旦业务量上来账户行会成为整个系统最大的热点锁所有资金操作都堵在同一个行的行锁上数据库 CPU 不高但事务就是提交不上去。我们最终采用的模型是“账户只存最近状态 所有变更都由流水推导”。也就是说account 表里确实可以有一个 current_balance 字段但它只作为读优化用的冗余核心数据来源是另外两张只追加、不更新的流水表和台账表。这样每次资金变更在 DB 层面只是插入一条流水再在同一个事务里更新账户余额热点锁的粒度被大幅降低。有人会问那余额不一致怎么办这里的关键是余额永远不是权威数据流水才是。对账时如果发现账户余额跟流水汇总对不上以流水为准进行纠偏。所以在我们的系统里账户表更像是一个缓存而不是事实来源。2.2 流水与台账单向追加和借贷平衡流水表记录每一笔资金动作的原始事实包括请求幂等键、账户ID、变动方向、变动金额、交易类型、关联订单号、渠道、发生时间等。它的特点是一旦写入就不允许 UPDATE 和 DELETE我们直接在数据库账号层面回收了这两个权限从机制上保证历史记录不会被篡改。即使是补偿操作也是新插入一条冲正流水而不是把原来的流水改掉。这个规矩一开始执行起来有点麻烦很多开发习惯性想 update但坚持一段时间后大家发现查账非常轻松所有历史动作都完整保留很少出现“这钱到底怎么没的”这种谜案。台账表则更像会计里的明细账。它按照“借贷平衡”的思路设计一个业务动作会拆成多行分录比如用户支付 100 元可能对应账户 A 减 100账户 B 加 100或者一部分进平台收入、一部分进平台暂存。每一批分录有一个 batch_id必须满足SUM(debit_amount) SUM(credit_amount)否则事务整体回滚。有人可能觉得这就是普通的事务嵌套但它在处理“平账”时特别有用。比如退款、手续费分账、优惠券核销这种多账户动作如果只记流水不记台账事后很难快速判定哪些账户需要轧差。有了台账每一笔业务动作的资金流向都在同一批分录里看得明明白白。2.3 表结构示例与索引设计要点这里给一个简化版的 DDL 作为参考实际生产环境的字段会比这多不少比如会加二方的商户号、渠道手续费、优惠分摊金额等但核心骨架是这样CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_no VARCHAR(32) NOT NULL UNIQUE, user_id VARCHAR(64) NOT NULL, currency CHAR(3) NOT NULL, current_balance BIGINT NOT NULL DEFAULT 0 COMMENT 单位:分, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2冻结 3关闭, version INT NOT NULL DEFAULT 0, created_at DATETIME(3) NOT NULL, updated_at DATETIME(3) NOT NULL, KEY idx_user (user_id) ) ENGINEInnoDB; CREATE TABLE txn_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, txn_no VARCHAR(64) NOT NULL COMMENT 业务交易号, idempotent_key VARCHAR(128) NOT NULL COMMENT 幂等键, account_no VARCHAR(32) NOT NULL, direction TINYINT NOT NULL COMMENT 1流入 2流出, amount BIGINT NOT NULL COMMENT 单位:分, txn_type VARCHAR(32) NOT NULL, ref_order_no VARCHAR(64) NOT NULL, channel VARCHAR(32) NOT NULL, status TINYINT NOT NULL, occurred_at DATETIME(3) NOT NULL, UNIQUE KEY uk_idempotent (idempotent_key), KEY idx_account_time (account_no, occurred_at), KEY idx_ref_order (ref_order_no) ) ENGINEInnoDB; CREATE TABLE ledger_entry ( id BIGINT PRIMARY KEY AUTO_INCREMENT, batch_id VARCHAR(64) NOT NULL COMMENT 分录批次, account_no VARCHAR(32) NOT NULL, direction TINYINT NOT NULL COMMENT 1借 2贷, amount BIGINT NOT NULL COMMENT 单位:分, entry_type VARCHAR(32) NOT NULL, txn_no VARCHAR(64) NOT NULL, memo VARCHAR(255), created_at DATETIME(3) NOT NULL, KEY idx_batch (batch_id), KEY idx_account (account_no, created_at) ) ENGINEInnoDB;这里面有几个设计要点值得单独拿出来说。金额一律用整数单位用“分”。浮点数在金额计算中是禁区因为二进制无法精确表示所有十进制小数哪怕单笔误差一厘汇总到千万笔就是无法忽视的差额。我们用 BIGINT 存分导出报表时再转成元这样加减乘除全部是整数运算不会有精度问题。幂等键必须唯一uk_idempotent是这整张表最重要的约束它保证同一笔业务请求即使被客户端重试、被 MQ 重复投递在 DB 层面都无法插入第二条记录。索引要覆盖查询路径账户流水的查询通常是“某个账户一段时间内的流水”所以组合索引account_no occurred_at比单列索引高效很多对账系统则经常按ref_order_no反查业务单据单独建索引可以避免全表扫描。3. 资金逻辑里最容易翻车的三件事幂等、状态机、对账3.1 幂等同一笔请求重试一百次结果必须一致资金服务最常见的故障来源是重复请求。上游超时之后会重试MQ 消费失败后会重新投递前端用户卡顿会连点支付按钮。如果我们不在入口做幂等一次支付动作可能被连续执行两遍直接导致重复扣款。我们的做法是每个涉及资金变更的接口都要求调用方传入一个全局唯一的幂等键比如业务订单号。服务端先检查这个幂等键是否处理过处理过就直接返回上次的结果没处理过才真正执行。落到代码上可以用一个前置中间件把幂等检查做在业务逻辑之前但中间件只能算第一道防线最终的幂等还是要靠数据库的唯一索引兜底。两道防线缺一不可因为在极端并发下两个请求可能同时通过中间件检查但最终还是被唯一索引挡住一个。建议在代码里把唯一索引冲突当成正常分支处理而不是当成异常报警否则线上会因为重复请求刷出一堆误报警告真正的异常反而被淹没。func IdempotentMiddleware(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { key : r.Header.Get(X-Idempotency-Key) if key { http.Error(w, missing idempotency key, http.StatusBadRequest) return } if result, ok : cache.Get(key); ok { w.Header().Set(Content-Type, application/json) w.Write(result) return } // 用分布式锁防止并发请求同时到达 lock : redisLock(idem: key) if !lock.TryLock() { http.Error(w, duplicate request, http.StatusConflict) return } defer lock.Unlock() // 再次检查因为锁等待期间可能已经被处理 if result, ok : cache.Get(key); ok { w.Write(result) return } next(w, r) } }这里还要注意缓存里保存的返回结果必须和真正成功时的返回结果完全一致包括状态码和响应体。否则上游重试时拿到一个“成功”的缓存响应但内部业务状态其实是“处理中”会让调用方产生误解。我们在缓存里存的是序列化后的完整响应对象并且设置了合理的过期时间一般跟订单支付超时时间对齐避免一个幂等结果被永久缓存。对于超时后一直没处理完的请求我们设置了一个兜底任务定期扫描处理中状态的单据超时后转入失败或人工处理队列。3.2 状态机交易状态不能允许任意跳转交易状态如果没有约束代码里到处写if status 2 { status 3 }很快就会失控。一个支付单可能会从“待支付”被重复推进到“已支付”再被错误地“取消”然后对账怎么都对不上。我们在系统里为每一类金融单据定义了明确的状态机例如支付单待支付 - 支付中 - 支付成功待支付 - 已关闭支付中 - 支付失败。凡是状态变更统一走状态机服务或至少一个状态校验函数不允许业务代码里直接 assign。实际编码时我们用一个 map 保存合法迁移关系每次更新都带条件where status ?做乐观锁控制。这种方式比在业务逻辑里写一堆 if-else 要清晰得多也更容易做并发控制。两个请求同时想改状态时数据库的更新条件会挡住一个保证状态不会因为并发而错乱。后来我们甚至把状态机单独抽成了一个配置化组件每种单据类型只需要定义节点和合法迁移路径代码里不再出现任何魔法数字也让测试可以针对每个节点穷举所有可能的跳转。var payStateTransitions map[int][]int{ StatePending: {StateProcessing, StateClosed}, StateProcessing: {StateSuccess, StateFailed}, StateSuccess: {}, StateFailed: {StatePending}, // 允许部分场景下失败后重试 StateClosed: {}, } func Transition(current, target int) error { for _, allowed : range payStateTransitions[current] { if allowed target { return nil } } return fmt.Errorf(illegal transition: %d - %d, current, target) }状态机的另一个作用是方便做对账和排查。当一张单据出现异常时我们可以顺着状态流转历史定位它到底卡在哪一步。我们在每张单据表里都加了一个 state_history 字段或单独的历史表记录每一次状态变化的时间、操作人、原因。排查问题时不用再靠日志大海捞针直接查状态历史就能还原整条时间线。这个习惯后来帮我们解决过不少棘手的客诉问题比如用户说“我明明支付成功了为什么订单显示未支付”一查状态历史发现是回调通知丢了单据停留在“支付中”问题归属一目了然。3.3 对账实时一致性做不到就用最终对得上资金系统里最让人头疼的问题就是“两边账对不上”。业务订单系统说这笔支付成功了资金服务却找不到对应流水渠道侧说已经扣款我们的数据库里却没有这笔记录。要解决这种问题不能只靠实时事务必须建立一套对账机制。我们每天凌晨会把三份数据进行比对内部流水、内部台账、渠道账单。比对的主体是金额和单号差异会落到差异表里由系统自动分类处理。业务方有单、资金无流水一般标记为“资金漏记”这种情况需要转人工核查确认是消息丢失还是接口漏调必要时发起补账。资金有流水、业务方无单可能有两种原因一种是调用方传了错误的订单号另一种是异常入账需要检查是否存在非法调用或测试数据混入生产。金额不一致通常是最麻烦的它可能是渠道手续费、优惠分摊逻辑有问题也可能是某个金额字段在不同系统里的单位不一致比如一个用分、一个用元。我们在对账差异表里专门加了一个差异类型字段方便把这些问题分类统计按优先级推进处理。这套机制虽然不是实时的但它能保证即便线上出现了问题也能在 T1 发现并纠正不会一直错下去。我给团队立过一个规矩实时一致性做不到就用最终一致性加定期对账来兜底。对账不是可有可无的运维操作它和幂等、状态机一样是资金系统的基础设施。对账脚本本身也需要测试我们会在测试环境故意注入几类差异数据确认系统能正确识别和告警防止对账逻辑形同虚设。4. 安全护栏权限、加密和审计日志的工程实现4.1 越权访问每个接口都要过一遍资源归属校验资金服务最怕的问题不是被暴力破解而是越权。一个用户如果可以利用订单号遍历其他人的交易明细那加密做得再好都没用。我们在所有涉及资金数据的接口里都会做两层校验。第一层是身份认证确认调用者是谁走统一的登录态和鉴权服务。第二层是资源归属校验确认这个调用者是否有权操作目标资源。比如查询账户流水的接口除了要求登录态还必须校验所查询的 account_no 是否属于当前用户如果是内部运营平台调用还要校验运营人员是否有对应菜单的数据权限。有一种容易漏的情况是批量接口。单个查询校验了归属批量查询经常因为拼接条件时忘加 user_id 过滤条件而变成全量查询。我们后来统一封装了一个数据权限组件所有查询都在 SQL 生成层自动追加归属条件避免业务同学在写代码时凭记忆加条件。这个改动带来的安全收益比后来做的任何一次渗透测试都实在。除此之外我们还会对敏感操作做频控同一账号短时间内的查询次数超过阈值就自动触发告警防止恶意遍历或者数据爬取。4.2 敏感字段存储层加密和脱敏返回是两件事资金相关系统里身份证号、银行卡号、手机号都属于敏感数据。很多团队把“敏感字段加密”和“接口返回值脱敏”混为一谈实际上这是两件独立的事。存储层加密解决的是数据库泄露后数据仍然不可读的问题。我们使用字段级加密对身份证号、银行卡号这类字段加密后再入库查询时在服务内解密。这里的要点是加密密钥要托管在独立的密钥管理系统里定期轮换不能把私钥写在配置文件里跟代码一起提交。接口返回值脱敏解决的是展示层泄露的问题。即使内部服务有权限查看明文返回到前端或第三方时也要按规则打码。比如手机号只显示前三位和后四位银行卡号只显示后四位。我们用一个统一的序列化注解或脱敏函数处理不在每个业务方法里手动拼接字符串避免漏脱敏。这里特别提醒日志里千万别打印明文敏感字段。我们有次排查线上问题开发临时在日志里打印了整个请求体里面带着完整银行卡号日志又接入了第三方检索平台最后不得不连夜做日志脱敏和清理。这类事故比代码 bug 更隐蔽也更容易被忽略。4.3 审计日志谁在什么时间对哪笔资金做了什么资金系统对审计有刚需任何一笔资金操作事后都必须能回答谁、在什么时间、对哪笔资金、做了什么操作、前后值分别是什么。我们在写操作入口统一埋点记录操作人 ID、操作人 IP、请求 traceId、接口名、入参摘要、变更前后的状态和金额、操作结果。这些审计日志独立存储保留周期要比普通业务日志长很多且不允许一般开发人员删除或修改。实现审计日志时不要用业务日志表来代替业务日志可以被截断、可以被业务代码写乱审计数据需要单独的存储和权限管理。我们后来干脆把所有写接口的审计数据异步发送到独立的审计消息队列再由审计服务单独落库这样即使 finance 服务整体重启审计链路也不会丢数据。审计日志的查询也要做好隔离运营人员只能通过内部平台查询不能直连数据库。审计日志的写入不能影响主链路性能所以异步化是必须的但异步化会带来一定的延迟如果某个操作立刻需要查询审计结果需要通过 traceId 去追踪这个体验需要提前跟业务方说清楚。5. 压测与上线我们用一组量化指标说服了所有人5.1 关注的三个核心指标上线前压测其实是项目经理问得最多的问题性能到底行不行我们没有拍脑袋而是先定义了三个核心指标。第一个是交易成功率正常压测场景下要求不低于 99.99%失败率不能因为并发上升而明显放大。第二个是 P99 延迟资金接口的 P99 不能超过 300 毫秒这个值对用户体验和上游超时设置都比较友好。第三个是数据库连接池水位在目标压力下连接使用率不能超过 70%要留出缓冲应对突发流量。指标目标值说明交易成功率≥ 99.99%失败率不能随并发上升而恶化P99 延迟≤ 300ms兼顾用户体验与上游超时配置连接池水位≤ 70%预留突发流量和慢查询的缓冲这三个指标要预先写进测试计划里而不是压测完再对结果做解释。否则很容易出现“压测结果不太好看但开发说业务场景特殊然后大家就认可了”的情况最后带着隐患上线。资金服务尤其不能靠“感觉可以”上线我们要的是可量化的数字最好能落到发布检查单里每次发版都自动核对一遍避免引入新的性能回归。5.2 压测场景设计压测不是把并发数拉到很高然后看整体指标那样只能测出系统能扛多少次裸请求。我们设计了三个贴近真实的场景。第一个场景是正常支付链路从鉴权、幂等检查、资金扣减、记账、发消息一路走到底模拟日常高峰期的主链路。第二个场景是超时重试风暴人为制造上游超时让同一批请求大量重试目的是验证幂等和锁能不能扛住重复流量。第三个场景是慢查询干扰人为在某个关联表上模拟慢 SQL看主链路会不会被拖垮。这三个场景跑完我们发现慢查询干扰场景最容易暴露问题因为资金服务内部查询模式非常固定一旦某条新需求引入了一个没走索引的查询整体连接池就可能被拖住。后来我们规定所有涉及资金表的 SQL 上线前必须 EXPLAIN 确认走索引并把这条写进发布检查单。超时重试风暴场景也很重要因为它能检验幂等中间件在压力下是否真的有效。有一次压测就发现分布式锁在极端竞争下出现了大量冲突报错虽然没造成数据错误但影响了用户体验后来我们优化了锁的重试策略才把错误率降下来。5.3 上线回放验证压测再充分和生产流量之间还是存在差距。我们上线时用了一个“回放验证”的土办法把测试环境的流量录下来或者用影子表方式在预发环境回放对比回放前后的账户余额、流水总数和台账总数。只要三个数能对齐就说明这次变更没有破坏资金账务的闭环。实际执行时影子表方案会比全链路压测简单很多我们用一个标记位把回放流量路由到影子库数据写进去后跑对账 SQL不占用生产主库压力。这套机制在验证数据库迁移、状态机调整、查询逻辑优化时都非常好用哪怕发现问题也只会污染影子库不会影响真实用户。回放验证不是万能的它只能验证“逻辑等价”不能验证“性能是否达标”所以它和压测是互补关系。我们在发版checklist里固定了两步先跑一次小流量灰度观察核心指标是否有异常再逐步放量到全量。金融服务的每一次变更都值得用这种谨慎的方式对待因为线上资金事故的修复成本往往比任何演练成本都高。6. 联调与生产中踩过的真实问题6.1 时钟漂移导致的时间戳排序错乱联调阶段最让人意外的问题来自时间戳。多个服务分别记录交易时间一开始都用各自服务器的本地时间。结果有两台机器时钟漂移同一笔交易在服务 A 记录的时间比服务 B 晚了十几秒展示给用户时交易顺序完全错乱对账脚本按时间排序也总是出现倒挂。这个问题在功能测试阶段很难发现因为测试环境只有一两台机器时间差异不明显但到预发环境多机部署后就暴露了。我们很快统一改用数据库的时钟来写入 occurred_at应用层不再直接使用本机时间作为资金记录的时间源。这样做的代价是性能上稍微多一次数据库时间获取但对资金系统来说时间源的统一远比那一点性能重要。如果用数据库当前时间要注意应用层拿到的值和数据库实际写入值可能还有微小时差所以我们干脆在 INSERT 语句里直接写NOW(3)让数据库来定时间避免应用层二次赋值。对于跨地域的分布式部署还要进一步考虑用统一的 NTP 服务和时间同步策略。6.2 数据库连接池被打满原因居然是慢日志有次线上报警显示数据库连接数接近上限一开始以为是流量峰值后来一查发现是某条新上线的流水查询 SQL 没走索引单次查询耗时接近两秒因为连接持有时间被拉长连接池自然被打满。这个问题其实在压测阶段出现过类似情况但当时压测的查询条件正好命中索引没暴露出来属于典型的“测试数据分布和生产不一致”导致的问题。生产环境的历史数据量远大于测试环境索引失效的影响被放大了几十倍。这个坑让我们总结出一条经验资金服务的数据库连接池配置不仅要看平时水位还要考虑“最慢 SQL 的持有时间”。我们把连接池最大连接数从经验值改成了按 P99 查询耗时和 QPS 估算目标连接数约等于 QPS × P99 耗时 × 1.5 的安全系数。那个 1.5 的系数就是留给慢查询和突发流量的缓冲。同时也加强了慢查询监控任何超过 500ms 的 SQL 都会实时告警DBA 和开发一起排查避免慢 SQL 再次拖垮连接池。6.3 缓存与数据库的一致性资金数据不能随便缓存资金服务上线一段时间后有同学为了提高查询性能把账户余额加了一层本地缓存。听起来没什么但在一个并发变更频繁的账户上缓存会导致页面显示的余额和数据库实际余额出现短暂不一致。对普通业务来说忍忍就过去了但资金业务里一个用户看到充值后余额没变或者在重复扣款后余额没减少产生的客诉和对账成本都远超缓存省下的那点数据库开销。我们的结论是资金数据的读取可以走只读从库可以走预聚合报表但不要轻易加业务缓存。如果实在需要缓存只能缓存那些不可变或低频变更的数据比如账户状态字典、交易类型配置等。余额、流水、台账这类数据必须实时读库。我也理解性能优化的压力但资金域的性能瓶颈很少出现在单行余额查询上更多是出现在跨行汇总、复杂统计和报表导出上这些问题应该通过合理的索引、读写分离和预计算来解决而不是靠缓存绕过一致性。这套原则我们后来写进了团队的资金开发规范成为所有新同学入职必读的一部分。