目录
2.3 GitEgg Spring Cloud 微服务系统架构
2.2 简略的微服务系统架构流程图
接下来，以上面图片为例进行解释。
2.2.1 用户访问层
以用户访问www.baidu.com为例。
解析流程：用户→用户本地 host 缓存→浏览器缓存→DNS 服务器（DNS也有缓存，大概10分钟）→获取域名对应 IP（如baidu.com对应192.168.0.1、192.168.0.2）。
注：这里的ip是公网ip。即，公网可访问的 Nginx 集群的入口 IP，用来定位 “公网流量网关” 的位置。
2.2.2 公网层（流量网关）
图中的 “Nginx（流量网关）” 是一个集群（多台 Nginx 服务器组成），只对外暴露443端口（HTTPS 协议的默认端口）。用户的请求会先到达这个 Nginx 集群：
- 它负责接收公网所有流量，是用户从互联网进入系统的 “第一道门”。
- 作为 “流量网关”，它还会做负载均衡（把请求分摊到集群内的不同 Nginx 节点），防止单台服务器过载。
具体流程为：
DNS解析得到Nginx集群的公网IP → 请求发送到Nginx集群（公网443端口） → Nginx把流量转发到内网的后续服务。
2.2.3 内网网关层
- spring-cloud-gateway（业务网关）：
功能：管控业务规则，如订单接口 QPS 限制（例：下单接口 QPS 设为 1 万，超 2 万时丢弃部分请求）。
- API 网关：
- 功能：规范数据结构，组装后台微服务接口，自身无数据库。
- 作用：避免前端直接调用微服务导致数据泄露（例：抖音用户详情接口若直接暴露手机号会引发严重事故）；规范前后端参数交互（定义前端可传、后端可返的参数范围）。
- API网关通过RPC调用微服务，在整合。
- 例子：假设前端发来请求，要获取 “用户基本资料 + 粉丝数 + 作品列表”，这三个数据分别存在「用户服务」「粉丝服务」「作品服务」里。
API 网关会先接收前端的请求，然后通过 RPC 分别调用这三个微服务，拿到各自的数据后，剔除手机号、身份证号等敏感信息，再组装成一个统一的响应结果返回给前端。
API 网关是 “数据整合者”，而 RPC 是它和微服务之间的 “通信工具”。
2.2.4 微服务层
- 服务组成：订单服务、商品服务、用户服务等。
- 服务通信：通过 RPC 方式调用。
- 集群调用解决方案：
- 内网搭建 DNS 解析服务器，服务启动时自动注册（调用接口向 DNS 服务器添加记录）。
- DNS 服务器具备监控功能，实时检测服务状态，若服务挂掉则主动移除记录。
- 服务调用时通过域名访问（而非硬编码 IP），适配多集群部署（例：订单服务调用商品服务时，用域名http://商品服务域名:18088/product/list发起请求）。
- 注：
- 为什么内网需要搭建DNS服务器：
核心目的就是解决微服务集群（比如多实例的商品服务）的调用问题。
- 首先明确痛点
商品服务是集群（多个实例，IP 可能是 192.168.0.3、0.4、0.5…），如果用硬编码 IP 的方式调用，新增 / 减少实例时要改代码（比如从 3 个扩到 4 个，就得手动加 IP），又麻烦又容易出错，只适合极小系统。
- 内网 DNS 服务器的解决方案
用 “域名” 替代 “硬编码 IP”，让 DNS 服务器来管理集群实例的 IP。
- 注册：商品服务每个实例启动时，会自动注册（即主动调用接口把自己的 IP、端口、服务名称等信息上报给内网 DNS）；
- 监控与移除：DNS 服务器会持续监控这些实例，挂掉的会自动移除，保证记录的都是可用的；
- 调用时用域名：订单服务调用商品服务时，只需要用 “商品服务域名” 发起请求，DNS 会返回当前可用的实例 IP，不用管集群有多少个实例。
- 最终效果：不管商品服务集群扩到 10 个还是 20 个实例，订单服务的调用地址（域名）永远不变，彻底解决了集群调用的灵活性和维护性问题。
2.2.5 数据层
- MySQL（主备架构）：
- 部署：纯内网环境，避免端口暴露（防止勒索病毒、数据泄露等风险）。
- 访问方式：通过域名（如mysql-server）访问，而非直接写 IP。其访问 URL 格式和 HTTP/HTTPS 类似，只是协议名称改为mysql（如mysql://mysql-server:3306/数据库名）。
- 架构特点：支持主备切换，主数据库负责日常读写，备数据库同步主库数据，主库故障时备库可自动切换为主库，保障数据服务不中断。
- Redis：
- 部署：纯内网环境，不暴露公网。
- 作用：作为缓存组件，专门存储常用数据（如商品库存、用户登录状态），能快速读取数据，减少 MySQL 的查询压力，提升系统响应速度。
- ClickHouse：
- 部署：纯内网环境，不暴露公网。
- 作用：用于大数据量的存储和分析（比如统计商品销售趋势、用户行为数据等），适合处理海量数据的查询分析需求，和 MySQL 的 “日常业务读写” 功能互补。
2.2.6 安全与部署原则
- 端口暴露原则：能不暴露端口就不暴露端口，端口暴露能少则少（例：订单服务、商品服务等 100% 部署在内网，避免因接口漏洞引发重大事故）。
- 数据层安全：MySQL、Redis、ClickHouse 等数据组件均部署于纯内网，不直接暴露公网（防止勒索病毒、数据泄露）。
- 员工公网访问安全边界：
- 核心逻辑：员工需通过VPN（虚拟专用网络） 接入内网，才能访问微服务、数据库等内部资源。
- 作用：VPN 相当于 “加密通道”，能隔离公网的不安全环境，防止员工在外部网络（如家里、咖啡厅 WiFi）直接访问内网时，数据被窃取或篡改。
- 本质：是 “技术组件 + 安全规范” 的结合 ——VPN 是实现工具，“必须通过 VPN 访问内网” 是强制规范，共同构成公网到内网的安全边界。
- 部署前提：需先捋清从用户侧到内网的全链路（域名解析、网关、微服务、数据层），再明确各环节部署方式。
2.3 GitEgg Spring Cloud 微服务系统架构
上面的2.2其实就是在说的是这个图，只是2.2比较简略。
2.3.1 用户访问与公网防御层
- 用户端：手机、电脑等终端发起请求。
- DDoS 防护与防火墙：抵御 DDoS 攻击（如 “肉鸡” 大规模恶意访问，类似黄牛占满网站资源导致正常用户无法访问）。
- VIP、主备 HAProxy+Keepalived：实现负载均衡与高可用，保障流量分发稳定。
- 高防服务器：互联网企业、政府官网必须部署，是公网流量的第一道安全屏障，避免 Nginx 直接暴露公网。这里的高防服务器指的不是单一的硬件。而是通过软件策略（DDoS 防护规则、防火墙策略） + 服务集群（HAProxy+Keepalived 的高可用架构），模拟出 “高防服务器” 的抗攻击、保稳定效果。这种设计在微服务架构中很常见，用组件组合替代单一硬件，更灵活也更易扩展。图中
这些内容共同组成了 “高防体系”，而不是说这些组件本身就是高防服务器。
- Nginx+Keepalived 负载均衡集群：承接公网流量，初步分发请求（与2.2架构图中公网 Nginx 集群逻辑一致）。
- CDN（内容分发网络）：本质是遍布各地的高带宽文件服务器，只存文件、不做任何计算。专门放 HTML、CSS、JS、图片、视频等前端静态资源（这些资源不用实时运算，像普通文件一样）。把这些静态资源提前放到 CDN 的各地服务器上后，用户访问网站时，从离自己最近的 CDN 服务器拿资源，不用去远的源服务器，让页面加载更快，还能减轻源服务器的压力。
2.3.2 内网网关层（Gateway 集群）
- 功能：路由转发、流量限制（如秒杀时 QPS 超限则限流，出现 “当前服务过于火爆” 提示）、统一权限认证、请求过滤（与2.2架构图中 spring-cloud-gateway、API 网关的流量管控逻辑一致）。
- 关联组件：
- Ribbon：客户端负载均衡，选择合适的服务实例调用。
- Sentinel：实现限流、熔断、降级，保障服务稳定性。
- 注：
- 熔断：可以理解为电路的保险丝，当某一服务频繁调用失败（比如连续多次超时、报错），就会 “熔断” 这个服务的调用链路，暂时不再向它发请求，避免一直消耗资源却得不到响应，等一段时间后再尝试恢复调用。
- 降级：当系统压力过大时，把一些非核心功能的服务 “降级” 处理（比如返回默认数据、简化逻辑），优先保证核心功能（如订单支付）的正常运行，防止整个系统被拖垮。
2.3.3 服务注册与微服务层
- 服务注册中心（Nacos）
- 所有微服务（如订单、商品服务）启动时，自动注册（向 Nacos上报 IP、端口、服务名称等信息注册），其他服务通过Nacos发现并调用目标服务（与2.2架构图中内网 DNS 服务器的服务注册与发现逻辑一致，解决集群调用问题）。
- 这里的Nacos 在微服务架构中的作用，就相当于2.2里的的 “内网 DNS 服务器”—— 都是用来管理 “服务域名→可用 IP” 的映射，解决集群调用的问题。
- 上图有多个nacos，这是 Nacos 的集群部署，多台 Nacos 实例一起工作，既提升了注册中心的可用性（一台故障，其他还能工作），又能分担访问压力，保障服务注册与发现的稳定性。
- Nacos 主要负责服务注册 / 发现和配置管理，它不直接 “监控服务的健康状态、性能指标”；而服务监控是由 Spring Boot Admin 这类专门的监控工具来完成的。
- SpringBoot 服务集群：多个 Server 实例（如 Server-A、Server-B）组成集群，共同处理业务，提升并发与容错能力（与2.2架构图中微服务集群逻辑一致）。
- 服务通信：通过 RPC 方式调用（与2.2架构图中微服务通信逻辑一致）。
- Fegin：是 RPC 的具体实现工具（属于 Spring Cloud 生态），它让微服务间的 RPC 调用变得更简单 —— 你只需要写一个接口，Fegin 会自动帮你完成服务发现、请求发送、结果解析等操作，不用关心底层的 HTTP 通信细节。
2.3.4 中间件层
- Redis Cluster：分布式 Redis 集群，缓存热点数据（如商品库存），减轻数据库压力（与2.2架构图中 Redis 逻辑一致）。
- MongoDB Cluster：非关系型数据库，存储非结构化数据（如日志）。
- XXL-JOB 集群：分布式任务调度，执行定时任务（如每天凌晨执行数据统计）。
- 分布式文件存储（OSS、MinIO）：存储用户头像、商品图片等文件资源。
- 消息中间件（RabbitMQ、RocketMQ、Kafka）：实现服务间异步通信、解耦。
2.3.5 数据持久化层
关系型数据库（MySQL 主从架构）：
- 主从复制与主备热切：主库处理读写请求，备库同步数据，主库故障时备库可切换为主库，保障数据服务不中断。（和2.2一致）
- MyCat 读写分离：实现数据库的读写分离，提升数据库的并发处理能力。
- JDBC、Druid/HikariCP：数据库连接池与驱动，优化数据库连接的管理。
- MyBatis、MyBatis-Plus：持久层框架，简化数据库操作。
- SEATA：分布式事务框架，保障分布式场景下数据的一致性。
2.3.6 监控与 DevOps
- Spring Boot Admin 监控：监控微服务健康状态与性能指标。
- Skywalking：分布式链路追踪，排查服务调用链路问题。
- 分布式日志管理平台（filebeat + es + kibana）：采集、存储、分析应用日志，实现可视化查询。
- GitLab：代码仓库，进行版本管理与协作开发。
- Jenkins：一个功能强大的自动化服务器，它通过插件生态系统可以实现从代码构建、测试、打包（如 Docker 镜像）到部署的整个软件开发生命周期的自动化。它是持续集成（CI）和持续部署（CD）流程中不可或缺的核心工具。
- SonarQube：代码扫描工具，进行代码审计与漏洞检测。
- Harbor：私有镜像仓库，存储 Docker 镜像（比如从Jenkins生成的docker镜像），便于分发管理。像要下载docker镜像，就和从maven仓库里下载jar包一样，通过坐标下载。
- k8s（Kubernetes）：容器编排平台，管理大规模容器化应用的部署与运维。
2.3.7 安全与部署原则
- 端口暴露原则：能不暴露端口就不暴露，微服务、数据库 100% 内网部署（与2.2架构图中安全原则一致）。
- 员工公网访问：需通过 VPN 接入内网，保障数据安全（与2.2架构图中安全原则一致）。
扫一扫
4211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
