← Hub
System Architecture Redesign
ปัจจุบัน vs ที่เสนอ — แก้จุดที่พังจริงวันนี้ (registry เก่า, symbol ผิด) ไม่ใช่รื้อทิ้งทั้งระบบ
xauusd_ob_bot · เสนอ 2026-07-11
คง $0/เดือน ไม่ต้องมี Cloud/DB Server Migrate ทีละ Phase ของเดิมใช้งานได้ระหว่างย้าย
0 · ภาพรวมการทำงาน — AI Brain (ทุก 2 ชั่วโมง)
วงจรที่ป้อนข้อมูลให้ Babata Optimizer ตัดสินใจ — เขียนเป็นค่าเริ่มต้นคือ "ข้าม" ถ้าไม่มีอะไรใหม่จริง กันข้อมูลบวมไร้สาระ
AI Brain — ขั้นตอนการทำงานแต่ละรอบ ไดอะแกรมแสดงว่า AI Brain cron (ทุก 2 ชั่วโมง) ตัดสินใจอย่างไรในแต่ละรอบ ตั้งแต่อ่าน journal ไปจนถึงเขียนหรือข้าม Knowledge Base AI Brain — ขั้นตอนการทำงานแต่ละรอบ (ทุก 2 ชั่วโมง) /loop cron — ตายเมื่อปิด session, กลับมาอัตโนมัติทุก session ใหม่ ⏱ Cron ยิงทุก 2 ชั่วโมง session ต้องเปิดอยู่ 📖 อ่าน trade_journal.json + babata_reports/ ล่าสุด มีเทรด/รายงาน ใหม่จริงไหม? ไม่มี (บ่อยสุด) ⏭ ข้ามรอบนี้ ไม่เขียน KB ซ้ำ กันข้อมูลบวมไร้สาระ มีของใหม่ 🔍 หา pattern น่าสงสัย sample เล็ก, แพ้ติดกัน, บั๊กที่ข้อมูลบอก เหมือนคนตรวจทานจริงจะสังเกต มั่นใจจริง + n พอหรือยัง? ไม่พอ 📝 เขียนแบบ confidence ต่ำ ห้ามยัดให้ดูน่าเชื่อเกินจริง มั่นใจสูง ✅ ai_brain_kb.append_entry() ใครอ่าน KB ต่อ? babata_optimizer.py อ่านอย่างเดียว ทำได้แค่: • เพิ่ม confidence ของกฎเดิม • เสนอ raise threshold เบาๆ ✗ ห้าม BAN / ลด threshold เอง ยังต้องผ่านทุกด่านเดิม Tester backtest → Deployer dry-run → Telegram approve (คุณ) ไม่แตะ config จริงตรงๆ เลย
⚡ หลักการที่ยึดตลอดการออกแบบนี้
ปัญหาที่เจอจริงวันนี้ (APEX/NEXUS/SevenEleven หายจากตาราง, Basket โชว์ symbol ผิด) ไม่ได้เกิดจากการไม่มี framework ทันสมัย — เกิดจาก "ไม่มีแหล่งความจริงเดียว" (single source of truth) ทำให้ไฟล์ทะเบียนเก่าหลุด sync จากของจริงใน MT5 ข้อเสนอนี้จึงเน้นแก้โครงสร้างข้อมูล ไม่ใช่เปลี่ยนเทคโนโลยีทั้งยวง — ยังคง Python + ไฟล์ในเครื่อง + ไม่มีค่าใช้จ่ายเพิ่มเหมือนเดิม
1 · ภาพรวม เปรียบเทียบชั้นต่อชั้น
🔴 ปัจจุบัน
Frontend
5+ ไฟล์ HTML แยกกัน (hub/dashboard/workflow/public/apex) — แต่ละไฟล์ก็อป CSS/nav/polling logic ของตัวเอง
ต้องแก้ 3-4 ที่เวลาเพิ่มบอทใหม่
การสื่อสาร
Poll ทุก 5 วิ ผ่าน fetch() — ไม่มี push จริง
โหลดซ้ำโดยไม่จำเป็น เห็นข้อมูลช้าสุด 5 วิ
API Servers
3 process แยก (serve_dashboard :8765, apex_serve :8767, nexus_serve :8766) — คนละไฟล์ คนละ logic ก็อปกัน
แก้ magic-mapping ต้องจำไปแก้หลายที่
Registry ("ใครคือใคร")
accounts.json แก้มือ ไม่มีอะไรบังคับให้ sync กับบอทที่มีจริง
เจอจริง: ไม่เคยเพิ่ม APEX/NEXUS/SevenEleven เลย
Data Layer
JSON file ล้วน (atomic write ปลอดภัยดีอยู่แล้ว) — แต่ query/filter ต้องโหลดทั้งไฟล์มา scan ทุกครั้ง
journal โตขึ้นเรื่อยๆ จะช้าลง
🟢 ที่เสนอ
Frontend
Shell เดียว (hub.html) + shared header/nav component โหลดผ่าน fetch include — หน้าอื่นเป็น "panel" ที่ฝังเข้ามา ไม่ก็อปโค้ด
เพิ่มบอทใหม่ = แก้ที่เดียว
การสื่อสาร
Server-Sent Events (SSE) แทน polling — browser ได้มาตรฐานในตัว ไม่ต้องติดตั้งอะไรเพิ่ม
เห็นข้อมูลทันทีที่เปลี่ยน ไม่ใช่รอ 5 วิ
API Gateway
รวมเป็น 1 process (api_gateway.py) — endpoint ทั้งหมดอยู่ที่เดียว ยังเป็น stdlib http.server เหมือนเดิม (ไม่เพิ่ม dependency)
แก้ magic-mapping ที่เดียว จบ
Registry ("ใครคือใคร")
bot_registry.py (Python code, ไม่ใช่ JSON แก้มือ) — เป็นแหล่งความจริงเดียวสำหรับ magic/port/log file ของทุกบอท (ต่อยอดจาก bot_magic_map.py ที่ทำไปแล้ว)
บอทใหม่ = เพิ่ม 1 บรรทัดในไฟล์เดียว ทุกหน้าเห็นทันที
Data Layer
SQLite สำหรับ trade_journal (stdlib sqlite3, ไฟล์เดียวในเครื่อง ไม่ใช่ server) — query/filter เร็วขึ้นมาก, ไฟล์อื่นๆ (live_data, config) คง JSON เหมือนเดิม
Query "กลยุทธ์ X ใน session Y" ได้ใน 1 คำสั่ง
2 · แผนย้ายระบบ — เรียงตามความเสี่ยง/ผลตอบแทน
แต่ละ Phase ทำงานได้อิสระ ไม่ต้องรอ Phase อื่นเสร็จก่อน และของเดิมยังใช้งานได้ตลอดการย้าย (ไม่มี downtime)
Phase 1
🗂️ Bot Registry รวมศูนย์
ขยาย bot_magic_map.py ให้เป็น bot_registry.py เต็มรูป — เก็บ magic range, log file, process name, port ของทุกบอทไว้ที่เดียว แทน accounts.json + hardcode กระจายทุกไฟล์
ความเสี่ยงต่ำ~2-3 ชม.
Phase 2
🗄️ Journal → SQLite
ย้าย trade_journal.json → SQLite ไฟล์เดียว เขียนคู่ขนานช่วงเปลี่ยนผ่าน (dual-write) จนมั่นใจแล้วค่อยตัด JSON ทิ้ง — deep_insights/Babata query เร็วขึ้นมาก
ความเสี่ยงกลาง~1 วัน
Phase 3
🔌 รวม API เป็น Gateway เดียว
ย้าย endpoint จาก serve_dashboard/apex_serve/nexus_serve มารวมใน api_gateway.py ตัวเดียว — ยังเป็น stdlib server เดิม แค่รวม process
ความเสี่ยงกลาง~1 วัน
Phase 4
📡 Polling → SSE Push
เปลี่ยนหน้าเว็บจาก setInterval(fetch) เป็น EventSource — server ส่งข้อมูลเองเมื่อมีการเปลี่ยนแปลงจริง ลด request ที่ไม่จำเป็น
ความเสี่ยงสูงกว่า~1-2 วัน
3 · สรุปเทียบตรงประเด็น
หัวข้อปัจจุบันที่เสนอ
เพิ่มบอทใหม่ 1 ตัวแก้ accounts.json + serve_dashboard.py + hub.html + workflow_status.py (4 ที่)เพิ่ม 1 entry ใน bot_registry.py (1 ที่)
ดูออเดอร์สด3 endpoint ต่างกัน ผลไม่ตรงกันได้ (เจอจริงวันนี้)endpoint เดียว อ่านจาก MT5 ตรงเสมอ
Query สถิติย้อนหลังโหลด JSON ทั้งไฟล์มา loop ทุกครั้งSQL query ตรง มี index
ความสดของข้อมูลหน้าเว็บล่าช้าสูงสุด 5 วินาที + poll แม้ไม่มีอะไรเปลี่ยนอัพเดตทันทีที่มีเหตุการณ์จริง
ค่าใช้จ่าย/เดือน$0$0 (เหมือนเดิม — ไม่มี cloud/server เพิ่ม)
Dependency ใหม่—ไม่มี — sqlite3/EventSource เป็น stdlib/browser-native ทั้งคู่
🔴 หลักฐานสดที่เจอระหว่างเขียนหน้านี้: serve_dashboard.py ค้างทั้งเซิร์ฟเวอร์ไปเลยกลางอากาศ (ทุกหน้าตอบ connection refused) ตรวจแล้วพบว่าใช้ HTTPServer ธรรมดา (single-threaded) ไม่ใช่ ThreadingHTTPServer — ถ้า request ใดค้าง (เช่นรอ MT5 ตอบช้า) จะบล็อกทุก client ที่เหลือทันที ต้อง restart เพื่อกู้คืน นี่คือหลักฐานจริงที่สนับสนุน Phase 3 (รวม API Gateway) — และเป็น "quick win" ที่ทำได้ก่อน Phase 3 เต็มรูปได้เลย: สลับเป็น ThreadingHTTPServer บรรทัดเดียว กัน 1 request ช้าล้มทั้งระบบ
คำแนะนำเรื่องจังหวะ: ระบบเพิ่งเข้าสู่ช่วง "เก็บข้อมูลสะสม 300-500 เทรด" ที่ตกลงกันไว้เมื่อวาน (Variant Lab + score_breakdown ใหม่) — แนะนำให้ทำแค่ Phase 1 (Bot Registry) ตอนนี้เพราะเสี่ยงต่ำและแก้ต้นตอบั๊กที่เจอวันนี้โดยตรง ส่วน Phase 2-4 ควรรอจนสะสมข้อมูลครบก่อน เพื่อไม่ให้การรื้อโครงสร้างไปรบกวนช่วงที่กำลังวัดผลบอทอยู่