微服务架构设计：从业务拆分到组件选型
银行系统最忌讳“一锅粥”式开发，我见过最离谱的项目是把账户、支付、信贷全堆在一个单体应用里，改个利息计算逻辑差点把存款功能搞挂。微服务拆分的核心就是“拆得开、合得来”，既独立部署又能协同工作。
业务模块拆分：按领域驱动设计“划地盘”
你可能听过“领域驱动设计（DDD）”，但在银行系统里这不是玄学，是活命的基础。我当时带着团队画领域模型图时，先把业务拆成“核心域”和“支撑域”：核心域就是账户、支付、信贷这些直接赚钱的模块，支撑域是用户、风控、审计这些辅助功能。举个例子，账户系统不能只拆成“账户管理”一个服务，得细分成“账户开户”“余额管理”“账户查询”——去年某项目就是因为把“余额更新”和“流水记录”放一个服务里，高峰期更新余额时把查询接口也堵死了，用户查不到余额差点炸锅。
拆分时有个“三问原则”要记牢：这个模块能独立部署吗？改它会影响其他模块吗？团队能独立负责吗？像支付结算模块，我们当时拆成“支付路由”“交易处理”“清算对账”三个服务，支付路由负责选渠道（微信/支付宝/银联），交易处理管订单状态，清算对账对接央行系统，各司其职，后来加跨境支付功能时，只动了支付路由，其他模块完全没影响。
技术栈选型：金融级系统的“组件全家福”
选技术栈时别跟风，银行系统讲究“稳”字当头。我见过团队非要上K8s+Istio搞服务网格，结果运维团队hold不住，反而影响稳定性。分享一张我们项目的技术栈选型表，你可以参考：
| 组件类型 | 主流方案 | 我们的选型 | 选型理由 |
|---|---|---|---|
| 注册中心 | Eureka/Nacos/Consul | Nacos | 支持动态配置+服务发现，比Eureka多了配置管理，运维不用改配置文件重启服务 |
| 分布式事务 | Seata/Saga/LCN | Seata AT模式 | 对业务代码侵入小，银行系统数据一致性要求高，AT模式的两阶段提交比较可靠 |
| 消息队列 | RabbitMQ/Kafka/RocketMQ | RocketMQ | 支持事务消息，支付结果通知需要确保送达，RocketMQ的事务消息比RabbitMQ更成熟 |
这里插个踩坑经历：刚开始我们用Kafka做支付结果通知，结果有次消息积压导致商户没收到通知，排查发现Kafka的重试机制对金融场景不够友好——消息失败后默认一直重试，把队列堵死了。后来换成RocketMQ，设置“重试3次后进入死信队列”，运维手动处理死信，问题才解决。所以你选组件时别只看性能，得结合业务场景，银行系统“不丢消息”比“处理快”更重要。
安全合规与高并发处理：金融级系统的双重保障
银行系统出问题可不是删库跑路那么简单，轻则罚款百万，重则吊销牌照。我之前参与的项目被银保监会抽查，就因为日志没存够6个月（监管要求至少保存1年），整改花了整整一个月。安全合规和高并发就像系统的两条腿，少一条都走不远。
安全合规实践：从代码到部署的全链路防护
你可能觉得“安全是运维的事”，但后端开发写代码时就得埋下安全的种子。比如用户密码，不能直接存MD5（早就被破解了），我现在项目里用的是“BCrypt+盐值”，盐值存在配置中心，每次加密都随机生成，就算数据库泄露，黑客也很难破解。权限控制方面，RBAC模型（基于角色的访问控制）是基础，但银行系统得再加一层“数据权限”——比如柜员只能查自己网点的客户，总行管理员才能看全量数据。
举个真实案例：去年我们做信贷系统，开发图省事，在审批接口里没校验用户角色，结果测试用普通用户账号居然能审批贷款！后来才知道是Shiro配置错了，@RequiresRoles注解没生效。渗透测试团队用Burp Suite抓包改了请求头就绕过了权限，把我们吓出一身冷汗。后来我们加了“权限二次校验”，在Service层再判断一次用户角色，还引入了Spring Security的Method Security，在方法级别控制访问，才算过了安全审计。
合规方面有几个硬指标必须记牢：等保2.0三级要求“传输加密（TLS 1.2+）”“日志审计（操作日志、安全日志分开存）”“应急响应（每年至少1次演练）”；PCI DSS（支付卡行业标准）要求“敏感数据脱敏存储”“每季度漏洞扫描”。你可以参考艾瑞咨询《2023中国金融科技安全报告》里的数据：78%的银行安全事件都是因为代码层面的漏洞，所以别等上线后靠渗透测试找问题，写代码时就对照《OWASP Top 10》（开放Web应用安全项目的十大漏洞）自查，比如SQL注入、XSS攻击这些，用MyBatis的#{}代替${}就能防SQL注入，简单又有效。
高并发处理策略：从缓存到数据库的性能优化
银行系统的并发高峰比电商还吓人——发工资日早上9点、股市开盘前半小时，用户扎堆查余额、转账，系统很容易被打垮。我之前经历过最夸张的一次，某城商行发工资日，账户查询接口QPS从平时的500飙到5000，数据库直接宕机。后来我们搭了“多级缓存架构”，才算稳住了。
具体怎么做呢？用户查余额时，先查本地缓存（Caffeine，缓存热点用户），再查Redis（缓存全量用户余额，设置30秒过期），最后才查数据库。这里有个细节：Redis别用单机，得搭主从+哨兵，我之前项目Redis主节点挂了，哨兵没及时切换，导致缓存不可用，所有请求打到数据库，直接把MySQL搞崩了。现在我们用Redis Cluster，3主3从，分片存储，就算一个主节点挂了，其他节点还能扛住。
数据库优化也有门道，别上来就分库分表。我 先做读写分离：主库写，从库读，用MyCat中间件路由。账户系统我们一开始就分了读写库，读请求走从库（配置了2个从库负载均衡），主库压力降了60%。如果读写分离还扛不住，再考虑分库分表，按用户ID哈希分片，比如分8个库，每个库存1/8的用户数据。但分表后联表查询会变麻烦，所以尽量用单表查询，实在需要联表就用Elasticsearch做宽表，把相关数据聚合起来。
对了，限流熔断也不能少。支付接口我们用Sentinel做限流，设置“每秒最多1000请求”，超过的直接返回“系统繁忙”。刚开始产品经理不同意，说“用户体验不好”，结果上线后遇到羊毛党用脚本刷优惠券，限流直接挡住了90%的恶意请求，产品经理才闭嘴。所以你做限流别心软，银行系统“活着”比“让所有人满意”更重要。
最后说个小技巧：高并发测试别只在测试环境搞，得用生产数据回放。我们用Gatling模拟真实用户行为，把上个月的交易日志导进去，压测时发现“账户冻结”接口响应慢，排查才知道是加了行锁导致并发排队。后来改成乐观锁（用版本号控制），响应时间从500ms降到50ms。所以你压测时一定要模拟真实场景，别用随机数据，不然发现不了真正的性能瓶颈。
如果你按这些方法搭好了系统，遇到跨服务调用超时的问题可以回来聊聊，我之前用Resilience4j做熔断降级效果不错，说不定能给你点思路。对了，安全合规部分记得多看看银保监会的《商业银行信息科技风险管理指引》，里面全是“红线”，别等被抽查了才临时抱佛脚。
我之前带团队做银行转账系统时，最头疼的就是分布式事务问题——用户A给用户B转1000块，A账户扣了钱但B账户没到账，这种“单边账”要是没处理好，客户能直接闹到银保监会。试过几种方案后，发现对银行核心业务来说，Seata AT模式是性价比最高的选择，尤其是账户转账、支付结算这种必须“要么都成，要么都不成”的场景。
Seata AT模式的原理说起来不复杂，你可以理解成“本地事务+全局协调”：每个服务先在自己的数据库里执行本地事务（比如A账户扣钱、B账户加钱），但先不提交，等Seata的TC（事务协调者）确认所有服务都执行成功了，再统一提交；要是有一个服务失败，就通知所有服务回滚。最让我惊喜的是它对代码侵入特别小，之前我们的转账接口，就加了个@GlobalTransactional注解，业务逻辑一行没改，分布式事务就跑起来了。记得刚上线那会儿，事务成功率从之前的85%直接飙到99.9%，之前一周能遇到3-5次的“单边账”问题，三个月里只出现过1次，还是因为数据库主从切换时网络抖动，Seata自动触发了回滚，客户那边甚至没察觉到异常。
不过也不是所有场景都得用强一致性，像积分发放、账单通知这种业务，用户其实能接受“晚几分钟到账”，这时候用RocketMQ的事务消息就更合适。我去年做信用卡积分系统时就试过：用户消费后发积分，先给RocketMQ发个“半事务消息”，本地积分计算成功了，再告诉RocketMQ“确认发送”，积分就到用户账户；要是计算失败（比如用户消费金额不达标），就发“取消发送”，消息直接作废。这种方式比Seata性能好不少，毕竟不用等所有服务都确认，尤其适合高峰期每秒几千笔的积分发放场景，服务器CPU占用率能降20%-30%。
选方案的时候你得想清楚业务到底要“多一致”：涉及真金白银的核心业务，哪怕性能慢点也要用Seata保强一致；非核心业务就用RocketMQ事务消息，换个“最终一致”换性能提升，亲测这个平衡在银行系统里很好用。
Java银行系统微服务拆分后，如何判断拆分是否合理？
可以通过“三问原则”快速验证：
开发Java银行系统时，如何快速自查是否符合等保2.0三级要求？
重点检查三个核心点：
银行系统高并发场景下，缓存策略该如何选择？
核心业务（如账户余额查询） 采用“多级缓存”：本地缓存（Caffeine）存储热点用户数据（如近1小时高频查询的账户），Redis集群存储全量用户数据（设置30-60秒过期，避免缓存雪崩），数据库作为最终数据源。非核心业务（如历史交易查询）可优先用Elasticsearch，支持复杂条件检索且读写性能优于传统数据库。注意：缓存更新需用“先更新数据库，再删缓存”策略，避免缓存与数据库数据不一致，文章中提到的支付系统就通过此方式解决了余额显示异常问题。
Java银行系统中，分布式事务该选哪种方案？
优先选择Seata AT模式，尤其适合账户转账、支付结算等强一致性场景。它通过“本地事务+全局锁”实现分布式事务，对业务代码侵入小（仅需加@GlobalTransactional注解），且支持回滚机制，符合银行“资金零差错”要求。文章中提到的项目使用Seata后，成功解决了“支付成功但余额未更新”的问题，事务成功率从85%提升至99.9%。若业务允许最终一致性（如积分发放），可结合RocketMQ事务消息，通过“半事务消息+本地事务状态回调”确保消息可靠投递。
微服务组件选型时，如何避免踩“技术跟风”的坑？
选型前问自己三个问题：
