DAPR - mikroserwisy skrojone na miarę część 1

Jednym z podejść, które zdobywa coraz większą popularność są mikroserwisy. Jednak każda architektura potrzebuje narzędzi by można było ją zrealizować. Odpowiedzią na tak sformułowane potrzeby jest DAPR.

Czym jest DAPR ?

DAPR, czyli Distributed Application Runtime, to open-source'owe narzędzie stworzone z myślą o ułatwieniu tworzenia aplikacji rozproszonych w architekturze mikroserwisowej. DAPR jako projekt został zainicjowany przez Microsoft w 2019 roku. Jest nadal przez niego rozwijany w ramach projektu wolnego oprogramowania. Kodów źródłowych dla tego projektu może odszukać na GitHub (w chwili obecnej w wersji 1.11) pod adresem https://github.com/dapr

Dla jakich języków programowania?

DAPR posiada wsparcie (w postaci SDK) dla takich języków jak:

• .NET
• Java (oraz języki oparte na JVM np. Kotlin)
• Python
• Go
• Javascript
• C++
• Rust

W szczególności jakie funkcjonalności są wspierane w danym SDK odsyłam do dokumentacji DAPR https://docs.dapr.io/developing-applications/sdks/

Gdzie możemy je uruchamiać?

 DAPR obsługuje konkretne środowiska uruchomieniowe:

• Lokalne do celów developerskich przy użyciu Dockera
• Klaster Kubernetesa

Główne części składowe:

Dla DAPR możemy wyróżnić następujące części składowe:

• Service invocation
• State management
• Publish and subscribe
• Bindings
  • Input
  • Output

• Actors
• Observability
• Secrets
• Configuration
• Distributed lock
• Workflow
• Cryptography

W naszej serii wpisów o DAPR skupimy się tylko na kilku elementach składowych tego frameworka by na końcu pokazać konkretne ich użycie w działającej aplikacji.

Ogólny schemat działania

DAPR sidecar – każda aplikacja wdrażana za pomocą DAPR na Kubernetes otrzymuje swoją dodatkową usługę, która automatycznie jest wdrażana przez framework na tym samym podzie co aplikacja. Jest to łącznik aplikacji z resztą innych appek w tym środowisku. Komunikacja między aplikacjami w klastrze nie odbywa się bezpośrednio, ale za pomocą usług serwowanych przez sidecar.

Service invocation

W przypadku, gdy Service A próbuje dokonać komunikacji z Service B na samym początku dokonuje komunikacji ze swoim sidecarem. Przekazuje nazwę serwisu z którym chce dokonać połączenia. Sidecar wykonuje procedurę rozpoznania nazwy (Name resolution) i mając komplet informacji, gdzie dany Service B się znajduję dokonuje połączenia z jego sidecarem. Tak zestawione połączenie miedzy sidecarami jest zabezpieczone na poziomie komunikacji za pomocą połączenia szyfrowanego. Następnie sidecar Service B zestawia połączenie z Service B i budowany jest kanał połączeniowy między Service A a Service B. Komunikacja zwrotna odbywa się za pomocą tak zbudowanego kanału.

State management

Istnieją przypadki, gdy mikroserwis musi zapisać swój stan np. gdy musi współdzielić swój stan między swoim wieloma instancjami. DAPR daje specjalną funkcjonalność by obsłużyć takie przypadki. Serwis komunikując się ze swoim sidecarem może zapisać swój stan. Jako backend dla takiej usługi może być użyte wiele silników baz danych. Są to między innymi:

• Baza in memory (w przypadku środowiska developerskiego)
• Redis
• MySQL
• Oracle
• Bazy chmurowe :
  • AWS DynamoDB
  • GCP Firestore
  • Azure Cosmo DB

Pełna lista wspieranych silników baz danych znajduje się w dokumentacji  https://docs.dapr.io/reference/components-reference/supported-state-stores/

Publish and subscribe

Komunikacja między mikroserwisami może wymagać także przesyłania odpowiednich komunikatów. Tak jak w wypadku schematu powyżej Service A generuje komunikat, który powinny subskrybować Service B oraz Service C. DAPR w tym wypadku daje specjalną funkcjonalność – za pomocą sidecarów możemy wysyłać komunikaty oraz je subskrybować. Jako backend dla tej usługi możemy używać wielu rozwiązań kolejkowych takich jak:

• Redis streams
• In memory (w przypadku środowiska developerskiego)
• Apacha Kafka
• Rabbit MQ
• Rozwiązania chmurowe
  • AWS SNS/SQS
  • GCP Pub/Sub
  • Azure Service Bus

Pełna lista wspieranych systemów kolejkowych znajduje się w dokumentacji https://docs.dapr.io/reference/components-reference/supported-pubsub/

Secrets

Architektura mikroserwisowa wymaga także w niektórych wypadkach dzielenia się wspólnymi sekretami. Mogą to być np. dane logowania do baz danych , dane autoryzacyjne do serwisów itp.

W celu zapewnienia takiej funkcjonalności otrzymujemy ją jako usługę na sidecar. Jako backend dla tej usługi możemy używać wielu rozwiązań do magazynowania danych o sekretach takich jak:

• HashiCorp Valut
• Kubernetes Secret
• Local enivroment variables (w przypadku środowiska developerskiego)
• Rozwiązań chmurowych
  • AWS Secrets Manager
  • GCP Secret Manager
  • Azure Key Vault

Pełna lista wspieranych systemów magazynowania sekretów znajduje się w dokumentacji:

https://docs.dapr.io/reference/components-reference/supported-secret-stores/

Bindings

Są to usługi do komunikacji ze środowiskami poza klastrem. Dzielimy je na dwie główe grupy:

• Output (do komunikowania się z systemami zewnętrznymi)
• Inputs (do przyjmowania danych z systemów zewnętrznych)

W szczególności może to być binding związany z komunikacją z zewnętrznym serwerem SMTP jak na poniższym schemacie:

Za pomocą usługi dostępnej na sidecar możemy wysyłać maile.

Pełna lista wspieranych bindings zarówno rodzaju input jaki i output znajdziemy w dokumentacji

https://docs.dapr.io/reference/components-reference/supported-bindings/

Na zakończenie zastanówmy jaki jest sens istnienia DAPR. Wiele z tych usług można napisać samodzielnie i to bez trudu. Kluczem w tym wypadku jest wspólne API nie zależnie od tego jakiego rozwiązania  użyjemy w backendzie . Z naszymi usługami wystawionymi przez DAPR będziemy zawsze komunikować się za pomocą spójnego interfejsu. Ponadto zmiana obsługiwanego backendu to tylko kwestia konfiguracyjna samego DAPR.

W następnej części pokażemy przykład rozwiązania, która używa przedstawionych tu składowych DAPR. Opiszemy sposób konfiguracji takiego rozwiązania oraz pokażemy kod źródłowych takich usług wraz ze sposobem ich integracji z DAPR.