692 lines
24 KiB
Markdown
692 lines
24 KiB
Markdown
# Multicloud Network Architecture 详细说明
|
||
|
||
本文用于解释 `network-architecture-diagram.drawio` 中的两个页面，帮助产品、研发、集成和评审人员快速理解这套架构为什么这样设计、每个区域代表什么、各条访问链路分别承担什么职责，以及从网络拓扑角度如何理解各 VNet / VPC 之间的连通关系。
|
||
|
||
这个 draw.io 文件现在包含两个视图：
|
||
|
||
- `Network Architecture`：架构评审视图，重点说明业务域边界、主访问链路、供应商接入方式和历史系统兼容策略。
|
||
- `Network Topology`：网络拓扑视图，重点说明 VNet / VPC 边界、公网入口、私有服务区、跨网络访问路径和允许 / 例外链路。
|
||
|
||
两张图表达的是同一套系统，但侧重点不同：第一张回答“为什么这样分域、谁应该访问谁”，第二张回答“网络上从哪里进、跨哪些边界、通过哪些受控入口连通”。
|
||
|
||
## 1. 这张图整体在表达什么
|
||
|
||
这张图表达的是一套“三域分离、主链路统一、供应商隔离、历史系统兼容”的多云网络架构。
|
||
|
||
它的核心目标不是展示某个具体服务器怎么部署，而是说明以下几个关键架构原则：
|
||
|
||
- `Mobile App -> App Backend` 是唯一主访问链路。
|
||
- `App Backend` 是 APP 的统一主后台和业务编排中心。
|
||
- `F6` 是供应商能力域，不是 APP 的主后台。
|
||
- `Mobile App -> F6` 只允许发生在嵌入式 `WebView` 场景。
|
||
- `App Backend -> F6 API` 必须通过 `F6 Integration Adapter` 访问。
|
||
- `Mini Program Backend` 保持独立后台域，但面向 APP 的能力应优先通过 `App Backend` 聚合。
|
||
- `App Backend -> Mini Program Backend` 和 `App Backend -> F6` 都是跨独立 VPC / VNet 边界的受控后端访问，不是主域内部本地调用。
|
||
- 历史上少量 APP 直连 Mini 后台的场景可以兼容保留，但不能继续扩散。
|
||
|
||
从架构表达上看，这张图并不是一张“部署拓扑详图”，而是一张“面向架构评审的网络边界与主访问链路图”。
|
||
|
||
## 2. 顶部：Mobile App 和 Internet
|
||
|
||
图最上方是 `Mobile App`，下面是 `Internet`。
|
||
|
||
这部分表示：
|
||
|
||
- 用户所有访问都从移动端发起。
|
||
- APP 访问不同后端域时，需要通过公网链路进入各自对外暴露的入口层。
|
||
- 移动端不是直接连内部服务，而是只访问被允许暴露的受控入口。
|
||
|
||
这张图中，APP 主要存在两类访问路径：
|
||
|
||
- 主访问路径：`Mobile App -> App Backend`
|
||
- 特殊访问路径：`Mobile App -> F6 WebView Pages`
|
||
|
||
其中第一条是主链路，第二条是例外链路，而且这个例外只允许发生在 F6 的嵌入式 WebView 场景。
|
||
|
||
## 3. 中间 Azure 域：Primary App Backend Domain
|
||
|
||
中间区域是 `Azure China (Beijing) VNet`，它代表 APP 主业务域，也是整张图最核心的部分。
|
||
|
||
这一块承担的是：
|
||
|
||
- APP 的统一主后台。
|
||
- 身份、门店、权限、菜单、配置等基础能力中心。
|
||
- 多系统数据聚合和业务编排中心。
|
||
- F6 和 Mini Program Backend 的统一接入和治理出口。
|
||
|
||
### 3.1 为什么这块是核心
|
||
|
||
整张图最重要的一条架构原则就是：
|
||
|
||
`Mobile App -> App Backend`
|
||
|
||
这意味着 APP 不应该把多个后台都当成自己的“直接主后台”。真正的主后台只有一个，就是这里的 `App Backend`。
|
||
|
||
这样做的好处是：
|
||
|
||
- APP 不需要分别理解多个后端的认证和权限模型。
|
||
- 门店上下文、角色上下文、菜单权限可以统一收口。
|
||
- F6 和历史 Mini 服务的复杂性可以被隔离在后端。
|
||
- 前端链路更稳定，后端也更方便统一治理。
|
||
|
||
### 3.2 DMZ / Public Ingress Zone
|
||
|
||
Azure 域上半部分是 `DMZ / Public Ingress Zone`。
|
||
|
||
这部分是公网入口区，作用是先接住来自 APP 的外部请求，不让外部流量直接打进私有服务区。
|
||
|
||
里面包括：
|
||
|
||
- `WAF / Application Gateway`
|
||
- `Public Load Balancer`
|
||
|
||
这两个组件组合表达的是标准公网入口模式：
|
||
|
||
- 先经过网关和安全过滤。
|
||
- 再经过负载均衡。
|
||
- 最后把请求转发到私有区中的后端服务。
|
||
|
||
这里的 `WAF / Application Gateway` 主要表示：
|
||
|
||
- Web 应用防护。
|
||
- 统一入口控制。
|
||
- 基础七层流量治理。
|
||
- 对异常流量、非法请求做第一层拦截。
|
||
|
||
`Public Load Balancer` 则表示：
|
||
|
||
- 对后面的 APP 后端服务实例进行流量分发。
|
||
- 屏蔽单实例细节。
|
||
- 让后面服务集群保持弹性扩缩能力。
|
||
|
||
### 3.3 Private Application Zone
|
||
|
||
Azure 域下半部分是 `Private Application Zone`，也就是私有业务服务区。
|
||
|
||
这里才是真正承载 APP 业务能力的地方。
|
||
|
||
它包含以下几个关键组件：
|
||
|
||
#### App Backend BFF / Unified APIs
|
||
|
||
这是 APP 的统一接口层，可以理解成 APP 面向移动端的统一后端入口。
|
||
|
||
它负责的事情包括：
|
||
|
||
- 登录认证。
|
||
- 用户信息返回。
|
||
- 门店上下文建立和切换。
|
||
- 菜单与权限返回。
|
||
- 系统配置下发。
|
||
- F6 WebView 启动参数准备。
|
||
- 为移动端提供统一接口风格。
|
||
|
||
图中旁边的说明框：
|
||
|
||
`Identity / Store Context / Menu / Config / WebView Ticket`
|
||
|
||
就是为了强调这件事：APP 依赖的核心控制面能力必须由主后台统一掌握。
|
||
|
||
#### Business Aggregation / Orchestration
|
||
|
||
这是业务聚合与编排层。
|
||
|
||
它和 `App Backend BFF / Unified APIs` 的区别在于：
|
||
|
||
- `BFF / Unified APIs` 更偏向“给移动端一个统一的接口入口”。
|
||
- `Business Aggregation / Orchestration` 更偏向“把多个后端系统的数据和流程编排成一个完整业务结果”。
|
||
|
||
比如：
|
||
|
||
- 首页工作台聚合多个系统数据。
|
||
- 采购、库存、延保、返利等场景的跨系统整合。
|
||
- 对 Mini 后台返回结果做标准化。
|
||
- 把 F6 能力、Mini 后台能力和 APP 自身基础能力组合起来。
|
||
|
||
这个层次存在的意义是：
|
||
|
||
- 把复杂的多系统业务放在后端做，而不是让 APP 自己拼装。
|
||
- 让 APP 更像一个统一入口，而不是一个多系统直连终端。
|
||
|
||
#### F6 Integration Adapter
|
||
|
||
这是 F6 供应商接入适配层。
|
||
|
||
它的职责是：
|
||
|
||
- 发起对 F6 的 allowlisted B2B 访问。
|
||
- 处理 F6 鉴权、签名、票据换取。
|
||
- 组装调用 F6 所需的 Header 或上下文。
|
||
- 做字段映射和错误码转换。
|
||
- 做超时、重试、熔断、异常隔离。
|
||
- 把供应商侧不稳定性隔离在适配层内。
|
||
|
||
它存在的意义非常重要：
|
||
|
||
- APP 主后台不应该让每个业务模块都自己直接调 F6。
|
||
- F6 是外部供应商域，协议、鉴权、返回结构都可能与主系统不同。
|
||
- 所有访问 F6 API 的逻辑都集中在这里，才能实现统一治理。
|
||
|
||
#### NSG / Access Control
|
||
|
||
这个框表示私有区里的访问控制层。
|
||
|
||
`NSG` 一般可以理解为 `Network Security Group`，也就是网络安全组。
|
||
|
||
它在图里的意思不是某个独立业务服务，而是一层安全控制能力，用来表达：
|
||
|
||
- 私有业务区不是公网可直接访问的。
|
||
- 即使请求已经通过前面的 `WAF / Application Gateway` 和 `Public Load Balancer`，进入私有区后仍要受访问控制规则约束。
|
||
- 私有区内部组件之间也不应该默认全部互通，而应按来源、目标、协议、端口进行规则控制。
|
||
|
||
用更直白的话说，这一层是在强调：
|
||
|
||
“后端服务即使在一个私有网络里，也不是谁都能访问谁，必须按规则放行。”
|
||
|
||
#### Unified Error / Audit / Logging / Security
|
||
|
||
这个说明框不是单独服务，而是架构责任说明。
|
||
|
||
它表达的是：
|
||
|
||
- 错误处理要统一。
|
||
- 安全能力要统一。
|
||
- 审计记录要统一。
|
||
- 日志追踪要统一。
|
||
|
||
这也是为什么 `App Backend` 被定义为主业务域，而不是单纯一个 API 容器。
|
||
|
||
## 4. 右侧 F6 Supplier VPC：F6 供应商域
|
||
|
||
右侧区域是 `F6 Supplier VPC (Alibaba Cloud)`，它表示供应商 F6 所在的独立云网络域。图中同时标注 `Supplier-managed VPC / network boundary`，用来强调 F6 不只是一个业务系统框，而是供应商侧独立管理的 VPC 网络边界。
|
||
|
||
这块的标题是：
|
||
|
||
`F6 Supplier VPC (Alibaba Cloud)`
|
||
|
||
这句话非常关键，它强调：
|
||
|
||
- F6 由供应商管理。
|
||
- F6 是外部能力域。
|
||
- F6 不是 APP 主后台的一部分。
|
||
- APP 需要接入 F6，但不能把 F6 当成自己的主系统。
|
||
|
||
### 4.1 F6 域的两类能力
|
||
|
||
F6 域中被分成两类对外能力：
|
||
|
||
- `F6 WebView Pages`
|
||
- `F6 Capability APIs (Backend Only)`
|
||
|
||
这两者是整张图中最重要的区别之一。
|
||
|
||
#### F6 WebView Pages
|
||
|
||
这是给用户页面使用的能力，也就是嵌入到 APP WebView 里的页面。
|
||
|
||
适用于：
|
||
|
||
- 扫码开单页。
|
||
- 到店记录页。
|
||
- 报价开单页。
|
||
- 施工查车页。
|
||
- 结算收银页。
|
||
- 扫码收货页。
|
||
- 部分采购和促销页面。
|
||
|
||
访问链路是：
|
||
|
||
`Mobile App -> Internet -> Access Gateway / WAF -> Load Balancer -> F6 WebView Pages`
|
||
|
||
这条链路的含义是：
|
||
|
||
- APP 可以直接访问 F6，但仅限于嵌入式 WebView 页面。
|
||
- 这里的“直接访问”不是绕过主后台做业务控制，而是在进入 WebView 之前，由 `App Backend` 先完成票据、上下文和权限准备。
|
||
|
||
#### F6 Capability APIs (Backend Only)
|
||
|
||
这是系统间调用的接口能力。
|
||
|
||
图上明确标注了：
|
||
|
||
`Backend Only`
|
||
|
||
这表示：
|
||
|
||
- 移动端不能直接调这些接口。
|
||
- 这些接口只能由 `App Backend` 经由 `F6 Integration Adapter` 发起访问。
|
||
|
||
典型用途包括：
|
||
|
||
- 获取 WebView 免登票据。
|
||
- 获取采购、促销、ERP补充能力。
|
||
- 发起供应商相关查询或写入。
|
||
- 执行需要后端协同的业务流程。
|
||
|
||
### 4.2 F6 域的入口层
|
||
|
||
F6 域上部也分为公网入口区：
|
||
|
||
- `Access Gateway / WAF`
|
||
- `Load Balancer`
|
||
- `Allowlisted B2B API Gateway`
|
||
|
||
这三者分别表达不同入口：
|
||
|
||
- WebView 页面流量走 Access Gateway / WAF 和 Load Balancer。
|
||
- 后端 API 调用走专门的 allowlisted B2B API Gateway。
|
||
|
||
这正是图中为什么要同时区分页面链路和 API 链路，因为它们不是一回事。
|
||
|
||
### 4.3 App Backend 到 F6 的受控后端集成链路是什么意思
|
||
|
||
图中从 `F6 Integration Adapter` 指向 `Allowlisted B2B API Gateway` 的绿色后端集成链路，表示：
|
||
|
||
- 这是系统间受控访问。
|
||
- 不是终端用户流量。
|
||
- 需要白名单放通。
|
||
- 这是从 App Backend 所在 Azure VNet 到 F6 Supplier VPC 的跨网络边界访问。
|
||
- 访问入口必须落在 F6 VPC 对外暴露的受控 B2B API Gateway 上，而不是直接访问 F6 私有服务节点。
|
||
- 同时承担获取 WebView 票据、签名、免登参数等职责。
|
||
- 图上不再在线路上写长标签，而是通过颜色和图例表达其语义。
|
||
|
||
这也是为什么 PRD 里强调：
|
||
|
||
- F6 API 必须通过 App Backend 调用。
|
||
- APP 对 F6 的直接访问只保留 WebView 场景。
|
||
|
||
## 5. 左侧 Mini Program Backend VPC：历史小程序后台域
|
||
|
||
左侧区域表示历史小程序后台域。图中外层标注为 `Mini Program Backend VPC`，用来说明 Mini 后台不是 App Backend 私有区里的内部模块，而是保留在独立 VPC / 网络域中的历史后台集合。
|
||
|
||
这一域在图中的定位是：
|
||
|
||
- 它仍然存在。
|
||
- 它仍然是独立后台边界。
|
||
- 它不会被简单视为 APP 的主后台。
|
||
- 面向 APP 的能力应逐步被 `App Backend` 聚合。
|
||
|
||
### 5.1 为什么这里采用聚合表示而不是展开拓扑
|
||
|
||
图中把它写成：
|
||
|
||
`Independent Mini Services`
|
||
|
||
并列出：
|
||
|
||
- `O2O`
|
||
- `Warranty`
|
||
- `Retail Store`
|
||
- `ROOS`
|
||
- `Shared Capabilities`
|
||
|
||
这样写是为了强调：
|
||
|
||
- Mini Program Backend 不是一个单体后台。
|
||
- 它是多个历史业务后台的集合。
|
||
- 它们仍然可能各自承担不同的数据主来源和业务责任。
|
||
- 其中 `Retail Store` 对应“马上下单”体系中的门店注册、门店信息修改、店员管理等门店基础资料能力，不再使用容易误解为交易订单的 `Order` 表述。
|
||
- 这张图是评审视图，因此只保留“入口层 + 独立服务集合”的表达，不再展开每个历史服务之间的内部转发关系。
|
||
|
||
图这样画，更符合 PRD 对历史系统边界的定义，也能避免内部箭头过多影响主链路可读性。
|
||
|
||
### 5.2 主推荐链路：通过 App Backend 聚合
|
||
|
||
从 `Business Aggregation / Orchestration` 指向 Mini 域入口的是绿色后端集成链路。
|
||
|
||
这条线表达的是推荐架构：
|
||
|
||
- 新能力优先通过 `App Backend` 聚合后暴露给 APP。
|
||
- 历史 Mini 后台继续作为独立服务存在。
|
||
- 但它们不再被 APP 当成第一入口直接大量访问。
|
||
- 从网络角度看，这条链路是 App Backend 所在 Azure VNet 到 Mini Program Backend VPC 的受控后端调用。
|
||
- App Backend 应访问 Mini VPC 暴露的网关、防火墙或受控入口，不应把 Mini 私有服务当作同一 VNet 内的本地服务直接访问。
|
||
|
||
这是“统一主后台”原则的重要一部分。
|
||
|
||
### 5.3 兼容链路：少量保留直连
|
||
|
||
图中从 `Internet` 指向 Mini 域入口的灰色虚线标注为：
|
||
|
||
`Legacy only`
|
||
|
||
这条线表达的是：
|
||
|
||
- 某些历史模块短期还保留 APP 直连 Mini 后台的方式。
|
||
- 但这种方式只是兼容，不是推荐方案。
|
||
- 这不是未来架构方向。
|
||
- 新模块不应该继续沿用这种方式。
|
||
|
||
这条线的存在是为了如实表达现状，同时避免评审误解为：
|
||
|
||
“APP 会长期平行直连所有历史后台。”
|
||
|
||
## 6. 这张图里的主要链路怎么理解
|
||
|
||
### 6.1 主链路：APP 到主后台
|
||
|
||
链路为：
|
||
|
||
`Mobile App -> Internet -> WAF / Application Gateway -> Public Load Balancer -> App Backend BFF / Unified APIs`
|
||
|
||
这条链路表示：
|
||
|
||
- 用户所有主业务请求先进入主后台域。
|
||
- 主后台对移动端暴露统一接口。
|
||
- APP 的身份、权限、门店上下文和主流程控制都从这里进入。
|
||
|
||
这是整个系统最重要的访问路径。
|
||
|
||
### 6.2 F6 H5 页面链路
|
||
|
||
链路为：
|
||
|
||
`Mobile App -> Internet -> Access Gateway / WAF -> Load Balancer -> F6 WebView Pages`
|
||
|
||
这条链路表示：
|
||
|
||
- APP 可直接以 WebView 方式打开 F6 页面。
|
||
- 但这里的“直接打开”是页面访问级别，而不是随意直接调用供应商 API。
|
||
- 页面进入前的上下文准备、票据获取、权限判断仍由 `App Backend` 完成。
|
||
|
||
### 6.3 F6 API 链路
|
||
|
||
链路为：
|
||
|
||
`Mobile App -> App Backend -> Business Aggregation / Orchestration -> F6 Integration Adapter -> F6 Supplier VPC / Allowlisted B2B API Gateway -> F6 Capability APIs`
|
||
|
||
这条链路表示：
|
||
|
||
- 所有后端级 F6 能力都应该由主后台发起调用。
|
||
- 供应商集成逻辑不直接暴露给移动端。
|
||
- 主后台统一承担安全、审计、错误处理和链路治理。
|
||
- 网络上这是跨 VPC / VNet 的后端集成链路，需要通过 F6 VPC 暴露的 allowlisted API 入口进入。
|
||
|
||
### 6.4 Mini 聚合链路
|
||
|
||
链路为：
|
||
|
||
`Mobile App -> App Backend -> Business Aggregation / Orchestration -> Mini Program Backend VPC -> Mini Gateway / Firewall -> Independent Mini Services`
|
||
|
||
这条链路表示：
|
||
|
||
- 历史后台能力仍被使用。
|
||
- 但 APP 访问时优先走主后台聚合。
|
||
- 这有利于统一接口、统一权限和统一数据口径。
|
||
- 网络上这不是 App Backend 内部进程调用，而是从主后台 VNet 到 Mini 后台 VPC 的受控后端访问。
|
||
- Mini VPC 的外层入口承担网络隔离、访问控制和历史服务保护职责。
|
||
|
||
### 6.5 Mini 兼容直连链路
|
||
|
||
链路为：
|
||
|
||
`Mobile App -> Internet -> Mini Program Backend Domain`
|
||
|
||
但图中明确标注这是：
|
||
|
||
`Legacy compatibility direct access only`
|
||
|
||
它表示：
|
||
|
||
- 当前还有少量历史兼容模块未完成收敛。
|
||
- 架构上允许暂时存在。
|
||
- 但这不是目标态。
|
||
|
||
## 7. 为什么说这是多云架构
|
||
|
||
这张图之所以叫 `Multicloud`，是因为主系统不是部署在单一云环境里，而是跨越了多个云网络边界：
|
||
|
||
- 移动端经公网访问。
|
||
- 主业务域在 `Azure China`。
|
||
- F6 供应商域在 `Alibaba Cloud`。
|
||
- 历史 Mini Program Backend 在独立 VPC / 云网络域中。
|
||
|
||
这意味着：
|
||
|
||
- 不同域之间不是天然内网互通。
|
||
- 跨域访问必须经过明确入口。
|
||
- 供应商域和主域的边界要清晰。
|
||
- 历史系统不能被简单视为主域内部服务。
|
||
|
||
这也是为什么图中如此强调：
|
||
|
||
- VPC / VNet 边界。
|
||
- DMZ 与私有区分层。
|
||
- 受控 API 链路。
|
||
- 兼容直连和推荐主链路的区别。
|
||
|
||
## 8. 这张图的价值是什么
|
||
|
||
这张图的价值不在于说明某台机器部署在哪，而在于回答下面这些评审问题：
|
||
|
||
- APP 到底应该先访问谁。
|
||
- F6 是主后台还是供应商域。
|
||
- 为什么 F6 页面能直开，但 F6 API 不能让 APP 直接调。
|
||
- 历史 Mini 后台还保不保留。
|
||
- App Backend 到底是不是只是一个 API 网关，还是主编排中心。
|
||
- 多个系统的数据、权限和上下文由谁统一控制。
|
||
|
||
如果用一句话总结整张图：
|
||
|
||
“APP 只有一个主后台入口，供应商能力通过受控方式接入，历史小程序后台继续存在但逐步被主后台聚合，整个系统通过多云边界和访问控制实现职责分离与链路治理。”
|
||
|
||
## 9. 如何理解图中的关键标签
|
||
|
||
### Primary App Backend Domain
|
||
|
||
表示 APP 的统一主业务域，是控制面和编排面的中心。
|
||
|
||
### F6 Supplier VPC
|
||
|
||
表示 F6 是位于 Alibaba Cloud 的供应商管理独立 VPC，不属于 App Backend 主后台域。
|
||
|
||
### Independent Mini Services
|
||
|
||
表示历史小程序后台不是一个单系统，而是一组位于独立 VPC / 网络域内的后台服务。
|
||
|
||
### DMZ / Public Ingress Zone
|
||
|
||
表示对外暴露入口区，用于承接公网流量，隔离内网服务。
|
||
|
||
### Private Application Zone / Private Service Zone
|
||
|
||
表示真正承载业务服务的私有区域，不直接向公网开放。
|
||
|
||
### NSG / Access Control
|
||
|
||
表示私有区域内的访问控制和安全规则层，强调后端服务是受控访问而非默认互通。
|
||
|
||
### F6 Integration Adapter
|
||
|
||
表示对 F6 的统一适配与治理出口。
|
||
|
||
### Backend integration path
|
||
|
||
表示推荐路径，即主后台通过受控 VPC 网络入口优先聚合历史系统能力。
|
||
|
||
### Legacy only
|
||
|
||
表示兼容性保留链路，不是目标架构，不应扩散到新模块。
|
||
|
||
## 10. 第二页 Network Topology 怎么理解
|
||
|
||
`Network Topology` 是对第一张 `Network Architecture` 的补充，不是重复画一张架构图。
|
||
|
||
第一张图更偏“架构职责和访问原则”，所以使用了较多业务组件、说明框和颜色区分；第二张图更偏“网络连通和边界关系”，所以采用黑白灰拓扑表达，避免让颜色承担业务语义。
|
||
|
||
这张拓扑图重点表达四件事：
|
||
|
||
- 三个核心网络边界：`Primary App Backend VNet`、`Mini Program Backend VPC`、`F6 Supplier VPC`。
|
||
- 公网访问统一从 `Mobile App -> Internet -> Public DNS / Domain` 进入。
|
||
- 每个网络域只通过自己的受控入口暴露能力，而不是暴露内部服务。
|
||
- 跨 VNet / VPC 的访问必须经过网关、防火墙、API Gateway 或适配层。
|
||
|
||
### 10.1 为什么拓扑图是黑白灰
|
||
|
||
网络拓扑图的目标不是强调业务域颜色，而是强调：
|
||
|
||
- 网络边界在哪里。
|
||
- 公网入口在哪里。
|
||
- 私有服务在哪里。
|
||
- 哪些链路是允许的。
|
||
- 哪些链路只是兼容例外。
|
||
|
||
因此第二页没有继续沿用第一张图里的蓝色、绿色、橙色业务域配色，而是使用黑白灰表达。
|
||
|
||
这样更符合网络拓扑图的阅读习惯：读者主要通过形状、边界框、线型和线条粗细理解网络关系，而不是通过颜色理解业务语义。
|
||
|
||
### 10.2 拓扑图里的主要区域
|
||
|
||
#### Public Network
|
||
|
||
中间的 `Public Network` 表示公网访问区。
|
||
|
||
里面包括：
|
||
|
||
- `Mobile App`
|
||
- `Internet`
|
||
- `Public DNS / Domain`
|
||
|
||
它表达的是：移动端访问后端系统时，首先进入公网和域名解析层，然后再被路由到不同网络域暴露出来的公网入口。
|
||
|
||
这里不是一个业务系统，而是网络访问路径的公共部分。
|
||
|
||
#### Azure China / Primary App Backend VNet
|
||
|
||
左上区域表示 APP 主后台所在的 Azure China VNet。
|
||
|
||
它内部用虚线框标出 `VNet boundary`，并分成两层：
|
||
|
||
- `Public DMZ Subnet`
|
||
- `Private Application Subnet`
|
||
|
||
`Public DMZ Subnet` 中放的是 `WAF / App Gateway + Public LB`，表示 APP 主链路必须先经过公网入口、防护和负载均衡。
|
||
|
||
`Private Application Subnet` 中放的是：
|
||
|
||
- `NSG / Access Rules`
|
||
- `App Backend BFF + Orchestration`
|
||
- `F6 Integration Adapter`
|
||
|
||
这表示真正的 APP 后台服务不直接暴露公网，而是在私有子网中运行，并受到 NSG / Access Rules 约束。
|
||
|
||
#### Mini Program Backend Independent VPC
|
||
|
||
左下区域表示历史小程序后台所在的独立 VPC。
|
||
|
||
它内部包括：
|
||
|
||
- `Mini Gateway / Firewall`
|
||
- `Mini Services`
|
||
|
||
这里强调的是：Mini 后台不是 Azure App Backend VNet 里的内部模块，而是另一个独立网络边界中的历史服务集合。
|
||
|
||
APP 面向 Mini 能力的目标链路应当是：
|
||
|
||
`App Backend -> Mini Gateway / Firewall -> Mini Services`
|
||
|
||
而不是让 APP 长期绕过主后台直接访问 Mini 服务。
|
||
|
||
#### F6 Supplier VPC / Alibaba Cloud
|
||
|
||
右侧区域表示供应商 F6 所在的 Alibaba Cloud VPC。
|
||
|
||
它内部用 `Supplier-managed VPC boundary` 表示这是供应商管理的独立网络边界，不属于 APP 主后台网络。
|
||
|
||
F6 侧有两个不同入口：
|
||
|
||
- `Access Gateway / WAF + Load Balancer`
|
||
- `Allowlisted B2B API Gateway`
|
||
|
||
前者服务于 F6 WebView 页面访问，后者服务于主后台到 F6 API 的后端集成。
|
||
|
||
这两个入口不能混在一起理解，因为它们的访问来源、访问目的和安全要求都不同。
|
||
|
||
### 10.3 拓扑图里的线型含义
|
||
|
||
第二页不用颜色区分链路，而是用线型和粗细表达语义。
|
||
|
||
#### Primary App route
|
||
|
||
主访问链路是：
|
||
|
||
`Mobile App -> Internet -> Public DNS / Domain -> WAF / App Gateway + Public LB -> App Backend`
|
||
|
||
这条链路表示 APP 的主业务请求进入 Azure App Backend VNet，由主后台统一承接。
|
||
|
||
#### Backend integration
|
||
|
||
后端集成链路有两类：
|
||
|
||
- `App Backend -> Mini Gateway / Firewall -> Mini Services`
|
||
- `App Backend -> F6 Integration Adapter -> Allowlisted B2B API Gateway -> F6 Capability APIs`
|
||
|
||
这两类链路都表示受控的跨网络边界访问。
|
||
|
||
它们不是同一 VNet 内部的本地调用，也不是移动端直接访问第三方或历史后台。
|
||
|
||
#### F6 WebView route
|
||
|
||
F6 WebView 链路是：
|
||
|
||
`Mobile App -> Internet -> Public DNS / Domain -> F6 Access Gateway / WAF + Load Balancer -> F6 WebView Pages`
|
||
|
||
这条链路表示 APP 可以打开供应商 F6 的嵌入式页面。
|
||
|
||
但它仍然只是 WebView 页面访问例外，不代表 APP 可以直接访问 F6 API。
|
||
|
||
#### Legacy compatibility
|
||
|
||
Mini legacy 兼容链路是：
|
||
|
||
`Mobile App -> Internet -> Public DNS / Domain -> Mini Gateway / Firewall`
|
||
|
||
这条线用虚线表达，含义是：
|
||
|
||
- 这是历史兼容链路。
|
||
- 不是目标态主链路。
|
||
- 不应继续扩散到新功能。
|
||
- 后续应尽量收敛到 `App Backend -> Mini` 的后端聚合路径。
|
||
|
||
### 10.4 Network Architecture 和 Network Topology 的区别
|
||
|
||
两张图的区别可以这样理解：
|
||
|
||
| 页面 | 主要回答的问题 | 适合谁看 | 重点 |
|
||
| --- | --- | --- | --- |
|
||
| `Network Architecture` | 为什么这样分域、主链路是谁、F6 和 Mini 怎么定位 | 产品、研发、架构评审 | 架构原则、职责边界、访问治理 |
|
||
| `Network Topology` | 网络上怎么连、从哪里进、跨哪些 VNet / VPC | 网络、安全、运维、集成 | 网络边界、入口节点、连通路径、线型语义 |
|
||
|
||
因此，第二张图看起来应该比第一张更“网络化”：
|
||
|
||
- 更少业务说明。
|
||
- 更强调 VNet / VPC boundary。
|
||
- 更强调 ingress / gateway / firewall。
|
||
- 更强调公网和私网分层。
|
||
- 更强调跨网络访问不是默认互通，而是通过受控入口连接。
|
||
|
||
## 11. 结论
|
||
|
||
这两张图合起来已经把系统最关键的几件事表达清楚了：
|
||
|
||
- APP 的统一主入口是 `App Backend`。
|
||
- F6 API 由主后台统一接入。
|
||
- 历史 Mini 后台独立保留在自己的 VPC / 网络域中，但应逐步收敛到主后台聚合。
|
||
- 各域通过公网入口区、私有服务区和访问控制层进行隔离。
|
||
|
||
因此，`Network Architecture` 本质上是一张“面向架构评审的网络边界与访问链路图”，重点在于：
|
||
|
||
- 说明系统边界。
|
||
- 说明主访问链路。
|
||
- 说明供应商接入方式。
|
||
- 说明历史系统兼容策略。
|
||
- 说明为什么要把 APP 主后台定义为统一编排中心。
|
||
|
||
而 `Network Topology` 则是一张“面向网络、安全和集成理解的拓扑图”，重点在于：
|
||
|
||
- 说明公网入口。
|
||
- 说明 VNet / VPC 边界。
|
||
- 说明私有服务区不直接暴露公网。
|
||
- 说明跨网络边界访问必须通过受控网关。
|
||
- 说明 legacy direct access 只是兼容例外，不是目标态。
|