第1章：模型结构——RTLA模型的层次化设计

各位好，我是老张。做并发系统十几年了，踩过的坑比写过的代码还多。今天咱们聊聊RTLA模型的层次化设计。说白了，就是怎么把一堆乱糟糟的并发逻辑，拆成能看懂、能维护、能验证的模块。

我记得刚入行那会儿，接手过一个电信计费系统。代码写得那叫一个随心所欲——所有进程混在一起，信号满天飞。改一个bug能引出三个新bug。后来我花了整整两周，才把系统重构出个模样。从那以后，我养成了一个习惯：先画结构，再写代码。

1.1 模块：系统的骨架

模块是最高层级的抽象。你可以把它理解成一个黑盒子——有明确的输入输出，内部实现对外部不可见。我习惯把模块对应到业务边界上。比如一个订单系统，可以拆成：订单模块、支付模块、库存模块、通知模块。

每个模块内部，可以再嵌套子模块。但我不建议超过三层。为什么？因为人脑能同时处理的信息有限。三层以上，你自己都理不清了。

// RTLA模块定义示例
module OrderSystem {
    // 端口声明
    input  port order_req   : OrderRequest;
    output port order_resp  : OrderResponse;
    input  port pay_notify  : PaymentEvent;
    
    // 子模块实例化
    module OrderProcessor  proc_inst;
    module PaymentHandler  pay_inst;
    module InventoryManager inv_inst;
    
    // 内部连接
    connect proc_inst.pay_req -> pay_inst.pay_req;
    connect pay_inst.pay_done -> proc_inst.pay_done;
    connect proc_inst.inv_req -> inv_inst.inv_req;
}

注意看，模块的接口只有端口（port）。内部怎么实现，外部不关心。这就是封装。我在项目中遇到过有人把模块内部的信号直接拉到顶层，结果改一个模块，整个系统都要重新验证。嗯，血的教训。

1.2 进程：并发的原子单位

进程是RTLA里真正干活的东西。一个进程就是一个独立的执行流，有自己的状态、逻辑、时序。进程之间通过通道通信，不共享内存。这是RTLA和传统多线程编程最大的区别。

我建议你把进程想象成一个独立的人——他有自己的记忆（状态），有自己的工作流程（逻辑），只通过信件（消息）和别人交流。这样设计，并发问题就变成了通信问题，好分析得多。

// 进程定义示例
process OrderProcessor {
    // 进程状态
    state {
        OrderId current_order;
        int     retry_count;
        bool    is_processing;
    }
    
    // 进程逻辑
    behavior {
        // 等待订单请求
        wait(order_req);
        
        // 处理逻辑
        if (validate(order_req.data)) {
            send(inv_req, order_req.data);
            wait(inv_resp);
            send(pay_req, order_req.data);
        } else {
            send(order_resp, error_code);
        }
    }
}

这里有个关键点：进程不能直接访问其他进程的状态。我曾经在一个项目中，为了图方便，让两个进程共享了一个计数器。结果呢？死锁、竞态、数据不一致，全来了。最后花了三天才定位到问题。从那以后，我再也不敢打破这个规则了。

1.3 通道：通信的管道

通道是连接进程的桥梁。RTLA里的通道有三种类型：

类型	特点	适用场景
同步通道	发送方等待接收方确认	请求-响应模式
异步通道	发送方不等待，消息入队	事件通知、日志
广播通道	一对多，所有接收方都收到	状态同步、配置更新

你想想看，为什么要有这么多类型？因为不同的通信模式，对时序的要求不一样。同步通道保证强一致性，但会阻塞发送方。异步通道吞吐量高，但消息可能延迟。广播通道效率高，但接收方必须能处理重复消息。

我个人的习惯是：默认用异步通道。为什么？因为同步通道容易引发级联阻塞。一个进程卡住了，所有依赖它的进程都得等着。异步通道至少能保证系统不会整体瘫痪。当然，如果业务要求强一致性，那就得用同步通道。比如支付扣款，你总不能异步吧？

// 通道定义示例
channel OrderChannel {
    type: async;
    capacity: 100;
    policy: fifo;
    
    // 消息格式
    message OrderMessage {
        OrderId id;
        OrderType type;
        timestamp ts;
    }
}

1.4 接口定义与连接规范

接口是模块之间、进程之间的契约。RTLA的接口定义遵循几个原则：

• 显式声明：所有接口必须在模块/进程头部声明，不能隐式创建
• 类型安全：连接的两个端口类型必须匹配，编译器会检查
• 方向明确：每个端口标明是输入还是输出，不能双向
• 单一职责：一个端口只传递一种类型的数据

连接规范就更简单了——只能连接相同层级的元素。模块端口连模块端口，进程端口连进程端口。不能跨层连接。为什么？因为跨层连接会破坏层次结构，让系统变成一团乱麻。

我曾经接手过一个遗留系统，里面有个全局信号总线，所有模块都能往上面发信号。你猜怎么着？调试的时候，一个信号发出去，根本不知道是谁收的，也不知道会不会引起连锁反应。最后我们花了三个月，才把这个"总线地狱"拆成规范的层次结构。

1.5 一个完整的例子

说了这么多，咱们看个完整的例子。这是一个简单的日志收集系统：

// 顶层模块
module LogCollector {
    input  port log_in   : LogEntry;
    output port alert_out : AlertMessage;
    
    // 子模块
    module LogParser     parser;
    module LogAnalyzer   analyzer;
    module AlertNotifier notifier;
    
    // 内部通道
    channel parsed_log_ch : async, capacity=500;
    channel alert_ch      : sync;
    
    // 连接
    connect log_in -> parser.log_in;
    connect parser.parsed_out -> parsed_log_ch;
    connect parsed_log_ch -> analyzer.log_in;
    connect analyzer.alert_out -> alert_ch;
    connect alert_ch -> notifier.alert_in;
    connect notifier.alert_out -> alert_out;
}

// 解析进程
process LogParser {
    input  port log_in     : LogEntry;
    output port parsed_out : ParsedLog;
    
    behavior {
        wait(log_in);
        ParsedLog parsed = parse(log_in.data);
        send(parsed_out, parsed);
    }
}

// 分析进程
process LogAnalyzer {
    input  port log_in     : ParsedLog;
    output port alert_out  : AlertMessage;
    
    behavior {
        wait(log_in);
        if (is_anomaly(log_in.data)) {
            AlertMessage alert = generate_alert(log_in.data);
            send(alert_out, alert);
        }
    }
}

你看，这个结构清晰吧？每个模块只做一件事，每个进程只处理一种数据流。出了问题，顺着通道一查就知道是哪一步卡住了。

好了，这一章就到这里。记住一句话：好的结构是设计出来的，不是重构出来的。花时间把层次结构设计好，后面能省十倍的时间。

---