第2章 架构设计原则：高内聚低耦合、模块化与分层、可扩展性与可维护性、实时性与确定性
各位好，我是老张。今天咱们聊聊架构设计里那些绕不开的原则。说实话，这些原则听起来像教科书上的老生常谈，但我在工控行业摸爬滚打十几年，发现真正能把这些原则落地的人，还真不多。
你想想看，工业控制软件跟普通软件最大的区别是什么？是它要跟物理世界打交道。一个错误的指令，可能让整条产线停下来，甚至造成安全事故。所以，架构设计必须从一开始就打好基础。
2.1 高内聚低耦合：模块的“内功”与“外交”
高内聚低耦合，说白了就是一个模块内部要拧成一股绳，模块之间要尽量少打交道。我见过太多项目，代码写得像一团乱麻，改一个地方，十个地方跟着报错。
核心要点：
- 高内聚：一个模块只做一件事，并且把它做好。比如，数据采集模块就只管采集，别掺和报警逻辑。
- 低耦合：模块之间通过明确的接口通信，别直接访问对方的内部数据。
我在一个大型PLC项目中遇到过这样的问题：工程师把IO驱动、数据处理、界面显示全写在一个函数里。结果呢？换一个IO卡，整个程序都要重写。后来我强制要求拆分成独立模块，每个模块只暴露几个接口函数。嗯，改起来就轻松多了。
我的习惯：设计模块时，先问自己三个问题：这个模块的职责是什么？它依赖哪些外部模块？外部模块依赖它什么？如果答案超过三句话，说明内聚性不够。
2.2 模块化与分层设计：把复杂问题拆成小积木
模块化设计，就像搭积木。每一块积木功能明确，可以独立测试、替换、升级。分层设计则是给这些积木排个队，上层依赖下层，下层不依赖上层。
我建议采用经典的三层架构：
| 层次 | 职责 | 典型组件 |
|---|---|---|
| 应用层 | 业务逻辑、人机交互 | 配方管理、报警处理、画面显示 |
| 中间层 | 数据处理、协议转换 | 数据缓存、通信协议栈、算法库 |
| 驱动层 | 硬件抽象、IO操作 | IO驱动、定时器、中断管理 |
为什么要分层？举个例子。有一次客户要求把Modbus协议换成Profinet。如果协议处理代码散落在各个模块里，那简直是噩梦。但如果它被封装在中间层的通信模块里，我只需要替换这一个模块，上层应用完全不用动。
注意：分层不是越多越好。层数太多，性能损耗会变大，调试也麻烦。我个人习惯控制在3-4层，每层职责清晰，接口简洁。
2.3 可扩展性与可维护性：为未来留好“后门”
工控软件的生命周期通常很长，少则五年，多则十几年。你不可能预见所有未来的需求，但你可以让架构具备“生长”的能力。
可扩展性，说白了就是加新功能时，不用大改旧代码。可维护性，就是出问题时，能快速定位并修复。
我常用的几个技巧：
- 接口抽象：用回调函数或虚函数定义扩展点。比如，增加一个新的报警类型，只需要实现一个报警接口，然后注册进去。
- 配置驱动：把参数、策略放到配置文件中，而不是硬编码。我曾经见过一个项目，所有报警阈值都写在代码里，每次改参数都要重新编译、下载，太痛苦了。
- 日志与诊断：每个模块都要有独立的日志输出，并且支持分级（DEBUG、INFO、ERROR）。这样出问题时，能快速定位是哪个模块的锅。
// 一个简单的扩展点示例：报警处理器接口
typedef struct {
void (*init)(void);
void (*check)(float value);
void (*reset)(void);
} AlarmHandler;
// 注册新的报警类型
void register_alarm_handler(AlarmHandler *handler);避坑指南：我曾经为了追求“灵活”，设计了一个超级抽象的框架，结果新同事看了三个月都看不懂。后来我明白了：扩展性要适度，别为了未来可能不存在的需求，把现在搞复杂了。
2.4 实时性与确定性设计：时间就是生命
工控系统最核心的要求是什么？是“准时”。一个控制指令晚到1毫秒，可能产品就报废了。所以，实时性和确定性是工控架构的命脉。
实时性，指的是系统能在规定时间内完成任务。确定性，指的是每次执行的时间都差不多，不能这次1毫秒，下次10毫秒。
我总结了几条设计原则：
- 任务优先级管理：把关键任务（如急停、位置控制）设为最高优先级，非关键任务（如日志记录、界面刷新）设为低优先级。
- 避免动态内存分配：在实时任务中，malloc/free是禁忌。因为分配时间不确定，还可能产生碎片。我习惯在初始化时一次性分配好所有内存。
- 中断服务程序要短：中断里只做最必要的事（比如读取数据、设置标志），复杂的处理放到任务中去做。
- 使用看门狗：防止程序跑飞或死锁。但要注意，看门狗的超时时间要合理设置，别让正常任务被误复位。
一个真实案例：有一次，我们的运动控制卡在高速运行时偶尔出现抖动。查了三天，最后发现是一个低优先级的网络通信任务占用了太多CPU时间，导致控制任务被延迟。解决办法很简单：把控制任务的优先级提到最高，并且给它分配独立的定时器中断。
嗯，这里要注意：实时性不是越快越好，而是“可预测”。你想想看，一个任务每次执行时间都是5毫秒，比一个有时1毫秒、有时10毫秒的任务更可靠。
2.5 总结：原则是死的，人是活的
说了这么多，其实我想表达的是：这些原则不是教条，而是工具。在项目中，你可能会遇到各种矛盾——比如高内聚和性能的冲突，或者模块化和代码量的权衡。这时候，就需要你根据实际情况做取舍。
我个人习惯是：先按原则设计，再根据测试结果微调。别一开始就想着“最优解”，先让系统跑起来，再逐步优化。毕竟，一个完美的架构如果永远写不完，那还不如一个能用的烂架构。
好了，这一章就聊到这儿。下一章咱们讲讲具体的设计模式，看看怎么把这些原则落地到代码里。