W 2017 roku wygraliśmy konkurs na rozwój rdzenia transakcyjnego działalności inwestycyjnej Alfa-Banku i rozpoczęliśmy pracę (na HighLoad++ 2018 raportem dotyczącym rdzenia działalności inwestycyjnej Alfa-Banku Władimir Drynkin, szef rdzenia transakcyjnego działalności inwestycyjnej Alfa Banku). System ten miał agregować dane transakcyjne z różnych źródeł w różnych formatach, sprowadzić je do jednolitej postaci, przechowywać i zapewniać do nich dostęp.
W procesie rozwoju system ewoluował i nabywał funkcjonalności, aż w pewnym momencie zdaliśmy sobie sprawę, że krystalizujemy coś znacznie więcej niż tylko oprogramowanie aplikacyjne tworzone do rozwiązywania ściśle określonego zakresu zadań: udało się system do budowy aplikacji rozproszonych z pamięcią trwałą. Zdobyte doświadczenie stało się podstawą nowego produktu - (TDG).
Chcę opowiedzieć o architekturze TDG i rozwiązaniach, do których doszliśmy w procesie rozwoju, przedstawić Państwu główne funkcjonalności i pokazać, w jaki sposób nasz produkt może stać się podstawą do budowy kompletnych rozwiązań.
Architektonicznie podzieliliśmy system na osobne części rola, z których każdy jest odpowiedzialny za rozwiązanie określonego zakresu problemów. Pojedyncza działająca instancja aplikacji implementuje jeden lub więcej typów ról. W klastrze może istnieć kilka ról tego samego typu:
Złącze
Connector odpowiada za komunikację ze światem zewnętrznym; jego zadaniem jest przyjęcie żądania, przeanalizowanie go i jeśli to się powiedzie, przesłanie danych do przetwarzania do procesora wejściowego. Obsługujemy formaty HTTP, SOAP, Kafka, FIX. Architektura umożliwia proste dodanie obsługi nowych formatów, a obsługa IBM MQ będzie już wkrótce dostępna. Jeśli analiza żądania nie powiodła się, łącznik zwróci błąd; w przeciwnym razie odpowie, że żądanie zostało przetworzone pomyślnie, nawet jeśli w trakcie jego dalszego przetwarzania wystąpił błąd. Zrobiono to specjalnie, aby pracować z systemami, które nie wiedzą, jak powtarzać żądania - lub wręcz przeciwnie, robią to zbyt uporczywie. Aby nie utracić danych, stosuje się kolejkę naprawczą: obiekt najpierw do niej trafia, a dopiero po pomyślnym przetworzeniu jest z niego usuwany. Administrator może otrzymywać powiadomienia o obiektach pozostających w kolejce naprawy i po wyeliminowaniu błędu oprogramowania lub awarii sprzętu spróbować ponownie.
Procesor wejściowy
Procesor wejściowy klasyfikuje otrzymane dane według charakterystycznych cech i wywołuje odpowiednie procesory. Handlery to kod Lua, który działa w piaskownicy, więc nie mogą mieć wpływu na funkcjonowanie systemu. Na tym etapie dane można sprowadzić do wymaganej postaci, a w razie potrzeby uruchomić dowolną liczbę zadań, które będą w stanie wdrożyć niezbędną logikę. Przykładowo w produkcie MDM (Master Data Management) zbudowanym na Tarantool Data Grid, dodając nowego użytkownika, aby nie spowalniać realizacji zgłoszenia, jako osobne zadanie uruchamiamy tworzenie złotego rekordu. Sandbox obsługuje żądania odczytu, zmiany i dodania danych, umożliwia wykonanie niektórych funkcji na wszystkich rolach typu przechowywania oraz agregację wyniku (mapowanie/redukcja).
Handlery można opisać w plikach:
sum.lua
local x, y = unpack(...)
return x + yA następnie zadeklarowany w konfiguracji:
functions:
sum: { __file: sum.lua }
Dlaczego Lua? Lua jest bardzo prostym językiem. Z naszego doświadczenia wynika, że już po kilku godzinach od poznania ludzie zaczynają pisać kod, który rozwiązuje ich problem. I są to nie tylko profesjonalni programiści, ale na przykład analitycy. Dodatkowo, dzięki kompilatorowi jit, Lua działa bardzo szybko.
Magazynowanie
Pamięć przechowuje trwałe dane. Przed zapisaniem dane są sprawdzane pod kątem schematu danych. Do opisu obwodu używamy formatu rozszerzonego . Przykład:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}Na podstawie tego opisu automatycznie generowany jest język DDL (Data Definition Language) dla systemu DBMS Tarantula i schemat dostępu do danych.
Obsługiwana jest asynchroniczna replikacja danych (w planach jest dodanie synchronicznej).
Procesor wyjściowy
Czasami konieczne jest powiadomienie odbiorców zewnętrznych o nadejściu nowych danych, w tym celu służy rola Procesora wyjściowego. Po zapisaniu dane można przekazać do odpowiedniego handlera (np. doprowadzić do wymaganej przez konsumenta postaci) – a następnie przekazać do konektora w celu wysłania. Wykorzystywana jest tu także kolejka naprawy: jeśli nikt nie zaakceptował obiektu, administrator może spróbować ponownie później.
skalowanie
Role złącza, procesora wejściowego i procesora wyjściowego są bezstanowe, co pozwala nam skalować system w poziomie poprzez proste dodawanie nowych instancji aplikacji z włączonym żądanym typem roli. Pamięć jest używana do skalowania poziomego do organizowania klastra przy użyciu wirtualnych zasobników. Po dodaniu nowego serwera część segmentów ze starych serwerów jest przenoszona w tle na nowy serwer; dzieje się to w sposób transparentny dla użytkowników i nie ma wpływu na działanie całego systemu.
Właściwości danych
Obiekty mogą być bardzo duże i zawierać inne obiekty. Zapewniamy atomowość dodawania i aktualizacji danych przechowując obiekt ze wszystkimi zależnościami w jednym wirtualnym zasobniku. Zapobiega to „rozproszeniu” obiektu na kilka serwerów fizycznych.
Obsługiwane jest wersjonowanie: każda aktualizacja obiektu tworzy nową wersję, a my zawsze możemy poświęcić czas i zobaczyć, jak wtedy wyglądał świat. W przypadku danych, które nie wymagają długiej historii, możemy ograniczyć liczbę wersji lub nawet przechowywać tylko jedną – najnowszą – czyli w zasadzie wyłączyć wersjonowanie dla określonego typu. Możesz także ograniczyć historię według czasu: na przykład usunąć wszystkie obiekty określonego typu starsze niż 1 rok. Obsługiwana jest także archiwizacja: możemy wyładować obiekty starsze niż podany czas, zwalniając miejsce w klastrze.
zadania
Wśród ciekawych funkcji warto zwrócić uwagę na możliwość uruchamiania zadań planowo, na żądanie użytkownika lub programowo z piaskownicy:
Tutaj widzimy inną rolę - biegacza. Ta rola jest bezstanowa i w razie potrzeby do klastra można dodać dodatkowe instancje aplikacji z tą rolą. Zadaniem biegacza jest wykonanie zadań. Jak wspomniano, możliwe jest generowanie nowych zadań z piaskownicy; są one zapisywane w kolejce w magazynie, a następnie wykonywane w programie runner. Ten typ zadania nazywa się Job. Mamy również typ zadania o nazwie Zadanie — są to zadania zdefiniowane przez użytkownika, które uruchamiają się zgodnie z harmonogramem (przy użyciu składni cron) lub na żądanie. Do uruchamiania i śledzenia takich zadań służy wygodny menedżer zadań. Aby ta funkcjonalność była dostępna, musisz włączyć rolę planisty; ta rola ma stan, więc nie podlega skalowaniu, co jednak nie jest wymagane; jednocześnie, podobnie jak wszystkie inne role, może mieć replikę, która zacznie działać, jeśli mistrz nagle odmówi.
Logger
Inna rola nazywa się rejestratorem. Gromadzi logi ze wszystkich członków klastra i zapewnia interfejs do przesyłania i przeglądania ich za pośrednictwem interfejsu internetowego.
Usługi
Warto wspomnieć, że system ułatwia tworzenie usług. W pliku konfiguracyjnym możesz określić, które żądania mają być wysyłane do napisanej przez użytkownika procedury obsługi działającej w piaskownicy. W tym module obsługi możesz na przykład uruchomić zapytanie analityczne i zwrócić wynik.
Usługa opisana jest w pliku konfiguracyjnym:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
API GraphQL jest generowane automatycznie i usługa staje się dostępna do wywołania:
query {
sum(x: 1, y: 2)
}
Spowoduje to wywołanie procedury obsługi sumco zwróci wynik:
3
Profilowanie zapytań i metryki
Aby zrozumieć działanie systemu i profilowanie żądań, wdrożyliśmy obsługę protokołu OpenTracing. System może na żądanie wysyłać informacje do narzędzi obsługujących ten protokół, np. Zipkin, co pozwoli zrozumieć, w jaki sposób żądanie zostało zrealizowane:
Naturalnie system udostępnia wewnętrzne metryki, które można zbierać za pomocą Prometheusa i wizualizować za pomocą Grafany.
Wdrożyć
Tarantool Data Grid można wdrożyć z pakietów RPM lub archiwum, korzystając z narzędzia z dystrybucji lub Ansible, istnieje również wsparcie dla Kubernetes ().
Aplikacja realizująca logikę biznesową (konfiguracja, handlery) ładowana jest do wdrożonego klastra Tarantool Data Grid w formie archiwum poprzez UI lub za pomocą skryptu poprzez udostępnione przez nas API.
Przykładowe zastosowania
Jakie aplikacje można tworzyć przy użyciu Tarantool Data Grid? W rzeczywistości większość zadań biznesowych jest w jakiś sposób związana z przetwarzaniem, przechowywaniem i dostępem do przepływu danych. Dlatego jeśli masz duże strumienie danych, które muszą być bezpiecznie przechowywane i dostępne, nasz produkt może zaoszczędzić dużo czasu na opracowywaniu i skupić się na logice biznesowej.
Na przykład chcemy zbierać informacje o rynku nieruchomości, aby w przyszłości mieć np. informacje o najlepszych ofertach. W takim przypadku wyróżnimy następujące zadania:
- Naszymi źródłami danych będą roboty zbierające informacje z otwartych źródeł. Możesz rozwiązać ten problem korzystając z gotowych rozwiązań lub pisząc kod w dowolnym języku.
- Następnie Tarantool Data Grid zaakceptuje i zapisze dane. Jeżeli format danych z różnych źródeł jest inny, to możesz napisać w Lua kod, który dokona konwersji do jednego formatu. Na etapie wstępnego przetwarzania będziesz mógł także np. filtrować zduplikowane oferty czy dodatkowo aktualizować w bazie informacje o agentach pracujących na rynku.
- Teraz masz już skalowalne rozwiązanie w klastrze, które można wypełnić danymi i dokonać selekcji danych. Następnie możesz zaimplementować nową funkcjonalność, np. napisać usługę, która będzie żądać danych i podawać dziennie najkorzystniejszą ofertę - będzie to wymagało kilku linijek w pliku konfiguracyjnym i odrobiny kodu Lua.
Co dalej?
Naszym priorytetem jest poprawa łatwości programowania przy użyciu . Na przykład jest to środowisko IDE obsługujące profilowanie i debugowanie programów obsługi działających w piaskownicy.
Dużą wagę przywiązujemy także do kwestii bezpieczeństwa. W tej chwili jesteśmy w trakcie certyfikacji przez FSTEC Rosji, aby potwierdzić wysoki poziom bezpieczeństwa i spełnić wymagania dotyczące certyfikacji oprogramowania stosowanego w systemach informatycznych danych osobowych i systemach informacyjnych rządu.
Źródło: www.habr.com