Helidon、Vert.x 与其他云原生 Java 框架

• Helidon SE 的函数式模型
• Helidon MP 的 MicroProfile/CDI 模型
• 选型依据与适用场景

Helidon SE 是"函数式、轻量"的编程模型，基于函数式路由与响应式 API，开发者用显式请求处理（如 router 的 handler）来构建应用，无 CDI 容器，代码更直接、侵入性小、启动快、内存低，适合追求极致性能与轻量的场景。Helidon MP 是"MicroProfile 标准"的编程模型，基于 CDI 与 JAX-RS，提供 @Path、@Inject 等标准注解，支持 MicroProfile Config、Health、Metrics、Rest Client、Fault Tolerance 等规范，生态更标准、更贴近开发者熟悉的企业 REST 风格，适合需要标准规范、团队熟悉 CDI/JAX-RS 的场景。选择上：SE 适合轻量、性能敏感、偏好函数式/显式编程的项目；MP 适合希望遵循 MicroProfile 标准、团队已有 JAX-RS/CDI 经验、需要标准可移植性的项目。两者可共存于同一 Helidon 生态，底层共享响应式核心。

差异的核心是"函数式显式 vs 规范标准"。SE 用代码表达一切，MP 用注解与规范表达。选型取决于团队风格与标准诉求，需求明确、性能敏感用 SE，标准生态用 MP。

• EventLoop 线程模型
• Verticle 的部署与隔离
• SharedData 的共享机制

Vert.x 的核心是 EventLoop 线程模型：每个 EventLoop 线程在一个事件循环中处理事件，所有处理器（handlers）都在 EventLoop 上执行，Vert.x 保证同一 EventLoop 上的处理器不会并发执行，从而避免并发访问问题；但处理器绝不能阻塞，否则会饿死该 EventLoop 上的其他请求。Verticle 是 Vert.x 的部署单元，一个 Verticle 实例绑定到某个 EventLoop 线程，通过事件总线（EventBus）与其他 Verticle 通信，实现并发隔离与水平扩展。SharedData 用于在 Verticle 间共享数据，提供异步的本地 Map（LocalMap）、分布式 Map（Cluster-wide Map）、异步锁（Lock）与计数器（Counter），其中分布式 Map/Lock 依赖集群管理器（如 Hazelcast/Infinispan）。三者协同：EventLoop 提供确定性并发，Verticle 提供部署与隔离，SharedData 提供跨 Verticle 的共享与协调。

理解 Vert.x 响应式引擎的关键是"单线程事件循环 + 不阻塞"。EventLoop 是并发模型，Verticle 是组织单元，SharedData 是共享设施。不阻塞 EventLoop 是使用 Vert.x 的铁律。

• MicroProfile 与 Jakarta EE 的关系
• 各标准 API 的用途
• 微服务标准化的价值

MicroProfile 是一套面向微服务的 Java 规范，由 Eclipse 维护，是 Jakarta EE 的补充而非替代：它建立在 Jakarta EE 基础之上（复用 CDI、JAX-RS 等 Jakarta 规范），并扩展了微服务生态所需的额外 API。两者关系是"MicroProfile 基于 Jakarta EE 并补充微服务能力"。各标准 API 的作用：Config 提供类型化配置与多源配置加载；Health 提供应用健康检查（就绪/存活），供 K8s 探针使用；Metrics 提供指标统计与暴露（对接 Prometheus）；OpenAPI 提供 REST API 的 OpenAPI 文档生成；Fault Tolerance 提供超时/重试/熔断/限流；Rest Client 提供声明式 REST 客户端；JWT 提供基于 JWT 的认证。整体上，MicroProfile 让微服务有统一、可移植的标准 API，Quarkus、Helidon MP、OpenLiberty 等都实现这些规范，提升可移植性并降低锁死。

MicroProfile 是"微服务标准层"，Jakarta EE 是"企业基础层"。理解其"基于 EE 补充微服务"的关系，以及各 API 解决的具体问题，能帮助开发者用标准 API 构建可移植微服务。

• executeBlocking 的原理
• worker verticle 的作用
• 阻塞隔离与线程池

由于 EventLoop 线程不能阻塞，Vert.x 提供了两种把阻塞任务移出事件循环的方式。executeBlocking：在事件循环上调用 context.executeBlocking(handler, resultHandler)，Vert.x 会把 handler 提交到独立的"worker 线程池"执行，执行完成后把结果回调到原来的事件循环线程，从而让阻塞操作（如数据库查询、文件 IO）不占住事件循环，其他请求仍能处理。worker verticle：用 setWorker(true) 部署的 Verticle 运行在 worker 线程池而非 EventLoop，专用于执行阻塞代码，与普通（EventLoop）Verticle 隔离。两者都依赖 Vert.x 内部的工作线程池，通过把阻塞任务调度到该池，避免阻塞 EventLoop。使用时要合理配置 worker 线程池大小（避免阻塞过多导致 worker 池耗尽），并注意 executeBlocking 的并发上限与结果回调的线程模型。

核心是"EventLoop 不阻塞"的落地手段。executeBlocking 把单次阻塞调用调度到 worker 池并回调，worker verticle 把整个阻塞组件放到 worker 线程。理解阻塞隔离才能避免请求饿死。

• Future/CompositeFuture 的编排能力
• 与虚拟线程的对比
• 异步编排的取舍

Vert.x 的 Future 表示异步结果，支持组合操作（map、compose、recover 等），CompositeFuture 用于把多个 Future 编排在一起（all/any），实现并行/串行/条件等复杂异步流程，避免"回调地狱"。在虚拟线程时代，虚拟线程可以把阻塞式代码以"看似同步"的方式运行，降低并发编程复杂度。但 Vert.x 的异步编排（Future/Callback）仍是"高并发、非阻塞、确定性"的模型：它不占用线程栈、适合大量 IO 并发，且与 Vert.x 事件循环模型天然契合。因此定位是：在需要"非阻塞高并发 + 响应式"的场景，Future/CompositeFuture 仍是核心；虚拟线程则提供"用同步代码写并发"的替代路径。两者可互补：Vert.x 提供了虚拟线程兼容的 API（如 executeOnWorker 或对虚拟线程的支持），让开发者按需选择。总体，Vert.x 的响应式编排在底层 IO 密集场景仍占优，虚拟线程则简化了局部阻塞逻辑。

定位差异在于"非阻塞编排 vs 虚拟线程简化阻塞"。Future/CompositeFuture 适合事件循环下的大规模 IO 编排，虚拟线程适合"同步风格"的并发处理。二者并存，按场景选择。

• 虚拟线程的模型
• Nima 的架构
• 相对传统阻塞/响应式的优势

Helidon Nima 是 Helidon 基于虚拟线程（Java 21 Loom）的微服务框架，它把"每个请求一个虚拟线程"作为默认模型：请求处理逻辑运行在虚拟线程上，虚拟线程可自由阻塞（如 DB 访问、IO），而不会阻塞底层平台线程，因为虚拟线程的阻塞会挂起该虚拟线程并释放平台线程。因此开发者可以用"同步、阻塞式"的代码写业务逻辑，无需事件循环或回调，却获得接近非阻塞的高并发能力。Nima 的优势：编程模型简单（同步代码）、并发吞吐高（虚拟线程轻量、可创建大量）、无回调地狱、降低学习成本；同时保留 Helidon 的轻量与可观测性。相比传统"每请求一线程"的建模（线程昂贵、易耗尽），Nima 用虚拟线程解决了线程成本问题，相比响应式（回调/异步编程复杂）则简化了开发。Nima 是"同步代码 + 高并发"的折中方案，特别适合 IO 密集型微服务。

Nima 的价值在于"用同步代码获得高并发"。虚拟线程把阻塞挂起，让平台线程不被占用，从而兼具同步的简单与高并发的吞吐，是虚拟线程时代微服务框架的重要演进方向。

• 集群模式与集群管理器
• 分布式事件总线
• 集群共享数据与广播

Vert.x 集群模式让多个 Vert.x 实例组成一个集群，共享一个分布式事件总线与共享数据。集群管理器（Cluster Manager）负责成员发现、节点管理、分布式 Map/Lock 的实现，Hazelcast 与 Infinispan 是常用的实现。在集群模式下，EventBus 变成分布式事件总线：消息可以发送到集群中任意节点上的 Verticle 地址，支持点对点、发布/订阅、请求-响应模式，并支持集群范围的广播（publish）。集群管理器还提供分布式共享数据（分布式 Map、Counter、Lock），供跨节点协调。典型应用：把多个无状态服务实例通过集群 EventBus 互联，实现消息路由与负载均衡。要注意集群模式依赖网络与集群管理器，配置复杂，且广播消息会有网络开销，应在真正需要跨节点通信时使用集群 EventBus 而非单机 EventBus。

集群模式的核心是"集群管理器 + 分布式事件总线"的组合。集群管理器提供成员与共享数据，让 EventBus 在节点间路由消息，从而支撑水平扩展的分布式通信。

• Rest Client 的声明式客户端
• Fault Tolerance 注解（超时/重试/熔断/限流）
• 组合使用提升可靠性

MicroProfile Rest Client 提供声明式 REST 客户端：用 @RegisterRestClient 注解接口，@Path/@GET 等注解方法，框架生成实现，调用远程服务如同调用本地方法。MicroProfile Fault Tolerance 提供容错注解：@Timeout（超时）、@Retry（重试）、@CircuitBreaker（熔断）、@Bulkhead（限流/隔离）、@Fallback（降级）、@Asynchronous（异步）。两者可组合在 Rest Client 接口方法上，让远程调用具备容错能力：如给某个远程调用加 @Timeout + @Retry + @CircuitBreaker + @Fallback，实现超时重试、熔断降级。这解决了微服务通信的可靠性问题：远程调用可能超时、失败、雪崩，通过容错注解可以定义策略，避免故障扩散。相比手写容错逻辑，Fault Tolerance 注解声明式、可移植（基于 MicroProfile 标准），Quarkus、Helidon MP、OpenLiberty 都支持。

Rest Client 解决"如何调用"（声明式），Fault Tolerance 解决"失败了怎么办"（容错策略）。组合使用让远程调用既简洁又健壮，是 MicroProfile 微服务可靠性设计的核心。

• 组合的模式与架构
• 依赖注入与事件循环的协调
• 使用场景与注意事项

Vert.x 与 Spring 可以共存，常见做法是"以 Spring Boot 为应用外壳，用 Vert.x 作为高性能 IO/事件引擎"。例如：用 Spring Boot 管理依赖、配置、中间件集成，同时把 Vert.x 作为核心 IO 引擎（HTTP 服务器、EventBus、异步客户端），或者用 Vert.x 的 Web 处理高并发请求，Spring 负责业务与 Bean 管理。实践中常见组合：Spring Boot 中通过 @Bean 启动 Vert.x 实例，把 Vertx 作为 Spring Bean 注入，事件循环线程与 Spring 的线程池分离；或用 Vert.x 的 EventBus 作为异步消息总线，与 Spring 的响应式/消息组件集成。注意事项：Vert.x 的事件循环线程不能阻塞，若在 Vert.x 处理器中调用 Spring 的阻塞 Bean（如 JDBC 服务），应通过 executeBlocking 或 worker 线程执行，避免阻塞事件循环；同时要管理好 Vert.x 实例的生命周期与 Spring 容器关闭时的资源释放。这种组合适合"既要 Spring 生态、又要 Vert.x 高性能"的混合场景。

共存的关键是"职责分离 + 线程边界"。Spring 管业务与依赖，Vert.x 管 IO 与事件，通过 executeBlocking 隔离阻塞，避免事件循环被 Spring 阻塞调用拖慢。理解线程边界是组合成功的前提。

• 虚拟线程支持程度
• Native 支持程度
• 各框架的适用轨道

在"虚拟线程 + Native"双轨下，各框架定位不同。Spring（Boot 3.2+/4.x）支持虚拟线程（启用 spring.threads.virtual.enabled），Native 通过 Spring AOT 支持但兼容性成本较高；适合"需要 Spring 生态、Native 是可选"的团队。Quarkus 同时强化虚拟线程（quarkus-virtual-threads）与 Native 支持（编译时优先、扩展成熟），兼顾两者，适合"质量 + 性能 + Native"并重的场景。Helidon 提供 Nima（虚拟线程原生）与 SE/MP，Nima 在虚拟线程轨道体验好，Native 支持也完善，适合"拥抱虚拟线程 + 轻量"的场景。Vert.x 是事件循环/响应式模型，虚拟线程可以作为 executeBlocking 的底层（操作可跑在虚拟线程），Native 支持相对有限，适合"事件循环 + 高并发非阻塞"的传统响应式场景。选型矩阵可按两个维度打分：虚拟线程需求（高/低）× Native 需求（高/低）。若两者都高选 Quarkus/Helidon Nima；虚拟线程高、Native 低可选 Spring(虚拟线程)或 Helidon Nima；Native 高、虚拟线程低可选 Quarkus；都低则看团队与生态。总体上，虚拟线程与 Native 是正交的两个能力，按实际需求组合选择。

选型矩阵本质是"虚拟线程 × Native"两个正交维度的组合。理解各框架在两条轨道上的成熟度，按业务对二者的需求权重定位，避免一概而论。

• 规范的实现方式
• 性能与启动差异
• 各自动态与扩展

两者都实现 MicroProfile 标准（Config、Health、Metrics、OpenAPI、Fault Tolerance、Rest Client 等），因此 API 层面可移植、注解一致。差异在实现机制：Helidon MP 基于 CDI 容器（相对传统运行期装配），Quarkus 基于编译时优先（ArC CDI + 构建期生成元数据），因此 Quarkus 在启动时间、内存占用与 Native 支持上通常更优，Helidon MP 则更轻、实现更贴近标准容器。Helidon MP 强调模块化与轻量，与 Helidon SE 共享响应式核心，可逐步迁移到 SE；Quarkus 强调编译期优化与扩展生态（Dev Services、Dev UI、Native 成熟）。生态上 Quarkus 扩展更丰富、社区更大，Helidon MP 由 Oracle 维护、更专注企业级与轻量。选择上：追求标准兼容与轻量用 Helidon MP，追求极致性能、Native 与丰富生态用 Quarkus。两者都适合需要 MicroProfile 标准的微服务。

同为 MicroProfile 实现，差异在"实现哲学"——Helidon MP 标准而轻，Quarkus 编译期优化而高性能。API 兼容带来可移植，实现机制决定性能与生态。

• Router 与路由注册
• 子路由、失败处理、过滤器
• 与 Spring MVC 的编程模型对比

Vert.x Web 的 Router 是路由容器，用 router.get/post("/path").handler(ctx -> {...}) 注册路由处理器。子路由通过挂载子 Router 实现（router.mountSubRouter("/api", subRouter)），把一组路由按前缀组织。失败处理用 .failureHandler(ctx -> {...}) 捕获异常并返回错误响应，区别于正常 handler。过滤器用 .register 或 order 字段给路由绑定顺序化的处理逻辑（如鉴权、日志），类似拦截器。与 Spring MVC 相比，编程模型差异明显：Spring MVC 用注解 + 方法映射（@RestController/@GetMapping），框架通过反射扫描注册路由；Vert.x Web 用函数式代码显式注册路由与 handler，无注解、无反射，更直接也更有控制力。Spring MVC 更声明式、适合团队协作，Vert.x Web 更底层、更灵活、性能更高，适合需要精细控制路由与高并发的场景。

差异核心是"声明式注解 vs 函数式路由"。Spring MVC 用注解声明，Vert.x Web 用代码注册。理解子路由、失败处理、过滤器的 Vert.x 专属写法，是掌握其 Web 层的关键。

• 发布/订阅、点对点、请求-响应模式
• 消息编解码器
• 超时与失败处理

Vert.x EventBus 提供三种消息模式。点对点（send）：消息发送到某地址，由该地址的一个消费者接收（默认轮询），用于任务分发。发布/订阅（publish）：消息广播到该地址的所有消费者，用于事件通知。请求-响应（request/reply）：消费者处理后可 reply 返回结果，发送方用消息 replyHandler 接收响应，用于 RPC 式调用。消息编解码方面，EventBus 内置对 String、Buffer、JSON 等类型支持，自定义类型需注册 MessageCodec（Encoder/Decoder），集群模式下还需支持跨节点编解码。超时处理：send 时可设置超时（如 DeliveryOptions 的 sendTimeout），超时后 replyHandler 收到异常（NoHandlersException 或 timeout）；request/reply 也支持超时控制。合理设置超时与失败处理，能避免无消费者或消费超时导致请求挂起。整体上，EventBus 是 Vert.x 分布式通信的枢纽，支持多样消息模式与可靠编解码。

EventBus 是 Vert.x 的"消息中枢"。理解三种模式（send/publish/request-reply）、自定义编解码与超时，是构建基于事件总线架构的关键。点对点 vs 发布订阅的语义区别是重点。

• 原生编译的元数据支持
• 快速启动的机制
• 与编译期处理的结合

Helidon 对 GraalVM Native Image 支持良好。Helidon 从设计上减少反射与动态代理，配合 Native 编译所需的反射/序列化元数据（Helidon 提供相应配置与注解），可生成原生可执行文件。Helidon 的快速启动特性源于其轻量设计：Helidon SE 无 CDI 容器、函数式路由，启动开销小；Helidon MP 虽基于 CDI，但相对传统容器更轻。同时 Helidon 支持编译期处理（如 config 绑定、bean 生成的优化），减少运行期反射。原生可执行文件启动可达毫秒级、内存占用低，非常适合云原生与 Serverless 场景。Helidon 提供 helidon 工具链支持 Maven/Gradle 生成 Native 镜像，并适配 MicroProfile 的 Native 兼容性。总体，Helidon 以轻量 + 原生支持实现快速启动，满足云原生低资源需求。

快速启动源于"轻量 + 少反射 + 原生支持"。Helidon SE 的函数式轻量设计与 Native 元数据支持，让启动极快、内存低，是云原生场景的重要优势。

• HttpClient/WebClient 的流式响应
• 背压的 pause/resume 机制
• 防止内存溢出

Vert.x 的 HttpClient 与 WebClient 支持流式响应，通过 handler 逐块处理响应体。背压（backpressure）机制通过 pause/resume 控制数据流：当消费者处理慢时，调用 stream.pause() 暂停接收数据，避免数据积压导致内存溢出；当消费者就绪时调用 stream.resume() 恢复接收。类似的机制也存在于 Vert.x 的 ReadStream/WriteStream 接口（HTTP 响应、文件、EventBus 等都实现该接口）。背压解决的核心问题是"生产者快于消费者"导致的数据堆积与内存压力：在无背压时，接收方若不及时消费，数据会无限缓冲；pause/resume 让消费方按自身处理能力调节接收速率，实现流量控制。WebClient 在此之上提供更高级的请求/响应 API 与流式处理。理解背压是 Vert.x 事件驱动模型下避免内存问题的关键。

背压是响应式流的基石。pause/resume 让消费者控制接收速率，防止数据积压。理解 ReadStream 的 pause/resume 语义，是 Vert.x 中处理大响应与高吞吐流的关键。

• ConfigSource 的机制
• ConfigMap/Secret 读取
• 配置刷新与安全

Helidon Config 提供多源配置抽象，通过 ConfigSource 从不同来源加载配置（属性文件、环境变量、系统属性、Consul 等）。针对 Kubernetes，Helidon 提供 Kubernetes ConfigSource，可读取 K8s 的 ConfigMap 与 Secret 作为配置源，并把它们合并进统一配置树。开发者通过 Config API 或 @ConfigProperty 注入读取配置，无需关心来源。Helidon Config 支持配置刷新（on-change 监听），当 ConfigMap 更新时可重新加载配置。Secret 涉及敏感信息，Helidon 支持从 Secret 读取并配合加密/解密处理，保证安全。整体上，Helidon Config 把 K8s 的原生配置对象（ConfigMap/Secret）接入应用配置体系，实现"外部化 + 动态 + 安全"的配置管理，是云原生配置的典型实践。

集成核心是"把 ConfigMap/Secret 作为 ConfigSource 接入统一配置树"。Helidon Config 的多源合并 + 刷新 + 加密，让 K8s 配置对象与业务配置无缝衔接，兼顾外部化与安全。

• TCP/UDP 服务器的 API
• 自定义协议解析
• 网关与代理场景

Vert.x 提供 NetServer/NetClient（TCP）与 DatagramSocket（UDP），支持直接创建自定义协议服务器。开发者用 server.connectHandler(socket -> socket.handler(buffer -> {...})) 处理连接与数据，通过 Handler 逐块解析字节流，实现自定义协议（如二进制、TLV、自定义帧）。UDP 用 DatagramSocket.receive 监听报文。基于此可以构建网关/代理：用 NetServer 监听客户端连接，解析协议后转发到后端（用 NetClient 或 HttpClient），实现协议转换、负载均衡、流量控制；或用 Vert.x 的 HTTP 代理（ProxyServer）做 HTTP 网关。要注意 TCP 数据是字节流，需自己处理粘包/拆包（帧定界），Vert.x 的 Buffer 与 RecordParser 可辅助解析。Vert.x 高性能、非阻塞，适合作为网关的底层引擎，处理大量并发连接与自定义协议。

自定义协议服务器的核心是"连接 + 字节流解析"。理解 NetServer/DatagramSocket 与 Buffer/RecordParser 的使用，以及粘包拆包处理，是构建协议网关的关键。网关场景常与代理、负载均衡结合。

• Micrometer 集成与指标暴露
• 异常处理 handler
• 可观测性

Vert.x 通过 vertx-micrometer-metrics 集成 Micrometer，跟踪事件循环、HttpServer、HttpClient、EventBus、Verticle 等指标（如请求数、延迟、连接数、事件循环队列），并暴露到 Prometheus 等系统。通过 VertxOptions 配置 MicrometerMetricsOptions 启用，将指标注册到 Micrometer Registry，可在 /metrics 端点暴露。异常处理方面，Vert.x 提供多种 handler：RoutingContext 的 failureHandler 捕获路由处理中的异常并返回错误响应；HttpServer 的 exceptionHandler 处理连接级异常；一般 Verticle 中的异常可通过 handler 或 try/catch 处理，未处理异常会进入事件循环的异常处理。可结合 ErrorHandler 与自定义失败响应，统一错误格式。Metrics 与异常处理共同构成 Vert.x 应用的可观测性与健壮性，让运行状态可监控、错误可定位。

Micrometer 集成让 Vert.x 指标标准化、可接入 Prometheus；异常处理 handler 让错误可捕获、可响应。二者结合是 Vert.x 应用可观测性与健壮性的基础。

• 信创环境的背景
• 框架的国产化适配
• 落地考量

信创环境强调国产化、自主可控，涉及国产 CPU（如鲲鹏、飞腾、海光）、国产操作系统（如麒麟、统信 UOS）、国产数据库与中间件等。Helidon 与 Vert.x 都是纯 Java 框架，对底层平台依赖较小，理论上可在信创环境运行，但落地需关注：一、运行时版本（JDK）在国产平台的兼容性（需适配国产 JDK 或适配特定架构）；二、依赖库（如 Hazelcast、Netty 等）是否有国产化适配或替代；三、数据库连接（JDBC 驱动）需适配国产数据库（如达梦、人大金仓、GaussDB）；四、与国产中间件、云平台的集成。Vert.x 因底层依赖 Netty 等，需验证在国产 CPU 架构上的性能与兼容；Helidon 相对轻量、依赖少，适配相对简单。总体，两者在信创环境的适配正逐步推进，落地时需进行架构验证、兼容性测试与国产化组件替换，并关注安全合规。

信创适配的关键是"运行时 + 依赖 + 数据库 + 中间件"的国产化兼容。框架本身依赖少、纯 Java 更易适配，但需系统验证国产 CPU/OS/数据库链路，并做组件替换。

• Security 的 provider 链机制
• 注解式保护（@Authenticated/@RolesAllowed）
• OIDC/JWT 集成

Helidon Security 采用 provider 链（SecurityProvider 链）机制：认证与授权由一组 provider 按顺序处理，如 HTTP Basic、JWT、OIDC、DB 等 provider，形成认证链。请求先经过认证 provider 解析身份，再经授权 provider 校验权限，可组合多个 provider 实现混合认证。注解式保护通过 @Authenticated、@RolesAllowed、@PermitAll 等注解标注到资源/方法，由安全机制在请求时校验，未认证返回 401、无权限返回 403。OIDC/JWT 集成：Helidon Security 提供 OIDC provider（对接 Keycloak 等）与 JWT provider（解析并校验 JWT token），支持授权码流程、令牌验证、角色映射，实现基于 JWT 的无状态认证。整体上，Helidon Security 用 provider 链 + 注解 + OIDC/JWT 提供灵活、可扩展的安全框架，适配企业级认证授权需求。

Helidon Security 的核心是"provider 链 + 注解 + 标准协议"。provider 链让认证授权可组合，注解让保护声明式，OIDC/JWT 让认证标准化，三者结合形成完整的安全体系。