Infrastruktura

Infrastruktura Bota transakcyjnego ByNinja została zaprojektowana do długotrwałej, autonomicznej pracy w niestabilnych, rzeczywistych środowiskach. Systemy handlu kryptowalutami muszą działać 24/7, odzyskiwać sprawność po nieoczekiwanych awariach i minimalizować przestoje bez konieczności ręcznej interwencji.

Aby to osiągnąć, infrastruktura zawiera:

  • Pętle wykonawcze Watchdog
  • Automatyczne odzyskiwanie po awarii
  • Orkiestrację restartów procesów
  • Obsługę łagodnego zamykania
  • Trwałe środowisko wykonawcze
  • Izolowane wykonywanie modułów

Cała architektura jest zbudowana wokół tolerancji błędów i ciągłości operacyjnej.


Skrypty Watchdog

Główna warstwa wykonawcza systemu jest kontrolowana przez dedykowany skrypt uruchamiający Watchdog:

Code
./run.sh trading
./run.sh telegram

Skrypt Watchdog działa jako lekki nadzorca procesów odpowiedzialny za:

  • Walidację środowiska
  • Aktywację wirtualnego środowiska
  • Uruchamianie modułów
  • Wykrywanie awarii
  • Automatyczne ponowne uruchamianie

To podejście pozwala uniknąć konieczności używania zewnętrznych menedżerów procesów podczas programowania lub lekkich wdrożeń, zapewniając jednocześnie odporność na poziomie produkcyjnym.


Walidacja środowiska

Przed uruchomieniem dowolnego modułu skrypt sprawdza:

  • Argumenty wejściowe
  • Istnienie wirtualnego środowiska
  • Konfigurację środowiska wykonawczego

Przykład:

Code
if [[ "$MODULE" != "trading" && "$MODULE" != "telegram" ]]; then
    echo "Invalid argument"
    exit 1
fi

Skrypt zapewnia również, że wirtualne środowisko Pythona istnieje:

Code
if [ ! -f "$VENV_PATH" ]; then
    echo "Virtual environment not found"
    exit 1
fi

Zapobiega to przypadkowemu uruchomieniu z uszkodzonymi zależnościami lub nieprawidłowymi parametrami wykonania.


Izolowane środowisko wykonawcze

Infrastruktura aktywuje dedykowane wirtualne środowisko Pythona przed wykonaniem:

Code
source "./env/bin/activate"

Gwarantuje to:

  • Izolację zależności
  • Stabilne wersje pakietów
  • Powtarzalne zachowanie środowiska wykonawczego
  • Czystą separację wdrożeń

Program uruchamiający również jawnie definiuje PYTHONPATH:

Code
PYTHONPATH="$(pwd)/src" python3 -c "$CMD"

Zapewnia to niezawodne importy, niezależnie od bieżącego kontekstu powłoki lub lokalizacji wdrożenia.


System automatycznego restartu

Jedną z najważniejszych cech infrastruktury jest automatyczna pętla restartu.

Program uruchamiający nieustannie monitoruje proces bota:

Code
while true; do
    PYTHONPATH="$(pwd)/src" python3 -c "$CMD"
done

Jeśli proces zakończy się nieoczekiwanie, Watchdog natychmiast wykrywa awarię i automatycznie ponownie uruchamia moduł.

Logika wykrywania awarii:

Code
EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
    echo "[CRASH] Restarting..."
    sleep $RESTART_DELAY
fi

Tworzy to samonaprawiający się model wykonawczy zdolny do odzyskiwania po:

  • Nieoczekiwanych wyjątkach
  • Awariach sieci
  • Przestojach API
  • Zakleszczeniach
  • Tymczasowej niestabilności systemu
  • Zewnętrznym zakończeniu procesu

Kontrolowane opóźnienie restartu

Infrastruktura celowo dodaje czas ochłody restartu:

Code
RESTART_DELAY=3

Zapobiega to:

  • Nieskończonym pętlom szybkiego restartu
  • Skokom CPU podczas powtarzających się awarii
  • Nadmiernemu obciążeniu API
  • Zalewaniu logów

Krótkie opóźnienie daje systemom zewnętrznym czas na odzyskanie sprawności przed ponowną próbą wykonania.


Architektura oddzielnych usług

System dzieli infrastrukturę na dwie niezależnie restartowalne usługi:

UsługaOdpowiedzialność
Moduł transakcyjnySilnik transakcyjny i realizacja strategii
Moduł TelegramZdalne sterowanie i powiadomienia

Ta izolacja zapewnia kilka korzyści:

  • Jeden podsystem może zawieść niezależnie
  • Monitorowanie Telegram może pozostać online podczas awarii transakcyjnych
  • Handel może kontynuować, nawet jeśli Telegram zawiedzie
  • Łatwiejsze debugowanie i konserwacja

Moduły komunikują się przez wewnętrzną warstwę TCP, a nie przez bezpośrednie sprzężenie.


Obsługa łagodnego zamykania

Infrastruktura obsługuje kontrolowane zachowanie przy zamykaniu za pomocą obsługi sygnałów.

Przykład:

Code
signal.signal(signal.SIGINT, signal_handler)

Podczas zamykania:

  • Handel zatrzymuje się bezpiecznie
  • Trwałość zapisuje dane na dysk
  • Połączenia TCP zamykają się czysto
  • Wątki kończą się łagodnie

Przykładowy przepływ zamykania:

Code
🛑 Shutdown signal received...
💾 Forcing save to disk...
✅ PersistentMap stopped

Jest to krytyczne w systemach transakcyjnych, ponieważ nieprawidłowe zamknięcie może w przeciwnym razie prowadzić do:

  • Utraty stanu pozycji
  • Uszkodzonej trwałości
  • Niespójnych danych odzyskiwania
  • Niezamkniętych zleceń

Filozofia odzyskiwania po awarii

Infrastruktura kieruje się prostą, ale potężną zasadą:

Code
Crash → Detect → Restart → Recover State → Continue Trading

Bot został zaprojektowany przy założeniu, że awarie są nieuniknione w długo działających, rozproszonych systemach.

Zamiast próbować zapobiegać każdej możliwej awarii, architektura koncentruje się na:

  • Szybkim wykrywaniu
  • Niezawodnym restarcie
  • Odzyskiwaniu stanu trwałego
  • Ciągłości operacyjnej

To drastycznie zwiększa długoterminową niezawodność.


Integracja z warstwą trwałości

Infrastruktura ściśle współpracuje z podsystemem trwałości.

Przed zamknięciem lub ponownym uruchomieniem:

  • Stan wykonawczy jest zapisywany
  • Pozycje są utrwalane
  • Konfiguracja pozostaje nienaruszona
  • Metadane odzyskiwania są przechowywane

Po restarcie:

  • Stan jest automatycznie przeładowywany
  • Handel jest bezpiecznie wznawiany
  • Istniejące pozycje są przywracane
  • Łączność Telegrama powraca automatycznie

Tworzy to odporny potok odzyskiwania nawet po nieoczekiwanych awariach lub restartach serwera.


Monitorowanie infrastruktury przez Telegram

Podsystem Telegram działa również jako lekka warstwa monitorowania operacyjnego.

Zdarzenia infrastruktury są przesyłane bezpośrednio do Telegrama:

Code
[CRASH] Module trading exited with code 1
Restarting in 3 seconds...

Daje to operatorom natychmiastowy wgląd w:

  • Awarie
  • Restarty
  • Zamknięcia
  • Zdarzenia odzyskiwania
  • Problemy z łącznością TCP

Efektem jest zdalnie obserwowalna infrastruktura bez konieczności stosowania złożonych pulpitów monitorujących.


Projekt niezawodności zorientowany na produkcję

Infrastruktura ByNinja łączy kilka koncepcji operacyjnych klasy produkcyjnej:

  • Pętle wykonawcze Watchdog
  • Automatyczne odzyskiwanie po awarii
  • Obsługę łagodnego zamykania
  • Trwały stan wykonawczy
  • Izolację usług
  • Sam naprawiające się zachowanie restartu
  • Zdalne monitorowanie przez Telegram
  • Niezależne odzyskiwanie podsystemów

Razem te komponenty tworzą infrastrukturę zdolną do wspierania ciągłych, autonomicznych operacji handlowych przy minimalnym nadzorze ręcznym.