背景：这件事我们做了十二年，不是接了两个外包就开始聊
我们在金边做软件开发十二年，团队28个人，每年交付的项目数量在一百个左右。客户分布在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚，主攻电商、娱乐、金融/交易、地产、物流五个方向。金融/交易类系统在业务占比里很重，股票融资系统是其中一块。我们有成品系统在几十家客户那里实际运营，不是做完验收就结束的那种一次性项目。下面写的每一个架构决策，都是这些年被真实业务问题逼出来的。有些坑，没跑过几十家客户根本意识不到。
股票融资系统的复杂度，和普通证券交易系统不在一个量级
普通证券交易系统能把下单和行情做好，基本就及格了。股票融资系统在这之上还要处理三件事：杠杆资金管理、实时风控强平、利息与费用清算。用户的保证金比例随着行情波动连续变化，一笔急跌可能同时触发几十个账户的预警线，系统要在极短时间内完成判断、通知、执行。这三件事不是三个独立模块，它们互相影响。风控慢一步，强平价格就差一截，强平价格差一截，用户亏损就放大，用户亏损放大，平台垫资风险就上来。后端架构、数据层、通信链路、风控引擎必须作为整体设计，单点优化解决不了问题。
后端拆服务，按业务域拆，不按技术层拆
用户服务管注册登录和实名认证，账户服务管保证金、配资额度和盈亏核算，订单服务负责买卖和平仓指令，风控服务实时盯保证金比例和持仓集中度，行情服务对接数据源并推送给客户端，清算服务在盘后处理利息和管理费。内部调用走gRPC，异步消息用RocketMQ。选RocketMQ不是因为它热门，是因为这个场景下消息不能丢，强平通知、额度冻结这类消息丢了就是资金事故。
订单服务的幂等设计是硬要求。用户连点两下买入，系统必须只成交一次。我们在订单入口用唯一请求ID做去重，配合账户服务的分布式事务处理，保证一笔订单要么完整执行，要么完全回滚。这个逻辑说起来简单，真到并发场景下，交易记录和资金流水两边的状态一致性才是难点。早年在柬埔寨本地机房部署时，网络抖动导致事务消息重复投递，账户流水出现过多笔重复入账，后来才把本地消息表和RocketMQ的事务消息机制结合起来做兜底。
事件驱动在这里是刚需。一笔下单动作会触发风控校验、额度冻结、行情推送、通知提醒等多个后续动作，如果同步串行执行，核心链路延迟会明显上升。把这些动作解耦成领域事件异步处理，交易链路只保留必须同步完成的部分。后面要加自动跟单之类的功能，不用去改订单服务核心代码，这个扩展性上的收益是实打实的。
数据层：实时快照和持久化记录分开处理
实时查询的量级和交易记录的量级完全不同。用户实时保证金比例、股票最新价这类数据，查询频率高、对延迟敏感，用Redis Cluster存实时持仓快照和行情缓存。风控服务本地用Caffeine缓存静态配置，比如杠杆倍数规则和禁买股票列表。缓存一致性靠RocketMQ广播通知各节点清理本地缓存，不用过期时间硬扛，配置变更能更快生效。
交易记录和资金流水必须满足ACID。这部分用MySQL主从架构，高频表按用户ID哈希分表。历史数据查询和年度对账单这类需求，用TiDB处理，实时写入和海量分析查询都能兼顾。行情Tick数据和系统监控指标写InfluxDB，配合Grafana做监控大屏，API响应时间和GC频率直接可视化。
交易链路的时间预算，是按环节分配的
用户下单的链路是：客户端先进Nginx做Lua限流，到API网关，再到订单服务做风控校验，账户服务冻结保证金，转发到券商接口，返回成交结果。整条链路设总超时，每个环节都记录Trace ID，用SkyWalking或Zipkin追踪。哪个环节超时了，拉出来就能定位。行情接入层用Netty构建TCP长连接，内部用Protobuf序列化降低带宽占用。行情数据经过去重、校验、补全之后，通过Redis Pub/Sub或Kafka分发给各业务模块。去重这一步很多人不当回事，但重复行情数据如果直接推进风控引擎，可能引发误报甚至错误强平。
风控引擎：静态规则和动态计算必须分开
静态规则是单只股票仓位上限、禁止ST股交易、杠杆倍数限制这类，用Drools规则引擎实现，运营人员在后台动态调整，不用改代码。动态规则是保证金比例跌破预警线通知追加保证金、跌破强平线自动平仓这类，用Flink实时计算，从Kafka消费行情和订单流，为每个用户维护独立状态机。
强平执行策略有三个点：优先卖出流动性好的股票，避免砸盘造成更大亏损；强平指令走独立队列，优先级高于普通订单；强平操作记录完整日志，给用户留申诉通道。第三点经常被忽略，但强平过程不透明，上线后一定会出纠纷。
安全合规是前置条件，不是验收时补的文档
用户资金隔离存放，平台只记录流水不碰钱。资金操作走双因子认证，转账请求过风控二次确认。敏感信息用AES-256加密存储，密钥由独立KMS管理，通信层强制TLS 1.3。审计日志保留至少5年，管理员在后台的每一步操作都要留痕。反洗钱监控模块对大额交易和频繁出入金自动报警，这是配合监管的基本配置。
支付通道的边界要提前讲清楚：支付通道由客户自己提供资源，我们负责技术对接，不提供支付通道。这个边界不在项目开始前说清楚，后面扯皮很麻烦。
性能优化上踩过的坑
账户服务高频查询用读写分离加查询缓存。复杂统计SQL，比如计算所有用户总风险暴露，用ClickHouse做定时预聚合，不要实时算。并发控制用Redisson分布式锁，锁粒度要尽量细。我们一开始锁整个用户ID，后来发现同一用户同时操作不同股票也会被锁住，改成锁user_id加stock_code的组合，并发能力立刻上来了。
网络层面选BGP机房，部署多地域节点，用Anycast DNS让用户自动接入最近节点。WebSocket长连接做连接池管理。架构上把连接管理和业务逻辑分离之后，单节点的连接上限相比混在一起部署有明显提升。具体并发连接数【此处待填：描述实际部署规模和机型配置】。
东南亚市场的部署和监管差异
客户覆盖的七个国家，网络环境和监管要求差异很大。有些地区国际链路不稳定，需要在国内和海外都部署节点做冗余。有些国家对数据本地化有要求，部署方案要跟着调整。这些不是纯技术问题，但会直接影响架构设计。比如某国的数据中心位置限制，决定了哪些服务必须部署在境内，哪些可以放境外，这会影响整个服务拆分方案。
电商和娱乐类系统我们有成品，开箱即用，交付快。股票融资系统这类金融产品复杂度高，开发周期上，小项目几天能交付，大项目大约两个月。报价按功能清单评估，面谈或Telegram详谈。付款先付30%，验收后结清尾款。服务响应上，Telegram分钟级回复，有AI运维辅助监控。系统bug修复免费，新增功能按工作量收费。服务语言是中文。
后续方向
量化交易和AI策略在东南亚市场正在起量，股票融资系统接下来大概率要集成智能跟单和算法交易模块。现在把事件驱动和领域拆分做好，后面加这些功能才不用重构。如果你正在规划或重构股票融资系统，可以Telegram上找我们聊。架构设计、风控策略、部署方案，这些都是我们实际交付过的范围。