DEMO 体验
| 演示环境 | 相关视频 |
|---|---|
| ⚡ 直达演示环境
☕ 账号：admin ☕ 密码：admin |
🎬 1. [数式Oinone] #产品化演示# 后端研发与无代码辅助
🎬 2. [数式Oinone] #产品化演示# 前端开发 🎬 3. [数式Oinone] #个性化二开# 后端逻辑 🎬 4. [数式Oinone] #个性化二开# 前端交互 🎬 5. [数式Oinone] #个性化二开# 无代码模式 |
我想说的话
要把订单系统推到 10 万级 TPS，关键不在某个“神奇参数”，而是整体性工程化：
- 热路径最短化：下单主链只保留“幂等校验 + 关键写入 + 事件投递”三件事；其他全部异步化（EIP 流控 + MQ + 任务编排/MCP）。
- 状态切分：把“可强一致的小状态”（订单行、支付单号、扣减快照）与“可最终一致的大状态”（库存聚合、积分、营销）分层与分区。
- 读写隔离与缓存：订单写入只打主库/主分片；读走只读副本 + Redis；冷数据落到存储（对象/归档）。
- 弹性与降级：K8s 横向扩、限流与自适应回退（Fallback），接口“先稳住，再追赶”。
- 全链路观测：把耗时分摊与阻塞点量化到每一类线程池、连接池与 SQL。
> 工具与能力锚点： > > * 读写分离 > * 蓝绿发布 > * 6.3 部署与依赖说明（镜像、JAR、前后端分离） > * EIP 开放应用支持流控（6.2 起） > * MCP（集成接口/开放接口/Function → MCP Tools，6.3） > * 涡轮启动加速（6.0）、虚拟字段/AI 设计器（6.1）
1. 目标设定与负载模型
目标指标建议（以峰值 10 万 TPS 为例）：
- SLO：平均 RT ≤ 40ms，P99 ≤ 120ms；错误率 ≤ 0.1%
- 稳定性：30 分钟以上持续压测无雪崩；滚更不丢单
- 成本意识：单 TPS 成本可核算并可线性扩容
负载抽象：
- 下单写入：50% 创建、20% 支付回调、15% 取消/关闭、15% 变更
- 查询读取：下单后 5 分钟内 10x 读放大（客户端轮询/页面刷新）
- 库存模型：热点 SKU 服从 Zipf 分布（0.8~1.0），需做热点保护
2. 参考架构（结合 Oinone 能力）
[API GW/Nginx/LB]
|
[Order-Service] —— 幂等校验、关键写入、事件Outbox
| \
| \--[RocketMQ/Kafka] <—— EIP 流控/MCP 编排任务
| \
[MySQL 主库/分片] [异步消费者：库存、营销、通知、日志、审计]
|
[只读副本] ——> [Redis Cluster] ——> 查询聚合（界面设计器/数据大屏）
- 编排层：用 EIP + MCP Tools 串联外部网关（支付、物流、风控）；把“慢资源”与“高时延链路”从热路径拆走。
- 服务拆分：订单、库存、营销、通知为相对独立的“可异步一致”域；工作流（加签、委托等）不入热路径，仅在运营介入场景触发。
- 前后端分离 & 容器化：采用 6.3 designer-backend / designer-frontend 镜像，K8s 弹性伸缩；灰度/蓝绿按社区文章实践。
3. 数据与表设计：写入可控、查询高效
3.1 表与索引
- 订单主表（order）：
order_id(PK, hash分片),biz_id(UNIQUE, 幂等),user_id,status,ts_create,ts_update - 订单明细（order_item）：
order_id + sku_id复合索引 - 支付表（payment）：
pay_id(UNIQUE),order_id索引 - 出库快照（stock_reserve）：
order_id + sku_id（用于超卖兜底）
> 规则： > > * 单表行数控制在 500 万以内（水平分表 + 分区），冷热拆分； > * 唯一约束保证幂等（biz_id/pay_id）； > * 大字段（备注、扩展 JSON）旁路到对象存储或扩展表。
3.2 读写拆分与缓存策略
- 写：只打主库，事务尽量短；
- 读：只读副本 + Redis（订单状态、聚合视图），以 TTL+主动失效为主；
- 热点 SKU：库存变更走 Lua 原子扣减（分桶/预热），溢出到队列回补。
4. 主链路（Hot Path）最小化
4.1 下单流程（同步）
- 幂等校验：按
biz_id先查唯一键； - 写入订单 + 预占库存快照（同事务）；
- 记录 Outbox 事件（订单创建/库存预占）并提交事务；
- 快速返回（RT 控制在 10~20ms。
4.2 异步链路（EIP + MQ + MCP）
- 库存实际扣减、营销核算、积分、消息通知、审计日志等全部异步化；
- 通过 EIP 流控配置并发度/重试/补偿；将开放接口/Function转为 MCP Tool 统一治理（6.3）；
- 支付回调同样走幂等 → Outbox → 异步分发；对账落在异步任务。
> 经验：把“跨系统/慢组件/不确定性”全部搬到 EIP/MCP，热路径只做“可确定且必要”的写入。
5. 关键参数与调优清单（可对表排查）
5.1 运行时（JVM/容器）
- Xms=Xmx，G1/GenZ（JDK17+）；观察 Young GC < 20ms，Full GC 0；
- 容器 CPU Request=Limit（避免 CFS 抖动），内存留 30% 给页缓存；
- Netty/Tomcat MaxThreads ≈
CPU核数 * 4~8；Backlog 与somaxconn、tcp_tw_reuse按吞吐调高。
5.2 连接池与线程池
- DB 连接池：
max-active = 8~16 * 实例CPU；max-wait ≤ 100ms； - MQ 消费并发：每分区 1~2 个线程，单线程单批量优先保证顺序/幂等；
- 异步池：按链路拆分池，拒绝策略一律走降级/队列溢出落盘（不要直接抛上层）。
5.3 MySQL
innodb_flush_log_at_trx_commit=1（强一致热路径）；- 热点更新表行大小 < 8KB；二级索引不超过 5 个；
- 慢 SQL 阈值 50ms，强制索引与回表次数监控。
5.4 Redis
- 使用 Cluster + Pipeline；热点键分桶：
stock:{sku}:{bucket}； - Key 空间：严格统一前缀（如
oinone:order:*）； - 过期策略：TTL + 主动失效消息（通过 Outbox 触发）。
6. 可靠性与一致性
- 幂等三件套：
biz_id唯一约束、去重缓存（短 TTL）、Outbox 防丢。 - 库存不超卖：扣减走 Redis Lua + 预占快照，最终以数据库对账为准；
- 事务边界：主链只做本地事务；跨域靠消息一致性（消费侧“幂等表”+ 去重键）。
- 工作流：审批/加签/委托在运营流程中，不要卡热路径；通过“任务交接/待办可视化”提升人工效率（6.3 新增能力）。
7. 部署与弹性（对齐 6.3 文档）
7.1 镜像/方式
-
体验/一体化/后端/前端专用镜像（6.3 提供 amd64/arm64）；
-
典型：
docker pull harbor.oinone.top/oinone/designer-backend-v6.3:6.3.0 docker pull harbor.oinone.top/oinone/designer-frontend-v6.3:6.3.0 -
前后端分离配合 K8s HPA，按CPU/RT双指标自动扩。
7.2 读写分离与蓝绿
-
按社区的 **《读写分离》与《蓝绿发布》**实践：
- 读流量只走从库，写只走主库；
- 蓝绿版本共存：登录态/权限/Redis 前缀隔离，LB 按权重切流，回滚成本低。
