Sorunun yanıtı.
Sorunun tarihi
Swift'in eşzamanlılık evrimi, veri yarışlarını tek bir süreç içinde ortadan kaldırmak için yapılandırılmış eşzamanlılık ve yerel aktörler ile başladı. Dil, sunucu tarafı ve dağıtık sistemlere genişledikçe, geliştiricilerin, aktörlerin farklı makinelerde bulunduğu durumlarda Swift'in katı bellek güvenliği ve izolasyon garantilerini korumanın bir yoluna ihtiyacı vardı. DistributedActor önerisi, ağ çağrılarının yerel yöntem çağrılarıyla aynı async/await sözleşmelerine uyduğunu garanti eden, derleyici tarafından doğrulanan bir dağıtılmış bilgi işlem modeli getirdi.
Sorun
Geleneksel uzaktan prosedür çağrıları, Swift'in tür denetleyicisinden kaçan çalışma zamanı kodu üretimine veya dinamik proxy'lere dayanır; bu da API sözleşmeleri istemci ile sunucu arasında kaydığında hatalara yol açar. Dil, süreç sınırlarını aşan yöntemlerin serileştirilmesini, ağ gecikmesini ve taşıma hatalarını açık bir şekilde ele aldığından emin olmak için derleme zamanında bir mekanizma gerektiriyordu. Meydana gelen zorluk, aktör programlama modelini parçalara ayırmadan veya sıfır maliyetli soyutlama ilkelerini feda etmeden yerel senkron yürütmeyi uzaktan asenkron dağıtımdan ayırmaktı.
Çözüm
distributed actor beyanı, her örneğe bir ActorSystem özelliği enjekte ederek bir taşıma mekanizması sentezler. distributed anahtar kelimesiyle işaretlenmiş yöntemler, tüm parametrelerin ve dönüş değerlerinin Codable veya Sendable ile uyumlu olduğunu sağlamak için derleme zamanı doğrulamasına tabi tutulur ve derleyici, çağrıları kesen bir dağıtılmış thunk üretir. Uzaktan bir çağrı gerçekleştirildiğinde, ActorSystem argümanları düzenler, bunları taşıma katmanı aracılığıyla iletir ve serileştirme tamamlanıncaya kadar çağıran tarafı askıya alır; bu esnada Swift'in yapılandırılmış eşzamanlılığı ve hata işleme anlamlarını korur.
Hayattan bir durum
Sorun tanımı
Bir fintech girişimi, bir iOS istemcisi ile bir arka uç eşleştirme motoru arasında yüksek frekanslı ticaret durumunu senkronize etmesi gerekiyordu. Mevcut REST uygulaması, serileştirme yükü getirdi ve protokol sürümlerinin derleme zamanı doğrulamasını sağlamadı; bu da piyasa volatilitesi sırasında mesaj şemalarının farklılaştığında çalışma zamanı çözümleme hatalarına yol açtı.
İlk düşünülen çözüm: gRPC ve Protokol Buffers
Bu yaklaşım, dil sınırları arasında tür güvenli kod üretimi ve verimli ikili serileştirme sundu. Ancak, ayrı .proto tanım dosyalarını ve karmaşık bir derleme hattı entegrasyonu sürdürmeyi gerektiriyordu; bu da Swift'in yerel eşzamanlılık modeli ile bir uyumsuzluk yarattı. Geliştiricilerin, gRPC'nin geri çağırma tabanlı API'sini Swift'in async/await'i ile manuel olarak birleştirmesi gerekti; bu da iş mantığını bulanıklaştıran boilerplate ağırlıklı koda yol açtı.
İkinci düşünülen çözüm: WebSocket üzerinden özel ikili protokol
Özelleştirilmiş bir protokol geliştirmek maksimum performans kontrolü ve Swift'in yapılandırılmış eşzamanlılığı ile sıkı entegrasyon sağladı. Dezavantajı ise, uzaktan arayüzler için derleyici zorlamasının tamamen yokluğu idi; bu da parametre uyumsuzluklarını tespit etmek için kapsamlı entegrasyon testleri gerektiriyordu. Ayrıca, konum şeffaflığının yokluğu, geliştiricilerin yerel önbellekler ile uzaktan motorlar arasında paralel kod yollarını sürdürmelerini zorunlu kıldı; bu da bakım yükünü ve hata oranlarını artırdı.
Seçilen çözüm ve sonuç
Ekip, WebSocket üzerinden özel bir ActorSystem uygulaması ile Swift DistributedActors'ı benimsedi. Bu, ticaret aktörlerinin yerel Swift sözdizimi kullanılarak tanımlanmasını sağladı ve derleyici, tüm dağıtımlı yöntem parametrelerinin serileştirilebilir olduğunu ve yöntemlerin async throws ile işaretlendiğini doğruladı. distributed anahtar kelimesi, ağ sınırlarını belirgin hale getirirken, aktör sistemi taşıma mekaniklerini şeffaf bir şekilde yönetti. Sonuç olarak, uzaktan bir eşleştirme motoru ile etkileşim, yerel durum erişimi ile aynı sözdizimi kullanılarak gerçekleştirilmesi sağlandı; bu da çalışma zamanı API uyumsuzluklarını ortadan kaldırdı ve dağıtılmış sistem karmaşıklığını %40 oranında azalttı.
Adayların sıklıkla kaçırdığı noktalar
Neden dağıtılmış yöntemler, uygulama hatasız görünse bile throws olarak beyan edilmelidir?
Swift'in dağıtılmış aktör modeli, ağ hatalarını temel fizik olarak işler; uygulama hataları olarak değil. Derleyici, ActorSystem hatalarını, taşıma zaman aşımını ve serileştirme hatalarını ele almak için her dağıtım yöntemi etrafında bir fırlatma thunk'ı sentezler. İşyeri mantığı hiç fırlatmasa bile, altındaki taşıma, uzaktaki sunucuya ulaşmayı veya hatalı bir paket almayı başarısız kılabilir. Bu gereklilik, geliştiricileri, ağ bölünmeleri sırasında istemcinin çökmesini engelleyerek hata modlarını ele almak için Swift'in do-catch hata işleme mekanizmasını kullanmaya zorlar. throws notasyonu, dağıtılmış yöntemin ABI sözleşmesinin bir parçası haline gelir ve çağıranların güvenilmez ağ sınırının farkında kalmasını sağlar.
ActorSystem, bir dağıtılmış aktörün fiziksel konumunu nasıl belirler ve bir yerel aktör referansı uzaktan bir işleme geçildiğinde ne olur?
Her DistributedActor, oluşturulduğu ActorSystem tarafından atanmış benzersiz bir ActorID taşır; bu, aktörün konumunu temsil eden bir yetki belirteci gibidir. Bir dağıtılmış aktörü bir ağ sınırı boyunca geçirirken, Swift'in çalışma zamanı nesne işaretçisini iletmez; bunun yerine aktörün encode(to:) yöntemini kullanarak ActorID'yi kodlar. Alıcı süreç, aynı ActorID'ye sahip bir proxy aktör örneğini oluşturur, ancak bu yerel ActorSystem'e bağlıdır. Proxy, bir yöntem çağrısı aldığında, sistem yönlendirme tablosuna danışır; eğer ActorID uzaktaki bir düğüme işaret ediyorsa, çağrı şeffaf bir şekilde yönlendirilir. Bu, aktörlerin ağ boyunca değerle kopyalanmadığını ve Swift'in eşzamanlılık güvenliği için kritik olan tek sahiplik anlamlarını korur.
Bir distributed yöntemi, aynı dağıtılmış aktör içindeki bir normal yöntemden ne ayırır ve neden ikincisi uzaktan çağrılamaz?
Normal yöntemler içindeki DistributedActor, yerel iş parçacığında senkron olarak çalışır ve izolasyonu doğrudan erişir; dağıtılmış thunk mekanizmasını geçerek. Bu yöntemler ActorSystem üzerinden serileştirilmez; bu da ağ gecikmesi veya hata modlarını tolere edemeyecekleri anlamına gelir. Derleyici, uzaktan çağrıları yalnızca distributed yöntemlerle kısıtlar çünkü bunlar ek doğrulamaya tabi tutulur: async ve throws olmalı ve tüm parametreler Sendable veya Codable ile uyumlu olmalıdır. Uzaktan bir aktör referansındaki bir normal yöntemi çağırmayı denemek, derleyicinin yöntemin serileştirmeyi ele alıp almadığına veya dağıtılmış yürütme anlamlarını dikkate alıp almadığına dair bir kesinlik verememesi nedeniyle bir derleme zamanı hatasına yol açar. Bu ayrım, yerel işlemler için performansı korur ve ağ bağlantılı çağrılar için katı sözleşmeleri uygulamakta yardımcı olur.