Herkese selam! Harika haberlerimiz var; OTUS kursu Haziran ayında yeniden başlatıyor , bununla bağlantılı olarak geleneksel olarak faydalı materyalleri sizinle paylaşıyoruz.
Tüm bu mikro hizmetler olayıyla herhangi bir bağlam olmadan karşılaştıysanız, bunun biraz tuhaf olduğunu düşündüğünüz için affedilirsiniz. Bir uygulamayı bir ağa bağlı parçalara bölmek, sonuçta ortaya çıkan dağıtılmış sisteme karmaşık hata toleransı modlarının eklenmesi anlamına gelir.
Bu yaklaşım onu birçok bağımsız hizmete bölmeyi gerektirse de nihai amaç, bu hizmetlerin farklı makinelerde çalıştırılmasından çok daha fazlasıdır. Burada özünde de dağıtık olan dış dünyayla etkileşimden bahsediyoruz. Teknik anlamda değil, daha çok birçok kişiden, ekipten, programdan oluşan ve bu parçaların her birinin bir şekilde işini yapması gereken bir ekosistem anlamında.
Örneğin şirketler, bazı hedeflerin gerçekleştirilmesine kolektif olarak katkıda bulunan dağıtılmış sistemlerin bir koleksiyonudur. Onlarca yıldır bu gerçeği göz ardı ettik; dosyaları FTP yoluyla veya kurumsal entegrasyon araçlarını kullanarak birleştirmeyi sağlamaya çalışırken, kendi izole hedeflerimize odaklandık. Ancak hizmetlerin gelişiyle her şey değişti. Hizmetler, ufkun ötesine bakmamıza ve birlikte çalışan, birbirine bağımlı programlardan oluşan bir dünya görmemize yardımcı oldu. Ancak başarılı bir şekilde çalışabilmek için temelde farklı iki dünyayı tanımak ve tasarlamak gerekir: diğer birçok hizmetten oluşan bir ekosistem içinde yaşadığımız dış dünya ve tek başımıza yönettiğimiz kişisel iç dünyamız.
Bu dağınık dünya, büyüdüğümüz ve alışık olduğumuzdan farklı. Geleneksel yekpare mimariyi inşa etmenin ilkeleri eleştiriye dayanmıyor. Dolayısıyla bu sistemleri doğru şekilde kurmak, harika bir beyaz tahta şeması veya harika bir konsept kanıtı oluşturmaktan daha fazlasıdır. Önemli olan böyle bir sistemin uzun süre başarıyla çalışmasını sağlamaktır. Neyse ki, farklı görünmelerine rağmen hizmetler oldukça uzun bir süredir ortalıkta. Docker, Kubernetes ve biraz eski püskü hipster sakallarıyla bile tecrübeli olsalar bile hala güncelliğini koruyor.
Bugün kuralların nasıl değiştiğine, hizmetlere ve bunların birbirlerine aktardığı verilere yaklaşımımızı neden yeniden düşünmemiz gerektiğine ve bunu yapmak için neden tamamen farklı araçlara ihtiyacımız olduğuna bakacağız.
Kapsülleme her zaman arkadaşınız olmayacak
Mikro hizmetler birbirinden bağımsız olarak çalışabilir. Onlara en büyük değeri veren bu özelliktir. Bu aynı özellik hizmetlerin ölçeklenmesine ve büyümesine olanak tanır. Katrilyonlarca kullanıcıya veya petabaytlarca veriye ölçeklendirme anlamında değil (gerçi bunlar da bu konuda yardımcı olabilir), ekipler ve organizasyonlar sürekli büyüdükçe insanlar açısından ölçeklendirme anlamında.
Ancak bağımsızlık iki ucu keskin bir kılıçtır. Yani hizmetin kendisi kolayca ve doğal bir şekilde çalışabilir. Ancak bir işlev, başka bir hizmetin kullanımını gerektiren bir hizmet içinde uygulanırsa, o zaman her iki hizmette de neredeyse aynı anda değişiklik yapmak zorunda kalırız. Monolitte bunu yapmak kolaydır, sadece bir değişiklik yaparsınız ve onu yayına gönderirsiniz, ancak bağımsız hizmetlerin senkronize edilmesi durumunda daha fazla sorun olacaktır. Ekipler arasındaki koordinasyon ve serbest bırakma döngüleri çevikliği yok eder.
Standart yaklaşımın bir parçası olarak, işlevselliği hizmetler arasında açıkça bölerek can sıkıcı uçtan uca değişikliklerden kaçınmaya çalışırlar. Tek oturum açma hizmeti burada iyi bir örnek olabilir. Onu diğer hizmetlerden ayıran, açıkça tanımlanmış bir rolü vardır. Bu açık ayrım, etrafındaki hizmetlere yönelik taleplerin hızla değiştiği bir dünyada, tek oturum açma hizmetinin değişme ihtimalinin düşük olduğu anlamına gelir. Kesinlikle sınırlı bir bağlamda var olur.
Sorun, gerçek dünyada ticari hizmetlerin her zaman aynı saf rol ayrımını sürdürememesidir. Örneğin, aynı iş hizmetleri, diğer benzer hizmetlerden gelen verilerle daha büyük ölçüde çalışır. Çevrimiçi perakende satışla ilgileniyorsanız, sipariş akışının, ürün kataloğunun veya kullanıcı bilgilerinin işlenmesi, hizmetlerinizin çoğu için bir gereklilik haline gelecektir. Hizmetlerin her birinin çalışması için bu verilere erişmesi gerekir.
Çoğu iş hizmeti aynı veri akışını paylaştığından işleri her zaman iç içe geçmiş durumdadır.
Böylece konuşmaya değer önemli bir noktaya geliyoruz. Hizmetler, büyük ölçüde ayrı ayrı çalışan altyapı bileşenleri için iyi çalışsa da çoğu iş hizmeti, çok daha yakından iç içe geçmiş durumdadır.
Veri ikilemi
Hizmet odaklı yaklaşımlar hâlihazırda mevcut olabilir ancak büyük miktarda verinin hizmetler arasında nasıl paylaşılacağı konusunda hâlâ içgörüden yoksundurlar.
Temel sorun, veri ve hizmetlerin birbirinden ayrılamaz olmasıdır. Bir yandan, kapsülleme bizi verileri gizlemeye teşvik eder, böylece hizmetler birbirinden ayrılabilir ve bunların büyümesi ve daha fazla değişmesi kolaylaşır. Öte yandan, tıpkı diğer veriler gibi, paylaşılan verileri de özgürce bölüp ele geçirebilmemiz gerekiyor. Önemli olan herhangi bir bilgi sisteminde olduğu gibi özgürce hemen çalışmaya başlayabilmektir.
Ancak bilgi sistemlerinin kapsüllemeyle pek ilgisi yoktur. Aslında durum tam tersi. Veritabanları depoladıkları verilere erişim sağlamak için ellerinden geleni yaparlar. Verileri ihtiyaç duyduğunuz şekilde değiştirmenize olanak tanıyan güçlü bir bildirimsel arayüzle birlikte gelirler. Bu işlevsellik ön araştırma aşamasında önemlidir, ancak sürekli gelişen bir hizmetin artan karmaşıklığının yönetilmesi açısından önemli değildir.
Ve burada bir ikilem ortaya çıkıyor. Çelişki. İkilem. Sonuçta bilgi sistemleri veri sağlamakla, hizmetler ise saklamakla ilgilidir.
Bu iki kuvvet temeldir. Kurduğumuz sistemlerde mükemmellik için sürekli mücadele ederek işimizin çoğunu destekliyorlar.
Hizmet sistemleri büyüyüp geliştikçe, veri ikileminin sonuçlarını birçok yönden görüyoruz. Ya hizmet arayüzü giderek daha geniş bir işlevsellik yelpazesi sağlayacak şekilde büyüyecek ve çok şık, evde yetiştirilen bir veritabanına benzemeye başlayacak ya da hayal kırıklığına uğrayacağız ve tüm veri kümelerini toplu olarak hizmetten hizmete almanın veya taşımanın bir yolunu uygulayacağız.
Buna karşılık, evde yetiştirilen süslü bir veritabanına benzeyen bir şey oluşturmak, bir dizi soruna yol açacaktır. Neden tehlikeli olduğu konusunda ayrıntılara girmeyeceğiz paylaşılan veritabanı, önemli ölçüde maliyetli mühendislik ve operasyonel maliyetleri temsil ettiğini söyleyelim. onu kullanmaya çalışan şirket için.
Daha da kötüsü, veri hacimlerinin hizmet sınırı sorunlarını büyütmesidir. Bir hizmet içinde ne kadar çok veri paylaşılırsa, arayüz o kadar karmaşık hale gelecek ve farklı hizmetlerden gelen veri setlerini birleştirmek o kadar zor olacaktır.
Veri setlerinin tamamının çıkarılması ve taşınması şeklindeki alternatif yaklaşımın da kendi sorunları vardır. Bu soruya genel bir yaklaşım, basitçe tüm veri kümesini alıp depolamak ve ardından onu tüketen her hizmette yerel olarak depolamak gibi görünüyor.
Sorun, farklı hizmetlerin tükettikleri verileri farklı şekilde yorumlamasıdır. Bu veriler her zaman elinizin altındadır. Yerel olarak değiştirilir ve işlenirler. Oldukça hızlı bir şekilde kaynaktaki verilerle ortak hiçbir yanı kalmaz.
Kopyalar ne kadar değişken olursa, veriler zaman içinde o kadar fazla değişecektir.
Daha da kötüsü, bu tür verilerin geriye dönük olarak düzeltilmesi zordur ( Burası gerçekten kurtarmaya gelebileceği yer). Aslında işletmelerin karşılaştığı zorlu teknoloji sorunlarından bazıları, uygulamadan uygulamaya çoğalan farklı verilerden kaynaklanmaktadır.
Bu soruna çözüm bulmak için paylaşılan veriler konusunda farklı düşünmemiz gerekiyor. İnşa ettiğimiz mimarilerde birinci sınıf nesneler haline gelmeleri gerekiyor. bu tür verileri “harici” olarak adlandırıyor ve bu çok önemli bir özellik. Bir hizmetin iç işleyişini açığa çıkarmamak için kapsüllemeye ihtiyacımız var, ancak işlerini doğru şekilde yapabilmeleri için hizmetlerin paylaşılan verilere erişmesini kolaylaştırmamız gerekiyor.
Sorun şu ki, ne hizmet arayüzleri, ne mesajlaşma ne de Paylaşılan Veritabanı, harici verilerle çalışmak için iyi bir çözüm sunmadığı için, her iki yaklaşımın da günümüzde geçerliliği yoktur. Hizmet arayüzleri herhangi bir ölçekte veri alışverişi için pek uygun değildir. Mesajlaşma verileri taşır ancak geçmişini saklamaz, dolayısıyla veriler zamanla bozulur. Paylaşılan Veritabanları tek bir noktaya çok fazla odaklanır ve bu da ilerlemeyi engeller. Kaçınılmaz olarak bir veri hatası döngüsünde sıkışıp kalıyoruz:
Veri hatası döngüsü
Akışlar: veri ve hizmetlere merkezi olmayan bir yaklaşım
İdeal olarak hizmetlerin paylaşılan verilerle çalışma şeklini değiştirmemiz gerekir. Bu noktada her iki yaklaşım da yukarıda bahsedilen ikilemle karşı karşıyadır; çünkü üzerine serpilip onu yok edecek sihirli bir toz yoktur. Ancak sorunu yeniden düşünüp bir uzlaşmaya varabiliriz.
Bu uzlaşma belirli bir derecede merkezileşmeyi içerir. Güvenilir, ölçeklenebilir akışlar sağladığı için dağıtılmış günlük mekanizmasını kullanabiliriz. Artık hizmetlerin bu paylaşılan iş parçacıklarına katılıp üzerinde çalışabilmesini istiyoruz, ancak bu işlemeyi yapan karmaşık merkezi Tanrı Hizmetlerinden kaçınmak istiyoruz. Bu nedenle en iyi seçenek, her tüketici hizmetine akış işlemeyi eklemektir. Bu sayede hizmetler farklı kaynaklardan gelen veri setlerini birleştirip ihtiyaç duydukları şekilde çalışabilecek.
Bu yaklaşıma ulaşmanın bir yolu, bir akış platformunun kullanılmasıdır. Pek çok seçenek var, ancak bugün Kafka'ya bakacağız çünkü Durum Bilgili Akış İşleme'nin kullanılması, sunulan sorunu etkili bir şekilde çözmemize olanak tanıyor.
Dağıtılmış bir günlük kaydı mekanizması kullanmak, alışılagelmiş yolu takip etmemize ve çalışmak için mesajlaşmayı kullanmamıza olanak tanır . Bu yaklaşımın, akışın kontrolünü gönderici yerine alıcıya vermesi nedeniyle istek-yanıt mekanizmasından daha iyi ölçeklendirme ve bölümleme sağladığı düşünülmektedir. Ancak bu hayattaki her şey için ödeme yapmanız gerekiyor ve burada bir komisyoncuya ihtiyacınız var. Ancak büyük sistemler için bu ödünleşime değer (bu, ortalama web uygulamanız için geçerli olmayabilir).
Bir aracı, geleneksel mesajlaşma sistemi yerine dağıtılmış günlük kaydından sorumluysa, ek özelliklerden yararlanabilirsiniz. Aktarım, neredeyse dağıtılmış bir dosya sistemi kadar doğrusal olarak ölçeklenebilir. Veriler günlüklerde oldukça uzun süre saklanabilir, bu nedenle yalnızca mesaj alışverişini değil aynı zamanda bilgi depolamayı da elde ederiz. Değişken paylaşımlı durum korkusu olmadan ölçeklenebilir depolama.
Daha sonra, tüketen hizmetlere bildirim temelli veritabanı araçları eklemek için durum bilgisi olan akış işlemeyi kullanabilirsiniz. Bu çok önemli bir fikir. Veriler, tüm hizmetlerin erişebileceği paylaşılan akışlarda depolanırken, hizmetin yaptığı toplama ve işleme işlemleri özeldir. Kendilerini katı bir şekilde sınırlı bir bağlamda izole edilmiş halde buluyorlar.
Değişmez durum akışını ayırarak veri ikilemini ortadan kaldırın. Daha sonra bu işlevselliği Durum Bilgili Akış İşleme'yi kullanarak her hizmete ekleyin.
Böylece hizmetinizin siparişlerle, ürün kataloğuyla, depoyla çalışması gerekiyorsa tam erişime sahip olacaktır: hangi verilerin birleştirileceğine, nerede işleneceğine ve zaman içinde nasıl değişeceğine yalnızca siz karar vereceksiniz. Verilerin paylaşılmasına rağmen, onunla çalışmak tamamen merkezi değildir. Her şeyin sizin kurallarınıza göre gittiği bir dünyada, her hizmetin bünyesinde üretilir.
Verileri bütünlüğünden ödün vermeden paylaşın. İhtiyaç duyan her hizmette kaynağı değil işlevi kapsülleyin.
Verilerin toplu olarak taşınması gerekiyor. Bazen bir hizmet, seçilen veritabanı motorunda yerel bir geçmiş veri kümesi gerektirir. İşin püf noktası, gerekirse dağıtılmış kayıt mekanizmasına erişilerek kaynaktan bir kopyanın geri yüklenebileceğini garanti edebilmenizdir. Kafka'daki bağlayıcılar bu konuda harika bir iş çıkarıyor.
Dolayısıyla bugün tartışılan yaklaşımın birçok avantajı var:
- Veriler, günlüklerde uzun süre saklanabilen ortak akışlar biçiminde kullanılır ve ortak verilerle çalışma mekanizması, hizmetlerin kolay ve hızlı bir şekilde çalışmasına olanak tanıyan her bir bağlamda yerleşiktir. Bu şekilde verilerin ikilemi dengelenebilir.
- Farklı hizmetlerden gelen veriler kolaylıkla kümeler halinde birleştirilebilir. Bu, paylaşılan verilerle etkileşimi basitleştirir ve yerel veri kümelerinin veritabanında tutulması ihtiyacını ortadan kaldırır.
- Durum Bilgili Akış İşleme yalnızca verileri önbelleğe alır ve gerçeğin kaynağı genel günlükler olarak kalır, bu nedenle zaman içinde veri bozulması sorunu o kadar da ciddi değildir.
- Hizmetlerin özünde veri odaklı olması, sürekli artan veri hacimlerine rağmen hizmetlerin iş olaylarına hızla yanıt verebilmesi anlamına geliyor.
- Ölçeklenebilirlik sorunları hizmetlere değil komisyoncuya düşer. Bu, ölçeklenebilirlik hakkında düşünmeye gerek olmadığından yazma hizmetlerinin karmaşıklığını önemli ölçüde azaltır.
- Yeni servislerin eklenmesi eskilerinin değiştirilmesini gerektirmez, böylece yeni servislere bağlanmak daha kolay hale gelir.
Gördüğünüz gibi bu REST'ten daha fazlası. Paylaşılan verilerle merkezi olmayan bir şekilde çalışmanıza olanak tanıyan bir dizi araç aldık.
Bugünkü makalede tüm hususlar ele alınmamıştır. Hala istek-yanıt paradigması ile olay odaklı paradigma arasında nasıl denge kuracağımızı bulmamız gerekiyor. Ama bunu bir dahaki sefere halledeceğiz. Daha iyi tanımanız gereken konular var; örneğin Durum Bilgili Akış İşlemenin neden bu kadar iyi olduğu. Üçüncü yazımızda bundan bahsedeceğiz. Ve eğer onlara başvurursak yararlanabileceğimiz başka güçlü yapılar da var, örneğin: . Dağıtılmış iş sistemleri için oyun değiştiricidir çünkü işlem garantileri sağlar. ölçeklenebilir bir biçimde. Bu dördüncü makalede tartışılacaktır. Son olarak bu ilkelerin uygulama detaylarına değinmemiz gerekecek.
Ancak şimdilik şunu unutmayın: Veri ikilemi, iş hizmetleri oluştururken karşılaştığımız bir güçtür. Ve şunu hatırlamalıyız. İşin püf noktası her şeyi tersine çevirmek ve paylaşılan verilere birinci sınıf nesneler gibi davranmaya başlamaktır. Durum Bilgili Akış İşleme bunun için benzersiz bir uzlaşma sağlar. İlerlemeyi engelleyen merkezi “Tanrı Bileşenlerinden” kaçınır. Üstelik veri akışı işlem hatlarının çevikliğini, ölçeklenebilirliğini ve esnekliğini sağlar ve bunları her hizmete ekler. Bu nedenle herhangi bir hizmetin bağlanabileceği ve verileriyle çalışabileceği genel bilinç akışına odaklanabiliriz. Bu, hizmetleri daha ölçeklenebilir, değiştirilebilir ve özerk hale getirir. Dolayısıyla bunlar yalnızca beyaz tahtalarda ve hipotez testlerinde iyi görünmekle kalmayacak, aynı zamanda onlarca yıl boyunca çalışacak ve gelişecek.
Kaynak: habr.com