微服务架构——有关概念

目录

[2 微服务系统架构](#2 微服务系统架构)

[2.1 一些概念](#2.1 一些概念)

[2.1.1 域名](#2.1.1 域名)

[2.1.3 断点故障](#2.1.3 断点故障)

[2.1.2 DNS服务器](#2.1.2 DNS服务器)

[2.1.3 浏览器输入www.baidu.com的操作流程](#2.1.3 浏览器输入www.baidu.com的操作流程)

[2.1.4 localhost和 127.0.0.1 的区别](#2.1.4 localhost和 127.0.0.1 的区别)

[2.1.5 不同协议默认端口号](#2.1.5 不同协议默认端口号)

[2.1.6 网关](#2.1.6 网关)

[2.1.7 集群](#2.1.7 集群)

[2.1.8 QPS](#2.1.8 QPS)

[2.1.9 RPC](#2.1.9 RPC)

[2.1.10 VPN](#2.1.10 VPN)

[2.1.11 带宽](#2.1.11 带宽)

[2.1.12 网络通讯的五元组(七元组)](#2.1.12 网络通讯的五元组(七元组))

[2.1.13 有状态和无状态服务](#2.1.13 有状态和无状态服务)

[2.1.14 DNS 挟持](#2.1.14 DNS 挟持)


2 微服务系统架构

2.1 一些概念

2.1.1 域名

  1. 域名是互联网中用于标识某台 / 某组计算机的易记字符地址,对应背后唯一或多个 IP 地址,替代复杂难记的 IP(如 192.168.1.1),方便用户访问网络资源。
  2. 比如www.baidu.com。baidu.com是域名,其中www是域名下的子域名,用于标识具体的服务(如 Web 服务)。
  3. 特点:
  • 由点分隔的层级结构组成,比如www.processon.com,从右到左依次是顶级域名(.com)、二级域名(processon)、子域名(www)。
  • 具有唯一性,每个域名在全球范围内不会重复,需通过域名注册商申请获得。
  • 本质是 IP 地址的 "别名",通过 DNS 服务器解析后,才能让计算机找到对应的网络节点。

2.1.3 断点故障

  1. 在系统架构中,"断点故障" 通常指因某一节点(如服务器、网络设备、服务实例等)出现故障,导致整个链路或服务流程中断的情况。
  2. 以 DNS 和服务架构为例:
  • 若某台提供服务的服务器突然宕机,用户请求到该服务器的链路就会 "断点",导致服务不可用;
  • 若 DNS 服务器中某域名对应的某一个 IP 地址的服务器故障,就属于 "断点",但因为 DNS 支持一个域名对应多个 IP(即负载均衡或高可用设计),其他正常的 IP 仍能承接请求,从而避免整个服务因单个断点而故障。
    简单来说,断点故障就是系统中某一个环节 "断了",进而可能引发服务异常的情况,而通过多节点、多 IP 的设计(如 DNS 多 IP 映射、服务集群),可以有效规避这种单点断点导致的整体故障。

2.1.2 DNS服务器

  1. DNS(Domain Name System,域名系统)服务器是一种网络服务组件,它通过维护域名与 IP 地址的映射关系数据库,实现域名到 IP 地址的解析过程,是互联网中负责将人类易读的域名(如www.example.com)转换为计算机可识别的 IP 地址(如192.168.1.1)的关键基础设施,保障了网络资源的寻址与访问的可行性。
  2. 特点:
    DNS 服务器通过地域区分,让用户优先访问就近的网络资源;再配合多地域、多链路的架构,既提升了访问效率,又避免了因单点(某地域节点)故障导致的 "断点问题",保障了服务的高可用。
  • DNS服务器里一个域名对应多个IP 。
    这是为了防止断点故障。
    验证:
    以www.processon.com为例(其他网站也可以,只是其他的比如百度默认是IPV6,这个是ipv4,这里使用ipv4演示)。
    在不同电脑上打开cmd ,ping www.processon.com

    此时会发现不同电脑的地址不一样,有的电脑的一样。这是因为DNS服务器一个域名对应多个IP ,这个是为了防止断点故障。
  • DNS服务器有地域区分
    通过 "地域就近" 和 "多链路冗余" 来提升服务访问的效率与可靠性。
  • DNS 服务器会根据用户的地理位置分配就近的解析节点。

    比如图中用户位于 "保定",访问服务时会优先匹配距离较近的 "北京""石家庄" 等区域的 DNS 或网络节点,这样能减少域名解析的延迟,提升访问速度。
  • 地域链路的主备冗余
    在计算机领域,"冗余" 是指通过重复配置关键组件或链路,来提高系统可靠性、可用性和容错能力的设计思路。简单来说,就是 "多准备一份或几份",以防其中一部分出现故障时,另一部分能立刻顶上,保证系统不停机、数据不丢失。
    地域链路的主备冗余指的是,即使某条地域链路出现故障,也能通过备用链路保障访问。
  • 跨地域专线

    在 "北京" 节点新增了到 "上海" 的 "专线" 链路。这说明在地域分布的基础上,还可以通过跨地域专线进一步拓展网络覆盖,让 "保定" 用户也能通过北京的专线快速访问上海的资源,同时保留原有的 "山东→贵州" 链路,形成多地域、多链路的复杂网络架构。

2.1.3 浏览器输入www.baidu.com的操作流程

  1. 检查用户本地 host 缓存,查看是否有该域名对应的 IP 记录。如果有对应域名的 IP 记录,会直接使用该 IP 访问,不会再走后续的浏览器缓存和 DNS 服务器。
  2. 检查浏览器缓存,查看是否有该域名的 IP 缓存。同上。
  3. 向DNS 服务器发起请求,DNS 服务器也有缓存(大概 10 分钟),若缓存中无记录则逐级递归查询,最终获取www.baidu.com对应的 IP 地址。
  4. 建立 TCP 连接(基于 HTTP 协议默认 80 端口或 HTTPS 默认 443 端口)。
  5. 浏览器发送 HTTP 请求(如 GET 请求)。
  6. 服务器接收请求并返回响应,包含页面资源。
  7. 浏览器解析并渲染页面,用户看到界面。

2.1.4 localhost和 127.0.0.1 的区别

  • 127.0.0.1是一个具体的 IPv4 回环地址,用于指向本地计算机。
  • localhost是一个域名,通常在本地hosts文件中被解析为127.0.0.1(也可解析为其他回环地址)。它是一个逻辑名称,而127.0.0.1是实际的 IP 地址表示。

2.1.5 不同协议默认端口号

HTTP 协议:默认端口是80,如果你的请求是 HTTP 协议,会自动拼接80端口(若 URL 中未显式指定端口)。
HTTPS 协议:默认端口是443,同上。
流程是:

  • 若为HTTP 请求:用户HTTP请求(自动带80端口) → Nginx集群(若配置了80端口的监听和转发) → 转发到内网服务的对应端口;
  • 若为HTTPS 请求:用户HTTPS请求(自动带443端口) → Nginx集群(监听443端口) → 转发到内网服务的对应端口。

2.1.6 网关

在计算机系统架构中,"网关" 是一类负责流量转发、协议转换、业务规则管控的中间组件,不同层级的网关职责不同,所以公网层和内网网关层的设计有明显差异:

  1. 网关的核心定义
    网关是网络或系统间的 "中转站",承担流量接入、协议转换、权限控制、业务规则执行等功能,相当于不同网络 / 系统之间的 "守门人" 或 "调度员"。
  2. 公网层的网关(流量网关,如 Nginx 集群)
  • 存在原因:公网是开放的互联网环境,需要一个 "统一入口" 来管理所有外部流量,同时隔离内网与公网的直接接触(保障安全)。
  • 职责:
    • 作为公网流量的唯一入口,只暴露必要端口(如 HTTPS 的 443 端口),防止内网服务直接暴露在公网。
    • 实现负载均衡(把公网流量分摊到多台服务器),避免单节点过载。
    • 处理HTTPS 加密 / 解密(公网用 HTTPS 保障数据安全,Nginx 负责 SSL 证书的处理)。
  • 公网层的网关职责相对聚焦(就是 "流量接入 + 基本转发"),所以通常由一类组件(如 Nginx 集群)承担,不需要多层网关。
  1. 内网网关层(业务网关、API 网关)
  • 存在原因:内网是服务集群的内部网络,微服务数量多、业务规则复杂,需要细分网关来管控不同维度的需求(业务规则、数据结构、服务调用等)。
  • 各网关的职责:
  1. spring-cloud-gateway(业务网关):
  • 管控业务级规则,比如对 "下单接口" 设置 QPS(QPS 是每秒查询率,这里指的是该下单接口每秒能处理的最大请求数) 上限(如 QPS 超 2 万时丢弃部分请求),防止服务被流量冲垮。
  1. API 网关:
  • 负责数据结构规范和接口组装,把多个微服务的接口 "拼接" 成前端需要的统一接口;
  • 保障数据安全(比如过滤掉手机号、身份证号等敏感信息,防止前端调用时泄露)。
  • 为何内网需要多层网关:内网微服务架构复杂,不同环节的需求(业务管控、数据规范、服务组装)需要不同组件来承担,所以拆分成多层网关更能精准解决问题。
  1. 总结

|------|--------------------|-------------------------------------|
| 维度 | 公网层网关(如 Nginx) | 内网网关层(业务网关、API 网关) |
| 核心职责 | 公网流量统一接入、负载均衡、安全隔离 | 业务规则管控、数据结构规范、微服务接口组装 |
| 组件类型 | 通常是 Nginx 等流量转发组件 | 通常是 Spring Cloud Gateway、自研 API 网关等 |
| 数量 | 一层(聚焦流量接入) | 多层(各层负责不同细分职责) |
| 面向对象 | 外部互联网用户 | 内部微服务和前端应用 |

2.1.7 集群

集群就是把多个相同功能的服务器 / 服务实例,组合成一个 "整体" 来工作。
以商品服务集群为例,就是同时启动多台服务器,每台都运行一模一样的商品服务(都能处理查询商品、查库存的请求),它们对外相当于一个统一的服务,共同承接流量、分担压力。
核心作用:

  • 分担负载(比如 1 个实例扛不住 1 万 QPS,3 个实例就能一起扛);
  • 容错(一个实例宕机,其他实例还能继续工作,避免服务中断)。

2.1.8 QPS

QPS(Queries Per Second) 是每秒查询率,它衡量的是系统在一秒内能够处理的请求数量。
以"下单接口 QPS 上限" 为例,这里的 QPS 指的是该下单接口每秒能处理的最大请求数(比如设置 QPS 为 1 万,就是指接口每秒最多能处理 1 万个下单请求)。如果实际请求量超过这个上限(比如到了 2 万),业务网关就会丢弃部分请求,防止接口因流量过载而崩溃。

2.1.9 RPC

  1. RPC 是 "Remote Procedure Call" 的缩写,意思是 "远程过程调用",简单来说就是 "让一台服务器上的服务,像调用本地函数一样调用另一台服务器上的服务"。
  2. RPC 的作用:这些服务可能部署在不同的服务器上,RPC 让它们之间的远程调用变得像本地调用一样简单,不用关心网络通信的细节(比如 TCP 连接、数据序列化等)。
  3. 微服务之间 RPC 调用的区别:
  • 微服务之间的 RPC(比如订单服务调用商品服务),是 "服务对服务" 的业务协作(比如下单查库存);
  • API 网关的 RPC 调用,是 "网关对服务" 的数据采集(为了给前端组装统一接口),最终目的是给前端提供简洁、安全的接口,避免前端直接调用多个微服务。
  1. "RPC" 只是一种技术概念 / 通信方式,指 "微服务之间远程调用的逻辑";比如 Fegin 才是实现 RPC 的具体工具,是把 RPC 这个 "概念" 落地的 "手段"。

2.1.10 VPN

VPN是虚拟专用网络(Virtual Private Network)。下面以VPN 在微服务架构中对内网资源的安全接入的作用为例介绍:

  1. 定义:在公共网络(如互联网)上搭建加密专用通道的技术,核心是通过 "加密隧道" 实现外部设备与内网的安全通信,而非单纯隔绝。
  2. 核心逻辑:通过加密隧道将传输数据打包加密,既隔绝公网中黑客的监听、窃取与篡改,又能让授权设备 "伪装接入" 内网,等同于本地网络环境。
  3. 架构场景应用:
  • 员工远程访问:开发人员居家 / 出差时排查商品服务、订单服务问题,运营人员调取内网 MySQL 业务数据,需通过 VPN 安全接入,不暴露内网端口。
  • 跨地域节点互联:若微服务集群分布在保定多区域或异地分公司,VPN 可连接分散内网节点,让不同区域的商品服务、订单服务等像在同一局域网通信,数据传输全程加密。
  1. 与内网 DNS 的配合:VPN 负责外部设备安全接入内网,接入后可继续通过内网域名(如 MySQL-server、Redis-server)访问资源,无需记复杂 IP,契合 "端口暴露最小化" 原则。
    此外VPN还会用来加速跨境访问:用加密通道优化传输路径,绕开拥堵,衍生出 "加速" 的效果。

2.1.11 带宽

  1. 带宽的大小决定了服务器同时能处理多少用户的请求,是衡量网络传输能力的关键指标。
  2. 带宽可以类比成 **"马路的宽度"**:
  • 马路越宽(带宽越高),同时能通过的车(数据)就越多;
  • 马路越窄(带宽越低),车多了就会堵车,数据传输就会变慢甚至中断。
  1. 公网服务器为什么需要 "高带宽"
    公网服务器是用户访问系统的 **"第一道入口"**,要同时应对大量用户的请求(比如电商大促时的海量访问):
  • 如果带宽不够(马路窄),大量用户请求挤在一起,就会出现访问卡顿、页面加载慢,甚至直接无法访问(类似堵车堵死);
  • 高带宽(宽马路)能让更多用户的请求同时 "通过",保障系统在大流量下也能稳定响应。
    简单说,公网服务器的高带宽是为了扛住海量用户的并发访问,避免因网络拥堵导致服务瘫痪。

2.1.12 网络通讯的五元组(七元组)

  1. 五元组:用于唯一标识一个网络连接,由源 IP 地址、源端口号、目的 IP 地址、目的端口号、传输层协议(如 TCP、UDP)组成。
  2. 七元组:在五元组基础上,增加了网络层协议(如 IPv4、IPv6)和应用层协议(如 HTTP、FTP),能更精细地识别网络通信。

2.1.13 有状态和无状态服务

  1. 有状态服务:需要持久化数据的服务(如 MySQL 数据库),数据存储在本地或特定磁盘,迁移时需同步磁盘数据,无法直接动态扩缩容。
  2. 无状态服务:不依赖本地持久化数据的服务(如 Nginx、普通 Web 应用容器),可随时动态调整副本数(如从 2 个扩到 3 个),无需额外操作,扩缩容能力强。

2.1.14 DNS 挟持

  1. 定义:DNS 挟持就是攻击者修改 "域名 - IP 对应关系" 的存储环节(比如 Host 文件、本地缓存、DNS 服务器缓存),替换正常 IP 为恶意 IP,哪怕浏览器最终访问的是 IP,这个 IP 也是被篡改后的虚假地址,导致访问错误站点。
  2. 主要方式:
  3. 篡改本地 Host 文件:直接修改设备(如 Windows)的 Host 文件,写入虚假的域名 - IP 映射(比如"禁 Windows 自动更新" 时修改微软域名对应的 IP),优先级最高,会覆盖其他解析结果。
  4. 污染本地缓存:篡改浏览器缓存或设备的本地 DNS 缓存,替换已存储的正常域名 - IP 记录,让浏览器直接使用被篡改的缓存结果。
  5. 篡改服务器缓存:攻击 DNS 服务器(如公共 DNS、运营商 DNS),修改其缓存的域名 - IP 映射( DNS 服务器有 10 分钟左右缓存),让所有使用该 DNS 的用户都获取虚假解析结果。
  6. 网关 / 路由器劫持:在局域网路由器或网关中植入规则,拦截设备的 DNS 请求,强制返回恶意 IP,哪怕设备设置了正常 DNS,也会被网关拦截替换。
  7. 中间人拦截响应:在设备与 DNS 服务器通信过程中,拦截真实解析响应,抢先返回伪造的恶意 IP,让设备优先使用虚假解析结果。
相关推荐
小江的记录本2 小时前
【微服务与云原生架构】Serverless架构、FaaS/BaaS、核心原理、优缺点
java·后端·微服务·云原生·架构·系统架构·serverless
喜欢流萤吖~2 小时前
API包独立拆分:微服务的契约治理
微服务·架构
ai产品老杨3 小时前
【深度架构解析】高并发 AI 视频管理平台:兼容 GB28181/RTSP,支持 X86/ARM+GPU/NPU 异构部署与源码交付
人工智能·架构·音视频
cyber_两只龙宝3 小时前
【Oracle】Oracle数据库的登录验证
linux·运维·数据库·sql·云原生·oracle
csgo打的菜又爱玩3 小时前
8.WebMonitorEndpoint解析.md
大数据·架构·flink
薛定猫AI3 小时前
【深度解析】AI Coding 工具的模型自由与 Agent 架构:从 VS Code 插件到云端代理的技术演进
大数据·人工智能·架构
雪碧聊技术3 小时前
告别“复制粘贴”!微服务架构下如何统一管理POM依赖版本(实战详解)
微服务·云原生·架构
AI服务老曹3 小时前
从GB28181接入到边缘NPU算力调度:深度解析支持异构计算的工业级AI视频管理平台架构
人工智能·架构·音视频
齐潇宇3 小时前
Kubectl命令指南
linux·运维·云原生·容器·kubernetes