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 下单流程（同步）

1. 幂等校验：按 biz_id 先查唯一键；
2. 写入订单 + 预占库存快照（同事务）；
3. 记录 Outbox 事件（订单创建/库存预占）并提交事务；
4. 快速返回（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 按权重切流，回滚成本低。

---

8. 观测与容量规划

指标面板（必须有）：

• 网关：QPS、2xx/5xx、上游 RT、重试率
• 应用：线程池队列深度、拒绝次数、GC、错误分类
• DB：QPS/TPS、等待事件（锁/IO/Buffer）、慢 SQL 列表
• MQ：消息堆积、消费 RT、重试/死信
• Redis：命中率、慢日志、热键警报

容量估算（粗略公式）：

• 可承载TPS ≈ 实例数 * (每实例并发 * 单请求成功率) / P99耗时因子
• 峰值膨胀系数 ≥ 3（双十一式突刺）；
• 以单实例可承载 3~5k TPS为基线，推算副本数。

---

9. 压测方法（可复现）

1. 数据准备：按真实 SKU 分布造数，热度 Zipf；

2. 脚本设计：JMeter/Locust

   • 50% 下单，30% 查单，10% 支付回调，10% 取消/关闭；
   • 下单携带 biz_id（UUID），断网/重放模拟；

3. 分阶段：

   • 烟测（1k TPS）→ 梯度提升（5k/10k/…）→ 30 分钟稳态；
   • 每一档记录：平均/中位/P95/P99、错误率、关键池/队列深度；

4. 定位与优化：

   • 若 P99 飙高，优先看等待（锁/连池/队列）而非 CPU；
   • 慢 SQL → 改索引/覆盖索引/去 N+1；
   • 队列溢出 → 扩副本 + 分桶 + 降级开关。

---

10. 配置样例

数据源（读写分离）

datasource:
  master:
    url: jdbc:mysql://order-master:3306/order_db
  slave:
    url: jdbc:mysql://order-slave:3306/order_db
redis:
  prefix: oinone:order:

启用 MCP（6.3）

pamirs:
  boot:
    modules:
      - eip_mcp

库存 Lua（示意）

-- KEYS[1]=stock:{sku}:{bucket} ARGV[1]=num
local stock = tonumber(redis.call('GET', KEYS[1]) or "0")
if stock >= tonumber(ARGV[1]) then
  return redis.call('DECRBY', KEYS[1], ARGV[1])
else
  return -1
end

---

11. 常见“致命坑”

• 把工作流/审批放进下单主链 → 高峰期卡死
• 幂等只做缓存、数据库不加唯一约束 → 雪崩时穿透
• Redis 单实例/单分片承担全部热点 → 热键抖动
• 线程池共用（生产者/消费者/HTTP）→ 互相拖垮
• 蓝绿切换不做登录态/权限前缀隔离 → 混淆/越权

---

12. 收尾：落地顺序建议（两周可见效）

1. 一键压测基线：先跑出你当前的 30 分钟稳态曲线；
2. 主链收敛：把热路径“只留三件事”；
3. 索引与慢 SQL：一轮专项治理；
4. EIP/MCP 异步化：把跨系统操作全部搬走；
5. 读写分离 + Redis：读流量全迁只读与缓存；
6. 蓝绿/灰度：把“变更风险”降到 0；
7. 容量与报警：把扩容和熔断脚本固化到流水线。

① 系统总体架构（解耦 + 编排 + 异步）

flowchart LR
  subgraph Client["客户端/渠道"]
    H5 -->|下单| API
    APP -->|查单| API
  end

  API["API GW / LB"] --> ORD["Order-Service (热路径)"]
  ORD -->|事务提交+Outbox| DB[(MySQL 主库/分片)]
  ORD -->|只读查询| RO[(只读副本)]
  ORD -->|热数据| RDS[(Redis Cluster)]

  ORD -- "EIP 流控/MCP 调用" --> MQ[(RocketMQ/Kafka)]
  MQ --> INV["Inventory-Service (扣减/回补)"]
  MQ --> MKT["Marketing-Service (优惠/积分)"]
  MQ --> NOTI["Notify-Service (站内/短信/邮件)"]
  MQ --> AUD["Audit-Service (日志/审计)"]

  subgraph Oinone["Oinone 平台能力"]
    EIP["EIP 集成设计器<br>（并发/重试/补偿）"]
    MCP["MCP Tools（开放接口/Function 编排）"]
    WF["工作流（非热路径/运营）"]
  end

  ORD -. 使用 .- EIP
  EIP -. 编排/触发 .- MCP
  WF -. 人工干预/运营 .- MKT

  RO --&gt; BI[数据可视化/大屏]
  RDS --&gt; BI

② 下单热路径与异步链路时序

sequenceDiagram
  participant C as Client
  participant API as API GW
  participant O as Order-Service
  participant DB as MySQL(主)
  participant R as Redis
  participant MQ as RocketMQ/Kafka
  participant I as Inventory-Service

  C->>API: POST /orders (bizId)
  API->>O: 转发请求
  O->>DB: 幂等查询(bizId)
  DB-->>O: 不存在
  O->>DB: 订单写入 + 预占快照(同事务)
  O->>DB: Outbox 事件写入
  DB-->>O: 提交成功
  O-->>API: 200 OK (RT 10~20ms)
  API-->>C: 下单成功

  O->>MQ: 投递"ORDER_CREATED"
  MQ->>I: 异步消费(扣减库存)
  I->>R: Lua 扣减/分桶
  I->>DB: 对账/最终一致

---

数据与代码骨架

订单/明细/预占快照（DDL 精简版，按需分片/分区）

CREATE TABLE `order` (
  `id` BIGINT PRIMARY KEY,
  `biz_id` VARCHAR(64) NOT NULL UNIQUE,
  `user_id` BIGINT NOT NULL,
  `status` TINYINT NOT NULL,
  `ts_create` DATETIME(3) NOT NULL,
  `ts_update` DATETIME(3) NOT NULL,
  KEY `idx_user_time` (`user_id`, `ts_create`)
) /* 分区/分片策略按业务设定 */;

CREATE TABLE `order_item` (
  `id` BIGINT PRIMARY KEY,
  `order_id` BIGINT NOT NULL,
  `sku_id` BIGINT NOT NULL,
  `qty` INT NOT NULL,
  KEY `idx_order_sku` (`order_id`,`sku_id`)
);

CREATE TABLE `stock_reserve` (
  `id` BIGINT PRIMARY KEY,
  `order_id` BIGINT NOT NULL,
  `sku_id` BIGINT NOT NULL,
  `qty` INT NOT NULL,
  `state` TINYINT NOT NULL, -- 0:预占 1:已扣 2:回滚
  UNIQUE KEY `uk_order_sku` (`order_id`,`sku_id`)
);

Redis Lua（热点分桶原子扣减）

-- KEYS[1]=stock:{sku}:{bucket} ARGV[1]=num
local stock = tonumber(redis.call('GET', KEYS[1]) or "0")
if stock >= tonumber(ARGV[1]) then
  return redis.call('DECRBY', KEYS[1], ARGV[1])
else
  return -1
end

Outbox 事件模型（示例）

CREATE TABLE `outbox_event` (
  `id` BIGINT PRIMARY KEY,
  `aggregate_id` BIGINT NOT NULL,
  `type` VARCHAR(64) NOT NULL,   -- ORDER_CREATED 等
  `payload` JSON NOT NULL,
  `status` TINYINT NOT NULL,     -- 0:NEW 1:SENT 2:FAILED
  `ts_create` DATETIME(3) NOT NULL,
  KEY `idx_status_time` (`status`,`ts_create`)
);

Order-Service 事务片段（伪代码）

@Transactional
public Order create(OrderCmd cmd) {
  if (orderRepo.existsByBizId(cmd.bizId())) return orderRepo.byBizId(cmd.bizId());
  Order order = buildOrder(cmd);
  orderRepo.save(order);
  stockReserveRepo.saveAll(snapshot(order)); // 预占快照
  outboxRepo.save(new OutboxEvent(order.getId(), "ORDER_CREATED", payload(order)));
  return order;
}

---

Oinone 平台配置片段（对齐 6.3 能力）

启用 EIP + MCP 模块

pamirs:
  boot:
    modules:
      - eip_mcp   # 6.3 新增
spring:
  redis:
    prefix: oinone:order:
datasource:
  master: { url: jdbc:mysql://order-master:3306/order_db }
  slave:  { url: jdbc:mysql://order-slave:3306/order_db }

EIP 流控（示例，按你的命名调整）

eip:
  flows:
    order-created:
      concurrency: 128
      retry:
        maxAttempts: 5
        backoff: 50ms
      steps:
        - name: inventory-deduct
          tool: mcp://inventory/deduct
        - name: marketing-apply
          tool: mcp://marketing/apply
        - name: notify
          tool: mcp://notify/send

---

运行时与连接池参数（基线）

server:
  tomcat:
    threads:
      max: 400          # CPU核数 * 4~8
    accept-count: 200

spring:
  datasource:
    hikari:
      maximum-pool-size: 128      # 8~16 * 实例CPU，按DB承载回压
      minimum-idle: 32
      max-lifetime: 300000        # 5min
      connection-timeout: 100     # ms
  task:
    execution:
      pool:
        core-size: 64
        max-size: 256
        queue-capacity: 2000
      shutdown:
        await-termination: true
        await-termination-period: 30s

MySQL 关键项

innodb_flush_log_at_trx_commit = 1
innodb_buffer_pool_size       = 物理内存的 50%~60%
max_connections               = 2k~5k（视连接池总量）
long_query_time               = 0.05  # 50ms

---

压测脚本骨架

Locust（推荐，简单易改） locustfile.py

from locust import HttpUser, task, between
import uuid, random, json

HOT_SKUS = [10001,10002,10003,10004,10005]

class OrderUser(HttpUser):
    wait_time = between(0.1, 0.3)

    @task(5)
    def create_order(self):
        biz_id = str(uuid.uuid4())
        items = [{"skuId": random.choice(HOT_SKUS), "qty": 1}]
        self.client.post("/api/orders", json={"bizId": biz_id, "items": items}, name="create-order")

    @task(3)
    def query_order(self):
        # 真实环境可从 Redis/文件缓存最近订单ID
        oid = random.randint(1_000_000, 2_000_000)
        self.client.get(f"/api/orders/{oid}", name="get-order")

    @task(2)
    def notify_payment(self):
        pay_id = str(uuid.uuid4())
        self.client.post("/api/pay/callback", json={"payId": pay_id}, name="pay-callback")

JMeter（极简 TestPlan 片段，XML 可导入后补齐线程数/CSV）

<testplan enabled="true" testname="Oinone-Orders">
  <hashtree>
    <threadgroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="TG-CreateOrder">
      <stringprop name="ThreadGroup.num_threads">500</stringprop>
      <stringprop name="ThreadGroup.ramp_time">10</stringprop>
      <longprop name="ThreadGroup.duration">1800</longprop>
    </threadgroup>
    <hashtree>
      <httpsamplerproxy guiclass="HttpTestSampleGui" testname="POST /api/orders" enabled="true">
        <stringprop name="HTTPSampler.method">POST</stringprop>
        <stringprop name="HTTPSampler.path">/api/orders</stringprop>
        <stringprop name="HTTPSampler.postBodyRaw">true</stringprop>
        <elementprop name="HTTPsampler.Arguments" elementtype="Arguments">
          <collectionprop name="Arguments.arguments">
            <elementprop name="" elementtype="HTTPArgument">
              <boolprop name="HTTPArgument.always_encode">false</boolprop>
              <stringprop name="Argument.value">{"bizId":"${__UUID()}","items":[{"skuId":10001,"qty":1}]}</stringprop>
            </elementprop>
          </collectionprop>
        </elementprop>
      </httpsamplerproxy>
    </hashtree>
  </hashtree>
</testplan>

> 建议：压测脚本按 50% 下单 / 30% 查单 / 10% 回调 / 10% 取消 比例配权重；并用 Zipf 分布造热点 SKU。

---

K8s 弹性与限流

HPA（CPU + RT 自定义指标二选一，示例为 CPU）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 8
  maxReplicas: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

Deployment 关键片段

resources:
  requests: { cpu: "2", memory: "4Gi" }
  limits:   { cpu: "2", memory: "4Gi" }  # 避免 CFS 抖动
livenessProbe:  { httpGet: { path: /actuator/health, port: 8080 }, initialDelaySeconds: 20 }
readinessProbe: { httpGet: { path: /actuator/ready,  port: 8080 }, periodSeconds: 3 }

Nginx 入口级限流（防抖与热点保护）

limit_req_zone $binary_remote_addr zone=perip:10m rate=50r/s;
limit_req_status 429;

server {
  location /api/ {
    limit_req zone=perip burst=100 nodelay;
    proxy_pass http://order_svc;
  }
}

---

蓝绿发布关键片段（对齐社区实践）

不同环境 Redis 前缀隔离

spring:
  redis:
    prefix: oinone:blue:
# green 环境改为：oinone:green:

Nginx 权重切流（AB 共存，可回滚）

upstream order_upstream {
  server order-blue:8080 weight=90;
  server order-green:8080 weight=10;
}
server {
  location /api/ { proxy_pass http://order_upstream; }
}

---

观测与告警（上墙指标最少集）

• 入口层：总 QPS、2xx/4xx/5xx、上游 RT、重试率
• 应用层：线程池队列深度/拒绝次数、GC（Young<20ms，无 Full）、错误率
• DB：TPS/QPS、等待事件（锁、IO）、慢 SQL 列表（>50ms）、回表次数
• MQ：堆积量、消费 RT、重试/死信
• Redis：命中率、慢日志、热键（Keyspace hits/misses、top N keys）

故障优先级排查顺序：等待（锁/连接/线程）→ 慢 SQL → 队列/池容量 → CPU/GC → 网络/磁盘。

---

上线核对清单（最终版）

一、热路径最小化

• [ ] 同步只做：幂等校验 + 关键写入 + Outbox
• [ ] 跨系统/慢资源已搬到 EIP/MCP 异步链路
• [ ] 工作流不在热路径（仅运营介入）

二、数据与缓存

• [ ] 订单/明细索引命中，单表 < 500 万
• [ ] 读写分离生效；只读查询走副本
• [ ] Redis 使用 Cluster，Key 规范：oinone:order:*
• [ ] 热点 SKU 分桶 + Lua 原子扣减

三、参数与容量

• [ ] Hikari 连接池最大值 = 8~16 × CPU
• [ ] 线程池分域（HTTP/异步/消费）不共用
• [ ] HPA 生效；单实例基线 3~5k TPS，副本充足
• [ ] Nginx/网关限流开关已配置

四、灰度与回滚

• [ ] 蓝绿 Redis 前缀隔离、登录态安全
• [ ] AB 权重切流可控，回滚脚本就绪
• [ ] 数据变更 DDL 已评审并有回滚 SQL

五、观测与压测

• [ ] 仪表盘上线：入口/应用/DB/MQ/Redis 五大面
• [ ] 30 分钟稳态压测：P99、错误率、队列深度达标
• [ ] 故障演练：限流/熔断/节点淘汰可用