系统架构设计实战：从单体到微服务的演进之路

引言

在互联网高速发展的今天，系统架构已经从最初的单体应用演进到如今的微服务、云原生架构。每一次架构演进，都是为了应对业务规模扩张、团队协作效率、系统可维护性等挑战。

本文将通过神话公司B2C平台的真实案例，系统地介绍互联网公司系统架构的演进路径、微服务拆分的方法论，以及一个完整的互联网公司应该具备哪些核心系统。

为什么要做架构演进？

业务规模扩张: 从几千用户到千万级用户，单体架构无法支撑
团队协作效率: 几十人的开发团队，代码冲突频繁，发布效率低下
系统可维护性: 代码耦合严重，改一处动全身，测试和部署成本高昂
技术栈灵活性: 不同模块需要不同的技术栈，单体架构难以支持
故障隔离性: 一个模块出问题，整个系统崩溃

第一章：架构演进历程

1.1 单体架构时代

什么是单体架构？

单体架构（Monolithic Architecture）是指将所有业务功能集中在一个应用中，所有代码打包成一个可执行文件或WAR包部署。
单体应用 (Monolithic Application)
用户界面

User Interface
业务逻辑层

Business Logic
数据访问层

Data Access Layer
数据库

Database
用户

单体架构的优点:

✅ 开发简单: 所有代码在一个项目中，IDE支持好，调试方便
✅ 部署简单: 一个包部署到一台服务器即可
✅ 测试简单: 启动一个应用就能测试全部功能
✅ 技术栈统一: 只需要掌握一套技术栈

单体架构的缺点:

❌ 代码耦合严重: 模块边界不清晰，修改一处影响多处
❌ 部署效率低: 改一行代码也要重新部署整个应用
❌ 扩展性差: 无法针对单一模块扩容，只能整体扩容
❌ 技术栈固定: 难以引入新技术，技术债务累积
❌ 团队协作困难: 多人修改同一个代码库，冲突频繁

适用场景:

初创公司，业务规模小（< 10万用户）
团队规模小（< 10人）
业务逻辑简单，模块较少
快速验证商业模式（MVP阶段）

1.2 垂直拆分阶段

当业务规模增长到一定程度，单体架构的问题开始显现。垂直拆分是第一步优化方案。

什么是垂直拆分？

按照业务领域将单体应用拆分为多个独立的应用，每个应用负责一个或多个相关的业务模块，拥有独立的数据库。
垂直拆分架构
用户
Web应用
用户系统

User Service
商品系统

Product Service
订单系统

Order Service
支付系统

Payment Service
用户数据库

User DB
商品数据库

Product DB
订单数据库

Order DB
支付数据库

Payment DB

垂直拆分的优点:

✅ 业务隔离: 不同业务模块相互独立，故障隔离
✅ 独立部署: 每个系统可以独立发布，互不影响
✅ 数据库隔离: 每个系统独立数据库，避免单点故障
✅ 技术栈灵活: 不同系统可以选择不同技术栈
✅ 团队独立: 不同团队负责不同系统，减少协作成本

垂直拆分的缺点:

❌ 重复代码: 各系统存在大量重复的通用功能（如权限、日志）
❌ 服务间调用: 需要通过HTTP/RPC调用，增加网络开销
❌ 数据一致性: 跨系统事务难以保证
❌ 运维复杂度: 需要管理多个应用、多个数据库

拆分原则:

按业务领域拆分: 用户、商品、订单、支付等核心领域
高内聚低耦合: 系统内部功能紧密相关，系统之间尽量减少依赖
数据独立: 每个系统拥有独立的数据库，避免共享数据库
接口清晰: 定义明确的系统间接口，避免直接操作其他系统数据库

1.3 SOA服务化阶段

垂直拆分解决了业务隔离的问题，但带来了新的挑战：重复代码、服务治理、服务间通信。SOA（面向服务架构）应运而生。

什么是SOA？

SOA（Service-Oriented Architecture，面向服务架构）是一种软件设计风格，将应用的不同功能单元（服务）通过定义良好的接口和协议联系起来。
SOA架构
权限管理
日志监控
消息通知
Web应用
ESB企业服务总线
用户服务

User Service
商品服务

Product Service
订单服务

Order Service
支付服务

Payment Service
通用服务

Common Service
权限中心
日志中心
消息中心

SOA的核心概念:

ESB（企业服务总线）: 统一的服务通信总线，负责路由、转换、编排
服务注册与发现: 服务启动时注册到注册中心，调用方从注册中心发现服务
服务治理: 限流、熔断、降级、监控
服务编排: 将多个服务组合成一个业务流程

SOA的优点:

✅ 服务复用: 通用功能抽取为服务，避免重复开发
✅ 服务治理: 统一的服务管理、监控、限流、熔断
✅ 协议标准化: 统一的通信协议（如SOAP、RESTful）
✅ 业务编排: 通过ESB灵活编排业务流程

SOA的缺点:

❌ ESB成为瓶颈: 所有请求都经过ESB，容易成为性能瓶颈
❌ ESB过于复杂: 配置复杂，学习成本高
❌ 服务粒度不清晰: 缺乏明确的服务拆分方法论
❌ 技术栈厚重: 通常采用WebService、SOAP等厚重的协议

1.4 微服务架构

SOA解决了服务治理的问题，但ESB的中心化架构成为瓶颈。微服务架构去中心化，彻底解决了这个问题。

什么是微服务？

微服务架构是一种将单个应用拆分为一组小型服务的架构风格，每个服务运行在独立的进程中，服务间通过轻量级通信机制（通常是HTTP RESTful API）互相协调。
微服务架构
用户
API网关

Gateway
用户中心

User Service
商品中心

Product Service
订单中心

Order Service
支付中心

Payment Service
营销中心

Marketing Service
服务注册中心

Nacos/Consul
MySQL
MySQL
MySQL
MySQL
Redis
配置中心

Config Server
链路追踪

SkyWalking

微服务架构的核心特征:

服务粒度小: 每个服务只负责一个业务领域
独立部署: 每个服务可以独立部署、升级、扩展
去中心化治理: 没有中心化的ESB，服务间直接通信
轻量级通信: 使用HTTP REST、gRPC等轻量级协议
数据库独立: 每个服务拥有独立的数据库
自动化运维: 依赖CI/CD、容器化、服务编排

微服务 vs SOA:

特性	SOA	微服务
服务粒度	粗粒度，一个服务包含多个业务模块	细粒度，一个服务对应一个业务能力
通信方式	ESB中心化，SOAP/WebService	去中心化，HTTP REST/gRPC
数据管理	共享数据库	每个服务独立数据库
服务治理	中心化治理（ESB）	去中心化治理（服务网格）
技术栈	统一技术栈	多语言、多技术栈
部署方式	传统部署	容器化、K8s编排
团队组织	按技术栈划分团队	按业务领域划分团队

微服务架构的优点:

✅ 服务独立: 每个服务可以独立开发、测试、部署、扩展
✅ 技术异构: 不同服务可以选择最适合的技术栈
✅ 故障隔离: 一个服务故障不影响其他服务
✅ 团队自治: 团队可以独立决策，提高效率
✅ 容错性强: 通过熔断、降级、限流保证系统稳定性

微服务架构的挑战:

❌ 复杂度提升: 分布式系统的复杂度远高于单体系统
❌ 数据一致性: 分布式事务难以保证
❌ 服务间通信: 网络延迟、超时、失败处理
❌ 运维成本: 需要完善的监控、日志、链路追踪
❌ 测试复杂: 需要测试服务间的集成

案例:

神话公司全面转向微服务架构，按照领域驱动设计（DDD）拆分了8个核心域：

基础平台域: 用户中心、认证中心、权限中心、API网关、组织中心、配置中心、消息中心

商品域: 商品中心、类目中心、库存中心、价格中心

交易域: 购物车、订单中心、支付中心、结算中心

营销域: 促销中心、优惠券中心、会员中心、积分中心

内容域: CMS、评价中心、搜索服务、推荐服务

履约域: 仓储中心、物流中心、售后中心

运营域: 运营平台、客服系统、工单系统、风控系统

数据域: 数据仓库、BI系统、日志分析、实时监控

1.5 云原生与服务网格

微服务架构解决了业务拆分的问题，但带来了新的挑战：服务间通信、服务治理、可观测性 。云原生 和服务网格应运而生。

什么是云原生？

云原生（Cloud Native）是一种构建和运行应用的方法论，充分利用云计算的优势，使应用更具弹性、可扩展性和容错能力。

云原生的核心技术:

容器化（Container）: Docker、Containerd
服务编排（Orchestration）: Kubernetes、Docker Swarm
微服务（Microservices）: Spring Cloud、Dubbo
服务网格（Service Mesh）: Istio、Linkerd
声明式API: Kubernetes API
不可变基础设施: 镜像化部署，版本控制

什么是服务网格？

服务网格（Service Mesh）是一个基础设施层，用于处理服务间通信。将服务间通信的复杂性从应用代码中剥离，下沉到基础设施层。
服务网格架构 (Istio)
Service C
Service B
Service A
App C
用户
Ingress Gateway
App A
Envoy Sidecar A
App B
Envoy Sidecar B
Envoy Sidecar C
Control Plane

Istio Pilot
Telemetry

Prometheus

服务网格的核心功能:

流量管理: 路由、负载均衡、灰度发布、流量镜像
安全: mTLS、认证、授权
可观测性: 指标收集、日志收集、分布式追踪
策略执行: 限流、熔断、重试、超时
服务发现: 自动发现和注册服务

云原生架构的优点:

✅ 弹性伸缩: 根据负载自动扩缩容
✅ 故障自愈: 容器崩溃自动重启
✅ 声明式部署: 通过YAML定义期望状态，系统自动实现
✅ 多云部署: 支持混合云、多云部署
✅ DevOps: 完善的CI/CD流水线

1.6 架构演进总结

业务规模增长

团队协作困难
重复代码

服务治理
ESB瓶颈

粒度不清晰
运维复杂

可观测性
单体架构
垂直拆分
SOA架构
微服务架构
云原生架构

架构演进的驱动力:

阶段	用户规模	团队规模	核心痛点	解决方案
单体架构	< 10万	< 10人	快速上线，验证商业模式	单体应用
垂直拆分	10万-100万	10-30人	代码耦合，部署效率低	按业务拆分系统
SOA架构	100万-500万	30-100人	重复代码，服务治理	ESB、服务注册中心
微服务	500万-千万级	100-500人	服务粒度，技术栈灵活性	微服务、API网关、服务网格
云原生	千万级以上	500人以上	弹性伸缩，多云部署	Kubernetes、服务网格、DevOps

关键启示:

⚠️ 不要过度设计: 初创公司不要一上来就搞微服务，先用单体架构验证商业模式

⚠️ 渐进式演进: 架构演进是一个渐进的过程，不要想着一步到位

⚠️ 业务驱动: 架构演进的驱动力是业务规模和团队规模，不是为了技术而技术

⚠️ 权衡取舍: 任何架构都有优缺点，要根据自己的情况做出权衡

第二章：微服务拆分方法论

微服务拆分是一门艺术，拆得太粗会失去微服务的优势，拆得太细会增加系统复杂度。本章介绍基于**领域驱动设计（DDD）**的微服务拆分方法论。

2.1 领域驱动设计（DDD）

什么是DDD？

领域驱动设计（Domain-Driven Design，DDD）是一种软件设计方法论，强调软件设计应该围绕业务领域展开，而不是技术实现。

DDD的核心概念:
战术设计 (Tactical Design)
实体

Entity
值对象

Value Object
聚合

Aggregate
聚合根

Aggregate Root
领域服务

Domain Service
领域事件

Domain Event
仓储

Repository
战略设计 (Strategic Design)
领域

Domain
子域

Subdomain
核心域

Core Domain
支撑域

Supporting Domain
通用域

Generic Domain
限界上下文

Bounded Context
上下文映射

Context Mapping

DDD战略设计:

领域（Domain）: 公司的业务范围，如电商、金融、物流
子域（Subdomain）: 领域的细分，如电商包含商品、订单、支付、物流
核心域（Core Domain）: 公司的核心竞争力，如电商的推荐算法
支撑域（Supporting Domain）: 支撑核心域的业务，如库存管理
通用域（Generic Domain）: 通用的功能，如用户认证、权限管理
限界上下文（Bounded Context）: 明确的业务边界，每个上下文有独立的领域模型

DDD战术设计:

实体（Entity）: 具有唯一标识的对象，如用户、订单
值对象（Value Object）: 没有唯一标识的对象，如地址、金额
聚合（Aggregate）: 一组相关的实体和值对象，如订单聚合（订单+订单明细）
聚合根（Aggregate Root）: 聚合的入口，如订单聚合的订单实体
领域服务（Domain Service）: 不属于任何实体的业务逻辑
领域事件（Domain Event）: 领域中发生的事件，如订单创建事件
仓储（Repository）: 领域对象的持久化接口

神话公司的领域划分:
神话B2C电商平台
支撑
支撑
支撑
下单
履约
促销
基础平台域

Infrastructure Domain
商品域

Product Domain
交易域

Transaction Domain
营销域

Marketing Domain
履约域

Fulfillment Domain
内容域

Content Domain
运营域

Operations Domain
数据域

Data Domain

2.2 服务拆分原则

1. 单一职责原则（Single Responsibility Principle）

每个微服务只负责一个业务领域，不要让一个服务承担多个领域的职责。

反例:

复制代码

❌ 用户订单服务 (User-Order Service)
   - 用户注册
   - 用户登录
   - 订单创建
   - 订单查询

正例:

复制代码

✅ 用户中心 (User Center)
   - 用户注册
   - 用户登录
   - 用户信息管理

✅ 订单中心 (Order Center)
   - 订单创建
   - 订单查询
   - 订单状态管理

2. 高内聚低耦合原则

高内聚: 服务内部的功能紧密相关
低耦合: 服务之间的依赖尽可能少

示例:
低内聚高耦合（反例）
直接操作数据库
直接操作数据库
直接操作数据库
订单服务
库存DB
支付DB
物流DB
高内聚低耦合
创建订单事件
支付请求
物流通知
订单中心
库存中心
支付中心
物流中心

3. 按业务能力拆分（Bounded Context）

每个微服务应该对应一个限界上下文，有明确的业务边界。

神话公司的限界上下文:

限界上下文	业务能力	核心实体
用户中心	用户身份管理	User, UserProfile, UserAddress
商品中心	商品信息管理	Product, SKU, Category
库存中心	库存管理	Inventory, StockRecord
订单中心	订单生命周期管理	Order, OrderItem, OrderStatus
支付中心	支付与退款	Payment, Refund, Transaction
物流中心	物流追踪	Logistics, DeliveryRoute

4. 数据独立原则

每个微服务拥有独立的数据库，不共享数据库。服务间通过API或事件通信。
错误的做法 ❌
订单服务
共享DB
用户服务
正确的做法 ✅
API调用
订单服务
订单DB
用户服务
用户DB

为什么要数据独立？

✅ 服务自治: 服务可以独立部署、升级、扩展
✅ 技术异构: 不同服务可以选择不同的数据库（MySQL、MongoDB、Redis）
✅ 故障隔离: 一个数据库故障不影响其他服务
✅ 性能优化: 每个服务可以独立优化数据库

5. 服务粒度适中原则

太粗的微服务:

❌ 失去微服务的优势
❌ 服务内部耦合严重
❌ 难以独立部署

太细的微服务:

❌ 增加系统复杂度
❌ 服务间调用过多
❌ 分布式事务复杂

合适的粒度（理论值仅参考）:

指标	建议值
代码行数	5000-20000行
团队规模	2-7人（两个披萨团队）
API接口	10-30个接口
数据库表	5-15张表
部署时间	< 5分钟
启动时间	< 30秒

6. 演进式拆分原则

不要一开始就拆得很细，而是随着业务发展逐步拆分。

拆分路径:

复制代码

单体应用
  → 垂直拆分（按业务模块）
  → 水平拆分（按业务能力）
  → 细粒度拆分（按领域模型）

示例:
商品管理单体
商品中心
商品中心

Product Center
类目中心

Category Center
库存中心

Inventory Center
价格中心

Price Center

2.3 边界识别方法

如何识别微服务边界？

方法1: 事件风暴（Event Storming）

事件风暴是一种协作式的领域建模方法，通过识别领域事件来发现业务流程和服务边界。

步骤:

识别领域事件: 业务流程中发生的重要事件
- 用户注册成功
- 订单创建成功
- 支付完成
- 商品库存不足
识别命令（Command）: 触发事件的动作
- 注册用户 → 用户注册成功
- 创建订单 → 订单创建成功
- 发起支付 → 支付完成
识别聚合（Aggregate）: 处理命令的业务实体
- 用户聚合 (User Aggregate)
- 订单聚合 (Order Aggregate)
- 支付聚合 (Payment Aggregate)
识别限界上下文: 将相关的聚合分组
- 用户上下文 (User Context)
- 订单上下文 (Order Context)
- 支付上下文 (Payment Context)

示例：订单创建流程的事件风暴
是
否
用户选择商品
加入购物车事件
查询库存
库存充足?
创建订单命令
库存不足事件
订单创建成功事件
扣减库存命令
库存扣减成功事件
发起支付命令
支付成功事件

方法2: 名词动词法

通过分析业务需求中的**名词（实体）和动词（行为）**来识别服务边界。

步骤:

提取名词: 用户、商品、订单、支付、库存、物流
提取动词: 注册、登录、下单、支付、发货、退款
建立关联 :
- 用户 → 注册、登录、修改资料
- 商品 → 创建、上架、下架、查询
- 订单 → 创建、支付、发货、取消
识别边界 :
- 用户中心: 用户相关的所有操作
- 商品中心: 商品相关的所有操作
- 订单中心: 订单相关的所有操作

方法3: 康威定律

"设计系统的组织，其产生的设计等同于组织间的沟通结构。" ------ 梅尔文·康威

启示: 微服务的边界应该与团队组织结构对齐。

示例:

团队	职责	微服务
用户团队	用户管理	用户中心、认证中心
商品团队	商品管理	商品中心、类目中心、库存中心
交易团队	交易管理	订单中心、支付中心、结算中心
营销团队	营销活动	促销中心、优惠券中心、会员中心

2.4 微服务粒度把控

过细拆分的问题:

复制代码

❌ 用户注册服务 (User-Register-Service)
❌ 用户登录服务 (User-Login-Service)
❌ 用户资料服务 (User-Profile-Service)
❌ 用户地址服务 (User-Address-Service)

问题:

服务数量爆炸，运维成本高
服务间调用过多，性能下降
分布式事务复杂

合理粒度:

复制代码

✅ 用户中心 (User Center)
   ├── 用户注册
   ├── 用户登录
   ├── 用户资料管理
   └── 用户地址管理

粒度判断标准:

标准	说明
业务完整性	一个服务应该包含完整的业务能力
团队规模	一个服务由一个小团队（2-7人）负责
代码规模	5000-20000行代码
数据库表	5-15张表
API数量	10-30个接口
部署频率	每周至少部署一次
启动时间	< 30秒

拆分示例：电商订单中心
订单中心 (Order Center)
订单管理

Order Management
购物车

Shopping Cart
订单状态机

Order State Machine
订单查询

Order Query
订单导出

Order Export
订单DB

order_info

order_item

order_log
购物车DB

cart_item
用户

不拆分的原则:

✅ 高频交互的模块: 如订单和订单明细
✅ 强事务一致性要求: 如支付和账户余额
✅ 数据强关联: 如商品和SKU

需要拆分的信号:

❌ 服务代码量 > 50000行
❌ 数据库表 > 30张
❌ 团队规模 > 10人
❌ 部署时间 > 10分钟
❌ 启动时间 > 2分钟

第三章：互联网公司核心系统蓝图

一个成熟的互联网公司，通常会有以下核心系统。本章将详细介绍这些系统的职责、功能和架构。

3.1 基础平台域

基础平台域是所有业务系统的基础，提供统一的用户管理、认证授权、权限控制、消息通知等能力。
基础平台域
用户中心

User Center
统一认证中心

SSO Center
权限中心

Permission Center
API网关

API Gateway
组织架构中心

Organization Center
配置中心

Config Center
消息中心

Message Center

3.1.1 用户中心（User Center）

系统定位: 统一的用户身份管理和用户信息服务

核心功能:

用户注册、登录、注销
用户基本信息管理（昵称、头像、手机、邮箱）
用户实名认证
用户标签体系
用户分群管理
第三方账号绑定（微信、支付宝、QQ等）

依赖关系:

依赖: SSO认证中心（身份认证）、消息中心（通知发送）
被依赖: 几乎所有业务系统

3.1.2 统一认证中心（SSO Center）

系统定位: 提供统一的身份认证和授权服务

核心功能:

单点登录（SSO）
多端登录态管理
多用户类型认证（C端用户、员工、供应商）
Token生成与验证
OAuth2.0授权
登录安全防护（风控、验证码）
会话管理

支持的认证方式:

用户类型	认证方式
C端用户	手机号+密码/验证码、第三方登录（微信/支付宝）、扫码登录、生物识别
B端员工	工号+密码、企业微信/钉钉单点登录、LDAP/AD域认证、双因素认证（2FA）
供应商	供应商账号+密码、企业认证、数字证书认证
合作伙伴	合作伙伴账号+密码、API Key认证、OAuth2授权

认证流程:
Redis 用户中心/组织中心 SSO中心 API网关用户 Redis 用户中心/组织中心 SSO中心 API网关用户后续请求 1. 提交登录凭证 2. 转发认证请求 3. 验证用户凭证 4. 返回用户信息 5. 生成JWT Token 6. 存储会话信息 7. 返回Token 8. 返回Token 9. 携带Token访问 10. 验证Token签名 11. 检查Token是否在黑名单 12. 返回检查结果 13. 解析Token获取用户信息 14. 注入用户信息到Header

3.1.3 权限中心（Permission Center）

系统定位: 统一的权限管理和访问控制服务

核心功能:

基于RBAC的权限模型（用户-角色-权限）
多应用权限管理（OPS、MERCHANT、OPEN、CS、BI、APP、ADMIN）
应用权限隔离
资源权限管理（菜单、按钮、API）
数据权限管理（组织、部门、区域、商家维度）
角色管理与继承
权限校验服务（QPS > 10000，响应时间 < 10ms）
两级缓存（Redis + Caffeine）

RBAC权限模型:
RBAC权限模型
用户

User
用户角色关系

UserRoleRelation
角色

Role
角色权限关系

RolePermissionRelation
权限

Permission
资源

Resource
角色继承

RoleInheritRelation
用户直接权限

UserPermissionRelation
用户数据权限

UserDataScopeRelation
数据权限规则

DataScopeRule

权限校验算法:

java 复制代码

// 高性能权限校验（QPS > 10000，响应时间 < 10ms）
public boolean hasPermission(Long userId, String appCode, String permissionCode) {
    // 1. 查询Caffeine本地缓存 (1-2ms)
    String cacheKey = "perm:user:" + userId + ":app:" + appCode;
    BitSet permissions = caffeineCache.get(cacheKey);
    if (permissions != null) {
        int permissionId = getPermissionId(permissionCode);
        return permissions.get(permissionId);
    }

    // 2. 查询Redis分布式缓存 (3-5ms)
    String redisKey = "permission:user:" + userId + ":app:" + appCode;
    String bitmap = redisTemplate.opsForValue().get(redisKey);
    if (bitmap != null) {
        permissions = parseBitmap(bitmap);
        caffeineCache.put(cacheKey, permissions);
        int permissionId = getPermissionId(permissionCode);
        return permissions.get(permissionId);
    }

    // 3. 查询数据库并缓存 (30-50ms)
    permissions = loadUserPermissionsFromDB(userId, appCode);
    String bitmapStr = toBitmapString(permissions);
    redisTemplate.opsForValue().set(redisKey, bitmapStr, 30, TimeUnit.MINUTES);
    caffeineCache.put(cacheKey, permissions);

    int permissionId = getPermissionId(permissionCode);
    return permissions.get(permissionId);
}

数据权限实现:

通过MyBatis拦截器或SQL拼接实现多维度数据权限：

维度类型	说明	实现方式
全部数据	无限制	不添加WHERE条件
组织维度	指定组织及子组织	`orgId IN (1, 2, 3, ...)`
部门维度	指定部门及子部门	`deptPath LIKE '/1/3/%'`
区域维度	省-市-区	`provinceId = 11`
商家维度	供应商/商家	`supplierId = 123`
自定义维度	SpEL表达式	`userId = #{userId} AND status = 1`

3.1.4 API网关（API Gateway）

系统定位: 统一的API流量入口和管理平台

核心功能:

请求路由和转发
动态路由配置（支持管理后台）
协议转换（HTTP、gRPC、WebSocket）
统一鉴权（Token验证）
流量控制（限流、熔断、降级）
API监控和日志
API版本管理
灰度发布

架构设计:
API网关核心组件
客户端

Web/App/小程序
Nginx

负载均衡
API网关集群

Gateway Cluster
路由模块

Router
鉴权模块

Auth Filter
限流模块

Rate Limiter
熔断模块

Circuit Breaker
日志模块

Logger
用户中心

User Service
商品中心

Product Service
订单中心

Order Service
支付中心

Payment Service
Nacos

配置中心+注册中心
Redis

限流+黑名单
SkyWalking

链路追踪

核心过滤器链:

java 复制代码

// Spring Cloud Gateway过滤器链
public class GatewayFilterChain {

    // 1. 日志过滤器：记录请求日志，生成traceId
    public class LoggingFilter implements GlobalFilter {
        public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
            String traceId = UUID.randomUUID().toString();
            exchange.getRequest().mutate().header("X-Trace-Id", traceId);
            log.info("Request: method={}, uri={}, traceId={}",
                    exchange.getRequest().getMethod(),
                    exchange.getRequest().getURI(),
                    traceId);
            return chain.filter(exchange);
        }
    }

    // 2. 认证过滤器：验证Token
    public class AuthFilter implements GlobalFilter {
        public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
            String token = exchange.getRequest().getHeaders().getFirst("Authorization");
            if (token == null) {
                return unauthorized(exchange);
            }

            // 验证Token
            JwtPayload payload = jwtService.validateToken(token);
            if (payload == null) {
                return unauthorized(exchange);
            }

            // 注入用户信息到Header
            exchange.getRequest().mutate()
                    .header("X-User-Id", payload.getUserId())
                    .header("X-User-Type", payload.getUserType());

            return chain.filter(exchange);
        }
    }

    // 3. 限流过滤器：基于令牌桶算法
    public class RateLimitFilter implements GlobalFilter {
        public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
            String userId = exchange.getRequest().getHeaders().getFirst("X-User-Id");
            String key = "rate_limit:user:" + userId;

            // Redis实现分布式限流（令牌桶）
            boolean allowed = rateLimiter.tryAcquire(key, 100, 1, TimeUnit.SECONDS);
            if (!allowed) {
                return tooManyRequests(exchange);
            }

            return chain.filter(exchange);
        }
    }

    // 4. 熔断降级过滤器：基于Sentinel
    public class CircuitBreakerFilter implements GlobalFilter {
        public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
            String serviceName = getServiceName(exchange.getRequest().getURI());

            return chain.filter(exchange)
                    .onErrorResume(e -> {
                        log.error("Service {} call failed: {}", serviceName, e.getMessage());
                        return fallback(exchange);
                    });
        }
    }
}

3.1.5 组织架构中心（Organization Center）

系统定位: 企业组织架构和员工档案管理

核心功能:

公司、部门、岗位的层级管理
员工全生命周期管理（入职、调岗、晋升、离职）
供应商资质管理与评价
合作伙伴联系人管理
部门树查询（物化路径方案）

员工生命周期管理:
入职
转正
调岗/晋升/降职
离职
请假
销假
停薪留职
复职
离职
试用期
正式员工
离职
休假
停薪留职

3.1.6 配置中心（Config Center）

系统定位: 统一的配置管理和动态刷新

核心功能:

集中式配置管理
配置版本管理
配置动态刷新（无需重启）
配置灰度发布
配置回滚
配置审计

3.1.7 消息中心（Message Center）

系统定位: 统一的消息发送和通知管理

核心功能:

多渠道消息发送（短信、邮件、站内信、APP推送）
消息模板管理
消息发送记录
消息重试机制
消息统计和分析

消息渠道:

渠道	使用场景	优先级
短信	验证码、重要通知	高
邮件	订单确认、账单、营销	中
站内信	系统通知、活动通知	低
APP推送	实时消息、营销推送	中

消息发送流程:
推送服务邮件服务短信网关消息队列消息中心业务系统推送服务邮件服务短信网关消息队列消息中心业务系统 alt [发送失败] 1. 发送消息请求 2. 根据模板渲染消息 3. 持久化消息记录 4. 发送到消息队列 5. 消费消息 6. 调用短信网关 7. 返回发送结果 8. 更新发送状态 9. 重新入队（最多重试3次）

3.2 业务域系统

业务域系统是公司的核心业务系统，直接承载业务价值。
业务域系统
下单
履约
促销
评价
管理
管理
商品域

Product Domain
交易域

Transaction Domain
履约域

Fulfillment Domain
营销域

Marketing Domain
内容域

Content Domain
运营域

Operations Domain

3.2.1 商品域（Product Domain）

系统列表:

系统	职责	核心实体
商品中心	商品信息管理、SPU/SKU管理	Product, SKU, Brand
类目中心	商品类目管理、属性管理	Category, Attribute
库存中心	库存管理、库存预占、库存扣减	Inventory, StockRecord
价格中心	价格管理、价格策略	Price, PriceStrategy

SPU与SKU关系:

复制代码

SPU（Standard Product Unit）: 标准产品单元
  - iPhone 15

SKU（Stock Keeping Unit）: 库存保管单元
  - iPhone 15 128GB 黑色
  - iPhone 15 256GB 白色
  - iPhone 15 512GB 蓝色

3.2.2 交易域（Transaction Domain）

系统列表:

系统	职责	核心实体
购物车服务	购物车管理、价格计算	CartItem
订单中心	订单创建、订单状态管理	Order, OrderItem
支付中心	支付、退款、结算	Payment, Refund
结算中心	供应商结算、平台分账	Settlement, Bill

订单状态机:
创建订单
超时未支付/用户取消
支付成功
商家发货
用户确认收货
自动确认收货(7天)
申请售后
售后完成
待支付
已取消
待发货
待收货
已完成
售后中

订单创建流程（分布式事务）:
消息队列支付中心库存中心订单中心用户消息队列支付中心库存中心订单中心用户 1. 创建订单 2. 生成订单号 3. 预占库存 4. 扣减库存 5. 返回成功 6. 创建订单 7. 发布订单创建事件 8. 返回订单号 9. 发起支付 10. 调用支付网关 11. 通知支付成功 12. 更新订单状态 13. 确认库存扣减 14. 发布订单支付成功事件

3.2.3 营销域（Marketing Domain）

系统列表:

系统	职责	核心实体
促销中心	促销活动、满减、折扣	Promotion, PromotionRule
优惠券中心	优惠券发放、核销	Coupon, CouponTemplate
会员中心	会员等级、会员权益	Member, MemberLevel
积分中心	积分获取、积分消费	Points, PointsRecord

3.3 数据域系统

数据域系统负责数据采集、存储、分析、展示，支撑业务决策。
业务数据库

MySQL
数据采集

Canal/Debezium
消息队列

Kafka
实时计算

Flink
离线计算

Hive/Spark
数据仓库

ClickHouse
BI平台

Metabase/Superset
数据API

GraphQL

系统列表:

系统	职责	技术栈
数据仓库	数据存储、OLAP分析	ClickHouse、Hive、Doris
BI平台	数据可视化、报表	Metabase、Superset、QuickBI
日志分析	日志采集、分析、告警	ELK（Elasticsearch、Logstash、Kibana）
实时监控	系统监控、APM	Prometheus、Grafana、SkyWalking

3.4 运维与监控体系

DevOps流程:
代码提交

Git
代码检查

SonarQube
单元测试

JUnit
构建镜像

Docker
镜像仓库

Harbor
部署到K8s

ArgoCD
健康检查

Liveness/Readiness
灰度发布

Istio
全量发布

监控体系:

监控类型	工具	说明
基础设施监控	Prometheus + Grafana	CPU、内存、磁盘、网络
应用性能监控（APM）	SkyWalking、Pinpoint	接口性能、链路追踪
日志监控	ELK Stack	日志采集、检索、分析
业务监控	自研	订单量、GMV、转化率
告警通知	AlertManager + 钉钉/企业微信	告警聚合、通知

参考资料

《领域驱动设计》- Eric Evans
《微服务架构设计模式》- Chris Richardson
《Spring Cloud微服务实战》- 翟永超
《Kubernetes权威指南》- 龚正等

系统架构设计实战：从单体到微服务的演进之路

目录

引言

第一章：架构演进历程

1.1 单体架构时代

1.2 垂直拆分阶段

1.3 SOA服务化阶段

1.4 微服务架构

1.5 云原生与服务网格

1.6 架构演进总结

第二章：微服务拆分方法论

2.1 领域驱动设计（DDD）

2.2 服务拆分原则

2.3 边界识别方法

2.4 微服务粒度把控

第三章：互联网公司核心系统蓝图

3.1 基础平台域

3.1.1 用户中心（User Center）

3.1.2 统一认证中心（SSO Center）

3.1.3 权限中心（Permission Center）

3.1.4 API网关（API Gateway）

3.1.5 组织架构中心（Organization Center）

3.1.6 配置中心（Config Center）

3.1.7 消息中心（Message Center）

3.2 业务域系统

3.2.1 商品域（Product Domain）

3.2.2 交易域（Transaction Domain）

3.2.3 营销域（Marketing Domain）

3.3 数据域系统

3.4 运维与监控体系

参考资料