conti-docs/Architecture-Diagram/network-architecture-explanation.md

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 只是兼容例外，不是目标态。