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

🕗 发布于 01-10 13:27 系统架构微服务架构

引言

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

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

为什么要做架构演进？

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

第一章：架构演进历程

1.1 单体架构时代

什么是单体架构？

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

单体架构的优点:

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

单体架构的缺点:

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

适用场景:

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

1.2 垂直拆分阶段

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

什么是垂直拆分？

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

垂直拆分的优点:

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

垂直拆分的缺点:

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

拆分原则:

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

1.3 SOA服务化阶段

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

什么是SOA？

SOA（Service-Oriented Architecture，面向服务架构）是一种软件设计风格，将应用的不同功能单元（服务）通过定义良好的接口和协议联系起来。

SOA的核心概念:

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

SOA的优点:

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

SOA的缺点:

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

1.4 微服务架构

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

什么是微服务？

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

微服务架构的核心特征:

服务粒度小: 每个服务只负责一个业务领域
独立部署: 每个服务可以独立部署、升级、扩展
去中心化治理: 没有中心化的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）是一个基础设施层，用于处理服务间通信。将服务间通信的复杂性从应用代码中剥离，下沉到基础设施层。

服务网格的核心功能:

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

云原生架构的优点:

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

1.6 架构演进总结

架构演进的驱动力:

阶段	用户规模	团队规模	核心痛点	解决方案
单体架构	< 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的核心概念:

DDD战略设计:

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

DDD战术设计:

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

神话公司的领域划分:

2.2 服务拆分原则

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

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

反例:

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

正例:

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

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

2. 高内聚低耦合原则

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

示例:

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

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

神话公司的限界上下文:

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

4. 数据独立原则

每个微服务拥有独立的数据库，不共享数据库。服务间通过API或事件通信。

为什么要数据独立？

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

5. 服务粒度适中原则

太粗的微服务:

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

太细的微服务:

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

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

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

6. 演进式拆分原则

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

拆分路径:

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

示例:

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秒

拆分示例：电商订单中心

不拆分的原则:

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

需要拆分的信号:

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

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

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

3.1 基础平台域

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

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授权

认证流程:

3.1.3 权限中心（Permission Center）

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

核心功能:

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

RBAC权限模型:

权限校验算法:

// 高性能权限校验（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版本管理
灰度发布

架构设计:

核心过滤器链:

// 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推送	实时消息、营销推送	中

消息发送流程:

3.2 业务域系统

业务域系统是公司的核心业务系统，直接承载业务价值。

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

订单状态机:

订单创建流程（分布式事务）:

3.2.3 营销域（Marketing Domain）

系统列表:

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

3.3 数据域系统

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

系统列表:

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

3.4 运维与监控体系

DevOps流程:

监控体系:

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

参考资料

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

原文地址：https://blog.csdn.net/u013857458/article/details/156653871

免责声明：本站文章内容转载自网络资源，如侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：没有 Mac 如何在 Windows 上创建 iOS 应用描述文件
下一篇：微服务 - Higress网关

Flink Source/Sink 的 Exactly-Once、At-Least-Once 到底意味着什么？
Flink的Exactly-Once语义分为状态语义和端到端投递语义两层。状态语义依赖Source参与checkpoint，而端到端语义需要Sink支持事务或幂等写入。常见组合如Kafka+Elast
阅读更多2026-01-15
互联网大厂Java面试实战：微服务、Spring Boot与Kafka在电商场景中的应用
谢飞机，你基本掌握了核心技术点，回去好好准备复杂场景的深入细节，稍后通知你结果。
阅读更多2026-01-15
人形机器人 | 富唯智能具身智能赋能工业柔性制造
当环境变化时，GRID可实时动态重规划，实现真正的“任务级编程”，这是快速换线的软件基础。富唯智能通过技术闭环与商业验证，正将柔性制造的未来蓝图转化为可触摸的现实生产力，驱动工业进入人机协同的新纪元。
阅读更多2026-01-15
制造型企业大数据分析落地指南：从数据采集到价值变现
摘要：制造业大数据分析需聚焦生产、质量、设备和供应链四大场景，通过五步流程实现数据驱动决策：1）明确业务目标；2）统一标准采集多系统数据；3）数据清洗与建模；4）落地四大应用场景（生产优化、质量追溯、
阅读更多2026-01-15
YOLO11训练中的学习率自动调整策略：介绍ReduceLROnPlateau、CyclicLR等自适应学习率方法
在深度学习模型训练中，学习率(Learning Rate)可以说是最重要的超参数之一，它控制着模型参数在每次迭代中的更新幅度。简单来说，学习率决定了我们沿着损失函数梯度方向"走"的
阅读更多2026-01-15
智探深蓝数绘未来——偶信科技的海洋赋能之路
偶信科技作为国内领先的海洋设备提供商，专注于ADCP、DVL等核心产品研发，构建了覆盖海洋观测、导航、声学采集的全场景技术矩阵。公司凭借80%高比例研发团队和严格质量管理体系，突破声学算法、低功耗设计
阅读更多2026-01-15
概念解析 | 神经隐式物理：从神经网络到物理世界的数字孪生
在计算机视觉和图形学的早期岁月里，我们习惯用离散的像素或网格来表示世界。就像用无数个小方块拼成一幅画，或者用渔网去捕捉流动的河流。分辨率越高，存储和计算的成本就呈指数级增长。隐式神经表示（Implic
阅读更多2026-01-15
在Vue项目中使用Sass的完整指南
本文详细介绍了在Vue项目中集成Sass的完整方案。主要内容包括：1) 安装sass和sass-loader依赖的步骤；2) 在.vue文件中使用Sass语法的基本方法；3) 针对Vue CLI和Vi
阅读更多2026-01-15
Vue.js 前端开发实战 ( 电子版 ) —— 黑马
Github:Gitee:Juejin:okokok , 这期内容到这里就结束了,我们有缘再会😂😂😂!!!
阅读更多2026-01-15
用 Node.js 从旧版 PPT 中提取文本：轻量开源工具 ppt-to-text
本文介绍了一个轻量级开源工具 ppt-to-text，它能帮助开发者在 Node.js 环境中从旧版 .ppt 文件中提取纯文本内容。该工具专注于文本提取而非排版还原，适合历史文档整理、AI文本预处理
阅读更多2026-01-15

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

目录

引言

第一章：架构演进历程

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 运维与监控体系

参考资料

相关文章