--- title: "Microsoft Orleans 10: kiedy wybrać virtual actors" url: "https://majchrzycki.com/blog/microsoft-orleans-scalable-distributed-applications" description: "Kiedy Orleans 10 upraszcza system stanowy, a kiedy dokłada złożoność: grains, silosy, trwałość, klaster i awarie." --- # Microsoft Orleans 10: kiedy wybrać virtual actors 1 czerwca 2024· Aktualizacja: 27 września 2026·6 min czytania·Krzysztof Majchrzycki Temat: [AI SDLC](https://majchrzycki.com/blog/filar/ai-sdlc) Microsoft Orleans upraszcza budowę systemu, gdy domena składa się z wielu niezależnych, adresowalnych jednostek stanu: kont, sesji, urządzeń, zamówień albo graczy. Nie jest jednak ogólnym zamiennikiem bazy danych, kolejki ani zwykłego API. Model virtual actor ukrywa fizyczną lokalizację aktywacji, lecz nie usuwa opóźnień sieci, awarii, trwałości, wersjonowania i obserwowalności. Decyzja o Orleans powinna zaczynać się od granic domeny oraz testu scenariuszy awarii. ## Co Orleans 10 rzeczywiście upraszcza [Przegląd Orleans 10](https://learn.microsoft.com/en-us/dotnet/orleans/overview) opisuje framework do budowy rozproszonych aplikacji .NET, który może działać od pojedynczego serwera po klaster. Aplikacja definiuje grains, czyli logicznie adresowalne jednostki zachowania i stanu. Silos hostuje aktywacje grainów, a grupa silosów tworzy klaster. Kod odwołuje się do logicznej tożsamości grainu, podczas gdy runtime zajmuje się aktywacją i trasowaniem wywołań. [Dokumentacja korzyści Orleans](https://learn.microsoft.com/en-us/dotnet/orleans/benefits) wyjaśnia między innymi transparentną aktywację, location transparency i wykonywanie grainu w izolowanym modelu. Ułatwia to pracę z wieloma jednostkami, które można identyfikować stabilnym kluczem. Nie oznacza jednak, że każda klasa domenowa powinna stać się grainem. Dobry kandydat Dlaczego pasuje Sygnał ostrzegawczy Konto lub koszyk Stabilny identyfikator, niezależny stan Wymagane częste transakcje przez tysiące kont Urządzenie IoT Zdarzenia kierowane do konkretnego urządzenia Cała telemetria ma być trzymana w pamięci grainu Sesja gry Sekwencyjne polecenia i własny cykl życia Operacje blokujące w każdej wiadomości Workflow jednostki Naturalna odpowiedzialność i przypomnienia Brak reguł idempotencji i kompensacji Agregat zamówienia Operacje wokół jednego klucza Raportowanie przekrojowe wykonywane przez wywołanie wszystkich grainów Najważniejsze pytanie brzmi: czy żądania można kierować do naturalnej tożsamości, która posiada zachowanie i niewielki, spójny zakres stanu? Jeśli tak, Orleans może uprościć routing i współbieżność. Jeśli większość operacji to dowolne zapytania analityczne, masowe joiny lub transakcje obejmujące wiele agregatów, potrzebujesz innych mechanizmów jako głównej warstwy. ## Grain nie jest rekordem ani procesem systemowym Grain ma interfejs z asynchronicznymi metodami i logiczny identyfikator. Referencja może istnieć bez aktywnego obiektu w pamięci. Runtime aktywuje grain, gdy jest potrzebny, i może go później dezaktywować. Aplikacja nie powinna opierać poprawności na założeniu, że konkretna aktywacja żyje bez końca. Izolowany model wykonywania ogranicza potrzebę blokad wewnątrz grainu, ale projektant nadal odpowiada za reentrancy, długie operacje, wywołania między grainami i skutki awarii. Zewnętrzne API może ponowić żądanie. Wiadomość może dotrzeć w sytuacji, w której poprzednia operacja wykonała część skutków. Dlatego polecenia biznesowe potrzebują identyfikatorów, idempotencji albo jawnej kompensacji. Pojęcie Co zapewnia Orleans Czego nadal nie zapewnia projektowi Tożsamość grainu Stabilny adres logiczny Poprawnej granicy domeny Aktywacja Tworzenie na żądanie Wiecznego procesu w pamięci Izolacja Kontrolowany model wykonywania grainu Globalnej transakcji całego systemu Trasowanie Odnalezienie aktywacji w klastrze Zerowego opóźnienia sieciowego Trwałość Integrację z providerem storage Automatycznego modelu wersjonowania danych Klaster Członkostwo i rozmieszczenie aktywacji Gotowego SLO, capacity planu i runbooka ## Trwałość jest operacją, nie właściwością magiczną [Dokumentacja grain persistence](https://learn.microsoft.com/en-us/dotnet/orleans/grains/grain-persistence/) pokazuje model providerów stanu. Grain może wczytywać i zapisywać stan przez skonfigurowany magazyn. Trzeba jednak zdecydować, kiedy zapis następuje, jak obsłużyć błąd, jak migrować schemat i co zrobić z efektem zewnętrznym wykonanym przed zapisem. Stan w pamięci grainu jest kopią roboczą, a nie samą trwałością. Dla krytycznej operacji zaprojektuj kolejność: walidacja, zmiana, zapis, publikacja zdarzenia albo wywołanie zewnętrzne. Każda kolejność ma inny tryb awarii. Jeśli publikacja nastąpi po zapisie, może nie nastąpić. Jeśli nastąpi przed zapisem, konsument może zobaczyć zdarzenie bez utrwalonego stanu. Rozważ outbox, idempotentnych konsumentów lub proces kompensacyjny. Nie przechowuj w grainie nieograniczonej historii tylko dlatego, że model jest wygodny. Duży stan zwiększa koszt aktywacji, serializacji i zapisu. Dokumentacja Orleans wskazuje, że naturalne grainy często odpowiadają niezależnym jednostkom takim jak użytkownik, konto albo zamówienie. Jeśli jeden grain staje się całym tenantem i obsługuje wszystkie jego operacje, może utworzyć gorący punkt. ## Katalog grainów i ważne ograniczenie wersji 10 [Dokumentacja grain directory](https://learn.microsoft.com/en-us/dotnet/orleans/host/grain-directory) opisuje mapowanie logicznej tożsamości na aktualną aktywację. Domyślny rozproszony katalog w klastrze jest samowystarczalny i według dokumentacji pozostaje rekomendowanym punktem startu. Dokumentacja ostrzega, że przy niestabilności klastra mogą sporadycznie powstać zduplikowane aktywacje. Orleans 10 udostępnia również silnie spójny katalog in cluster, który ma zapobiegać duplikatom aktywacji w czasie zmian klastra. W aktualnej dokumentacji funkcja jest oznaczona jako preview i może się zmienić. Nie buduj krytycznej gwarancji biznesowej na samym założeniu „jeden grain oznacza zawsze dokładnie jeden fizyczny obiekt”. Nawet przy pojedynczej aktywacji efekty zewnętrzne i ponowienia nadal wymagają projektu odpornego na duplikaty. ## Klaster, hosting i obserwowalność Lokalny quickstart używa localhost clustering i pamięci, ale produkcja wymaga providerów członkostwa oraz trwałości odpowiednich dla środowiska. Orleans działa tam, gdzie działa .NET, i nie jest usługą wyłącznie dla Azure. Dokumentacja wskazuje między innymi Kubernetes, Azure App Service i Azure Container Apps jako opcje wdrożenia. Decyzja operacyjna Pytanie Test obowiązkowy Członkostwo klastra Jak silosy odnajdują się i usuwają martwe wpisy? Awaria i powrót węzła Trwałość Jaki provider, partycjonowanie i limit? Błąd zapisu i throttling Placement Gdzie powstają gorące grainy? Nierówny rozkład kluczy Wdrożenie Jak współistnieją wersje kodu? Rolling upgrade z aktywnym ruchem Obserwowalność Czy widać wywołanie przez wiele grainów? Śledzenie korelacji i timeoutu Disaster recovery Co odtwarzasz: klaster czy dane? Odtworzenie storage oraz konfiguracji Mierz czas wywołań, timeouty, aktywacje, błędy storage, kolejki pracy i rozkład obciążenia. Log bez identyfikatora korelacji nie pokaże ścieżki przez wiele grainów. Nie zapisuj w logach pełnego stanu ani danych wrażliwych. Runbook powinien odróżniać błąd aplikacji, storage, członkostwa klastra i sieci. ## Orleans i aplikacje AI Virtual actors mogą reprezentować rozmowę, użytkownika, urządzenie albo długotrwały proces agenta. To nie czyni grainu modelem AI. Grain powinien zarządzać stanem i regułami domeny, a wywołanie modelu pozostaje zewnętrzną, zawodną operacją z timeoutem, limitem i kontrolą danych. **Przykład syntetyczny.** Grain rozmowy przechowuje identyfikatory zatwierdzonych wiadomości i stan workflow, lecz dokumenty źródłowe pozostają w kontrolowanym repozytorium. Żądanie generacji ma własny identyfikator. Wynik modelu jest szkicem, a nie decyzją. Po timeoutcie ponowienie sprawdza identyfikator operacji, aby nie uruchomić tego samego narzędzia dwa razy. Człowiek zatwierdza działanie mające skutek poza systemem. Nie trzymaj długiego wywołania modelu w sekcji, która blokuje cały postęp danego grainu, jeśli pozostałe polecenia muszą być obsługiwane. Rozważ rozdzielenie orkiestracji, callback, strumień lub osobną jednostkę pracy. Kontroluj liczbę równoległych wywołań i koszt. Orleans ułatwia adresowanie wielu jednostek, więc bez limitów równie łatwo zwielokrotnić obciążenie zewnętrznej usługi. ## Kiedy wybrać prostszą architekturę Zwykłe ASP.NET Core API z bazą danych i kolejką jest często lepsze, gdy domena ma niewiele jednostek, obciążenie jest umiarkowane, a zespół nie potrzebuje długotrwałych stanowych interakcji. Prostota wdrożenia i diagnostyki jest realną wartością. Orleans dodaje runtime, członkostwo, semantykę grainów, providery oraz nowe scenariusze awarii. Wykonaj porównawczy prototyp. Ten sam przypadek zaimplementuj jako usługę bezstanową z bazą oraz jako grain. Zmierz złożoność kodu, czas reakcji, zachowanie po ponowieniu, awarii węzła i błędzie storage. Użyj nierównego rozkładu kluczy, bo równy test ukryje gorące jednostki. ## Semantyka wywołań i awarie częściowe Wywołanie metody grainu wygląda podobnie do lokalnego wywołania C#, ale przechodzi przez sieć i runtime klastra. Timeout nie rozstrzyga, czy kod po drugiej stronie nie wykonał się, wykonał częściowo, czy zakończył się, a odpowiedź zginęła. Operacje ze skutkiem powinny przyjmować identyfikator żądania albo inną podstawę deduplikacji. „Spróbuj ponownie” bez tej ochrony może podwójnie obciążyć konto, wysłać drugi komunikat lub powtórzyć wywołanie narzędzia. Projektuj kontrakty grainów jako komendy domenowe, a nie zdalny dostęp do pól. Metoda ZmienStatus z wymaganym powodem i oczekiwaną wersją jest bezpieczniejsza od zestawu dowolnych setterów. Zwracaj wynik, który rozróżnia konflikt wersji, odrzucenie reguły i błąd infrastruktury. Dzięki temu klient wie, czy ponowić, odświeżyć stan, czy przekazać sprawę operatorowi. Wywołania między grainami tworzą graf zależności. Długi łańcuch zwiększa opóźnienie i liczbę miejsc awarii. Nie buduj rozproszonego monolitu, w którym każda operacja przechodzi przez kilkanaście drobnych grainów. Granica powinna obejmować zachowanie i dane, które naturalnie zmieniają się razem. Dla procesu przekrojowego zastosuj jawny workflow, sagę albo koordynację z kompensacją. ## Wersjonowanie bez zatrzymania całego klastra Rolling deployment oznacza, że przez pewien czas w klastrze mogą działać różne wersje kodu. Kontrakty wiadomości i interfejsy grainów muszą być kompatybilne z tym okresem. Dodanie opcjonalnego pola jest zwykle łatwiejsze niż zmiana znaczenia istniejącego. Usunięcie pola wymaga upewnienia się, że żadna starsza wersja nadal go nie wysyła. Stan trwały również ma wersję. Migracja wykonywana przy aktywacji może rozłożyć koszt w czasie, ale musi być idempotentna i obserwowalna. Migracja offline daje większą kontrolę, lecz wymaga okna i planu wycofania. W obu wariantach zachowaj kopię, licznik nieudanych rekordów oraz test na reprezentatywnych danych. Antywzorzec Skutek Bezpieczniejszy kierunek Jeden grain na cały tenant Gorący punkt i kolejka poleceń Mniejsze agregaty z naturalnym kluczem Grain jako tabela Anemiczny model i zdalne settery Operacje wyrażające regułę domenową Synchroniczny łańcuch grainów Narastające opóźnienie i awarie Krótszy kontrakt lub jawny workflow Efekt zewnętrzny bez identyfikatora Duplikaty po ponowieniu Idempotencja, outbox lub deduplikacja Stan bez wersji Ryzykowne wdrożenia kroczące Schemat, migracja i kompatybilny kontrakt Brak limitu wywołań AI Skok kosztu i przeciążenie Budżet, kolejka, timeout i backpressure Kryterium Sygnał za Orleans Sygnał za prostszą usługą Model domeny Wiele niezależnych jednostek z tożsamością Głównie bezstanowe operacje i zapytania Współbieżność Operacje naturalnie skupione wokół grainu Transakcje przekrojowe dominują Cykl życia Aktywacje na żądanie upraszczają system Krótki request response wystarcza Skala Potrzebne drobne partycjonowanie Jeden serwis i baza mieszczą obciążenie Kompetencje Zespół rozumie systemy rozproszone Priorytetem jest mały koszt operacyjny Orleans może stać się warstwą wykonawczą w [systemie działania firmy](https://majchrzycki.com/system), gdy cyfrowy model ma liczne stanowe jednostki i jawne odpowiedzialności. Jeśli celem jest budowa rozwiązania opartego na modelach, retrieval i narzędziach, kolejnym krokiem jest ocena [Microsoft Foundry i jego warstw aplikacyjnych](https://majchrzycki.com/blog/co-to-jest-microsoft-azure-ai-foundry-poradnik-dla-firm). W poniedziałek wybierz jeden agregat z własnym identyfikatorem. Zapisz jego stan, polecenia, gwarancje i skutki zewnętrzne. Zbuduj grain oraz prosty endpoint z bazą. Uruchom ponowienie tego samego polecenia, błąd zapisu i restart procesu. Jeśli Orleans usuwa więcej kodu koordynacji, niż dodaje zależności operacyjnych, masz dowód do dalszego pilotażu. Jeśli nie, prostsza architektura jest lepszą decyzją. - Dane i analityka - Modele i LLM - Azure - Zarządzanie zmianą ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Blazor w .NET 10: renderowanie, stan i AI](https://majchrzycki.com/blog/microsoft-blazor-intelligent-web-apps) - [Aspire: AppHost, service discovery i dashboard](https://majchrzycki.com/blog/microsoft-dot-net-aspire-cloud-native) - [.NET 10 dla aplikacji AI: warstwy i wybór](https://majchrzycki.com/blog/microsoft-dot-net-ai-apps) - [Python w aplikacjach AI: architektura i test](https://majchrzycki.com/blog/python-ai-apps)