在上一篇中，我们深入探讨了“现代异构”数据源，尤其是API、JSON和流数据如何给传统ETL工具带来“连接器诅咒”、“重客户端手工作坊”和“批处理基因”这三重困局。其核心在于，传统工具的架构是为“DB优先、二维表、批处理”的T+1时代设计的。
本文将阐述，为什么B/S架构，即“Web原生架构”，是破局这一切的“利刃”。这种架构的优越性绝非“UI在浏览器里”这么简单，它带来的是一场从“分布式手工作坊”到“集中式数据平台”的范式转移。我们将分析Web架构如何凭借其“统一管控”、“API原生”和“弹性部署”三大基因，从根本上解决异构集成的核心难题。
1. 范式转移：从“C/S手工作坊”到“B/S集中平台”
前文提到，许多传统ETL工具（如Kettle, SSIS）是C/S架构。开发者在本地客户端设计“作业”，然后部署到服务器执行。这种模式导致了版本失控、环境不一和协作地狱。
Web架构（B/S）的第一个、也是最直观的变革，就是将“设计、配置、调度”的能力，从“分散的客户端”彻底收归“集中的服务器” 。
这带来了（一）中“C/S手工作坊”问题的完美解法：
- 零客户端（Zero Client）： 开发者、运维、数据分析师，所有人需要的只是一个浏览器。无需在本地安装GigaBytes级别的专用软件，更无需管理和配置本地的JDBC/ODBC驱动。
- 资产的集中化与版本化：
- C/S模式： 作业文件（.ktr）保存在哪？Git冲突怎么合？
- B/S模式： 所有的连接配置、转换脚本、调度任务，都作为“资产”统一存储在平台服务器的数据库中。这使得版本控制、权限管理和团队协作成为可能。
- 环境的绝对一致（WORE）：
- C/S模式： “Write Once, Run... maybe”。（本地Windows，生产Linux）。
- B/S模式： “Write Once, Run Everywhere”。开发者在Web上设计的任务，与生产环境执行的任务，共享的是同一套服务器端环境（相同的依赖、相同的驱动、相同的Runtime）。
2. 核心优势一：天然的“协议亲和性”（API-Native）
前文的核心痛点是：传统工具讲“JDBC语言”，而现代数据源讲“HTTP/API语言”。
Web原生架构的第二个基因优势在于，它本身就是用“HTTP/API语言”构建的。它的技术栈（如Java, Go, Python）与现代SaaS API的技术栈是同源的。这种“协议亲和性”使其在处理API数据源时具有碾压性优势。
它彻底解决了“连接器诅咒”：
- 内建的HTTP客户端： 它不再是“模拟”HTTP，它就是一个标准的、功能完备的HTTP客户端。
- 抽象复杂性，而非暴露复杂性：
- 前文中提到，传统工具的“通用REST连接器”要求用户自己处理Auth、分页、限流。而一个现代Web采集平台，会通过UI界面将这些复杂性抽象掉：
- 身份认证（Auth）： 平台提供一个“凭证管理器”。用户只需选择“OAuth 2.0”，并填入Client ID / Secret，平台会自动在后端完成Token的获取和刷新。
- 分页（Pagination）： 平台提供分页策略选项，例如：“基于页码（page）”、“基于偏移（offset/limit）”或“基于游标（next_token）”。用户只需选择并填入参数名，平台会自动循环拉取所有页面，而无需用户编写循环脚本。
- 速率限制（Rate Limit）： 平台内建了对429 Too Many Requests的自动重试和退避（Back-off）机制。
- JSON的原生处理能力：
- 前文中提到，传统ETL难以处理“N层嵌套JSON”。而Web架构平台通常内建了强大的JSON解析器。它们允许用户通过“JSON Path”表达式（如$.data[0].attributes.name）直接提取字段，甚至可以在Web UI上提供可视化的JSON结构点选，无需“拍平”，直接将嵌套结构映射到目标表。
3. 核心优势二：灵活的部署与可观测性
前文的第三个困局是传统ETL的“批处理基因”和“重型部署”模式。Web架构，特别是“云原生”时代的Web架构，从根本上改变了部署和服务模式。
现代Web采集平台，其架构通常被设计为“控制面-数据面分离”：
- 控制面（Web Server）： 这就是用户通过浏览器访问的“平台”。它负责：任务设计、凭证管理、任务调度、日志展示。它只发号施令，不干脏活累活。
- 数据面（Agent/Worker）： 负责实际执行数据采集和转换的“工作节点”。它们是无状态的、轻量级的执行单元。
这种解耦架构带来了巨大的灵活性：
- 弹性伸缩：
- 控制面（Web平台）可以部署在数据中心，而数据面可以被弹性部署。例如：
- 应对高并发： 需要同时采集100个API？平台只需启动100个临时的Worker实例（如K8s Pods）。
- 应对混合云： 目标数据库在客户的私有IDC内网？只需在客户内网部署一个轻量级Agent，它会反向连接公网的控制面（Web平台）来获取任务并回传数据，完美解决了网络隔离问题。
- 统一的可观测性：
- 由于所有任务都由“控制面”统一调度和管理，运维人员终于有了一个“上帝视角”的监控大盘。
- C/S模式： 日志分散在各个执行服务器上。
- B/S模式： 所有Worker的执行日志（stdout/stderr）、运行指标（采集条数、吞吐率）、任务状态（Success/Failed）全部自动汇集到Web平台的“控制面”，进行集中的告警和分析。
- “批流一体”的可能：
- 在这种架构下，“批处理”和“流处理”只是两种不同类型的“Worker”而已。
- 批处理任务： 控制面按时（如02:00）启动一个“批处理Worker”执行任务，完成后Worker自动销毁。
- 流处理任务： 控制面启动一个“流处理Worker”（如Kafka Consumer），该Worker 7x24小时常驻运行。
- 用户在同一个Web界面上，既可以配置T+1的批处理任务，也可以配置实时的流处理任务，实现了真正的“批流一体”管理。
4. 结论：
Web原生架构（B/S）对“现代数据采集”的破局，是架构层面的降维打击。
它不是对传统ETL工具的“改良”，而是彻底的“范式转移”：
- 它用“B/S集中平台”取代了“C/S手工作坊”，解决了运维、协作和版本管理的根本难题。
- 它用“API原生基因”取代了“DB原生基因”，将复杂的API（Auth, Paging, Rate Limit, JSON）交互“平台化”、“配置化”。
- 它用“控制面-数据面分离”的弹性架构，取代了“重型单体”部署，实现了弹性伸缩和统一的可观测性。
一个现代化的Web采集平台，用“平台化”和“协议统一”解决了异构连接和统一管理的核心难题。
