本篇是对 2025-05-19 到 2025-07-20 这段时间生活的记录和思考。
某灵工结算系统规划设计「内部记账本功能」，完成了需求分析、架构设计、代码开发、到最终的成功上线，但内心毫无成就感；
客户希望「结算平台」能够拥有独立的「内部记账本功能」，即同一个「主体账号」，系统基于「主体账号」给每一个客户创建独立的「虚拟子账号」；
举例：甲客户给「主体账号」 充值了 88 元，乙客户给「主体账号」 充值了 66 元，此时「主体账号」金额 154 元。「结算平台」要区分出来「主体账号」中 88 元属于甲客户的余额，66 元属于乙客户的余额。并且支持独立的转账、充值、提现等功能。
由于自己对「内部记账本」功能没接触过，所以没有经验。于是参考了一些技术文章，设计了出版的技术概要。
当刚了解到这个需求后，我做了如下分析：
通过分析，决定如下：
使用「腾讯在线文档」的智能表格来分配任务。
先新建一个「ALL-表格」，把所有任务罗列进去，便于全局查看任务。每个任务尽可能的控制在一人天，这样能够更加细粒度的把控任务进度。当出去任务延期时，也可快速察觉和纠正。
今天-看板：用来查看当天有哪些任务需要完成
本周-看板：用来查看本周有哪些任务需要完成，周维度查看直观的查看到本周的任务是否有堆积情况
未完成-看板：查看所有过期未完成的任务，次看板任务越多，就需要采取措施：投入更多的时间（加班）、投入更多的人力资源（加人 ）
姓名-看板：个人负责的任务看板，方便个人了解自己研发任务及计划
通过对需求的分析，编写了内部记账本概要设计，主要涵盖表设计、流程说明、余额设计、充值设计。
概要设计能够快速拉通与研发个人的认知偏差，统一代码实现逻辑。
内部记账本需要对接多结算渠道：招商、支付宝、平安……，并且都会调用各结算渠道的代发、代发状态查询、回执单下载等接口。
针对于各种类型的结算通道，使用枚举类。
@Getter
@AllArgsConstructor
public enum SettlementChannel {
CMB("CMB","招商银行"),
PAB("PAB","平安银行"),
ALI_PAY("ALI_PAY","支付宝");
private final String code;
private final String name;
}
对于不同结算渠道代发的实现方式不同，定义统一的接口，使用策略模式来获取对应的具体实现。
public interface Transfer {
/**
* 结算通道
* @return {@link SettlementChannel}
*/
SettlementChannel channel();
/**
* 代发
* @param request {@link TransferRequest}
* @return
*/
TransferResponse transfer(TransferRequest request);
}
@Component
public class TransferFactory implements InitializingBean {
@Resource
Collection<Transfer> transfers;
private Map<SettlementChannel, Transfer> transferMap;
public Transfer get(SettlementChannel channel) {
Transfer transfer = transferMap.get(channel);
if (Objects.isNull(transfer)) {
return null;
}
return transfer;
}
@Override
public void afterPropertiesSet() throws Exception {
this.transferMap = IterUtil.toMap(transfers, Transfer::channel);
}
}
余额存在同一时刻并发操作：支出、充值；所以余额变更需是线程安全的；
public class DefaultAccountBookLock implements AccountBookLock {
// 账户类
private volatile CashbookAccountBook cashbookAccountBook;
// 锁
private final ReentrantLock lock;
// 初始化
public DefaultAccountBookLock(CashbookAccountBook cashbookAccountBook) {
this.cashbookAccountBook = cashbookAccountBook;
this.lock = new ReentrantLock();
}
// 加锁
@Override
public void lock() {
lock.lock();
}
// 释放锁
@Override
public void unlock() {
lock.unlock();
}
}
定义AccountBookLock类，核心操作是ReentrantLock加锁和释放锁逻辑。一个账号对应一个锁。这样可保证在并发下线程是安全的。
@Slf4j
@Service
public class AccountBookManager implements AccountBook, InitializingBean {
// 账户锁
private final ConcurrentHashMap<String, AccountBookLock> accountLocks = new ConcurrentHashMap<>();
/**
* 创建账户，账户信息存并发安全的ConcurrentHashMap中
* @param cashbookAccountBook
* @return
*/
@Override
public void create(CashbookAccountBook cashbookAccountBook) {
accountLocks.computeIfAbsent(cashbookAccountBook.getAccountBookId(),
o -> new DefaultAccountBookLock(cashbookAccountBook));
}
// 代发
@Override
public void payroll(String accountBookId, BigDecimal rechargeAmount, BigDecimal frozenAmount) {
AccountBookLock accountBookLock = this.getAccountBookLock(accountBookId);
try {
accountBookLock.lock();
log.info(">>> [记账本][余额] 代发开始 | accountBookId={}", accountBookId);
// 代码逻辑......
log.info(">>> [记账本][余额] 代发结束 | accountBookId={}", accountBookId);
} finally {
accountBookLock.unlock();
}
}
private AccountBookLock getAccountBookLock(String accountBookId) {
AccountBookLock accountBookLock = accountLocks.get(accountBookId);
if (accountBookLock == null) {
log.error("[记账本][余额] 账户不存在 | accountBookId={}", accountBookId);
throw new ServiceException("账户不存在");
}
return accountBookLock;
}
@Override
public void afterPropertiesSet() throws Exception {
// 初始化数据
for (CashbookAccountBook accountBook : list) {
this.create(accountBook);
}
}
}
AccountBookManager统一对外操作余额接口，先使用「accountBookLock.lock()」方法对方法加锁，业务逻辑执行结束后，在 finally 代码块中释放锁「accountBookLock.unlock()」，从而实现了对余额进行增或减的线程安全操作。
针对每一次大版本的迭代上线，一定要考虑如何当上线版本出现重大问题，如何快速回退到上一个版本。
6 月底完成了研发测试工作，7 月 18 日迭代上线。
当晚上线还算比较顺利，上线后系统稳定运行，未出现结算多发、少发、余额不一致情况。
上一份周报停留在 2025-05-18 那一周，大部分原因是由于「内部记账本」研发周期严重偏离了原计划。导致自己大部分时间都投入到研发工作中，没有太多心思和精力去写博客了。
研发周期严重偏离计划有如下原因：
原计划中，我是「项目管理」的角色。但后期又以研发的角色加入项目，编写了：
从本次项目，我收获到：
2016 年 7 月 17 日，完成了「志邦7·17」现场抽奖大屏项目。当时成就感满满，那种发自内心的开心和喜悦是无法用言语表达出来的。
2025 年 7 月 18 日，「内部记账本」成功上线；内心却毫无波澜，没有任何成就感。即使「内部记账本」的技术难度比「志邦7·17」高了好几个 Level，也并不会因为技术提升而感到骄傲。
我不知道这种状态是否正常，我也不知道什么样的工作任务，能让我找到之前「成就感」的初心。
虽然大部分有意思的输入会在 「Lucky’s Footprints」 Telegram 频道里自动同步，不过还是挑选一部分在这里列举一下。并且把 Telegram Channel 消息作为内容源搭建了一个微博客 —— 「daily.gentlelucky.com」，可以更方便浏览了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。