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