Rozwój mikroserwisów w Cursor
Twój monolit właśnie uderzył w ścianę. Moduł przetwarzania zamówień zajmuje 45 sekund do wdrożenia, bo dzieli bazę kodu z serwisem użytkownika, trackerem inwentarza i systemem powiadomień. Bug w renderowaniu emaili crashuje cały przepływ checkout. Twój zespół ośmiu inżynierów ciągle depce sobie nawzajem po palcach w tym samym repozytorium. Zarząd chce mikroserwisów. Musisz rozbić działający system na niezależnie wdrażalne serwisy — bez utraty jednej transakcji.
Co wyniesiemy
Dział zatytułowany „Co wyniesiemy”- Konfigurację reguł Cursor, która utrzymuje AI świadome kontraktów między serwisami
- Przepływ pracy do generowania nowych serwisów ze spójną strukturą, współdzielonymi typami i konfiguracjami Docker
- Prompty do kopiowania i wklejania dla projektowania kontraktu API, tworzenia szkieletu serwisu i komunikacji między serwisami
- Strategię zarządzania multi-root workspaces w Cursor, aby tryb Agent rozumiał cały system rozproszony
- Techniki debugowania przepływów żądań obejmujących wiele serwisów
Konfiguracja Cursor dla mikroserwisów
Dział zatytułowany „Konfiguracja Cursor dla mikroserwisów”Największym wyzwaniem w rozwoju mikroserwisów ze wsparciem AI jest kontekst. Cursor musi rozumieć, że twój system to nie jeden projekt, ale konstelacja serwisów, które ze sobą rozmawiają. Multi-root workspaces są fundamentem.
Otwórz wszystkie katalogi serwisów w jednym oknie Cursor używając File > Add Folder to Workspace. Jeśli masz orders-service/, users-service/, inventory-service/ i api-gateway/, dodaj je wszystkie. Cursor indeksuje każdy root, więc tryb Agent może przeszukiwać między serwisami, gdy pytasz o przekrojowe zagadnienia.
Następnie utwórz reguły projektu, które kodują twoją topologię serwisów. To jest najważniejsza rzecz, jaką możesz zrobić dla pracy z mikroserwisami w Cursor.
# Architektura mikroserwisów
## Topologia serwisów- api-gateway (Node.js/Express): Trasowanie zewnętrznych żądań, rate limiting, auth- orders-service (Node.js/Express): CRUD zamówień, orkiestracja płatności- users-service (Python/FastAPI): Konta użytkowników, profile, tokeny auth- inventory-service (Go): Zarządzanie magazynem, alokacja warehouse- notification-service (Node.js): Email, SMS, push przez konsumentów eventów
## Wzorce komunikacji- Synchroniczna: REST między gateway i serwisami, gRPC między orders i inventory- Asynchroniczna: RabbitMQ dla eventów (order.created, payment.completed, stock.reserved)
## Współdzielone konwencje- Wszystkie serwisy eksponują endpointy /health i /ready- Wszystkie serwisy używają structured JSON logging z correlation IDs- Wersjonowanie API przez ścieżkę URL (/v1/, /v2/)- Baza danych per serwis: żadnych współdzielonych baz danychZ tym zestawem reguł zawsze stosowanym, każdy prompt, który wysyłasz w trybie Agent, będzie nosić twoją architekturę jako kontekst. AI przestaje sugerować współdzielone zapytania do bazy danych i zaczyna myśleć w kategoriach wywołań API i eventów.
Tworzenie szkieletu nowego serwisu
Dział zatytułowany „Tworzenie szkieletu nowego serwisu”Gdy potrzebujesz nowego serwisu, rozpoczynanie od zera jest wolne. Rozpoczynanie od generycznego szablonu jest niebezpieczne, bo przegapia konwencje twojego zespołu. Sweet spot to mieć Cursor generujący serwis, który pasuje do twoich istniejących wzorców.
Kluczową techniką tutaj jest odwoływanie się do istniejącego serwisu za pomocą symboli @. Wskazując Agentowi orders-service/src/app.ts, dajesz mu konkretny przykład twoich wzorców zamiast polegać na generycznych konwencjach. Wygenerowany serwis będzie używać twojego middleware obsługi błędów, twojego formatu logowania, twojej implementacji health check — nie jakiegoś generycznego boilerplate.
Po generacji starannie przejrzyj diff. Tryb Agent pokazuje ci każdy plik, który tworzy. Zwróć uwagę na:
- Czy nazwy zmiennych środowiskowych podążają za twoją konwencją nazewniczą
- Czy Dockerfile pasuje do twojego bazowego obrazu i etapów budowy
- Czy nazwy eventów podążają za twoim wzorcem nazewnictwa eventów domeny
Projektowanie kontraktów API najpierw
Dział zatytułowany „Projektowanie kontraktów API najpierw”W mikroserwisach kontrakt między serwisami jest ważniejszy niż implementacja za nim. Cursor błyszczy w rozwoju contract-first, bo możesz generować specyfikacje OpenAPI, a potem implementować przeciwko nim.
Gdy masz specyfikację, możesz użyć jej jako kontekstu dla implementacji:
@payments-service/docs/openapi.yml
Zaimplementuj handlery route dla payments-service, które dokładnie pasują do tej specyfikacji OpenAPI. Użyj tego samego wzorca middleware walidacji jak @orders-service/src/routes/orders.ts. Dla integracji Stripe użyj pakietu npm stripe z weryfikacją sygnatury webhook.To dwuetapowe podejście — najpierw specyfikacja, potem implementacja przeciwko specyfikacji — zapobiega wymyślaniu własnej powierzchni API przez AI. Specyfikacja staje się współdzielonym kontraktem, na którym mogą polegać zarówno zespół implementujący, jak i zespoły konsumujące.
Zarządzanie komunikacją między serwisami
Dział zatytułowany „Zarządzanie komunikacją między serwisami”Najtrudniejsza część mikroserwisów to sprawienie, by serwisy niezawodnie ze sobą rozmawiały. Cursor Agent może pomóc ci zaimplementować zarówno wzorce synchroniczne, jak i asynchroniczne, ale musisz pokierować go ku odpowiedniemu wzorcowi dla każdej interakcji.
Komunikacja synchroniczna
Dział zatytułowany „Komunikacja synchroniczna”Dla wzorców request-response między API gateway i serwisami backend:
// W trybie Agent odwołaj się do obu serwisów:// @api-gateway/src/routes/checkout.ts @orders-service/src/routes/orders.ts
"Endpoint checkout w API gateway musi:1. Wywołać users-service, aby zwalidować token auth i uzyskać customer_id2. Wywołać inventory-service, aby sprawdzić dostępność zapasów dla wszystkich przedmiotów3. Wywołać orders-service, aby utworzyć zamówienie4. Wywołać payments-service, aby zainicjować płatność
Zaimplementuj to z właściwą obsługą błędów:- Jeśli sprawdzenie inwentarza zawiedzie, zwróć 409 z niedostępnymi przedmiotami- Jeśli tworzenie zamówienia zawiedzie, płatność nie powinna być inicjowana- Uwzględnij wzorzec circuit breaker dla każdego wywołania downstream- Przekazuj correlation ID przez wszystkie żądania przez nagłówek x-correlation-id- Ustaw 5-sekundowy timeout na każdym wywołaniu downstream"Komunikacja asynchroniczna
Dział zatytułowany „Komunikacja asynchroniczna”Dla wzorców event-driven AI musi rozumieć twoją konfigurację brokera wiadomości:
// @orders-service/src/events/publisher.ts @notification-service/src/events/consumer.ts
"Utwórz konsumenta eventów w payments-service, który nasłuchuje eventów 'order.created'z RabbitMQ. Po otrzymaniu powinien:1. Wyodrębnić order_id, customer_id i total_amount z payload eventu2. Utworzyć Stripe PaymentIntent3. Opublikować event 'payment.initiated' z payment_intent_id4. Po potwierdzeniu webhook Stripe opublikować 'payment.completed' lub 'payment.failed'
Podążaj za tym samym wzorcem konsumenta używanym w notification-service, włącznie z:- Kolejką dead letter dla nieudanego przetwarzania- Sprawdzeniem idempotentności używając event_id- Structured logging z correlation_id z metadanych eventu"Debugowanie między serwisami
Dział zatytułowany „Debugowanie między serwisami”Gdy żądanie zawodzi i dotyka czterech serwisów, znalezienie pierwotnej przyczyny jest bolesne. Tryb Ask Cursor jest zaskakująco potężny tutaj, bo możesz podać mu logi z wielu serwisów i poprosić o korelację.
Zacznij od zebrania logów przefiltrowanych przez correlation ID:
Mam logi z trzech serwisów dla correlation ID "abc-123-def":
API Gateway:[2026-02-08T10:15:32Z] INFO gateway: Received POST /checkout, correlation_id=abc-123-def[2026-02-08T10:15:32Z] INFO gateway: Calling inventory-service, correlation_id=abc-123-def[2026-02-08T10:15:33Z] INFO gateway: inventory-service responded 200, correlation_id=abc-123-def[2026-02-08T10:15:33Z] INFO gateway: Calling orders-service, correlation_id=abc-123-def[2026-02-08T10:15:38Z] ERROR gateway: orders-service timeout after 5000ms, correlation_id=abc-123-def
Orders Service:[2026-02-08T10:15:33Z] INFO orders: Received POST /v1/orders, correlation_id=abc-123-def[2026-02-08T10:15:33Z] INFO orders: Validating order items[2026-02-08T10:15:33Z] INFO orders: Acquiring database lock for customer cust_456[2026-02-08T10:15:38Z] ERROR orders: Lock acquisition timeout after 5000ms
Przeanalizuj te logi. Jaka jest pierwotna przyczyna? Co powinienem zbadać dalej?Tryb Ask może korelować timestampy, identyfikować wąskie gardło (rywalizacja o lock bazy danych w orders-service) i sugerować ścieżki dochodzenia — wszystko bez modyfikowania jakichkolwiek plików.
Kiedy to się zepsuje
Dział zatytułowany „Kiedy to się zepsuje”Agent generuje współdzielone zapytanie do bazy danych między serwisami. To się dzieje, gdy twoje reguły nie mówią wyraźnie “baza danych per serwis”. Naprawa to dodanie tego ograniczenia do twoich reguł projektu i bycie wyraźnym w promptach: “Ten serwis dostępuje tylko do swojej własnej bazy danych. Aby uzyskać dane użytkownika, wywołaj API users-service.”
AI tworzy cykliczne zależności między serwisami. Jeśli payments-service wywołuje orders-service, który wywołuje payments-service, masz pętlę. Użyj najpierw trybu Ask, aby zmapować graf zależności: “Biorąc pod uwagę te interakcje serwisów, narysuj mi graf zależności i zidentyfikuj jakiekolwiek cykle.” Napraw cykle wprowadzając eventy lub nowy serwis koordynujący.
Wygenerowane konfiguracje Docker nie działają w twojej sieci compose. Agent często generuje samodzielne Dockerfile bez uwzględnienia twojego networkingu docker-compose. Zawsze odwołuj się do swojego istniejącego docker-compose.yml, gdy prosisz o nowe konfiguracje serwisów, i wyraźnie określ nazwę sieci.
Schematy eventów dryftują między publisherem i konsumentem. Gdy aktualizujesz schemat eventu w jednym serwisie, konsumenci łamią się cicho. Utwórz pakiet współdzielonych typów lub rejestr schematów i odwołuj się do niego w swoich promptach: “Użyj schematów eventów zdefiniowanych w @shared/events/schemas.ts.”