实习产出总结

项目简介一、系统定位和使用对象这是一个 电信业务支撑系统BSS的账务管理后台主要服务于电信营业厅工作人员 - 办理收费、退费、查询等业务财务对账人员 - 处理银行流水对账、单边账等异常审批管理人员 - 审核各类退费、调账申请运营管理人员 - 查看报表、监控系统运行系统管理员 - 配置参数、管理权限、维护系统简单说这就是电信公司内部用来管钱、管账、管审批的核心系统。二、核心业务模块详解1 审批流程模块approvalProcess- 最复杂的业务场景举例- 客户交了1000元话费后来发现多交了申请全额退款- 大客户签约时给了特殊优惠需要部分退费调整- 修改客户的缴费方式比如从现金改为银行代扣业务流程发起申请 → 填写资料 → 上传附件 → 提交审批 →多级审批通过/不通过/退回 → 执行操作 → 完成包含的子功能OneFullRefund - 一次性全额退费非因公原因OnePartRefund- 一次性部分退费OneFeeOrderAlter- 一次性费用订单变更OnePaymentWayStart/Deal - 缴费方式变更谁在用 营业厅前台发起各级领导逐级审批2 对账管理模块reconciliation- 财务的核心工作**什么是单边账就是银行那边扣了客户的钱但电信系统没收到或者电信系统记了账银行那边没扣款。这种不一致就叫单边账。主要功能UnilateralAcctQry - 查询单边账列表找出有问题的账目updateChkResult - 修正对账结果状态fxUnilateralAcctPl - 批量返销错误的单边账PaymentSum - 支付汇总统计CheckTaskInfoList - 对账任务管理工作流程每天定时对账 → 发现差异 → 列出单边账 →人工核实 → 修正或返销 → 生成对账报告谁在用 财务人员每天必做的工作3 报表统计模块report- 给领导看数据核心报表-OnceFeeReport - 一次性费用报表最大最复杂1000多行代码- 收费明细统计哪个营业厅收了多少- 收费清单每笔交易的详细记录- 代理商终端款给代理商的结算数据- IncomeReport - 收入报表- ApprovalReport - 审批情况报表- PayReport - 支付情况报表- IotOutgoingStatement - 物联网出账清单输出格式 Excel表格、PDF文档带水印防伪谁在用- 管理层看经营数据- 财务做月度结算- 代理商核对佣金4 运营管理模块operation- 系统日常运维功能包括- BootUpController - 系统启动初始化- TimerManagement - 定时任务管理比如每天凌晨自动对账- StepConfig - 流程步骤配置审批流程怎么流转- SysParam - 系统参数配置- LogManage - 日志管理查问题- RefreshStaticData - 刷新静态数据比如更新营业厅列表- InterceptWhite - 拦截白名单管理- AutoFee - 自动扣费配置谁在用 系统管理员、运维人员5 发票管理模块invoice功能- OnceInvoice - 一次性费用发票开具- MssInvoice - MSS系统发票对接- SkuInvoiceQry - 按商品SKU查询发票场景 客户交完费要开发票就在这里操作6 电子账单模块dz功能- BankChargeSummary - 银行收费汇总- ReconciliationTask - 对账任务调度- UnilateralAcct - 单边账处理入口这是和对账模块配合使用的更偏向于自动化处理7 反欺诈查询QryListAntiFraud干什么的防止有人恶意欠费、套现、刷单等欺诈行为功能- 查询可疑交易- 风控规则校验- 验证码防刷RandomCode谁在用 风控专员、稽核人员8 无理由取消noReasonCancel场景客户办了业务想取消但不符合正常退订条件走特殊通道功能查询可取消的订单提交取消申请9 大额客户管理bigCust针对谁 VIP大客户、集团客户功能 特殊优惠政策、专属服务通道10 一次性费用退OneTimeFeeRefund和审批流程模块配合专门处理一次性费用的退费逻辑11 DCA分布式缓存相关dca/dcaEmergencyDCA是什么 电信内部的分布式缓存系统类似Redis功能- 缓存热点数据比如用户信息、资费标准- dcaEmergency- 应急模式缓存挂了时的降级方案12 文件下载expFileDownLoad功能 导出各种Excel、CSV文件- 支持大数据量导出- 带水印防泄露13 金库核查vaultCheck干什么的类似银行的双人复核机制敏感操作需要两个人确认才能执行场景 大额退费、批量调账等高风险操作14 其他辅助模块accountType 账户类型管理个人账户、企业账户等cardweb 卡券管理dccPay DCC支付对接fb 复机/停机相关业务jsonEncryption JSON数据加密传输common/commonFlow 通用流程和公共服务三、典型业务场景串联场景1客户退费全流程客户到营业厅 → 前台在系统发起退费申请OneFullRefund →上传证明材料 → 提交审批 →班组长审批 → 部门经理审批 → 财务审批 →审批通过后执行退费 → 生成退费记录 →财务报表统计 → 月底对账场景2每日对账流程凌晨定时任务自动对账TimerManagement →对比银行流水和电信账单 →发现10笔单边账 →财务人员登录系统查询UnilateralAcctQry →逐笔核实原因 →修正状态或批量返销fxUnilateralAcctPl →导出对账报告ExportCsv →归档保存场景3月度报表生成月初1号 → 财务点击生成月报OnceFeeReport →系统统计上月所有收费记录 →按营业厅、支付方式、账目类型分组 →生成Excel报表带水印 →同时生成PDF版本 →发送给各级管理者四、技术亮点与业务价值1. **多级审批流程** - 保证资金安全防止内部舞弊2. **自动化对账** - 每天处理百万级交易减少人工错误3. **报表水印** - 防止敏感数据外泄4. **金库核查** - 高风险操作双重确认5. **反欺诈监控** - 实时识别异常交易6. **分布式缓存** - 提升系统性能支撑高并发实习产出产出1审批流策略化项目里的审批流程对应不同的操作流每钟审批状态对应的操作流不一样- 提交校验金额 → 改状态为待审批 → 通知审批人- 通过改状态为已通过 → 执行退费 → 记日志- 拒绝改状态为已拒绝 → 记录拒绝原因 → 记日志- 退回改状态为已退回 → 记录退回原因 → 通知发起人如果用if-elseif (操作是提交) {// 写提交的逻辑50行代码} else if (操作是通过) {// 写通过的逻辑40行代码} else if (操作是拒绝) {// 写拒绝的逻辑30行代码} else if (操作是退回) {// 写退回的逻辑35行代码}// ... 以后还要加撤销、转交等等问题- 这个方法会越来越长现在4个操作就150行了- 新增操作要改这个方法违反开闭原则对扩展开放对修改关闭- 测试困难要测各种分支策略模式的核心思想3个角色角色1策略接口Strategy Interface通俗理解 就像一个做菜的标准规定每个策略必须有什么方法。为什么需要接口- 保证所有策略都有统一的方法名都叫execute- 调用方不需要知道具体是哪个策略只要调用execute就行角色2具体策略类Concrete Strategy通俗理解 每个具体的做菜方法比如川菜怎么做、粤菜怎么做。- 每个策略类只管自己的逻辑互不干扰- 都实现了同一个接口所以长得很像都有execute和getSupportedAction- 每个策略类都很短30-50行容易看懂角色3策略工厂Strategy Factory**通俗理解** 就像一个调度员根据客人点的菜找到对应的厨师。**为什么要工厂**- 调用方不需要知道有哪些策略只需要说我要SUBMIT操作- 工厂帮你找到对应的策略对象- 新增策略时工厂代码不用改Spring自动注入产出2退费流程模板方法重构一、 任务背景任务描述导师提了一个新需求增加“部分退费”功能。业务规则用户申请退还部分话费需要校验剩余金额不能为负且需要记录详细的退费明细。现有参考系统里已经有一个“全额退费”功能OneFullRefundService。行动路径1. 第一步模仿打开 OneFullRefundService 的代码照着写一个 OnePartRefundService。2. 第二步发现发现两个 Service 的代码结构惊人地相似都要查用户、都要校验权限、都要调底层接口、都要记日志、都要发通知。3. 第三步思考如果以后还有“违约金减免”、“赠款退回”难道还要再复制一遍4. 第四步行动决定提取一个抽象基类 AbstractRefundService用模板方法模式重构这两个业务并在此基础上完成“部分退费”的开发。二、 刚接手时的代码状态1. 现有的“全额退费”代码参考对象2. 原本打算写的“部分退费”代码如果不优化的话痛点如果这么提交了代码Code Review 时导师可能会说“这两段代码 80% 是一样的能不能抽一下”三、优化产出模板方法模式第1步定义抽象基类核心产出退费业务抽象基类 - 模板方法模式定义了退费流程的固定骨架校验 - 执行 - 后置处理public abstract class AbstractRefundService {Autowiredprotected RefundApi refundApi;Autowiredprotected LogService logService;Autowiredprotected NotifyService notifyService;/*** 模板方法定义流程骨架final 防止子类修改顺序*/public final MapString, Object executeRefund(MapString, Object params) {try {// 1. 统一前置校验validateCommonParams(params);// 2. 子类特有的业务校验checkBusinessRule(params);// 3. 执行核心退费逻辑boolean success doRefund(params);// 4. 统一后置处理postHandle(success, params);return success ? ResultUtil.success() : ResultUtil.fail(退费执行失败);} catch (BusinessException e) {return ResultUtil.fail(e.getMessage());} catch (Exception e) {logService.saveErrorLog(e);return ResultUtil.fail(系统异常);}}/*** 公共校验所有退费都要校验工号*/protected void validateCommonParams(MapString, Object params) {if (Tools.isNull(params.get(staffId))) {throw new BusinessException(工号不能为空);}}/*** 钩子方法业务规则校验子类必须实现*/protected abstract void checkBusinessRule(MapString, Object params);/*** 钩子方法执行核心退费子类必须实现*/protected abstract boolean doRefund(MapString, Object params);/*** 钩子方法后置处理子类可选重写默认记录日志和通知*/protected void postHandle(boolean success, MapString, Object params) {if (success) {logService.saveLog(getBizType() 成功, params);notifyService.sendMsg((String)params.get(staffId), getBizType() 已受理);}}/*** 获取业务类型名称用于日志*/protected abstract String getBizType();}第2步重构“全额退费”五、 在实习报告中这样描述 “在负责‘部分退费’接口开发时我观察到它与现有的‘全额退费’流程高度相似存在大量重复的校验和后置处理代码。 为了避免代码冗余并提升可维护性我引入了模板方法模式抽取了 AbstractRefundService 抽象基类 1. 固化流程将‘参数校验、核心执行、日志通知’定义为标准模板 2. 隔离变化将具体的业务规则和底层接口调用下沉到子类实现 3. 成果不仅完成了新接口开发还重构了旧代码使后续新增退费类业务的代码量减少了 60%并统一了全模块的日志规范。”产出3分布式锁对账任务调度一、 业务背景与目标背景电信 BSS 账务系统每天产生数十万笔缴费流水需与银行/第三方支付平台进行核对以发现“单边账”即一方记账成功而另一方失败的情况。痛点原系统在集群环境下存在多节点同时执行对账任务的风险导致银行接口被高频调用甚至封禁且容易产生重复的对账差异记录。目标开发一个稳定、高效的每日自动对账定时任务确保在多台服务器部署的情况下同一时间仅有一个节点执行对账逻辑并实现故障自愈。二、核心技术栈框架Spring Boot MyBatis中间件Redis (用于分布式锁)、FTP (用于获取银行流水)工具UUID (身份标识)、Scheduled (定时触发)三、完整业务流程叙述第一阶段任务触发与抢占凌晨 2:00定时触发Spring Scheduled 注解在预设时间唤醒所有集群节点的任务线程。生成身份标识每个节点启动时利用 UUID.randomUUID() 生成一个全局唯一的字符串作为自己的“身份证”。尝试加锁关键步骤节点向 Redis 发送原子命令SET lock:task:daily_reconciliation [UUID] NX EX 14400。NX (Not Exists)确保只有当锁不存在时才设置成功。EX (Expire)设置 4 小时过期时间防止节点宕机导致死锁。结果判断抢锁成功该节点获得执行权进入业务处理流程。抢锁失败说明其他节点正在执行本节点打印日志“任务已在其他节点运行”并直接退出释放资源。第二阶段核心对账逻辑执行由抢到锁的节点执行数据拉取通过 SFTP 协议从银行服务器下载昨日的对账单文件。数据清洗解析银行文件将其转换为系统内部标准的流水格式。逐笔碰撞遍历银行流水根据“交易流水号”在本地数据库查找对应的电信侧记录。比对结果金额一致则标记为“平账”不一致或找不到记录的标记为“差异”。结果入库将比对产生的差异记录存入 unilateral_acct单边账表并更新对账任务状态。第三阶段资源释放与善后异常捕获使用 try-catch 包裹整个业务逻辑确保即使对账过程中出现网络中断或数据异常程序也不会崩溃退出。身份校验解锁Finally 块无论任务成功与否最终都会进入 finally 块。节点先从 Redis GET 锁的 Value与自己的 UUID 比对。校验通过执行 DEL 删除锁释放资源供明天使用。校验失败说明锁已过期并被其他节点抢占此时放弃删除操作保护当前运行节点的安全性。四、我的优化产出与价值引入分布式锁机制解决了集群环境下的任务幂等性问题杜绝了重复对账带来的资损风险和接口压力。实现故障自愈通过设置合理的过期时间TTL彻底消除了传统数据库状态位方案中因服务器宕机导致的“死锁”隐患实现了无人值守的稳定运行。封装通用工具类开发了 RedisLockUtil 工具类将加锁、校验、解锁逻辑标准化为系统后续其他定时任务如静态数据刷新提供了可复用的解决方案。还有这个产出4动态规则配置化一、 核心痛点硬编码的“僵化”Before业务规则如退费阈值、超时时间直接写死在 Java 的 if-else 里。后果业务部门想改个数字技术部得走一周的发版流程。系统无法适应电信行业快速变化的运营策略。二、核心产出动态配置引擎的实现逻辑不仅仅是加了个缓存而是设计了一套“从数据库到业务逻辑的动态映射链路”。第一步规则的“抽象化”建模没有为每个规则建一张表而是设计了一个通用的 StepConfig 模型Key (规则标识)比如 REFUND_LIMIT_025南京地区退费限额。Value (规则内容)具体的数值或 JSON 字符串。Scope (作用域)支持按 LATN_ID地区、USER_LEVEL用户等级进行维度划分。第二步实现“智能路由”的读取逻辑在的 StepConfigService 中实现了一套**优先级匹配算法**public String getDynamicRule(String ruleKey, String latnId) {// 1. 【精准匹配】先查有没有针对该地区的特殊配置String value configMapper.selectByRuleAndLatn(ruleKey, latnId);if (value ! null) {return value; // 找到了“南京专属”规则}// 2. 【默认兜底】如果没有地区配置则查找全省/全局默认配置value configMapper.selectByRuleAndLatn(ruleKey, DEFAULT);return value;}亮点这套逻辑让系统具备了“千人千面”的能力。同样的退费接口南京用户和苏州用户可以走完全不同的审批流而代码只需要写一遍。第三步业务层的“无感接入”通过封装让业务开发人员感觉不到配置的复杂性Beforeif (amount 500 city.equals(Nanjing)) ...Afterif (amount stepConfig.getThreshold(REFUND, currentCity)) ...价值业务逻辑变得极其干净所有的“变数”都交给了配置中心管理。三、配套的“后台管理与同步”机制为了让配置动起来开发了 StepConfigController1. 可视化维护提供界面让运维人员直接增删改查规则支持批量导入。2. 变更通知当配置修改后利用 AOP 切面 或 事件监听自动触发缓存清理逻辑。逻辑Update DB - Publish Event - Clear DCA Cache。效果确保了全集群节点在几秒钟内全部切换到新规则。四、稳定性保障防穿透/击穿在动态读取的基础上增加了空值缓存和互斥锁确保在配置频繁变更或恶意查询时数据库依然稳如泰山。这个产出的核心价值负责的核心产出是‘动态规则加载引擎’。并没有简单地做一个 Key-Value 查询而是设计了一套支持多维度地区、用户群优先级匹配的 Config Service。1. 逻辑层面实现了从‘全局默认’到‘局部特例’的智能路由解决了电信业务复杂的差异化运营需求 2. 架构层面通过‘后台配置自动缓存同步’的闭环将业务规则的生效时间从‘周级’缩短到了‘秒级’ 3. 代码层消除了全系统超过 200 处硬编码的 If-Else极大地提升了代码的可维护性和系统的灵活性。”