一、基础架构规范
目标:定义系统底层技术栈的选型、部署架构及核心组件配置标准,保障系统稳定性和扩展性。
1.1 技术栈选型约束
层级 | 技术组件 | 版本要求 | 说明 |
---|---|---|---|
基础环境 | JDK | 1.8 | 统一 JDK 版本,避免因版本差异导致的兼容性问题 |
Spring Boot | 2.7.x | 遵循 LTS 版本,兼容 Spring Cloud Alibaba 2021.0.x 及以上 | |
Spring Cloud Alibaba | 2021.0.x | 与 Spring Boot 2.7.x 兼容,提供注册中心、配置中心等核心能力 | |
注册与配置 | Nacos | 2.2.x | 作为注册中心(服务发现)和配置中心(动态配置),需集群部署保证高可用 |
流量控制 | Sentinel | 1.8.x | 集成至 Spring Cloud Alibaba,提供流量熔断、降级、系统保护能力 |
链路追踪 | Sleuth + Zipkin | Sleuth 3.1.x + Zipkin 2.24.x | 基于 OpenTelemetry 标准,实现全链路调用链监控 |
内部通信 | Feign | Spring Cloud OpenFeign 3.1.x | 声明式 HTTP 客户端,简化服务间调用 |
数据存储 | Druid | 1.2.x | 数据库连接池,提供监控、慢 SQL 分析能力 |
ORM | MyBatis-Plus | 3.5.x | 基于 MyBatis 扩展,简化 CRUD 操作,禁止直接编写 XML(除非复杂查询) |
日志 | Logback | 1.2.x | 统一日志框架,输出结构化日志(JSON 格式) |
应用监控 | Micrometer + Prometheus + Actuator | Micrometer 1.9.x | 采集应用指标(如 QPS、RT、错误率),通过 Prometheus 存储,Grafana 展示 |
消息中间件 | RocketMQ/RabbitMQ | RocketMQ 5.0.x/RabbitMQ 3.9.x | 异步解耦,支持事务消息(RocketMQ 优先) |
数据库 | MySQL 8.x / 高斯数据库 | MySQL 8.0+ | 关系型数据库,主从复制保证高可用;高斯数据库用于大数据量分析场景 |
缓存 | Redis | 7.0.x | 分布式缓存,支持分布式锁、限流,集群模式部署(主从+哨兵) |
搜索引擎 | Elasticsearch | 8.6.x | 全文检索,支持日志分析、商品搜索等场景 |
1.2 部署架构规范
目标:定义容器化部署、服务编排及网络通信标准,保障环境一致性和高可用。
1.2.1 容器化规范
- 容器引擎:统一使用 Docker 18.x 版本,镜像基于 Alpine 轻量级基础镜像(减少资源占用)。
- 镜像命名:
仓库地址/服务名:版本号
(如registry.example.com/order-service:v1.0.0
)。 - 容器配置:
- CPU/内存限制:根据服务负载设置(如
requests.cpu=500m, requests.memory=1Gi
;limits.cpu=1, limits.memory=2Gi
)。 - 健康检查:通过
docker exec
执行curl -f http://localhost:8080/actuator/health
验证服务存活。
- CPU/内存限制:根据服务负载设置(如
1.2.2 容器编排(K8s)规范
- 命名空间:按环境划分(
dev/test/prod
),服务名需包含环境标识(如order-service-dev
)。 - 服务发现:通过 K8s Service 实现内部服务发现,外部流量通过 Ingress 网关暴露。
- 副本策略:核心服务副本数 ≥ 3,非核心服务 ≥ 2,保障高可用。
- 资源配额:命名空间设置资源配额(如
requests.cpu=4, limits.cpu=8
),避免资源竞争。
二、开发规范
目标:规范代码编写、接口设计、依赖管理等开发行为,提升代码质量和可维护性。
2.1 代码分层规范
严格遵循 MVC + 领域驱动设计(DDD) 分层,不建议跨层调用,层级职责明确:
层级 | 职责 | 技术约束 |
---|---|---|
controller | 接收外部请求,参数校验,调用 Service 层,返回响应 | 使用 @RestController ,参数通过 @Valid 校验(JSR-303) |
service | 业务逻辑处理,事务管理(@Transactional ),调用 Manager 或外部服务 |
禁止直接操作数据库,复杂逻辑封装至 Manager 层;事务范围最小化(避免长事务) |
manager | 核心业务逻辑封装,协调多个 DAO 或外部服务调用 | 纯 Java 逻辑,无 HTTP/DB 操作;可调用 Feign 客户端或 RocketMQ 生产者 |
dao | 数据库操作(MyBatis-Plus) | 使用 BaseMapper 扩展方法,禁止编写原生 SQL(复杂查询用 XML 或 QueryDSL) |
model | 数据实体(DO/DTO/VO) | DO 对应数据库表(@Data + @TableName );DTO 用于接口入参/出参;VO 用于前端展示 |
2.2 接口设计规范
- 协议与格式:
- 内部服务调用:HTTP/REST(Feign)或 gRPC(可选),优先使用 HTTP/JSON(简单易用)。
- 入参/出参:统一使用
CommonRequest<T>
和CommonResponse<T>
包装(示例见下文)。
// 通用请求体(含链路追踪 ID) public class CommonRequest<T> { private String traceId; // 由 Gateway 注入 private T data; // 业务数据 } // 通用响应体(标准化错误码) public class CommonResponse<T> { private int code; // 0=成功,非0=错误码(参考 ErrorCodeEnum) private String message; // 错误信息 private T data; // 业务数据 }
- 接口命名:
- RESTful 风格:
GET /api/{service}/{resource}
(查询)、POST /api/{service}/{resource}
(新增)、PUT /api/{service}/{resource}/{id}
(修改)、DELETE /api/{service}/{resource}/{id}
(删除)。 - 示例:
GET /api/order-service/orders/{orderId}
(查询订单详情)。
- RESTful 风格:
2.3 Feign 客户端规范
- 声明式调用:使用
@FeignClient
定义客户端,接口方法与远程服务接口一一对应。@FeignClient( name = "inventory-service", contextId = "inventoryClient", configuration = FeignConfig.class // 自定义配置(如超时、编解码器) ) public interface InventoryFeignClient { @PostMapping("/inventory/deduct") CommonResponse<Boolean> deductInventory(@RequestBody DeductDTO deductDTO); }
- 超时与重试:
- 超时:全局配置
feign.client.config.default.connectTimeout=5000ms
(连接超时)、readTimeout=10000ms
(读取超时)。 - 重试:仅对幂等接口(如查询)启用重试,使用
Spring Retry
(@Retryable(maxAttempts=3)
),避免无限重试。
- 超时:全局配置
- 降级处理:通过
@FeignClient(fallback = InventoryFallback.class)
定义降级逻辑,返回预设的CommonResponse
。
2.4 MyBatis-Plus 规范
- CRUD 操作:
- 新增:使用
baseMapper.insert()
(自动生成主键,需@TableId(type = IdType.AUTO)
)。 - 查询:使用
QueryWrapper
构造条件(禁止SELECT *
,明确指定字段)。
// 正确示例:查询有效订单(status=1) QueryWrapper<Order> queryWrapper = new QueryWrapper<>(); queryWrapper.eq("status", 1).orderByDesc("create_time"); List<Order> orders = orderMapper.selectList(queryWrapper);
- 新增:使用
- 复杂查询:超过 3 个条件的查询,使用 XML 或 QueryDSL(禁止拼接原生 SQL)。
- 分页:统一使用
Page
对象(IPage<Order> page = orderService.page(new Page<>(current, size), queryWrapper)
)。
2.5 依赖管理规范
- 禁止循环依赖:通过
@Lazy
延迟加载或重构代码解决(如拆分公共模块)。 - 版本统一:所有依赖版本通过
spring-cloud-dependencies
管理(pom.xml
中不写死版本号)。
三、设计规范
目标:定义核心功能(认证、熔断、追踪、日志等)的设计标准和实现方案,保障系统可靠性和可观测性。
3.1 认证与授权设计
- 方案:JWT(JSON Web Token) + OAuth 2.0,流程如下:
- 登录:用户调用
auth-service/login
,验证账号密码后生成 JWT(包含user_id
、role
、exp
)。 - 传参:客户端请求头携带
Authorization: Bearer <JWT>
。 - 校验:Gateway 通过
AuthFilter
拦截请求,调用auth-service/verify
校验 JWT 有效性(缓存校验结果,降低 RPC 调用)。 - 鉴权:网关根据 JWT 中的
role
字段,结合@PreAuthorize("hasRole('ADMIN')")
实现接口级权限控制。
- 登录:用户调用
- 安全增强:
- JWT 密钥存储在 Nacos 配置中心(避免硬编码)。
- 敏感接口(如支付)启用二次验证(短信验证码)。
3.2 流量控制与熔断设计
- Sentinel 集成:
- 资源定义:以 Feign 客户端方法、Controller 接口为单位(通过
@SentinelResource
注解)。 - 规则存储:规则配置在 Nacos(
sentinel-flow-rules.json
),动态推送至服务。 - 熔断策略:
- 异常比例:当接口异常比例 ≥ 50%(
exceptionRatio=0.5
)时,触发熔断(降级返回)。 - 异常数:10s 内异常数 ≥ 20(
exceptionCount=20
)时,触发熔断。
- 异常比例:当接口异常比例 ≥ 50%(
// Feign 接口熔断示例 @FeignClient( name = "payment-service", fallback = PaymentFallback.class ) public interface PaymentFeignClient { @SentinelResource( value = "pay", fallback = "payFallback", blockHandler = "payBlockHandler" ) CommonResponse<String> pay(@RequestBody PayDTO payDTO); } // 降级方法(返回预设值) public CommonResponse<String> payFallback(PayDTO payDTO, Throwable ex) { return CommonResponse.error("PAY_001", "支付服务繁忙,请稍后再试"); }
- 资源定义:以 Feign 客户端方法、Controller 接口为单位(通过
3.3 链路追踪设计
- 集成 Sleuth + Zipkin:
- 自动埋点:Sleuth 自动为 HTTP 请求、Feign 调用、数据库操作生成
traceId
和spanId
。 - 手动打标:关键业务节点(如“库存扣减成功”)通过
Tracer
手动添加标签。
// 手动埋点示例 @Autowired private Tracer tracer; public void createOrder() { Span currentSpan = tracer.currentSpan(); if (currentSpan != null) { currentSpan.tag("orderId", "ORD_001"); // 添加业务标签 currentSpan.tag("userId", "123"); } }
- 自动埋点:Sleuth 自动为 HTTP 请求、Feign 调用、数据库操作生成
- 日志关联:通过 MDC(Mapped Diagnostic Context)将
traceId
注入日志,确保跨服务日志可追踪。// Gateway 拦截器注入 traceId public class TraceFilter implements GlobalFilter { @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { String traceId = exchange.getRequest().getHeaders().getFirst("X-Trace-Id"); if (traceId == null) { traceId = UUID.randomUUID().toString(); } MDC.put("traceId", traceId); // 注入 MDC return chain.filter(exchange); } }
3.4 日志设计
- 格式规范:统一使用 JSON 格式,包含
traceId
、service
、level
、message
等必填字段。{ "traceId": "6b3b3a3c3d3e3f404142434445464748", "service": "order-service", "level": "INFO", "logger": "com.example.order.controller.OrderController", "message": "订单创建成功,orderId=ORD_001", "timestamp": 1690000000000, "userId": "123", "orderId": "ORD_001" }
- 存储与检索:
- 日志收集:Filebeat 采集应用日志,发送至 Logstash 过滤(如提取
traceId
、service
),最终存储至 Elasticsearch。 - 检索:Kibana 创建仪表盘(如错误日志统计、慢接口排名),支持按
traceId
跨服务查询完整链路日志。
- 日志收集:Filebeat 采集应用日志,发送至 Logstash 过滤(如提取
四、运维规范
目标:定义监控、告警、部署、故障排查等运维行为,保障系统稳定运行。
4.1 监控指标规范
- 应用指标(Prometheus 采集):
- 核心指标:
http_server_requests_seconds_count
(请求量)、http_server_requests_seconds_max
(最大耗时)、jvm_memory_used_bytes
(JVM 内存)。 - 自定义指标:业务成功率(如
order_success_rate
)、缓存命中率(如redis_hit_rate
)。
- 核心指标:
- 环境指标(Prometheus 采集):
- 容器指标:CPU 使用率、内存使用率、网络流量。
- 数据库指标:QPS、连接数、慢 SQL 数(通过 Druid 监控页面)。
4.2 告警规则规范
- 紧急告警(触发即时通知):
- 服务宕机(
up == 0
)。 - 数据库主节点不可用(
mysql_global_status_uptime < 60
)。 - 消息中间件堆积量 > 10万(RocketMQ
storeMessageCount
)。
- 服务宕机(
- 重要告警(触发邮件/钉钉通知):
- 接口错误率 > 5%(
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m])) / sum(rate(http_server_requests_seconds_count[5m])) > 0.05
)。 - 缓存命中率 < 80%(
sum(rate(redis_keyspace_hits_total[5m])) / (sum(rate(redis_keyspace_hits_total[5m])) + sum(rate(redis_keyspace_misses_total[5m]))) < 0.8
)。
- 接口错误率 > 5%(
4.3 部署与发布规范
- CI/CD 流程(GitLab CI/Jenkins):
- 开发人员提交代码至
dev
分支,触发单元测试(覆盖率 ≥ 80%)。 - 合并至
release
分支,触发集成测试(验证服务间调用)。 - 打标签(如
v1.0.0
),触发生产环境部署(K8skubectl apply -f deployment.yaml
)。
- 开发人员提交代码至
- 灰度发布:新版本上线时,通过 K8s Service 的
subset
实现流量逐步切量(如 10%→30%→100%)。
4.4 故障排查规范
- 常见问题定位:
- 服务无响应:检查 Sentinel 熔断规则是否触发(
http://sentinel-dashboard:8080
)、Pod 状态(kubectl get pods
)。 - 接口超时:查看链路追踪(Zipkin)确认慢节点,检查数据库慢 SQL(Druid 监控)。
- 数据不一致:通过分布式事务日志(Seata)或消息队列(RocketMQ)追踪消息投递状态。
- 服务无响应:检查 Sentinel 熔断规则是否触发(
五、工具与平台规范
目标:定义开发、测试、运维过程中使用的工具平台及其操作标准,提升效率。
5.1 构建与依赖管理
- 构建工具:Maven(优先)或 Gradle,统一使用
mvn clean package -DskipTests
打包。 - 依赖检查:定期使用
mvn dependency:analyze
检查冗余依赖,移除未使用的库。
5.2 代码质量保障
- 静态扫描:SonarQube 集成至 CI 流程,强制修复代码异味(如重复代码、圈复杂度 > 10)。
- 单元测试:使用 JUnit 5 + Mockito,覆盖核心业务逻辑(如
OrderService.create()
),覆盖率报告提交至 SonarQube。
5.3 容器与编排工具
- Docker:镜像构建使用
Dockerfile
(多阶段构建减少体积),推送至私有仓库(Harbor)。 - K8s:通过
kubectl
或 Helm 管理部署,禁止直接修改 Pod 配置(通过 YAML 声明式更新)。
附:关键技术配置示例
5.1 Nacos 注册与配置(bootstrap.yml
)
spring:
application:
name: order-service
cloud:
nacos:
discovery:
server-addr: nacos-server:8848 # 集群地址(nacos1:8848,nacos2:8848,nacos3:8848)
cluster-name: DEFAULT_CLUSTER
config:
server-addr: nacos-server:8848
file-extension: yaml
shared-configs:
- data-id: common.yml # 公共配置
group: DEFAULT_GROUP
refresh: true # 动态刷新
5.2 Sentinel 流量控制规则(Nacos 存储)
// sentinel-flow-rules.json(Nacos 配置)
[
{
"resource": "com.example.order.controller.OrderController.create",
"limitApp": "default",
"grade": 1, // QPS 阈值
"count": 100,
"strategy": 0, // 直接拒绝
"controlBehavior": 0
}
]
5.3 SkyWalking 链路追踪(agent.config
)
# skywalking-agent.conf
agent.service_name=order-service # 服务名(与 Nacos 一致)
collector.backend_service=oap-server:11800 # OAP 地址
总结
本规范覆盖了微服务开发的全生命周期(架构设计→编码实现→测试部署→运维监控),结合 Spring Cloud Alibaba 技术栈的特性,明确了各层级的技术约束和最佳实践。实际落地时需根据业务场景调整细节(如调整 Sentinel 规则阈值、扩展日志字段),并通过持续监控和迭代优化保障系统稳定性。