# division

**Repository Path**: pengminghua/division

## Basic Information

- **Project Name**: division
- **Description**: Division 是新一代业务流计算框架，微秒级低延迟、单体服务500万Task并行调度能力、每秒3万Task吞吐量、具备高复杂度业务流设计的分布式计算平台。依靠自主技术无外部服务依赖，并实现支持横向扩展、环形高可用备份、Turbo超频模式、Job优先级、服务隔离、serviceMesh、版本控制、Trace日志追踪，将现有业务系统结合及实时响应能力提升至全新高度。
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: https://gitee.com/pengminghua/division/blob/master/README.md
- **GVP Project**: No

## Statistics

- **Stars**: 4
- **Forks**: 0
- **Created**: 2025-11-05
- **Last Updated**: 2026-04-13

## Categories & Tags

**Categories**: Uncategorized

**Tags**: 分布式计算, 任务调度, 流式计算, Java, 大数据

## README

# Openhandx-Division：业务流的极致低延迟计算框架介绍

作者： 彭明华  联系方式：pengminghua1976@foxmail.com

最后更新： 2025-11-30


Division 是新一代业务流计算框架，微秒级低延迟、单体服务500万Task并行调度能力、每秒3万Task吞吐量、具备高复杂度业务流设计的分布式计算平台。依靠自主技术无外部服务依赖，并实现支持横向扩展、环形高可用备份、Turbo超频模式、Job优先级、服务隔离、serviceMesh、版本控制、Trace日志追踪，将现有业务系统结合及实时响应能力提升至全新高度。

## 一、 摘要：重新定义业务流处理

当前实时计算领域的主流框架（如 Flink、Spark Streaming）主要面向**数据流水线**场景优化，但在处理**业务流**时面临诸多挑战。业务流（如金融风控、实时定价、复杂工作流）具有**路径动态可变、资源需求难以预测**等特征，具体体现在：

* **处理路径动态可变**：传统固定 DAG 设计为覆盖多种业务场景，往往引入冗余节点。而业务流的执行路径应能根据实时参数动态构建，以提升处理效率。
* **计算资源需求难以预测**：业务流中常包含大量 I/O 等待（如数据库访问、服务调用），传统固定 Slot 资源模型难以灵活应对，导致资源闲置。
* **高可用与扩展性瓶颈**：传统Job调度中心主备模式存在资源浪费与单点性能瓶颈，多主架构才是实现真正水平扩展的关键路径。
* **业务隔离和优先级保障**：多业务线共存时，需支持资源隔离与优先级调度，确保关键业务流优先执行并独占资源。
* **有限资源下的高要求**：许多企业硬件预算有限，需在 8C16G 等低配环境中部署完整的高可用流处理系统。

  Openhandx-Division 正是为应对上述挑战而生。它是一个面向**低延迟、高复杂度业务流**的分布式计算框架，通过通讯、调度、序列化等核心组件的垂直优化，在通用硬件上实现了**微秒级延迟**与**极致的资源利用率**，显著提升了业务实时响应能力。
Division 不仅适用于千级节点的 SaaS 环境，更针对中小企业极小化部署场景优化，助力在国产信创硬件上实现媲美国外高端服务器的处理性能，为构建安全可控的技术生态贡献力量。

## 二、 设计哲学与架构洞察

### 1. 核心挑战：从数据流到业务流的范式转变

*   **路径不确定性**：同一业务（如转账），因金额、用户等参数不同，其处理逻辑与计算量差异巨大，导致固定的 DAG 无法满足需求。
*   **资源不可预测性**：传统固定 Slot 的资源分配模型无法有效应对业务流的波峰波谷，造成资源闲置或拥堵。
*   **架构约束驱动创新**：
    *   **性能极致化**：为达成微秒级目标，必须摒弃通用序列化、重型中间件，转向自主研制的通讯与序列化协议。
    *   **环境适应性**：为服务更广泛的客户（最低支持openJdk 8 环境）、应对国产化硬件趋势，框架必须做到轻量、无外部依赖，并具备在有限算力下超越同类产品的性能。

### 2. 第一性原理设计

Division 回归第一性原理，拒绝在臃肿的开源堆栈上修修补补。一切从业务流的本质出发，重新设计了**服务发现、通讯、序列化、负载均衡、高可用、时钟同步**等核心组件，构建了一个高度协同、无缝集成的**一体化计算平台**。这种垂直整合是达成性能与效率目标的根本。

### 3. 国产技术自立与架构创新

Division 的诞生，源于一个核心信念：在基础软件领域，真正的自主可控意味着从“可用”到“好用”，并最终实现“技术引领”。这要求并非简单替代，而是必须向内求打破桎梏、突破极限、进行超越。
在当前国际环境下，直面两大现实约束：
  
*   **算力约束**：国产硬件在绝对性能上仍处于追赶阶段。
*   **生态约束**：必须摆脱对特定国外基础软件的技术依赖。

Division 能够在通用及国产硬件上，实现比肩甚至超越国外主流框架在高端硬件上的性能表现。这不仅是技术的胜利，更是一种以架构创新弥补算力差距，以软件定义实现产业自主的实践典范。

## 三、 核心架构与技术创新

Division 采用分层、模块化设计，其核心架构如下图所示，清晰地分离了控制面与数据面。

![Division 总体架构图](media/framework.png)

### 1. 低延迟设计体系

为将延迟推入微秒级，构建了三位一体的优化体系：

*   **通讯层**：基于 TCP 长连接，实现**零握手开销**的直接数据推送。
*   **数据层**：独创专有序列化协议。通过**精确字节布局**与**对象复用**，序列化体积仅为 JSON 的 1/3，耗时是 Jackson 的 1/6，并大幅减少 GC 压力。
*   **调度层**：**两级分区策略**。将 Task 按 Job 和子分区两级路由，彻底避免全局锁竞争，即使单 Job 承载千万级 Task，性能亦无衰减。

### 2. 高可用与可扩展性设计体系

*   **环形多主架构**：摒弃资源利用率低下的主从模式。所有控制中心实例均为主节点，通过**环形强一致性备份**实现高可用。此设计在保证数据一致性的前提下，实现了近乎线性的水平扩展能力。
*   **精准的服务粒度**：关键组件（控制中心、计算单元、控制台）均可独立动态扩缩容，架构天生为云环境设计。

### 3. 资源效率设计体系

*   **Turbo 超频模式**：针对业务流多 I/O 等待的特性，计算单元能突破固定线程数限制，在 CPU/内存低负载时动态超发Task，将资源利用率最大化。
*   **可量化的容量模型**：
    *   控制中心：**8CPU/8G 配置支持500万个Task并行（Task业务参数不大情况下）**。
    *   注册中心：**2vCPU/128MB 配置即可支持 10 个服务注册**，极致轻量。
    *   控制台：**2vCPU/512MB 配置即可支持 10 个服务监控**。

## 四、 组件精析与设计决策

Division的架构由五个松耦合的组件构成，每个组件都体现了特定的设计决策，以共同支撑框架的总体目标。

### 1. SDK客户端：将业务逻辑宣言式地转化为计算流

*   **设计决策**：将业务流的有向无环图定义完全交由业务端。这牺牲了框架的“黑盒”便利性，换取了极致的**灵活性**，使业务流的每个决策点都能根据实时计算结果动态改变路径。
*   **核心价值**：
    *   **链式API**：提供流畅、易读的DSL，降低开发复杂度。
    *   **全链路可观测性**：原生集成Trace Id，实现从业务端到计算单元的无缝链路追踪，并在计算单元侧Log4j日志中输出，方便问题定位。
    *   **精细化调度**：支持Task优先级、计算单元亲和性，为资源隔离与Service Mesh和版本控制奠定基础。

![SDK客户端架构](media/sdk.png)

### 2. 控制中心：集群的大脑与中枢神经系统

*   **设计决策**：采用**状态化**的调度器设计。与将状态外置（如存入Redis）不同，将调度状态维护在内存中，这是实现**微秒级调度**的根本。为此，设计了高可用的**环形多主**架构来保证状态一致性。
* 
 ![控制中心架构](media/center.png)  

* **核心创新**：
*   **两级分区策略**：将全局Task队列打散，实现细粒度锁调度，性能随Task量线性扩展。

      ![控制中心Task管理策略](media/task.png)

*   **强一致性备份**：在最终一致性与强一致性之间，因为业务场景对数据一致性的要求较高，且Division的调度性能非常高，最终一致性备份的进度严重落后，所以选择了后者，确保关键业务数据不丢失。

*   **环形多主高可用**：此设计不仅解决了主从模式下的单点性能瓶颈问题，实现了近乎线性的水平扩展能力，也不存在脑裂情况。只要没有两台相邻的主节点同时故障，就不会导致数据不一致，比一般的双机备份可靠性更高。此外备份策略采用自研算法减少网络传输，最大程度提高备份效率。

      ![控制中心高可用模式](media/backup.png)

*   **分组隔离**：此设计解决企业级多个系统流式计算统一管理的问题。针对控制中心进行分组，每个分组内的计算单元独占使用，而不会相互干扰。此外计算单元可以配置多个分组，实现资源最大化利用。

       ![控制中心分组隔离](media/group.png)

### 3. 计算单元：弹性且智能的计算力容器

*   **设计决策**：打破传统线程池模型。固定线程池适用于计算密集型Task，但业务流多为I/O密集型，导致CPU资源闲置。**Turbo超频模式**本质是一种**自适应弹性并发**机制，在系统资源允许时智能提升并发度。

![计算单元架构](media/unit.png)
*   **企业级特性**：
    *   **优先级控制**：优先拉取优先级高的Task，保证紧急重要的Task优先执行。
    
![计算单元优先级控制](media/level.png)

    *   **资源隔离**：两级隔离策略，通过分组设置和任务类型将计算单元池化，为不同业务系统提供独占资源。

![计算单元资源隔离](media/affinity.png)

    *   **Service Mesh和版本控制**：将Task版本与计算单元绑定，实现流量的精准灰度与滚动升级。

![计算单元版本控制](media/version.png)

    *   **资源精细化管理**：不同的业务代码可分配到不同的硬件资源计算，实现资源的精细化管理。

![计算单元资源精细化管理](media/resource.png)

    *   **Turbo超频模式**：在线程满载的情况下感知CPU和内存的使用率，允许在设定最大并发度的前提下，动态超发Task，进一步提高资源利用率。

  ![计算单元Turbo模式](media/turbo.png)

### 4. 注册中心：轻量级的基础设施与服务

*   **设计决策**：贯彻“无外部依赖”原则。将注册中心为内嵌分布式缓存的轻量级服务，其高可用模式可独立运行，除了注册中心的基本能力，更重要的是其环形备份调度能力，确保控制中心的高可用。
 
    ![注册中心架构](media/registry.png)

*   **核心能力**：
    *   **服务治理**：提供服务发现、健康检查与故障转移。
    
        ![注册中心服务发现与故障转移](media/registryBackup.png)
     
    *   **提供统一时钟服务**：为Job和Task的执行和调度提供统一的时钟对齐，避免服务器时钟不一致，简化运维。

### 5. 控制台：轻量级的调优与运维平台

*   **设计决策**：贯彻"无外部依赖"原则。将控制台也设计为内嵌分布式缓存的轻量级服务，其高可用模式可独立运行，极大降低了部署与运维成本。

    ![控制台架构](media/console.png)

*   **核心能力**：
    *   **全栈可观测性**：控制台提供从注册中心、控制中心、计算单元、控制台自身所有服务全方位监控，使系统成为一个**透明盒子**。
    
        ![控制台统一入口](media/main.png)
        ![控制台控制中心列表](media/centerList.png)
    
    *   **配置文件编辑**：控制台提供运行时态参数修改，无需重启服务立即生效，减少重启对整个系统的冲击。
    
        ![控制台修改配置参数](media/configEdit.png)
    
    *   **运行状态监控**：控制台分别从控制中心、计算单元角度对Job和Task执行全方位监控，以图表的方式展现吞吐量、成功率。
    
        ![控制台运行监控图](media/run.png)
    
    *   **系统状态监控**：控制台对每个服务提供系统监控，包括CPU、内存、网络全方位监控，显示系统资源压力为运维扩容提供依据。
    
        ![控制台系统监控图](media/system.png)
    
    *   **Job完成日志**：控制台对每个完成Job进行记录，包括Job级Node执行时间、执行状态，为研发人员提供优化依据。
    
        ![控制台Job完成日志](media/job.png)
    
    *   **服务状态接口**：控制台提供Http-Json API接口查询控制中心、注册中心、控制台每个服务的运行和系统压力，方便外部服务读取实现动态扩容。
  
    
## 五、 性能基准与量化验证

### 1. 核心路径延迟测试

*   **目标**：验证框架核心调度与通讯的极限延迟。
*   **场景**：串行发起1000次单Task Job。
*   **结果**：

| 项目        | 单机模式      | 双机模式（开启高可用） |
|:----------|:----------|:------------|
| **最低延迟**  | **252μs** | 706μs       |
| **P50延迟** | **419μs** | 978μs       |
| **P80延迟** | **531μs** | 1112μs   |
| **P95延迟** | **714μs** | 1,385μs   |

*   **结论**：Division在单机模式下实现了**稳定亚毫秒级**响应。开启强一致性高可用会带来一定开销，但其**P95延迟仍优于1.5ms**，完全满足苛刻的业务实时性要求。

### 2. 吞吐量测试

*   **目标**：验证控制中心的Task调度与协调能力。
*   **场景**：并发发起1万Job-10万Task，测量完成时间。每个Job 6个节点,深度4层，运行时分解出10个Task

    ![Job有向无环图](media/test.png)

*   **结果**：

| 项目         | 单机模式              | 双机模式（开启高可用）       |双机模式（关闭高可用）       |
|:-----------|:------------------|:------------------|:------------------|
| **并行异步发起** | **3,029ms**       | **4,036ms**       |**2,018ms**       |
| **吞吐量**    | **33,014 Task/秒** | **24,777 Task/秒** |**49,554 Task/秒** |

*   **结论**：控制中心无单点瓶颈，调度能力随实例增加近乎线性增长。**单实例每秒调度3.3万Task**的表现为高并发业务流提供了坚实保障。


### 3. 极限测试

*   **目标**：验证控制中心集群在大规模、高并发场景下的Task调度极限与水平扩展能力。
*   **场景**：模拟从100,000到800,000个并发Job（对应1百万至8百万个Task），在不同集群配置下的总完成时间。
*   **结果**：

| 项目                           | 单机模式               | 双机双中心模式（关闭高可用）      | 双机双中心模式（开启高可用）     | 双机4中心模式（开启高可用） |
|:-----------------------------|:-------------------|:--------------------|:-------------------|:---------------|
| **100,000Job/1,000,000Task** | **33,325ms**       | **16,130ms**        | **39,363ms**       | **27,244ms**       |
| **800,000Job/8,000,000Task** | **328,522ms**       | **142,970ms**        | **354,182ms**       | **223,758ms**       |


*   **结论**：

  **卓越的水平扩展能力**

在关闭高可用时，双机模式相比单机模式，完成时间缩短了50%-80%，证明了控制中心近乎线性的横向扩展能力。
引入四个控制中心的集群后，即使开启高可用，其处理速度也显著快于单机模式，并远优于双机高可用模式，证明了多主环形架构在承载极端负载时的有效性

  **高可用模式的性能权衡**

开启强一致性高可用（HA开）会引入数据同步开销，导致延迟增加。这体现了架构上在极致性能与数据可靠性之间的透明权衡。尽管如此，在四控制中心的集群下，即便开启高可用，依然能处理每秒数百万Task的吞吐量，满足了绝大多数关键业务场景对高可用与高性能的双重需求

  **强大的单机处理能力**

即使是在单机模式下，也能独立完成800万Task的调度与协调，证明了其核心调度器的高效与稳定性，为资源受限的场景提供了强大保障


### 4. 资源密集型任务测试

*   **目标**：验证计算单元在重负载下的大量数据处理能力。
*   **场景**：单个Job动态拆分为2002个Task，共处理100G CSV文件。

    ![处理CSV文件的Job有向无环图](media/csv.png)

*   **结果**：

| 项目         | 单机模式              | 双机模式（开启高可用）       |
|:-----------|:------------------|:------------------|
| **并行异步发起** | **445,567ms**     | **158,328ms**     |

*   **结论**：双机模式下，复杂的数据汇总Task在**158秒**完成，充分证明了框架处理计算与I/O混合型负载的高效性。


## 六、 典型应用场景

Division的架构特性使其在以下场景中具有显著优势：

*   **实时智能决策**（如风控、推荐）：利用**低延迟**与**动态DAG**，在用户交互瞬间完成基于多维度实时数据的、流程可变的复杂决策。
*   **复杂事件处理**：凭借**高并行调度**与**Turbo模式**，高效关联与分析来自不同数据源的流式事件，实时发现复杂模式。
*   **高性能计算资源调度**：可作为**算力网格**的核心调度引擎，为机器学习、科学计算等任务提供低延迟、高吞吐的资源分配与任务协调。
*   **实时数据ETL与增强**：为数据仓库或数据湖提供一条极速的**流式数据预处理**管道，在数据入库前完成清洗、打宽、聚合等操作。

## 七、 总结

Openhandx-Division 代表了一种架构范式的转变。它证明，通过针对特定领域（复杂业务流）进行深度垂直优化与自主创新，完全可以在通用硬件上实现数量级级别的性能提升与效率优化。

Division 的轻量级、无外部依赖、自动化运维的特性，极大地降低了企业获得顶尖实时业务计算能力的门槛。我们的目标，是让一台普通的国产服务器，就能承载起过去需要一个小型数据中心才能支撑的实时业务流。这不仅是技术的普惠，更是 Division 作为国产软件主力，在推动各行各业实现高质量数字化进程中的核心价值与产业责任。

## 八、相关文档
* [Division 研发手册](development.md)
* [Division 压力测试](stressTest.md)
* [Division 运维调优](devOps.md)