Odpowiedź na pytanie.
Historia pytania
Ewolucja współbieżności w Swift zaczęła się od strukturalnej współbieżności i lokalnych aktorów, aby wyeliminować wyścigi danych w obrębie jednego procesu. W miarę rozwoju języka w kierunku systemów serwerowych i rozproszonych, deweloperzy potrzebowali sposobu na zachowanie rygorystycznych gwarancji bezpieczeństwa pamięci i izolacji Swift w sytuacji, gdy aktory znajdują się na różnych maszynach. Propozycja DistributedActor wprowadziła model zdalnego przetwarzania zweryfikowany przez kompilator, zapewniając, że wywołania sieciowe honorują te same kontrakty async/await co lokalne wywołania metod.
Problem
Tradycyjne zdalne wywołania procedur opierają się na generacji kodu w czasie wykonywania lub dynamicznych proxy, które omijają typowy kontroler Swift, prowadząc do błędów, gdy kontrakty API odbiegają od siebie między klientem a serwerem. Język wymagał mechanizmu, który na etapie kompilacji wymuszałby, aby metody przekraczające granice procesów wyraźnie obsługiwały serializację, opóźnienia w sieci i błędy transportowe. Wyzwanie polegało na odróżnieniu lokalnych synchronizowanych operacji od zdalnych asynchronicznych, bez fragmentowania modelu programowania aktorów lub poświęcania zasad zerowego kosztu abstrakcji.
Rozwiązanie
Deklaracja distributed actor automatycznie syntezuję właściwość ActorSystem, wstrzykując mechanizm transportowy do każdej instancji. Metody oznaczone słowem kluczowym distributed przechodzą weryfikację w czasie kompilacji, aby upewnić się, że wszystkie parametry i wartości zwracane są zgodne z Codable lub Sendable, a kompilator generuje zdalny thunk, który przechwytuje wywołania. Gdy dochodzi do zdalnego wywołania, ActorSystem przesyła argumenty, transmitując je za pośrednictwem swojej warstwy transportowej, a wywołujący jest wstrzymywany do momentu zakończenia deserializacji, wszystko to przy zachowaniu strukturalnej współbieżności i semantyki obsługi błędów Swift.
Sytuacja z życia
Opis problemu
Startup fintechowy potrzebował synchronizacji stanu handlu wysokiej częstotliwości między klientem iOS a silnikiem dopasowującym w backendzie. Istniejąca implementacja REST wprowadzała narzut związany z serializacją i nie miała weryfikacji w czasie kompilacji wersji protokołu, co powodowało błędy dekodowania w trakcie zmienności rynku, gdy schematy wiadomości się różniły.
Pierwsze rozważane rozwiązanie: gRPC z protokołami buforowymi
To podejście oferowało generację kodu bezpiecznego dla typów i wydajną binarną serializację między językami. Jednak wymagało utrzymywania oddzielnych plików definicji .proto i skomplikowanej integracji potoku budowy, co stworzyło niedopasowanie z natywnym modelem współbieżności Swift. Deweloperzy musieli ręcznie złączyć API oparte na wywołaniach zwrotnych gRPC z Swift's async/await, co skutkowało kodem bogatym w szablony, który zaciemniał logikę biznesową.
Drugie rozważane rozwiązanie: Niestandardowy protokół binarny przez WebSocket
Zbudowanie zamkniętego protokołu zapewniło maksymalną kontrolę wydajności i ścisłą integrację z strukturalną współbieżnością Swift. Wadą był całkowity brak egzekwowania przez kompilator dla zdalnych interfejsów, co wymagało wyczerpującego testowania integracyjnego w celu wychwycenia niezgodności parametrów. Dodatkowo, brak przejrzystości lokalizacji zmusił deweloperów do utrzymywania równoległych ścieżek kodowych dla lokalnych pamięci podręcznych w porównaniu z zdalnymi silnikami, zwiększając obciążenie konserwacji i wskaźniki błędów.
Wybrane rozwiązanie i wynik
Zespół przyjął Swift DistributedActors z niestandardową implementacją ActorSystem przez WebSocket. Pozwoliło to na zdefiniowanie aktorów handlowych za pomocą natywnej składni Swift, przy czym kompilator weryfikował, że wszystkie parametry metod zdalnych były serializowalne i że metody były oznaczone jako async throws. Słowo kluczowe distributed uczyniło granice sieciowe wyraźnymi, podczas gdy system aktorów zajmował się mechaniką transportu w sposób przezroczysty. Wynikiem był zjednoczony kod, w którym interakcja z zdalnym silnikiem dopasowującym używała identycznej składni w porównaniu do lokalnego dostępu do stanu, eliminując niezgodności API w czasie wykonywania i zmniejszając złożoność systemu rozproszonego o 40%.
Co często umyka kandydatom
Dlaczego metody rozproszone muszą być deklarowane jako throws, nawet gdy implementacja wydaje się nieomylna?
Model rozproszonych aktorów Swift traktuje błędy sieciowe jako fundamentalną fizykę, a nie błędy implementacyjne. Kompilator syntezjuje rzucający thunk wokół każdej zdalnej metody, aby obsłużyć błędy ActorSystem, przekroczenia czasowego transportu i błędy deserializacji. Nawet jeśli logika biznesowa nigdy nie rzuca, transport mogą nie dotrzeć do zdalnego hosta lub otrzymać uszkodzony pakiet. To wymaganie zmusza deweloperów do obsługi trybów awaryjnych za pomocą obsługi błędów do-catch Swift, zapobiegając nieprzechwyconym wyjątków przed awarią klienta w czasie partycji sieciowych. Adnotacja throws staje się częścią umowy ABI metody zdalnej, zapewniając, że wywołujący pozostaje świadomy niepewnej granicy sieciowej.
Jak ActorSystem rozwiązuje fizyczną lokalizację rozproszonego aktora, i co się dzieje, gdy odniesienie lokalnego aktora jest przekazywane do zdalnego procesu?
Każdy DistributedActor ma unikalny ActorID przypisany przez jego tworzący ActorSystem, działający jako token uprawnienia reprezentujący lokalizację aktora. Podczas przekazywania rozproszonego aktora przez granicę sieciową, czas wykonania Swift nie przesyła wskaźnika obiektu; zamiast tego koduje ActorID za pomocą metody encode(to:) aktora. Proces odbierający materializuje instancję proxy aktora dzielącą to samo ActorID, ale związaną z lokalnym ActorSystem. Gdy proxy odbiera wywołanie metody, system konsultuje swoją tabelę routingu; jeśli ActorID wskazuje na zdalny węzeł, wywołanie jest przełączane w sposób przezroczysty. Gwarantuje to, że aktory nigdy nie są kopiowane przez wartość przez sieć, co zachowuje semantykę jednolitego właściciela, co jest kluczowe dla bezpieczeństwa współbieżności Swift.
Co odróżnia metodę distributed od zwykłej metody w tym samym rozproszonym akcie, i dlaczego nie można wywoływać tej drugiej zdalnie?
Zwykłe metody w obrębie DistributedActor wykonywane są synchronizowanie na lokalnym wątku i bezpośrednio uzyskują dostęp do izolowanego stanu, omijając mechanizm zdalnego thunka. Te metody nie są serializowane przez ActorSystem, co oznacza, że nie mogą tolerować opóźnień sieciowych lub trybów awaryjnych. Kompilator ogranicza zdalne wywołania do metod distributed, ponieważ te wymagają dodatkowej weryfikacji: muszą być async i throws, a wszystkie parametry muszą być zgodne z Sendable lub Codable. Próba wywołania zwykłej metody na zdalnym odniesieniu aktora skutkuje błędem w czasie kompilacji, ponieważ kompilator nie może zagwarantować, że metoda obsługuje serializację lub przestrzega semantyki zdalnego wykonania. Ta różnica zachowuje wydajność dla operacji tylko lokalnych, jednocześnie narzucając rygorystyczne kontrakty dla wywołań związanych z siecią.