资产管理系统架构怎么设计？分层与集成要点解析

去年我们接触一家做精密零部件的工厂，年产值过亿，设备有 200 多台，加上叉车、电脑、检测仪器，资产总数超过 600 项。这些东西分别躺在设备科的 Excel、IT 部门的 OA、财务的 ERP 模块里。年底一盘点，三张表对不上，账实差异超过 8%。根源不是员工不认真，而是系统架构混乱，没有统一的资产主数据，也没有清晰的集成边界。

资产管理系统架构设计的核心，是分层清晰、边界明确、集成有序。通常按职责拆成三层——接入层、业务层、数据层，再通过统一的接口网关与 ERP、MES、IoT 平台打通，撑起资产从采购、入账、运维到报废的全生命周期管理。

背景：单体系统为什么撑不住

很多公司早期把所有功能塞进一个系统：采购登记、折旧计算、维修工单、盘点流程全在一个大模块里跑。资产规模小的时候看挺省事，一旦规模过千、设备类型超过五种，问题就集中爆发。

我们在梳理一家物流企业的旧系统时看到，盘点功能改一个字段，整个应用要重启一遍；接入 IoT 数据时，因为耦合太紧，扫描工单模块也跟着卡顿。单体架构在功能迭代和数据扩展上都很吃力。更棘手的是集成——对方原本希望系统对接财务软件，但财务模块和业务模块共用一张数据库表，任意一边升级都可能让另一边报错。

分层思路：把职责拆到三层

成熟的资产管理系统一般采用三层结构，每层只管自己的事，跨层调用走标准接口。

接入层：采集入口统一

这一层负责把各种数据源接进来——条码扫描枪、RFID 读写器、IoT 传感器、ERP 主数据、移动端 APP。接入层不处理业务逻辑，只做协议转换和数据归一化。

比如同一家工厂既有老式的 RS485 传感器，也有新型的 MQTT 设备，接入层先把它们都转成统一的消息格式，再送给业务层处理。否则业务层要同时维护十几种协议适配器，后期维护成本会失控。

业务层：核心规则在这里

资产主数据管理、折旧规则、维修工单流转、备件库存逻辑、权限审批——所有跟业务流程相关的内容都集中在这一层。常见做法是采用微服务或模块化设计，按业务域（财务域、运维域、库存域）拆分。

以折旧计算为例，把平均年限法、双倍余额递减法、工作量法封装成独立服务，不同子公司、不同国家的资产调同一套接口就行，不用重复开发。

数据层：主数据与时序数据分治

数据层要回答两个问题：现在有哪些资产、历史轨迹是什么。前者用关系型数据库存主数据，后者用专门的时序数据库（InfluxDB、TDengine 这类）记录传感器采集的运行参数。

上海择捷在搭这类方案时，常用的做法是：把车载温湿度这类运行参数单独放在时序库，主数据放在 MySQL。两边通过资产编号关联，查询时按时间窗口聚合，互不拖累，也为后续做预测性维护留出空间。

集成要点：哪些边界必须守住

架构好不好，最后都要在集成环节接受检验。三个集成点最关键。

与 ERP 的主数据同步

资产卡片要在资产管理系统和 ERP 之间保持一致。建议采用单向同步为主、变更通知为辅：资产新增、状态变更、调拨、报废由资产系统推送，ERP 端只接收并更新。这样可以避免双向同步造成的主数据漂移——两边互相覆盖、谁也说不清哪条记录是真。同步频率上，主数据按事件触发即可，不必走定时轮询。

与 IoT 平台的数据回流

IoT 平台负责设备联网和实时数据采集，资产系统负责把采集到的数据匹配到具体资产，并触发后续业务规则（例如设备连续高温就自动生成巡检工单）。集成方式推荐使用消息队列（Kafka、RabbitMQ），异步处理能避免尖峰时刻系统互相阻塞。

与 OA、HR 的弱耦合对接

审批流程、人员组织架构通常在 OA 或 HR 系统里维护。资产系统只需要调用它们的接口获取组织树和人员信息即可，不要把审批逻辑写在自己的数据库里——改一个流程不至于动整库。

实施中容易踩的几个坑

再好的架构，执行不到位也会变形。以下三个坑出现频率最高。

坑一：分层分成了"两层皮"。表面上分了层，实际上数据层和业务层表结构还是耦合在一起，迁移数据库等同于重写业务。应对办法是严格约束跨层调用——业务层只能通过数据层提供的 DAO 接口访问数据，绕过这一层就视作违规代码提交。

坑二：集成接口太多变成接口沼泽。每个业务系统都自建对接点，几十个接口没人能理清。建议引入统一的 API 网关，所有对外接口注册在网关层面，谁调用、谁负责、调用频次多少都有日志可查。

坑三：时序数据当主数据存。把设备每秒一次的运行数据塞进关系库，半年后单表上亿行，查询卡死。时序数据必须单独存放，并配套数据降采样策略。

落地建议：从哪一步开始

如果资产规模在 500 项以下、类型不超过三种，先用一套成熟的资产管理系统标准产品跑通流程，不必一上来就自研分层架构。

资产规模过千、类型超过五种、且需要与至少两个外部系统集成时，建议按分层思路重新设计。优先把主数据规范化、接入层归一化做扎实，业务层再按域逐步拆分。

无论哪种规模，有一件事必须一开始就定下来：主数据由谁定义、变更走什么流程。架构只是容器，容器里装的东西有规则，整个系统才能长期稳定地跑下去。