Neden Orleans içinde akışlar?

Akış işleme sistemleri oluşturmak için çok çeşitli teknolojiler zaten mevcuttur. Bu sistemler arasında akış verilerini kalıcı olarak depolayan sistemler (örneğin, Event Hubs ve Kafka) ve akış verileri üzerinde hesaplama işlemlerini ifade eden sistemler (örneğin, Azure Stream Analytics, Apache Storm ve Apache Spark Streaming) bulunur. Bunlar verimli veri akışı işleme işlem hatları oluşturmanıza olanak sağlayan harika sistemlerdir.

Mevcut sistemlerin sınırlamaları

Ancak bu sistemler akış verileri üzerinden ayrıntılı serbest biçimli işlem için uygun değildir. Yukarıda belirtilen akış işlem sistemleri , tüm akış öğelerine aynı şekilde uygulanan işlemlerin birleşik bir veri akışı grafiğini belirtmenize olanak tanır. Bu, veriler tekdüzen olduğunda ve bu veriler üzerinde aynı dönüştürme, filtreleme veya toplama işlemlerini ifade etmek istediğinizde güçlü bir modeldir. Ancak diğer kullanım örnekleri, farklı veri öğeleri üzerinde temel olarak farklı işlemleri ifade etmek gerektirir. Bu durumların bazılarında, işlemenin bir parçası olarak, ara sıra rastgele rest API çağırma gibi bir dış çağrı yapmanız gerekebilir. Birleşik veri akışı akış işleme altyapıları bu senaryoları desteklemez, bunları sınırlı ve kısıtlanmış bir şekilde destekler veya bunları desteklemede verimsizdir. Bunun nedeni, büyük miktarda benzer öğe için doğal olarak iyileştirilmiş olmaları ve genellikle ifade ve işleme açısından sınırlı olmalarıdır. Orleans Akışlar bu diğer senaryoları hedefler.

Motivasyon

Her şey, bir grain yöntemi çağrısından bir dizi öğe döndürmeyi desteklemek için kullanıcılardan gelen Orleans isteklerle başladı. Tahmin edebileceğiniz gibi, bu sadece buzdağının ucuydu; çok daha fazlasına ihtiyaçları vardı.

Akışlar için Orleans tipik bir senaryo, kullanıcı başına akışlara sahip olmanız ve bu kullanıcı bağlamında her kullanıcı için farklı işleme gerçekleştirmek istemenizdir. Milyonlarca kullanıcınız olabilir, ancak bazıları hava durumuyla ilgileniyor ve belirli bir konum için hava durumu uyarılarına abone olurken, diğerleri spor etkinlikleriyle ilgileniyor; başka biri belirli bir uçuşun durumunu izliyor olabilir. Bu olayların işlenmesi farklı mantık gerektirir, ancak akış işlemenin iki bağımsız örneğini çalıştırmak istemezsiniz. Bazı kullanıcılar yalnızca belirli bir hisse senediyle ilgilenebilir ve yalnızca bu hisse senediyle ilgili belirli bir dış koşul geçerliyse, bu koşul akış verisinin bir parçası olmayabilir ve bu nedenle işlemenin bir parçası olarak gerçek zamanlı kontrol edilmesi gerekir.

Kullanıcılar her zaman ilgi alanlarını değiştirir, böylece belirli olay akışlarına abonelikleri dinamik olarak gelir ve gider. Bu nedenle akış topolojisi dinamik ve hızlı bir şekilde değişir. Buna ek olarak, kullanıcı başına işleme mantığı, kullanıcı durumuna ve dış olaylara göre dinamik olarak gelişir ve değişir. Dış olaylar belirli bir kullanıcının işleme mantığını değiştirebilir. Örneğin, bir oyun hilesi algılama sisteminde, yeni bir hile yöntemi bulunduğunda, işleme mantığının bu ihlali algılamak için yeni kuralla güncelleştirilmesi gerekir. Bu işlem elbette devam eden işlem hattı kesintiye uğramadan yapılmalıdır. Toplu veri akışı işleme motorları bu tür senaryoları destekleyecek şekilde tasarlanmadı.

Böyle bir sistemin yalnızca tek bir düğümde değil, ağa bağlı birkaç makinede çalışması gerektiğini söylemeye bile gerek yok. Bu nedenle, işleme mantığının bir sunucu kümesinde ölçeklenebilir ve esnek bir şekilde dağıtılması gerekir.

Yeni gereksinimler

Yukarıdaki senaryoları hedeflemek üzere bir Akış İşleme sistemi için dört temel gereksinim belirlendi:

1. Esnek akış işleme mantığı
2. Yüksek dinamik topoloji desteği
3. Ayrıntılı akış tanecikliği
4. Dağıtım

Esnek akış işleme mantığı

Sistem, akış işleme mantığını ifade etmenin farklı yollarını desteklemelidir. Yukarıda bahsedilen mevcut sistemler, geliştiricilerin genellikle işlevsel bir programlama stilini izleyerek bildirim temelli bir veri akışı hesaplama grafiği yazmasını gerektirir. Bu, işleme mantığının ifade ve esnekliğini sınırlar. Orleans akışlar, işleme mantığının nasıl ifade edildiğine kayıtsızdır. Veri akışı (örn. .NET'te Reaktif Uzantılar (Rx) kullanılarak), işlevsel bir program, bildirim temelli sorgu veya genel kesinlik temelli mantık olarak ifade edilebilir. Mantık durum bilgisi olan veya durum bilgisi olmayan olabilir, yan etkileri olabilir veya olmayabilir ve dış eylemleri tetikleyebilir. Tüm güç geliştiriciye gider.

Dinamik topoloji desteği

Sistem, dinamik olarak gelişen topolojilere izin vermelidir. Yukarıda belirtilen mevcut sistemler genellikle dağıtım zamanında düzeltilen ve çalışma zamanında geliştirilemeyen statik topolojilerle sınırlıdır. Aşağıdaki veri akışı ifadesinde, değiştirmeniz gerekene kadar her şey güzel ve basittir:

Stream.GroupBy(x=> x.key).Extract(x=>x.field).Select(x=>x+2).AverageWindow(x, 5sec).Where(x=>x > 0.8) *

Filtredeki Where eşik koşulunu değiştirin, bir Select deyim ekleyin veya veri akışı grafiğine başka bir dal ekleyin ve yeni bir çıkış akışı üretin. Mevcut sistemlerde bu, topolojinin tamamını yok etmeden ve veri akışını sıfırdan yeniden başlatmadan mümkün değildir. Pratikte, bu sistemler mevcut hesaplamayı kontrol eder ve en son kontrol noktasından yeniden başlatılabilir. Yine de, bu tür bir yeniden başlatma, anında sonuçlar üreten çevrimiçi hizmet için kesintiye neden olur ve maliyetlidir. Bu tür bir yeniden başlatma işlemi, sürekli değişen benzer ancak farklı parametrelerle (kullanıcı başına, cihaz başına vb.) yürütülen çok sayıda ifadeyle ilgilenirken özellikle pratik olmaz.

Sistem, işlem grafiğine yeni bağlantılar veya düğümler ekleyerek veya işlem düğümleri içindeki işlem mantığını değiştirerek akış işleme grafiğinin çalışma zamanında gelişmesine izin vermelidir.

Ayrıntılı akış tanecikliği

Mevcut sistemlerde en küçük soyutlama birimi genellikle akışın tamamıdır (topoloji). Ancak birçok hedef senaryo, topolojideki tek bir düğümün/bağlantının mantıksal varlığın kendisi olmasını gerektirir. Bu şekilde, her varlık bağımsız olarak yönetilebilir. Örneğin, birden çok bağlantıdan oluşan büyük bir akış topolojisinde, farklı bağlantılar farklı özelliklere sahip olabilir ve farklı fiziksel taşımalar üzerinden uygulanabilir. Bazı bağlantılar TCP yuvaları üzerinden, bazıları ise güvenilir kuyruklar kullanabilir. Farklı bağlantıların farklı teslimat garantileri olabilir. Farklı düğümlerin farklı denetim noktası oluşturma stratejileri olabilir ve bunların işleme mantığı farklı modellerde ve hatta farklı dillerde ifade edilebilir. Bu esneklik genellikle mevcut sistemlerde mümkün değildir.

Soyutlama ve esneklik savı, SoA (Hizmet Odaklı Mimariler) ile Aktörler karşılaştırmasına benzer. Aktör sistemleri, her aktör temelde bağımsız olarak yönetilen "küçük bir hizmet" olduğundan daha fazla esneklik sağlar. Benzer şekilde, akış sistemi bu tür ayrıntılı denetime izin vermelidir.

Dağıtım

Ve elbette, sistem "iyi bir dağıtılmış sistemin" tüm özelliklerine sahip olmalıdır. Buna şunlar dahildir:

1. Ölçeklenebilirlik: Çok sayıda akışı ve işlem öğesini destekler.
2. Esneklik: Yüke göre kaynakların eklenmesine/kaldırılmasına izin verir.
3. Güvenilirlik: Hatalara dayanıklıdır.
4. Verimlilik: Altyapı kaynaklarını verimli bir şekilde kullanır.
5. Yanıt Hızı: Neredeyse gerçek zamanlı senaryoları etkinleştirir.

Akış oluşturma Orleans gereksinimleri şunlardı.

Açıklama: Orleans Şu anda yukarıdaki örnekte olduğu gibi bildirim temelli veri akışı ifadeleri yazmayı doğrudan desteklememektedir. Geçerli Orleans Akış API'leri, akış API'lerindeOrleans açıklandığı gibi daha düşük düzeyli yapı taşlarıdır.

Ayrıca bakınız

Orleans Streams Programlama API'leri