Rust dla firm — usługi wysokiej wydajności

Większość aplikacji biznesowych nie potrzebuje Rusta — dobrze zaprojektowany Laravel z kolejkami i cache wystarcza z zapasem. Są jednak miejsca, w których liczy się każda milisekunda i każde żądanie na sekundę: przyjmowanie dużego strumienia zdarzeń, obliczenia na dużych zbiorach danych, API odpytywane tysiące razy na minutę. Tam stawiamy osobne usługi w Rust.

Rust obok Laravela, nie zamiast niego

Nie przepisujemy całego systemu. Główna aplikacja zostaje w Laravelu, gdzie najszybciej dowozimy logikę biznesową, panele i integracje. Wąskie gardło wydzielamy do osobnej usługi w Rust, która komunikuje się z resztą przez API albo kolejkę (RabbitMQ, Kafka) i korzysta z tej samej bazy PostgreSQL.

Nasz stack w Rust

• Axum — asynchroniczny framework HTTP do budowy szybkich API.
• SeaORM — warstwa dostępu do danych w PostgreSQL.
• Asynchroniczne przetwarzanie — obsługa wielu jednoczesnych połączeń i strumieni zdarzeń przy niskim zużyciu pamięci.
• Docker i CI — usługi wdrażamy tak samo jak resztę systemu, z testami przy każdym pull requeście i monitoringiem na produkcji (zobacz DevOps i utrzymanie serwerów).

Co daje Rust w takich usługach

• Przewidywalne opóźnienia — brak garbage collectora oznacza brak nagłych przestojów pod obciążeniem.
• Niskie zużycie pamięci i CPU — ta sama praca na mniejszych serwerach, co przy stałym, dużym ruchu przekłada się na niższe rachunki za infrastrukturę.
• Bezpieczeństwo pamięci — kompilator wyłapuje całe klasy błędów, które w innych językach wychodzą dopiero na produkcji.
• Jeden plik wykonywalny — usługa w Rust to mały obraz Dockera bez zależności uruchomieniowych, łatwy do wdrożenia i skalowania.

Kiedy Rust ma sens

• endpoint lub proces, który po optymalizacji w PHP nadal jest wąskim gardłem,
• przetwarzanie dużych strumieni danych, np. z urządzeń IoT albo systemów zdarzeniowych,
• usługi, w których koszt serwerów rośnie szybciej niż ruch.

Jak wygląda wydzielenie usługi

Zaczynamy od pomiaru: które żądania albo procesy są wolne i dlaczego. Jeśli problem da się rozwiązać w istniejącej aplikacji, robimy to tam. Jeśli nie, projektujemy usługę z jasno określonym kontraktem (API albo format komunikatów w kolejce), piszemy ją w Rust, testujemy pod obciążeniem narzędziem k6 i wdrażamy obok istniejącego systemu. Ruch przełączamy stopniowo, więc w razie problemu można wrócić do poprzedniej ścieżki.

Zanim zaproponujemy Rust, sprawdzamy, czy problemu nie rozwiąże optymalizacja istniejącej aplikacji — indeksy, cache, kolejki albo Laravel Octane. Dopiero gdy to nie wystarcza, wydzielamy usługę. Więcej o stacku, w którym powstaje główna aplikacja, na stronie Laravel.