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