26 Şubat'ta açık kaynak projesine katkıda bulunanların konuştuğu bir Apache Ignite GreenSource buluşması düzenledik. . Bu topluluğun yaşamındaki önemli bir olay, bileşenin yeniden yapılandırılmasıydı. Bu, özel mikro hizmetleri doğrudan bir Ignite kümesine dağıtmanıza olanak tanır. Buluşmada bu zorlu süreci anlattı , yazılım mühendisi ve iki yılı aşkın süredir Apache Ignite'a katkıda bulunuyor.
Apache Ignite'ın genel olarak ne olduğuyla başlayalım. Bu, SQL, işlemsellik ve önbelleğe alma desteğine sahip, dağıtılmış bir Anahtar/Değer deposu olan bir veritabanıdır. Ayrıca Ignite, özel hizmetleri doğrudan bir Ignite kümesine dağıtmanıza olanak tanır. Geliştiricinin, Ignite'ın sağladığı tüm araçlara (dağıtılmış veri yapıları, Mesajlaşma, Akış, Bilgi İşlem ve Veri Izgarası) erişimi vardır. Örneğin Data Grid kullanıldığında veri depolama için ayrı bir altyapının yönetilmesi sorunu ve bunun sonucunda ortaya çıkan genel giderler ortadan kalkıyor.
Service Grid API'yi kullanarak, yalnızca dağıtım şemasını ve buna göre yapılandırmada hizmetin kendisini belirterek bir hizmeti dağıtabilirsiniz.
Tipik olarak bir dağıtım şeması, küme düğümlerine dağıtılması gereken bulut sunucusu sayısının bir göstergesidir. İki tipik dağıtım şeması vardır. Bunlardan ilki Cluster Singleton'dur: herhangi bir zamanda, bir kullanıcı hizmetinin bir örneğinin kümede mevcut olması garanti edilir. İkincisi Node Singleton'dur: hizmetin bir örneği her küme düğümüne dağıtılır.
Kullanıcı ayrıca tüm kümedeki hizmet örneklerinin sayısını belirtebilir ve uygun düğümlerin filtrelenmesi için bir koşul tanımlayabilir. Bu senaryoda Service Grid, hizmetlerin dağıtımı için en uygun dağıtımı kendisi hesaplayacaktır.
Ayrıca Affinity Hizmeti diye bir özellik var. Afinite, anahtarların bölümlerle ilişkisini ve topolojideki tarafların düğümlerle ilişkisini tanımlayan bir fonksiyondur. Anahtarı kullanarak verilerin depolandığı birincil düğümü belirleyebilirsiniz. Bu şekilde kendi hizmetinizi bir anahtar ve benzeşim işlevi önbelleğiyle ilişkilendirebilirsiniz. Benzeşim işlevi değişirse otomatik yeniden dağıtım gerçekleşir. Bu şekilde hizmet, her zaman işlemesi gereken verilere yakın konumlandırılacak ve buna bağlı olarak bilgiye erişim yükü de azalacak. Bu şemaya bir tür yan yana hesaplama denilebilir.
Artık Service Grid'in güzelliğinin ne olduğunu anladığımıza göre, onun gelişim geçmişinden bahsedelim.
daha önce ne vardı
Service Grid'in önceki uygulaması Ignite'ın işlemsel kopyalanmış sistem önbelleğine dayanıyordu. Ignite'taki "önbellek" kelimesi depolama anlamına gelir. Yani bu sanıldığı gibi geçici bir şey değil. Önbelleğin kopyalanmasına ve her düğümün tüm veri kümesini içermesine rağmen, önbelleğin içinde bölümlenmiş bir temsil vardır. Bunun nedeni depolama optimizasyonudur.
Kullanıcı hizmeti dağıtmak istediğinde ne oldu?
- Kümedeki tüm düğümler, yerleşik Sürekli Sorgulama mekanizmasını kullanarak depolamadaki verileri güncellemek için abone oldu.
- Başlatan düğüm, okunarak taahhüt edilen bir işlem altında, serileştirilmiş örnek de dahil olmak üzere hizmet yapılandırmasını içeren veritabanında bir kayıt yaptı.
- Yeni bir giriş bildirildiğinde koordinatör, konfigürasyona göre dağıtımı hesapladı. Ortaya çıkan nesne veritabanına geri yazıldı.
- Bir düğüm dağıtımın parçasıysa koordinatörün onu dağıtması gerekiyordu.
Bize uymayan şey
Bir noktada şu sonuca vardık: hizmetlerle çalışmanın yolu bu değil. Bunun birkaç nedeni vardı.
Dağıtım sırasında bir hata meydana gelirse, bu yalnızca her şeyin gerçekleştiği düğümün günlüklerinden öğrenilebilir. Yalnızca eşzamansız dağıtım vardı, bu nedenle dağıtım yönteminden kontrolü kullanıcıya geri verdikten sonra, hizmeti başlatmak için biraz ek süre gerekiyordu ve bu süre zarfında kullanıcı hiçbir şeyi kontrol edemiyordu. Service Grid'i daha da geliştirmek, yeni özellikler yaratmak, yeni kullanıcılar çekmek ve herkesin hayatını kolaylaştırmak için bir şeylerin değişmesi gerekiyor.
Yeni Service Grid'i tasarlarken her şeyden önce eşzamanlı dağıtım garantisi sağlamak istedik: Kullanıcı API'den kontrolü geri alır almaz hizmetleri hemen kullanabilir. Ayrıca başlatıcıya dağıtım hatalarını ele alma yeteneği vermek istedim.
Ayrıca uygulamayı basitleştirmek, yani işlemlerden ve yeniden dengelemeden uzaklaşmak istedim. Önbelleğin çoğaltılmasına ve dengeleme olmamasına rağmen, çok sayıda düğüm içeren büyük bir dağıtım sırasında sorunlar ortaya çıktı. Topoloji değiştiğinde düğümlerin bilgi alışverişinde bulunması gerekir ve büyük bir dağıtımda bu veriler çok ağır olabilir.
Topoloji kararsız olduğunda koordinatörün hizmetlerin dağıtımını yeniden hesaplaması gerekiyordu. Ve genel olarak, işlemlerle kararsız bir topoloji üzerinde çalışmak zorunda kaldığınızda, bu, tahmin edilmesi zor hatalara yol açabilir.
Sorunları
Sorunların eşlik etmediği küresel değişiklikler nelerdir? Bunlardan ilki topolojideki değişiklikti. Herhangi bir anda, hatta hizmet dağıtımı anında bile bir düğümün kümeye girebileceğini veya kümeden çıkabileceğini anlamalısınız. Ayrıca, dağıtım sırasında düğümün kümeye katılması durumunda, hizmetlerle ilgili tüm bilgilerin tutarlı bir şekilde yeni düğüme aktarılması gerekecektir. Ve sadece halihazırda konuşlandırılmış olanlardan değil, aynı zamanda mevcut ve gelecekteki konuşlandırmalardan da bahsediyoruz.
Bu, ayrı bir listede toplanabilecek sorunlardan sadece bir tanesidir:
- Düğüm başlangıcında statik olarak yapılandırılmış hizmetler nasıl dağıtılır?
- Bir düğümü kümeden bırakmak - düğüm hizmetleri barındırıyorsa ne yapmalısınız?
- Koordinatör değişirse ne yapmalı?
- İstemci kümeye yeniden bağlanırsa ne yapmalı?
- Etkinleştirme/devre dışı bırakma isteklerinin işlenmesi gerekiyor mu ve nasıl?
- Ya önbellek imhası çağrısında bulunurlarsa ve buna bağlı benzeşim hizmetlerimiz varsa?
Ve bu her şeyden uzak.
karar
Hedef olarak, mesajları kullanarak süreç iletişiminin uygulanmasıyla Olay Odaklı yaklaşımı seçtik. Ignite, düğümlerin kendi aralarında mesaj iletmesine olanak tanıyan iki bileşeni zaten uyguluyor: iletişim-spi ve keşif-spi.
Communication-spi, düğümlerin doğrudan iletişim kurmasına ve mesajları iletmesine olanak tanır. Büyük miktarda veri göndermek için çok uygundur. Discovery-spi, kümedeki tüm düğümlere mesaj göndermenize olanak tanır. Standart uygulamada bu, halka topolojisi kullanılarak yapılır. Zookeeper ile de entegrasyon mevcuttur, bu durumda yıldız topolojisi kullanılır. Dikkat edilmesi gereken bir diğer önemli nokta ise Discovery-Spi'nin mesajın tüm düğümlere kesinlikle doğru sırada iletileceğinin garantisini vermesidir.
Dağıtım protokolüne bakalım. Dağıtım ve dağıtımın kaldırılmasına ilişkin tüm kullanıcı istekleri, Discovery-spi aracılığıyla gönderilir. Bu aşağıdakileri verir önlemler:
- İstek, kümedeki tüm düğümler tarafından alınacaktır. Bu, koordinatör değiştiğinde isteğin işleme devam etmesine olanak tanıyacaktır. Bu aynı zamanda tek bir mesajda her düğümün, hizmet yapılandırması ve onun serileştirilmiş örneği gibi gerekli tüm meta verilere sahip olacağı anlamına da gelir.
- Mesaj tesliminin sıkı bir şekilde sıralanması, yapılandırma çakışmalarının ve rekabet eden isteklerin çözülmesine yardımcı olur.
- Düğümün topolojiye girişi de Discovery-Spi aracılığıyla işlendiğinden, yeni düğüm, hizmetlerle çalışmak için gerekli tüm verileri alacaktır.
Bir istek alındığında, kümedeki düğümler bunu doğrular ve işleme görevleri oluşturur. Bu görevler sıraya alınır ve daha sonra ayrı bir çalışan tarafından başka bir iş parçacığında işlenir. Bu şekilde uygulanır çünkü dağıtım önemli miktarda zaman alabilir ve pahalı keşif akışını dayanılmaz derecede geciktirebilir.
Kuyruktan gelen tüm istekler dağıtım yöneticisi tarafından işlenir. Bu kuyruktan bir görevi çeken ve dağıtıma başlamak için onu başlatan özel bir çalışana sahiptir. Bundan sonra aşağıdaki eylemler gerçekleşir:
- Yeni deterministik atama fonksiyonu sayesinde her düğüm, dağılımı bağımsız olarak hesaplar.
- Düğümler, dağıtımın sonuçlarını içeren bir mesaj oluşturur ve bunu koordinatöre gönderir.
- Koordinatör tüm mesajları toplar ve Discovery-Spi aracılığıyla kümedeki tüm düğümlere gönderilen tüm dağıtım sürecinin sonucunu oluşturur.
- Sonuç alındığında dağıtım işlemi sona erer ve ardından görev kuyruktan kaldırılır.
Yeni olay odaklı tasarım: org.Apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Dağıtım sırasında bir hata oluşursa, düğüm bu hatayı derhal koordinatöre gönderdiği mesaja dahil eder. Mesaj toplamanın ardından koordinatör, dağıtım sırasındaki tüm hatalar hakkında bilgi sahibi olacak ve bu mesajı Discovery-spi aracılığıyla gönderecektir. Hata bilgileri kümedeki herhangi bir düğümde mevcut olacaktır.
Servis Izgarasındaki tüm önemli olaylar bu işletim algoritması kullanılarak işlenir. Örneğin topolojinin değiştirilmesi de Discovery-Spi aracılığıyla gönderilen bir mesajdır. Ve genel olarak, öncekiyle karşılaştırıldığında protokolün oldukça hafif ve güvenilir olduğu ortaya çıktı. Dağıtım sırasında herhangi bir durumu ele almak için yeterlidir.
Sırada ne olacak?
Şimdi planlar hakkında. Ignite projesindeki herhangi bir büyük değişiklik, IEP adı verilen bir Ignite iyileştirme girişimi olarak tamamlanır. Service Grid'in yeniden tasarımı aynı zamanda bir IEP'ye sahiptir - "Servis Izgarasında yağ değişimi" alaycı başlığıyla. Ama aslında motor yağını değil, motorun tamamını değiştirdik.
IEP'deki görevleri 2 aşamaya ayırdık. Bunlardan ilki, dağıtım protokolünün yeniden çalışılmasını içeren büyük bir aşamadır. Zaten ana sürüme dahil edilmiştir, 2.8 sürümünde görünecek olan yeni Servis Izgarasını deneyebilirsiniz. İkinci aşama başka birçok görevi içerir:
- Sıcak yeniden konuşlandırma
- Hizmet sürümü oluşturma
- Artırılmış hata toleransı
- Zayıf müşteri
- Çeşitli ölçümleri izlemeye ve hesaplamaya yönelik araçlar
Son olarak, hataya dayanıklı, yüksek kullanılabilirliğe sahip sistemler oluşturmak için size Service Grid konusunda tavsiyelerde bulunabiliriz. Ayrıca sizi bizi ziyaret etmeye davet ediyoruz. и deneyiminizi paylaşın. Deneyiminiz topluluk için gerçekten önemlidir; bundan sonra nereye gideceğinizi, bileşeni gelecekte nasıl geliştireceğinizi anlamanıza yardımcı olacaktır.
Kaynak: habr.com
