簡介智能電表遠(yuǎn)程抄表繳費(fèi)管理平臺JAVA源碼是一套基于JAVA技術(shù)構(gòu)建的物聯(lián)網(wǎng)應(yīng)用主要面向物業(yè)管理方、房東及物聯(lián)網(wǎng)開發(fā)工程師。平臺兼容正泰、人民、天正、許繼等主流品牌電表通過GPRS、LoRa、NB-IoT等通信方式實(shí)時采集讀數(shù)有效減少人工抄表負(fù)擔(dān)同時提供線上繳費(fèi)、用戶權(quán)限管理、異常報警和能耗報表生成等完整功能適用于寫字樓、園區(qū)等集中用電場景。資源包為rar壓縮格式共86個文件含77個java源文件、8個xml配置文件和1個iml工程模塊文件整體僅67KB。java文件承載業(yè)務(wù)邏輯與通信解析xml用于配置框架與接口目錄結(jié)構(gòu)簡潔便于快速定位核心代碼。該源碼的價值在于完整呈現(xiàn)了從設(shè)備接入、數(shù)據(jù)任務(wù)調(diào)度到支付接口聯(lián)動、報表輸出的物聯(lián)網(wǎng)閉環(huán)。尤其wwby-worker-ammeter模塊清晰展示了定時采集與任務(wù)處理的實(shí)現(xiàn)思路。已有2181人學(xué)習(xí)下載適合希望掌握遠(yuǎn)程抄表系統(tǒng)設(shè)計、或需要二次開發(fā)為生產(chǎn)級能耗管理平臺的技術(shù)人員。1. 它解決的痛點(diǎn)不止抄表從遠(yuǎn)程抄表到繳費(fèi)對賬的一站式Java工程最近拆了一套智能電表遠(yuǎn)程抄表繳費(fèi)管理平臺的Java源碼工程第一感受是它做的不是“遠(yuǎn)程抄表”這一個動作而是把抄表、計費(fèi)、繳費(fèi)、對賬、能耗報表這些原本散落在Excel里的活全部收攏成了代碼閉環(huán)。管理員在后臺點(diǎn)一下“抄表”系統(tǒng)自動向電表下發(fā)指令拿回讀數(shù)生成賬單用戶繳費(fèi)后回調(diào)自動核銷整個過程不需要人碰電表。對開發(fā)者的意義在于這套源碼把通信協(xié)議、定時調(diào)度、賬單狀態(tài)機(jī)、支付回調(diào)這些可復(fù)現(xiàn)的技術(shù)點(diǎn)完整地串了起來既適合做能源信息化項目落地也適合拿來當(dāng)練手工程二次改造。下文我按“架構(gòu)怎么拆、代碼怎么讀、本地怎么跑、坑在哪、怎么改”的順序拆開來寫。2. 技術(shù)選型與整體架構(gòu)從Netty通信網(wǎng)關(guān)到MySQL賬單落庫2.1 三層模塊劃分網(wǎng)關(guān)負(fù)責(zé)通信核心負(fù)責(zé)業(yè)務(wù)任務(wù)負(fù)責(zé)調(diào)度這套工程的Maven結(jié)構(gòu)是典型的多模塊單體我拆包后看到的模塊劃分大致如下meter-platform ├── meter-common // 通用工具、統(tǒng)一返回體、常量、異常 ├── meter-gateway // Netty服務(wù)、DL/T645協(xié)議編解碼、設(shè)備連接管理 ├── meter-core // 設(shè)備檔案、抄表、賬單、繳費(fèi)業(yè)務(wù)邏輯 ├── meter-job // 定時任務(wù)與分布式鎖 ├── meter-admin // 管理后臺HTTP接口對接Vue前端 └── sql // 建表腳本與初始數(shù)據(jù)把網(wǎng)關(guān)層獨(dú)立成模塊是我比較認(rèn)可的設(shè)計。抄表平臺最容易變的部分是“設(shè)備怎么連、報文怎么解析”而賬單和繳費(fèi)相對穩(wěn)定所以通信協(xié)議的變化被隔離在 meter-gateway 里不影響 meter-core 的業(yè)務(wù)代碼。數(shù)據(jù)流向大致是電表或集中器主動連接Netty服務(wù)端口建立TCP長連接并維持心跳定時任務(wù)或手動指令觸發(fā)抄表動作網(wǎng)關(guān)按設(shè)備檔案拼裝協(xié)議報文解析完的上行數(shù)據(jù)經(jīng)倍率換算后寫入抄表讀數(shù)表業(yè)務(wù)層按賬期聚合用電量套用電價方案生成賬單用戶繳費(fèi)后支付網(wǎng)關(guān)的回調(diào)通知更新繳費(fèi)流水和賬單狀態(tài)整條鏈路到這一步就形成了閉環(huán)。2.2 技術(shù)棧選型為什么用Netty而不是HTTP輪詢層技術(shù)選型理由后端框架Spring Boot 2.x生態(tài)成熟Java開發(fā)效率高設(shè)備接入Netty 4.x處理電表長連接和高頻報文比BIO可靠業(yè)務(wù)數(shù)據(jù)庫MySQL 8.x存儲設(shè)備檔案、讀數(shù)、賬單、流水緩存Redis分布式鎖防重復(fù)采集緩存設(shè)備地址ORMMyBatis-Plus單表CRUD代碼量小前端Vue Element UI管理后臺類項目標(biāo)配組件豐富定時任務(wù)Spring Scheduled 自研Redis鎖輕量不需要額外引入任務(wù)中心有人會問電表抄表為什么不用后端定時發(fā)HTTP請求去讀常見做法是智能電表或集中器主動連采集主站因為電表大多部署在配電房、表箱這類內(nèi)網(wǎng)環(huán)境主站主動訪問會被網(wǎng)絡(luò)策略擋住設(shè)備主動建連反而最簡單。Netty在這種場景下有天然優(yōu)勢大量電表長連接復(fù)用少量線程報文邊界靠ByteBuf處理協(xié)議解析用Handler鏈實(shí)現(xiàn)后續(xù)要支持新協(xié)議只需要新增一種decoder。2.3 數(shù)據(jù)庫設(shè)計五張核心表撐起業(yè)務(wù)閉環(huán)整個業(yè)務(wù)閉環(huán)依賴的核心表有 meter_info、meter_reading、bill_info、payment_record、read_task。先看設(shè)備檔案表這個表是網(wǎng)關(guān)層和業(yè)務(wù)層共同的基礎(chǔ)CREATE TABLE meter_info ( id bigint(20) NOT NULL AUTO_INCREMENT, meter_no varchar(12) NOT NULL COMMENT 12位表地址BCD序低位在前, meter_status tinyint(4) NOT NULL DEFAULT 1 COMMENT 1在線 0離線 2故障, location varchar(64) DEFAULT NULL COMMENT 安裝位置, multiplier decimal(10,2) NOT NULL DEFAULT 1.00 COMMENT 互感器倍率, protocol varchar(16) NOT NULL DEFAULT DLT645 COMMENT 通信協(xié)議類型, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_meter_no (meter_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT電表檔案表;表地址字段和倍率字段在抄表、計費(fèi)兩處都會用到所以做了唯一索引避免同一塊表重復(fù)建檔。meter_reading 表保存每次采集到的原始讀數(shù)唯一索引建在 (meter_no, data_id, read_time) 上data_id 是數(shù)據(jù)標(biāo)識用來區(qū)分總電量、峰電量、谷電量等不同數(shù)據(jù)項。bill_info 表里有一個 status 字段標(biāo)識賬單狀態(tài)0待支付、1已支付、2已沖正這個狀態(tài)字段是整個繳費(fèi)流程的流轉(zhuǎn)依據(jù)。明白這些表的關(guān)系之后再去看代碼基本就能在半小時內(nèi)把項目主路徑摸清定時任務(wù)驅(qū)動網(wǎng)關(guān)讀表讀到的數(shù)據(jù)進(jìn) meter_reading業(yè)務(wù)層按賬期聚合生成 bill_info繳費(fèi)成功后 payment_record 記錄流水并反向更新 bill_info。核心開發(fā)時只要不打破這條閉環(huán)在這幾章表上做擴(kuò)展都比較安全。3. 核心模塊拆解一次抄表從指令下發(fā)到生成賬單的完整鏈路3.1 網(wǎng)關(guān)層DL/T645報文構(gòu)建與響應(yīng)解析遠(yuǎn)程抄表的第一道坎是協(xié)議。國內(nèi)智能電表大部分走DL/T645-2007規(guī)約報文特征是以多個FE作為前導(dǎo)符接著68開頭、16結(jié)尾。讀表指令長這樣FE FE FE FE 68 12字節(jié)表地址 68 控制碼 數(shù)據(jù)域長度 數(shù)據(jù)域 校驗和 16。其中表地址是BCD碼且低位在前控制碼0x01表示讀數(shù)據(jù)數(shù)據(jù)域里放的是數(shù)據(jù)標(biāo)識。public class Dlt645Codec { private static final byte START 0x68; private static final byte END 0x16; /** 組裝讀表指令dataId 示例00010000 表示讀當(dāng)前組合有功總電能 */ public static byte[] buildReadRequest(String meterNo, String dataId) { byte[] addr reverseBcd(meterNo); byte[] data hexToByte(dataId); // 這里按DL/T645規(guī)則做加擾數(shù)據(jù)標(biāo)識每個字節(jié)加0x33 for (int i 0; i data.length; i) { data[i] (byte) ((data[i] 0x33) 0xFF); } ByteBuffer buf ByteBuffer.allocate(1 12 1 1 1 data.length 1 1); buf.put(START); buf.put(addr); // 12字節(jié)地址域 buf.put(START); buf.put((byte) 0x01); // 控制碼讀數(shù)據(jù) buf.put((byte) data.length); buf.put(data); buf.put((byte) 0); // 校驗和占位 buf.put(END); byte[] frame buf.array(); frame[frame.length - 2] checksum(frame, 1, frame.length - 3); return frame; } /** 從起始符后一個字節(jié)開始累加到數(shù)據(jù)域結(jié)束為止 */ private static byte checksum(byte[] data, int from, int to) { int sum 0; for (int i from; i to; i) { sum (sum (data[i] 0xFF)) 0xFF; } return (byte) sum; } }校驗和運(yùn)算范圍從第一個68之后開始更容易因為邊界問題翻車。請求報文的組裝邏輯里表地址翻轉(zhuǎn)和0x33加擾是新手最容易漏的兩步漏了以后電表要么不響應(yīng)要么一直返回錯誤幀。響應(yīng)報文的解析方向相反Netty的Handler里收到完整幀后先校驗起始符、校驗和再取數(shù)據(jù)域長度然后對數(shù)據(jù)區(qū)做反轉(zhuǎn)加擾還原。DL/T645的數(shù)據(jù)區(qū)第4位是0x33加密后的科學(xué)計數(shù)因此還原時每個字節(jié)加0x33換算成十進(jìn)制后再移小數(shù)點(diǎn)。這個讀取邏輯可以封裝為public static BigDecimal decodeReadResponse(byte[] frame) { if (frame[0] ! START || frame[frame.length - 1] ! END) { throw new IllegalArgumentException(非法幀); } int len frame[10] 0xFF; // 數(shù)據(jù)域長度 byte[] data Arrays.copyOfRange(frame, 14, 14 len); // 前4字節(jié)是數(shù)據(jù)標(biāo)識后面才是電能值 byte[] valueBytes Arrays.copyOfRange(data, 4, data.length); for (int i 0; i valueBytes.length; i) { valueBytes[i] (byte) ((valueBytes[i] 0x33) 0xFF); } long raw bytesToLong(valueBytes); return BigDecimal.valueOf(raw).movePointLeft(4); }這里的 movePointLeft(4) 是因為DL/T645電能值最小單位是0.0001kWh讀到的整數(shù)要除以10000。不同廠家的實(shí)時數(shù)據(jù)、需量數(shù)據(jù)、電壓數(shù)據(jù)在數(shù)據(jù)標(biāo)識和單位上各有差別所以實(shí)際工程中通常把 data_id 和單位一起配置成字典避免在代碼里做死。3.2 采集調(diào)度定時任務(wù)配合Redis鎖防止重復(fù)執(zhí)行定時抄表最簡單的方式就是Spring的Scheduled但生產(chǎn)環(huán)境部署多個實(shí)例時同一個任務(wù)會在每臺機(jī)器上各跑一次導(dǎo)致同一時段出現(xiàn)多條讀數(shù)。我習(xí)慣用Redis的setIfAbsent做一個分布式鎖搶到鎖的實(shí)例才執(zhí)行任務(wù)Component Slf4j public class MeterReadScheduler { Resource private StringRedisTemplate redisTemplate; Resource private MeterReadService meterReadService; Scheduled(cron ${meter.gather.cron}) public void autoRead() { String lockKey task:autoRead:2025041502; Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, running, Duration.ofMinutes(30)); if (!Boolean.TRUE.equals(locked)) { log.warn(已有實(shí)例在執(zhí)行抄表任務(wù)本次跳過); return; } try { meterReadService.readAllOnlineMeters(); } finally { redisTemplate.delete(lockKey); } } }lockKey 里帶上任務(wù)批次號避免兩輪任務(wù)之間因為執(zhí)行時間過長而互相干擾。鎖的過期時間按任務(wù)最大耗時設(shè)置我一般會留兩倍余量防止斷電或重啟導(dǎo)致鎖永久不釋放。readAllOnlineMeters 內(nèi)部會分批處理設(shè)備先把在線設(shè)備id列表查出來每100臺一組分組發(fā)起讀命令避免一次性把幾千臺設(shè)備全部壓給網(wǎng)關(guān)層。若設(shè)備回包超時則把該設(shè)備標(biāo)記為離線等待下輪任務(wù)重試。3.3 計費(fèi)邏輯階梯電價和倍率換算怎么落進(jìn)代碼抄到原始讀數(shù)之后不能直接把讀數(shù)差值乘以電價。實(shí)際用電量要先乘上互感器倍率因為大部分電表經(jīng)電流互感器接入表上顯示1度實(shí)際可能是幾十度。其次大多場景采用階梯電價按總用電量分檔計價public BigDecimal calcBillAmount(MeterReading reading, PricePlan plan) { BigDecimal actual reading.getKwh().multiply(reading.getMultiplier()); BigDecimal amount BigDecimal.ZERO; if (actual.compareTo(plan.getFirstStage()) 0) { amount actual.multiply(plan.getPrice1()); } else if (actual.compareTo(plan.getSecondStage()) 0) { amount plan.getFirstStage().multiply(plan.getPrice1()) .add(actual.subtract(plan.getFirstStage()).multiply(plan.getPrice2())); } else { amount plan.getFirstStage().multiply(plan.getPrice1()) .add(plan.getSecondStage().subtract(plan.getFirstStage()).multiply(plan.getPrice2())) .add(actual.subtract(plan.getSecondStage()).multiply(plan.getPrice3())); } return amount.setScale(2, RoundingMode.HALF_UP); }所有金額計算全部用BigDecimal這一點(diǎn)是踩過坑才有的覺悟。用double計費(fèi)每筆差幾分錢日積月累到月底對賬就是一筆糊涂賬。階梯判斷的結(jié)構(gòu)化表達(dá)其實(shí)可以用策略模式重構(gòu)但當(dāng)前這種if-else寫法在電價檔位不超過三檔時最直觀后續(xù)要支持峰平谷分時電價再增加按時間段拆分用電量的計算器即可。3.4 繳費(fèi)回調(diào)用冪等鍵擋住重復(fù)請求繳費(fèi)環(huán)節(jié)最容易出問題的不是支付而是回調(diào)。支付渠道為了確保通知送達(dá)往往會重試多次如果后端不處理重復(fù)請求同一筆繳費(fèi)就會生成多條流水賬單被更新兩次。處理方式是一條唯一索引外加事務(wù)內(nèi)的先查后寫Transactional(rollbackFor Exception.class) public void handlePaymentNotify(PaymentNotifyDTO dto) { Integer count paymentRecordMapper.countByPaymentNo(dto.getPaymentNo()); if (count 0) { return; // 重復(fù)回調(diào)直接忽略 } PaymentRecord record new PaymentRecord(); record.setPaymentNo(dto.getPaymentNo()); record.setBillId(dto.getBillId()); record.setStatus(1); paymentRecordMapper.insert(record); billInfoMapper.updateStatus(dto.getBillId(), BillStatus.PAID); }代碼層面的count查詢只是第一道防線payment_record 表上的 payment_no 唯一索引才是兜底。萬一兩個請求同時進(jìn)來一個插入成功另一個會觸發(fā)唯一鍵沖突由全局異常處理器捕獲后同樣返回成功避免支付渠道誤以為通知失敗繼續(xù)重試。4. 本地跑起來從建庫建表到模擬電表回包的完整流程4.1 環(huán)境準(zhǔn)備與工程導(dǎo)入需要準(zhǔn)備JDK 8或以上版本、Maven 3.x、MySQL、Redis、IDEA。拿到源碼包后用IDEA以Maven工程方式打開根目錄 pom.xml等待依賴下載完成即可。這份工程沒有依賴外部中間件MySQL和Redis裝好就能跑。我通常先把 sql 目錄下的腳本按順序執(zhí)行命名一般是 schema.sql 建表、data.sql 初始化演示數(shù)據(jù)執(zhí)行完后確認(rèn) meter_info 里有幾條設(shè)備記錄。4.2 修改配置時區(qū)和端口是命門application.yml 里要改的是數(shù)據(jù)源、Redis和Netty端口三個地方server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/meter_platform?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8mb4 username: root password: root redis: host: localhost port: 6379 mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml meter: netty: port: 8304 boss-threads: 1 worker-threads: 4 gather: cron: 0 15 2 * * ?數(shù)據(jù)源連接串里的 serverTimezone 一定要顯式寫 Asia/Shanghai實(shí)踐中有不少項目在本地連庫沒問題一部署到服務(wù)器上報表就少一天就是時區(qū)沒指定。Netty端口記住一個數(shù)就行后面模擬電表也要用同一個端口。抄表 cron 我改成每分鐘一次方便本地驗證生產(chǎn)環(huán)境再換回凌晨執(zhí)行。提示建議本地驗證時把 cron 調(diào)成0 * * * * ?這樣一分鐘就能看到一次自動采集效果不用手動點(diǎn)按鈕等半天。4.3 寫一個模擬電表把回包做實(shí)沒有真實(shí)電表怎么驗證鏈路常見做法是本地起一個TCP服務(wù)模擬電表監(jiān)聽同一端口收到讀表命令就回一幀固定數(shù)據(jù)。這里貼一個我在本地反復(fù)用過的最小實(shí)現(xiàn)public class SimulatorMeterServer { /** 數(shù)據(jù)區(qū)固定回復(fù)當(dāng)前組合有功總電能 123.45 kWh已按DL/T645規(guī)則做過加擾 */ private static final byte[] RESPONSE hexStringToByteArray( 68 11 11 11 11 11 11 68 81 06 00 01 00 00 45 23 01 00 55 16); public static void main(String[] args) throws Exception { ServerSocket serverSocket new ServerSocket(8304); System.out.println(simulator meter listening on 8304); while (true) { Socket socket serverSocket.accept(); new Thread(() - handle(socket)).start(); } } private static void handle(Socket socket) { try (InputStream in socket.getInputStream(); OutputStream out socket.getOutputStream()) { byte[] buffer new byte[128]; int len in.read(buffer); // 粗略判斷收到以68起始的讀請求幀 if (len 4 buffer[4] (byte) 0x68) { out.write(RESPONSE); out.flush(); } } catch (IOException ignored) { } finally { try { socket.close(); } catch (IOException ignored) { } } } }這段模擬器只做了一件事收到讀請求后返回寫死的電量幀。真實(shí)工程里一個集中器下帶多塊表模擬器還要根據(jù)報文中的表地址返回對應(yīng)讀數(shù)但本地驗證核心鏈路用這個就夠了。運(yùn)行時先啟動模擬器再啟動后端日志里能看到Netty服務(wù)啟動并且定時任務(wù)觸發(fā)后會打印讀到的電量值。如果讀到的數(shù)據(jù)不對先從模擬器回包檢查起再對照協(xié)議幀格式排查。4.4 驗證一條完整業(yè)務(wù)鏈后端啟動完成后通過HTTP接口逐層驗證更直觀操作請求路徑預(yù)期結(jié)果查看設(shè)備列表GET /api/meter/list?page1能看到模擬表記錄手動抄表POST /api/meter/1/read返回當(dāng)前讀數(shù)生成賬單POST /api/bill/settle?billId1賬單狀態(tài)為待支付繳費(fèi)回調(diào)POST /api/pay/notify賬單狀態(tài)變?yōu)橐阎Ц禼url -X POST http://localhost:8080/api/meter/1/read \ -H Content-Type: application/json -d {}我建議把這條鏈路完整走一遍再去看前端頁面。后端調(diào)通能提前暴露大部分問題比如協(xié)議解析錯誤、賬單金額不對、回調(diào)冪等失效這類問題卡在前端調(diào)試階段反而費(fèi)時間。走完這四步這個項目對你來說就已經(jīng)從“源碼”變成“跑起來的系統(tǒng)”了。5. 避坑與排查這套平臺最容易翻車的五個細(xì)節(jié)5.1 現(xiàn)象模擬電表能連接但始終解析不到數(shù)據(jù)日志里出現(xiàn) “invalid frame” 或 “校驗和錯誤”時先不要懷疑代碼邏輯大概率問題出在幀邊界處理。原因在于前端發(fā)了4個FE前導(dǎo)符某些實(shí)現(xiàn)會在讀取時把前導(dǎo)符也算進(jìn)幀體導(dǎo)致程序從錯誤的位置開始解析。 解決方法是統(tǒng)一約定發(fā)送端補(bǔ)前導(dǎo)符接收端在解碼器里跳過FE字節(jié)只拿FE后面的68 開頭報文。另外檢查表地址是否做了低位反轉(zhuǎn)DL/T645里地址是按字節(jié)倒序傳輸?shù)牡刂穼懛戳穗姳頃苯硬豁憫?yīng)。5.2 現(xiàn)象同一塊表在同一抄表周期出現(xiàn)了兩條讀數(shù)這是典型的定時任務(wù)重復(fù)執(zhí)行。本地單實(shí)例不暴露生產(chǎn)環(huán)境多節(jié)點(diǎn)部署后Scheduled在每個節(jié)點(diǎn)都會觸發(fā)一遍。 原因就是缺分布式鎖。 解決方法是給任務(wù)加Redis鎖像前面代碼里那樣用 setIfAbsent 保證同一時刻只有一個實(shí)例執(zhí)行。還有一種隱蔽場景任務(wù)A執(zhí)行到一半重啟鎖還沒釋放下個周期任務(wù)B看到鎖存在就跳過導(dǎo)致這個周期漏采。所以鎖的過期時間要按任務(wù)最大耗時配置而不是默認(rèn)10秒。5.3 現(xiàn)象繳費(fèi)后賬單狀態(tài)一直停留在“待支付”這類問題大多出現(xiàn)在回調(diào)處理上。支付渠道回調(diào)通知后端后端更新數(shù)據(jù)庫失敗但返回了成功渠道認(rèn)為通知已到達(dá)不再重試賬單就卡住了。 另一類原因是先查后寫沒有做好冪等同一回調(diào)處理兩次導(dǎo)致數(shù)據(jù)錯亂。 解決方法是繳費(fèi)流水表加唯一索引事務(wù)內(nèi)先查流水再插流水最后更新賬單任何一步失敗都拋異常讓事務(wù)回滾返回非成功讓渠道繼續(xù)重試。排查時先查 payment_record 表有沒有對應(yīng)流水沒有就是回調(diào)壓根沒進(jìn)來有就要看賬單更新語句是否被異常攔截。5.4 現(xiàn)象賬單金額和實(shí)際用電對不上月底總差幾塊錢金額對不上基本是精度問題。用double做乘法或者倍率計算順序錯了都會累積誤差。 我在本地測試時試著把電表讀數(shù)直接用kwh乘以單價結(jié)果10臺模擬表跑一個月差異從幾分錢慢慢放大到幾塊錢。 解決方法是結(jié)算金額統(tǒng)一用BigDecimal并且先乘倍率得到實(shí)際電量再按階梯分檔計算倍率要讀 meter_info 里的 multiplier 字段不能寫死在代碼里。還有一個注意點(diǎn)抄表讀數(shù)要保留數(shù)據(jù)來源總電量要區(qū)分峰平谷否則做分時電價時還得重新解析歷史報文。5.5 現(xiàn)象前端頁面一到月底報表查詢就卡死數(shù)據(jù)量上來之后meter_reading 表會膨脹得很快一天一抄一年就是365條每表。幾萬塊表跑一年就是上千萬行報表查詢沒有索引就是全表掃描。 常見誤區(qū)是只給主鍵建索引查詢條件里的 meter_no 和 read_time 完全沒有索引可用。 解決方法是建組合索引 (meter_no, read_time)報表統(tǒng)計時把日期條件作為強(qiáng)制過濾項。更徹底的做法是按月分表或建立日匯總表把明細(xì)數(shù)據(jù)歸檔到歷史庫日常對賬只查匯總結(jié)果。這套工程本地跑沒有問題要上生產(chǎn)必須提前考慮這個增長模型。6. 二次開發(fā)從抄表平臺延伸到能耗分析6.1 用策略模式接入新協(xié)議實(shí)際落地時幾乎一定會遇到第二種、第三種電表協(xié)議比如Modbus RTU或某個廠家的私有協(xié)議。網(wǎng)關(guān)層如果繼續(xù)用if-else判斷協(xié)議類型新協(xié)議多了之后代碼會迅速腐化。更合適的做法是定義協(xié)議處理器接口public interface MeterProtocolHandler { boolean support(String protocol); MeterData read(MeterDevice meter); }網(wǎng)關(guān)收到抄表任務(wù)時遍歷所有已注冊的 ProtocolHandler找到 support 返回true的那個實(shí)例來執(zhí)行讀取。新增一種協(xié)議只需要寫一個新的實(shí)現(xiàn)類并注冊到Spring容器不需要改動原有的DL/T645邏輯。我第一次給這類平臺加Modbus協(xié)議時因為協(xié)議解析耦合在讀表服務(wù)里改一處動了全鏈路后來重構(gòu)出這個接口才好了從那以后我每接觸一套抄表平臺都會先看協(xié)議層是否留了擴(kuò)展點(diǎn)。6.2 把固定抄表頻率改成按設(shè)備可配平臺默認(rèn)全局一個 cron 表達(dá)式所有設(shè)備一個頻率。但能耗管理場景里要按15分鐘頻率采集園區(qū)重點(diǎn)回路普通住戶表一天一次就夠了。改造思路是給 read_task 表增加 cron 字段配置每類設(shè)備的采集頻率調(diào)度器每分鐘掃一次任務(wù)表命中時間點(diǎn)的任務(wù)才下發(fā)采集請求。這里要重點(diǎn)處理高頻設(shè)備的并發(fā)問題同一集中器下的設(shè)備讀取要串行化否則集中器處理不過來會大量丟包。6.3 從賬單延伸到能耗分析抄表數(shù)據(jù)的價值不止于出賬單。采集頻率提高后可以用小時、天、月維度做聚合統(tǒng)計算出環(huán)比同比識別出異常用電時段。比如某條回路線路在半夜用電量突增大概率是設(shè)備非正常開啟或線路漏電。DL/T645協(xié)議里電壓、電流、有功功率都有對應(yīng)的數(shù)據(jù)標(biāo)識擴(kuò)展采集時不改協(xié)議層只要在數(shù)據(jù)字典里增加新的 data_id 配置就能把更多電能質(zhì)量數(shù)據(jù)拉回來。順著這個方向這套平臺就不再只是“抄表繳費(fèi)”而是慢慢長成一個小型的企業(yè)能耗平臺。我拆完這個工程最大的習(xí)慣變化是以后再接手這類Java項目第一件事不是讀業(yè)務(wù)代碼而是先把模擬器跑起來把端到端鏈路驗證通再決定從哪里動手改。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取