背景与痛点

最近在写一个抢票程序。功能覆盖演出搜索、选座下单、支付回调、订单管理，麻雀虽小五脏俱全。一开始图省事，一个 Spring Boot 单机就上了controller / service / dao 按包分层。所有表塞在一个库，跑起来飞快。

痛点 1：并发压力失控

同一个演出场次、同一个价位，几百号人在倒计时结束的瞬间同时点“立即购买”。单机在这种并发下单已经吃力，更别说后面还有支付回调、订单超时取消、库存实时同步这些链路。程序能否“扛住”成为关键。

痛点 2：单体 成本高

继续往单机上堆内存、加线程池只能暂时缓解，成本指数级增长；不过，而业务上线速度受限于一次完整的部署。不过，

面对上述两条痛点。只有两条路可走：

• 继续在单体上硬件叠加
• 把程序拆成多个可独立部署的服务

最终我们选择了后者。

拆哪几块？——从业务上下文出发的分解思路

拆服务从来不是目的，而是手段。拆之前先回答几个关键问题：

• 哪些业务上下文是独立的、可以被单独部署？
• 哪些操作必须在同一个数据库事务里哪些可以最终一致？
• 并发热点在哪里能否通过服务隔离来分散？

主要服务划分

经过分析，我们最终将程序拆成以下 5 个主要微服务：

graph TB
Client --> Gateway
Gateway --> User
Gateway --> Program
Gateway --> Order
Gateway --> Pay
Gateway --> Common
User --- Nacos
Program --- Nacos
Order --- Nacos
Pay --- Nacos
Common --- Nacos
Program -.->|Feign| Order
Order -.->|Feign| User
Order -.->|Feign| Pay
Gateway -->|全局过滤器| Redis
Gateway -->|API 日志| Kafka
style Client fill:#f9f。stroke:#000
style Gateway fill:#ff9,stroke:#000
style Nacos fill:#9cf,stroke:#000
style Redis fill:#f66,stroke:#000
style Kafka fill:#fc6,stroke:#000

拆分原则：按业务能力纵向切，不要按技术层横向切。其实，

Pitfall提醒：最初我们计划再拆出“库存服务”。但库存和座位状态与节目数据耦合紧密，额外的 RPC 调用导致延迟增加。当拆分带来的延迟超过收益时就不要强行拆。

服务发现与调用机制

Nacos的观点是，注册 + 配置一把抓

为什么选 Nacos？从三字概括来看，够省事，

• Eureka 停更后需要分别搭配注册中心和配置中心；Nacos 一站式解决，两者合一。
• 自带控制台。可自动检测 MySQL 并切换持久化模式，无需额外中间层。
• 支持多环境多命名空间。只需通过环境变量切换前缀，实现灰度和多租户。

示例配置：

从spring来看，application:
说到name，${prefix.distinction.name:app}-program-service
至于cloud，nacos:
discovery:
server-addr: ${nacos.server}
username: admin
password: admin
从config来看。server-addr: ${nacos.server}
file-extension: yaml
shared-configs:
- data-id: common.yaml
refresh: true

环境变量切换示例：

// 所有 Feign Client 使用统一前缀
public static final String SPRING_INJECT_PREFIX_DISTINCTION_NAME =
"${prefix.distinction.name:app}";

在 staging 环境只需设置 PREFIX_DISTINCTION_NAME=app-staging。所有服务即注册为 app-staging-program-service,与开发环境天然隔离。

S​pring Cloud Gateway：不止是路由器，还承担防御与链路透传

1️⃣ 路由转发 + 动态负载均衡

spring这方面，cloud:
gateway:
从routes来看，- id: app-program-service
从uri来看，lb://app-program-service # 基于 Nacos 的 Service List + LoadBalancer
predicates:
- Path=/app/program/**
filters:
- StripPrefix=2 # 去掉 /app/program 前缀
- id: app-order-service
至于uri。lb://app-order-service
predicates:
- Path=/app/order/**
filters:
- StripPrefix=2

2️⃣ 全局防御

flowchart LR
A --> B{全局限流开关}
B -- on --> C
B -- off --> D
C --> E{方法白名单?其实，}
D --> E
E -- no --> F
F --> G
G --> H{API 限流?}
H -- yes --> I
I --> J
H -- no --> J

@Component
public class RequestValidationFilter implements GlobalFilter。Ordered {
@Override
public Mono filter(ServerWebExchange exchange,GatewayFilterChain chain) {
if ) {
rateLimiter.acquire;// Semaphore.tryAcquire，拿不到直接抛异常
}
// RSA 签名校验 + Token 校验 + API 细粒度限流略...
return chain.filter;不过，}
@Override public int getOrder { return -1;}
}

3️⃣ 链路透传

// FeignRequestInterceptor：所有 Feign 调用自动携带链路上下文
@Component
public class FeignRequestInterceptor implements RequestInterceptor {
@Override
public void apply {
RequestAttributes ra = RequestContextHolder.getRequestAttributes;if {
HttpServletRequest request = ra).getRequest;template.header);template.header);template.header);// 灰度参数 fallback 示例：
String gray = request.getHeader;if ) {
gray = serverGray;// 来自 ${spring.cloud.nacos.discovery.metadata.gray:false}
}
template.header;}
}
}

#Feign + 熔断：让跨服务调用像本地方法一样使用较稳定

@FeignClient(
value = SPRING_INJECT_PREFIX_DISTINCTION_NAME + "-order-service",fallback = OrderClientFallback.class)
public interface OrderClient {
@PostMapping
ApiResponse create;@PostMapping
ApiResponse status;}

feign这方面，okhttp:
enabled: true # 用 OkHttp 替代默认 HttpURLConnection，提高性能
hystrix:
enabled: true # 开启熔断降级
feign的观点是。compression:
request:
enabled: true # 请求体 gzip 压缩
response:
enabled: true # 响应体 gzip 压缩
java>
// 熔断降级实现示例：
@Component
public class OrderClientFallback implements OrderClient {
@Override
public ApiResponse create {
return ApiResponse.error;
按理说，// 简单返回程序错误。可进一步改造为 MQ 异步下单等策略
}
@Override
public ApiResponse status {
return ApiResponse.error;}
}

#横切关注点抽象为工程语言——注解+AOP实现锁与幂等 

@ServiceLock：锁对你而言就是一行注解 
@Target
@Retention
public @interface ServiceLock {
LockType lockType default LockType.Reentrant;String name default "";String keys，// SpEL 动态 Key 列表
long waitTime default 0L;TimeUnit timeUnit default TimeUnit.SECONDS;LockTimeOutStrategy lockTimeoutStrategy default LockTimeOutStrategy.FAIL;String customLockTimeoutStrategy default "";// 超时自定义兜底方法名
}
java>
// 切面主要原因：
@Aspect @Component public class ServiceLockAspect {
@Around")
public Object around(ProceedingJoinPoint pjp。ServiceLock servicelock) throws Throwable {
String lockName = lockInfoHandle.getLockName(pjp,servicelock.name,servicelock.keys);
 ServiceLocker locker = serviceLockFactory.getLock);其实，if (locker.tryLock(lockName,servicelock.timeUnit。servicelock.waitTime)) {
try { return pjp.proceed;}
finally { locker.unlock;}
}
// 超时处理：
if )) {
return handleCustom,pjp);}
servicelock.lockTimeoutStrategy.handler;return null，

}
}


使用示例

java)
// 对"节目+场次+票档"维度加可重入锁：
@ServiceLock(name = "PROGRAMORDERCREATE"。keys = {"#programId","#showTimeId","#ticketCategoryId"})
public String createOrder(Long programId,Long showTimeId,Long ticketCategoryId) {…}

// 对"订单号"维度加公平锁：
@ServiceLock(lockType = LockType.Fair。name = "ORDER_CANCEL",keys = {"#orderNumber"})
public void cancelOrder {…}


@RepeatExecuteLimit：防重提交的终极方案 

java)
@Target
@Retention
public @interface RepeatExecuteLimit {
String name default "";String keys，// SpEL 动态 Key 列表
long durationTime default 0L;// 幂等窗口期
String message default "提交频繁，请稍后重试";}


实现要点


Caffeine 本地锁先拦截同 JVM 内的重复请求，避免一次网络 IO。

If 本地未命中。再走 Redis 分布式锁/SETNX，实现跨实例幂等。不过，

`durationTime` 控制窗口期。例如设为 `3000` 表示 3 秒内只能成功一次。


java)
// 防重提交示例：
@RepeatExecuteLimit(name = "PROGRAM_ORDER_CREATE"。keys = {"#programId","#userId","#ticketCategoryId"},durationTime = 3000)
public String submitOrder {…}


#配套治理——让微服务安全平稳运行 

* 文档聚合 *

K​nife4j 在网关层开启聚合模式。将所有子服务的 OpenAPI 汇总到统一地址 /doc.html. 团队成员无需记住每个子程序的 Swagger 地址，只需在网关页面切换标签即可查看对应接口定义。话说回来，

yaml
knife4j:
gateway:
enabled: true # 开启聚合模式
strategy: discover # 自动发现 Nacos 上注册的所有微服务
discover:
version: openapi3 # 使用 OpenAPI v3 标准
enabled: true


* 全链路监控 *


S​pring Boot Admin：a 单独部署的监控中心。通过 Nacos 心跳上报各实例状态，包括 CPU、内存、线程池使用率还有 GC 情况。曾因忘记关闭 `ScheduledExecutorService` 导致内存泄漏，全靠 Admin 中持续上升的堆曲线定位问题。

K​afka & Redis 指标：K​afka 消费延迟、Redis QPS 在 Grafana 上实时展示，为容量规划提供依据。

L​og TraceID 链路追踪：K​ibana 配合 Logback MDC 输出统一 `TRACE_ID`，快速定位跨服务异常方法。


* 模块化依赖管理 *

xml

${revision}
${revision}
${revision}
${revision}
${revision}
${revision}


/* 子模块使用 */



${project.groupId}
${project.artifactId}-common-starter

${revision}





好处统一版本避免了“某个微服务因依赖不同版本导致序列化异常”的尴尬。

#小结 – 从单体到微服务的第一程已经完成 


"拆了什么": 使用者、节目、订单、支付及公共数据五大业务域；明确了不必强行拆出的库存子域。

"怎么发现的": 使用 Nacos 实现注册+配置统一管理；Gateway 完成动态路由与全局防御；Feign+Hystrix 提供声明式远程调用+熔断降级。

"怎么调用的": 基于 LoadBalancer 的无感知负载均衡；全链路 TraceID 与灰度标识通过 Header 自动透传。老实说，

"怎么防御的": 全局限流＋签名校验＋细粒度 API 限流；自研注解实现分布式锁 & 幂等控制，让业务代码保持干净.

"横切关注点如何抽象": 用 `@ServiceLock` 与 `@RepeatExecuteLimit` 两大注解配合 AOP。把锁和幂等逻辑从业务代码中剥离出来.

"配套治理": 文档聚合、监控、统一依赖管理确保团队协作顺畅.


后续我们将继续深挖技术细节，包括：


L​ua 原子库存扣减实现方案；

S​hardingSphere 分库分表踩坑经验；

P​抢票引擎四代演进路线图。老实说，