thảo luận Hệ thống Trading Phân tán mã nguồn do mình tự phát triển

  • Người tạo chủ đề Người tạo chủ đề javdev
  • Ngày bắt đầu Ngày bắt đầu
J

javdev

Junior Member

🚀

[Open Source] Emporia – Hệ thống Trading Phân tán với Java 21 & Spring Boot 4
Chào mọi người,
Mình xin chia sẻ một dự án open-source mà mình vừa hoàn thành: Emporia Trading Platform – một hệ thống mô phỏng sàn giao dịch chứng khoán phân tán (Distributed Stock Trading Platform).
Dự án mô phỏng trọn vẹn dòng chảy từ lúc Trader đặt lệnh trên màn hình React UI, qua các dịch vụ kiểm tra rủi ro, điều hướng thuật toán, cho tới khi khớp lệnh và tự động hạch toán danh mục đầu tư.
👉
GitHub Repository: GitHub - nvxtien/emporia: Emporia is a microservices-based trading platform built with Spring Boot, React, Kafka, and PostgreSQL, featuring real-time market data, order management, execution strategies, and OAuth2 security. (https://github.com/nvxtien/emporia)
📚
GitHub Wiki (Sơ đồ & Tài liệu chi tiết): Home (https://github.com/nvxtien/emporia/wiki)

🌟
Điểm Nổi Bật Của Dự Án​

    • Công nghệ hiện đại: Xây dựng trên Java 21 (Virtual Threads, Records), Spring Boot 4.0.7, React 19 và Apache Kafka.
    • Kiến trúc Microservices chuẩn: Chia thành 9 dịch vụ độc lập theo nghiệp vụ (Quản lý lệnh, Dữ liệu thị trường, Định tuyến thuật toán, Danh mục đầu tư, Xác thực OAuth2/OIDC). Each service sở hữu database PostgreSQL riêng.
    • Tính năng tài chính thực tế:
      • Khớp lệnh siêu tốc: Tích hợp LMAX Disruptor matching engine.
      • Điều hướng lệnh thông minh (SOR & VWAP): Tự động quét giá tốt nhất trên các sàn (NBBO) và tự động chia nhỏ lệnh lớn theo thời gian.
      • Quản trị rủi ro & Danh mục: Tự động tính giá vốn bình quân, Lãi/Lỗ thực tế & tạm tính (Realized/Unrealized PnL), chặn lệnh lỗi (Fat-finger guard).
    • Chất lượng kiểm thử cao: Đạt 92% Test Coverage, được kiểm thử concurrency khắt khe chống nghẽn lệnh/deadlock và tuân thủ clean code.

🤝
Rất Mong Nhận Được Đóng Góp & Feedback!​

 
Chào bạn, mình không rõ code lắm và chưa đọc và tìm hiểu rõ về hệ thống trading này của bạn, nhưng thấy rất thú vị, không biết hệ thống này có thể hỗ trợ chạy lệnh theo sát giây, kết nối nhiều lệnh và các portfolio lại được với nhau được k nhỉ
 
javdev đã nói:

🚀

[Open Source] Emporia – Hệ thống Trading Phân tán với Java 21 & Spring Boot 4
Chào mọi người,
Mình xin chia sẻ một dự án open-source mà mình vừa hoàn thành: Emporia Trading Platform – một hệ thống mô phỏng sàn giao dịch chứng khoán phân tán (Distributed Stock Trading Platform).
Dự án mô phỏng trọn vẹn dòng chảy từ lúc Trader đặt lệnh trên màn hình React UI, qua các dịch vụ kiểm tra rủi ro, điều hướng thuật toán, cho tới khi khớp lệnh và tự động hạch toán danh mục đầu tư.
👉
GitHub Repository: GitHub - nvxtien/emporia: Emporia is a microservices-based trading platform built with Spring Boot, React, Kafka, and PostgreSQL, featuring real-time market data, order management, execution strategies, and OAuth2 security. (https://github.com/nvxtien/emporia)
📚
GitHub Wiki (Sơ đồ & Tài liệu chi tiết): Home (https://github.com/nvxtien/emporia/wiki)

🌟
Điểm Nổi Bật Của Dự Án​

    • Công nghệ hiện đại: Xây dựng trên Java 21 (Virtual Threads, Records), Spring Boot 4.0.7, React 19 và Apache Kafka.
    • Kiến trúc Microservices chuẩn: Chia thành 9 dịch vụ độc lập theo nghiệp vụ (Quản lý lệnh, Dữ liệu thị trường, Định tuyến thuật toán, Danh mục đầu tư, Xác thực OAuth2/OIDC). Each service sở hữu database PostgreSQL riêng.
    • Tính năng tài chính thực tế:
      • Khớp lệnh siêu tốc: Tích hợp LMAX Disruptor matching engine.
      • Điều hướng lệnh thông minh (SOR & VWAP): Tự động quét giá tốt nhất trên các sàn (NBBO) và tự động chia nhỏ lệnh lớn theo thời gian.
      • Quản trị rủi ro & Danh mục: Tự động tính giá vốn bình quân, Lãi/Lỗ thực tế & tạm tính (Realized/Unrealized PnL), chặn lệnh lỗi (Fat-finger guard).
    • Chất lượng kiểm thử cao: Đạt 92% Test Coverage, được kiểm thử concurrency khắt khe chống nghẽn lệnh/deadlock và tuân thủ clean code.

🤝
Rất Mong Nhận Được Đóng Góp & Feedback!​

Nhấp để mở rộng...
Khớp lệnh siêu tốc, nhưng truớc đó tạo order trên postgres đã là bottoneck rồi
 
Ngài Pussi đã nói:
Chào bạn, mình không rõ code lắm và chưa đọc và tìm hiểu rõ về hệ thống trading này của bạn, nhưng thấy rất thú vị, không biết hệ thống này có thể hỗ trợ chạy lệnh theo sát giây, kết nối nhiều lệnh và các portfolio lại được với nhau được k nhỉ
Nhấp để mở rộng...
Có, hướng thiết kế của hệ thống là hỗ trợ được các flow như vậy, nhưng mình sẽ nói rõ hơn một chút để tránh hiểu nhầm.

Hiện tại hệ thống phù hợp với kiểu electronic trading / algorithmic execution: nhận lệnh, quản lý vòng đời lệnh, chia lệnh theo strategy như SMART/VWAP, gửi sang execution engine, nhận fill/reject/cancel, rồi cập nhật lại OMS và portfolio.

Về “chạy lệnh theo sát giây”: hệ thống có thể hướng tới mức near real-time theo giây hoặc dưới giây, ví dụ strategy tick, VWAP slice, routing, execution event. Nhưng đây chưa phải hệ thống HFT hard real-time kiểu nanosecond/microsecond. Vì đang dùng Spring/Kafka/Postgres nên cần đo p50/p95/p99 latency rõ ràng trước khi cam kết SLA.

Về “kết nối nhiều lệnh và portfolio”: phần này có nền tảng rồi. Order có quan hệ parent/child/root order, nên có thể gom nhiều child orders dưới một parent strategy order. Portfolio service cũng quản lý trạng thái portfolio, balance, risk seed, snapshot. Mục tiêu tiếp theo là gắn chặt hơn order, execution, strategy và portfolio bằng risk-service/strategy-engine để nhiều lệnh có thể được kiểm soát theo portfolio/account/desk một cách rõ ràng hơn.

Nói ngắn gọn: có thể hỗ trợ, đặc biệt cho seconds-level algorithmic trading và portfolio-aware execution. Nhưng nếu muốn production-grade thì cần hoàn thiện thêm phần latency dashboard, risk engine, strategy runtime, backtest/replay và performance baseline. Hiện tại mình đang đi theo hướng đó.
 
Violet_7 đã nói:
Khớp lệnh siêu tốc, nhưng truớc đó tạo order trên postgres đã là bottoneck rồi
Nhấp để mở rộng...
Đúng rồi, bạn nói rất đúng. Nếu mình cứ tạo order rồi ghi Postgres đồng bộ trước khi cho lệnh đi tiếp thì Postgres chắc chắn sẽ thành bottleneck, và lúc đó nói “khớp lệnh siêu tốc” là hơi quá.

Hiện tại hệ thống của mình chưa phải kiểu HFT hay matching engine tối ưu đến microsecond. Nó đang giống một nền tảng trading có OMS, execution, portfolio, audit, Kafka, Postgres hơn. Postgres hiện vẫn đóng vai trò khá lớn để đảm bảo trạng thái order, audit và recovery.

Hướng mình đang muốn đi là tách rõ hơn: phần cần nhanh thì đi qua memory/cache/event bus/execution engine, còn Postgres dùng để lưu bền, audit, replay và rebuild state. Tức là không để Postgres nằm ngay giữa đường nóng của lệnh nữa.

Nên nếu nói chính xác thì: hiện tại hệ thống có thể làm algo/electronic trading và đo latency theo p50/p95/p99, nhưng chưa nên claim là “siêu tốc”. Muốn tới mức đó thì cần refactor hot path, giảm synchronous DB write, và benchmark thật kỹ. Cảm ơn bạn bắt đúng điểm này.
 
javdev đã nói:
Đúng rồi, bạn nói rất đúng. Nếu mình cứ tạo order rồi ghi Postgres đồng bộ trước khi cho lệnh đi tiếp thì Postgres chắc chắn sẽ thành bottleneck, và lúc đó nói “khớp lệnh siêu tốc” là hơi quá.

Hiện tại hệ thống của mình chưa phải kiểu HFT hay matching engine tối ưu đến microsecond. Nó đang giống một nền tảng trading có OMS, execution, portfolio, audit, Kafka, Postgres hơn. Postgres hiện vẫn đóng vai trò khá lớn để đảm bảo trạng thái order, audit và recovery.

Hướng mình đang muốn đi là tách rõ hơn: phần cần nhanh thì đi qua memory/cache/event bus/execution engine, còn Postgres dùng để lưu bền, audit, replay và rebuild state. Tức là không để Postgres nằm ngay giữa đường nóng của lệnh nữa.

Nên nếu nói chính xác thì: hiện tại hệ thống có thể làm algo/electronic trading và đo latency theo p50/p95/p99, nhưng chưa nên claim là “siêu tốc”. Muốn tới mức đó thì cần refactor hot path, giảm synchronous DB write, và benchmark thật kỹ. Cảm ơn bạn bắt đúng điểm này.
Nhấp để mở rộng...
Vl, ông bảo con chatgpt reply à :shame: .
Anyway, ông nên tự benchmark hệ thống đc bao nhiêu tps trc khi nói siêu tốc.
 
javdev đã nói:
Có, hướng thiết kế của hệ thống là hỗ trợ được các flow như vậy, nhưng mình sẽ nói rõ hơn một chút để tránh hiểu nhầm.

Hiện tại hệ thống phù hợp với kiểu electronic trading / algorithmic execution: nhận lệnh, quản lý vòng đời lệnh, chia lệnh theo strategy như SMART/VWAP, gửi sang execution engine, nhận fill/reject/cancel, rồi cập nhật lại OMS và portfolio.

Về “chạy lệnh theo sát giây”: hệ thống có thể hướng tới mức near real-time theo giây hoặc dưới giây, ví dụ strategy tick, VWAP slice, routing, execution event. Nhưng đây chưa phải hệ thống HFT hard real-time kiểu nanosecond/microsecond. Vì đang dùng Spring/Kafka/Postgres nên cần đo p50/p95/p99 latency rõ ràng trước khi cam kết SLA.

Về “kết nối nhiều lệnh và portfolio”: phần này có nền tảng rồi. Order có quan hệ parent/child/root order, nên có thể gom nhiều child orders dưới một parent strategy order. Portfolio service cũng quản lý trạng thái portfolio, balance, risk seed, snapshot. Mục tiêu tiếp theo là gắn chặt hơn order, execution, strategy và portfolio bằng risk-service/strategy-engine để nhiều lệnh có thể được kiểm soát theo portfolio/account/desk một cách rõ ràng hơn.

Nói ngắn gọn: có thể hỗ trợ, đặc biệt cho seconds-level algorithmic trading và portfolio-aware execution. Nhưng nếu muốn production-grade thì cần hoàn thiện thêm phần latency dashboard, risk engine, strategy runtime, backtest/replay và performance baseline. Hiện tại mình đang đi theo hướng đó.
Nhấp để mở rộng...
cho em hỏi bao nhiêu năm kinh nghiệm mới làm được hệ thống cỡ này ạ ?
 
Violet_7 đã nói:
Vl, ông bảo con chatgpt reply à :shame: .
Anyway, ông nên tự benchmark hệ thống đc bao nhiêu tps trc khi nói siêu tốc.
Nhấp để mở rộng...
Haha đúng, câu trước nghe hơi “AI trả lời hộ” thật 😅

Ông nói đúng. Tui không nên dùng chữ “siêu tốc” khi chưa có benchmark rõ ràng. Hiện tại nên gọi nó là hệ thống electronic/algo trading đang được tối ưu dần thì đúng hơn.

Tui có benchmark local bước đầu rồi, trên máy dev thì vùng ổn định khoảng ~40 orders/sec, Nhưng đó chỉ là số local, chưa phải production benchmark.

Nên nhận xét của ông đúng: trước khi claim nhanh hay siêu tốc thì phải có p50/p95/p99, TPS, cấu hình môi trường, bottleneck rõ ràng. Tui đang bổ sung dashboard và benchmark để nói bằng số liệu thay vì nói cảm tính.
 
Sửa lần cuối:
javdev đã nói:
Haha đúng, câu trước nghe hơi “AI trả lời hộ” thật 😅

Ông nói đúng. Tui không nên dùng chữ “siêu tốc” khi chưa có benchmark rõ ràng. Hiện tại nên gọi nó là hệ thống electronic/algo trading đang được tối ưu dần thì đúng hơn.

Tui có benchmark local bước đầu rồi, trên máy dev thì vùng ổn định khoảng ~40 orders/sec, lên khoảng 48 orders/sec là latency bắt đầu nhảy mạnh, p50 lên vài giây. Nhưng đó chỉ là số local, chưa phải production benchmark.

Nên nhận xét của ông đúng: trước khi claim nhanh hay siêu tốc thì phải có p50/p95/p99, TPS, cấu hình môi trường, bottleneck rõ ràng. Tui đang bổ sung dashboard và benchmark để nói bằng số liệu thay vì nói cảm tính.
Nhấp để mở rộng...
Mé vẫn dùng chatgpt reply lại
 
Ae cẩn thận, mấy hôm nữa thread này lại có quảng cáo bán khóa học đấy :shame:
 
Bạn phải đăng nhập hoặc đăng ký để trả lời tại đây.

Chủ đề tương tự

Ước mộng IT
thảo luận Ghi chú theo định dạng Plaintext: Markdown Text Org-mode...Tổng hợp các ứng dụng, chia sẻ trải nghiệm
3 4 5
Trả lời
90
Lượt xem
18K
Nightcall
Nightcall
duykhanh471
thảo luận Nhật kí tự học lập trình Rust - phát triển ứng dụng Desktop (Both CLI + GUI)
6 7 8
Trả lời
142
Lượt xem
27K
emlameo4`
emlameo4`
hungdt138
tuyển dụng Chứng khoán DSC Tuyển Backend Developer (upto 35M)
Trả lời
7
Lượt xem
2K
Phap Nguyen
P
buonnguqua10
kiến thức [2023]Tổng hợp các khóa học lập trình free và hay trên Youtube bằng tiếng Việt
14 15 16
Trả lời
315
Lượt xem
110K
buonnguqua03
buonnguqua03
buonnguqua
  • Đã khóa
kiến thức Tổng hợp các khóa học lập trình free và hay trên Youtube (tiếng Việt hết nhé các fen, tiếng mẹ đẻ nên rất dễ hiểu)
24 25 26
Trả lời
510
Lượt xem
194K
Vipluckystar
Vipluckystar

Thống kê chủ đề

Ngày tạo
javdev,
Người trả lời cuối
javdev,
Trả lời
48
Lượt xem
3.957

Chia sẻ trang này

Quay lại
Lên đầu trang