Service Mesh, mikro hizmetleri entegre etmeye ve bulut altyapısına geçmeye yönelik iyi bilinen bir mimari modeldir. Bugün bulut konteyner dünyasında onsuz yapmak oldukça zordur. Piyasada çeşitli açık kaynaklı hizmet ağ uygulamaları mevcut ancak bunların işlevselliği, güvenilirliği ve güvenliği, özellikle ülke çapındaki büyük finans şirketlerinin gereksinimleri söz konusu olduğunda her zaman yeterli olmuyor. Bu nedenle biz Sbertech olarak Service Mesh'i özelleştirmeye karar verdik ve Service Mesh'in neyin iyi olduğu, neyin o kadar da iyi olmadığı ve bu konuda ne yapacağımız hakkında konuşmak istiyoruz.
Service Mesh modelinin popülaritesi, bulut teknolojilerinin popülaritesiyle birlikte artıyor. Farklı ağ hizmetleri arasındaki etkileşimi basitleştiren özel bir altyapı katmanıdır. Modern bulut uygulamaları, her biri binlerce kopyaya sahip olabilen bu tür yüzlerce hatta binlerce hizmetten oluşur.
Bu hizmetler arasındaki etkileşim ve bunların yönetimi, Hizmet Ağının önemli bir görevidir. Aslında bu, merkezi olarak yönetilen ve bir dizi çok yararlı işlevi yerine getiren birçok proxy'den oluşan bir ağ modelidir.
Proxy düzeyinde (veri düzlemi):
- Yönlendirme ve trafik dengeleme ilkelerini atama ve dağıtma
- Anahtarların, sertifikaların, jetonların dağıtımı
- Telemetri toplanması, izleme metriklerinin oluşturulması
- Güvenlik ve izleme altyapısıyla entegrasyon
Kontrol düzlemi seviyesinde:
- Yönlendirme ve trafik dengeleme ilkelerini uygulama
- Yeniden denemeleri ve zaman aşımlarını yönetme, "ölü" düğümleri tespit etme (devre kesme), ekleme hatalarını yönetme ve diğer mekanizmalar aracılığıyla hizmet esnekliğini sağlama
- Arama kimlik doğrulaması/yetkilendirmesi
- Bırakılan ölçümler (gözlemlenebilirlik)
Bu teknolojinin geliştirilmesiyle ilgilenen kullanıcı yelpazesi çok geniştir - küçük girişimlerden PayPal gibi büyük İnternet şirketlerine kadar.
Kurumsal sektörde Service Mesh'e neden ihtiyaç duyulur?
Hizmet Ağı kullanmanın pek çok açık faydası vardır. Her şeyden önce, geliştiriciler için oldukça uygundur: kod yazmak için bir teknoloji platformu ortaya çıkıyorTaşıma katmanının uygulama mantığından tamamen izole olması nedeniyle bulut altyapısına entegrasyonu önemli ölçüde basitleştiren.
Buna ek olarak, Service Mesh, tedarikçiler ve tüketiciler arasındaki ilişkiyi basitleştirir. Bugün, API sağlayıcıları ve tüketicilerin, özel bir entegrasyon aracısı ve hakemi olan kurumsal hizmet veriyolunu dahil etmeden, arayüzler ve sözleşmeler üzerinde kendi başlarına anlaşmaya varmaları çok daha kolaydır. Bu yaklaşım iki göstergeyi önemli ölçüde etkilemektedir. Yeni işlevselliği pazara sunma hızı (pazara çıkış süresi) artar, ancak aynı zamanda entegrasyonun bağımsız olarak yapılması gerektiğinden çözümün maliyeti de artar. Hizmet Ağının iş işlevselliği geliştirme ekipleri tarafından kullanılması burada dengenin korunmasına yardımcı olur. Sonuç olarak, API sağlayıcıları yalnızca hizmetlerinin uygulama bileşenine odaklanabilir ve bunu yalnızca Hizmet Ağı'nda yayınlayabilir - API anında tüm müşterilerin kullanımına sunulacak ve entegrasyon kalitesi üretime hazır olacak ve tek bir işlem gerektirmeyecek ek kod satırı.
Bir sonraki avantaj ise Geliştirici, Service Mesh'i kullanarak yalnızca iş işlevselliğine odaklanır — hizmetinin teknolojik bileşeninden ziyade ürüne. Örneğin, ağ üzerinden bir hizmetin çağrıldığı bir durumda, bir yerde bağlantı arızasının meydana gelebileceğini artık düşünmenize gerek yok. Ayrıca Service Mesh, aynı hizmetin kopyaları arasındaki trafiğin dengelenmesine yardımcı olur: kopyalardan biri "ölürse" sistem tüm trafiği kalan canlı kopyalara aktarır.
Hizmet Ağı - bu, dağıtılmış uygulamalar oluşturmak için iyi bir temeldirhem dahili hem de harici olarak hizmetlerine çağrı sağlamanın ayrıntılarını müşteriden gizleyen. Service Mesh'i kullanan tüm uygulamalar aktarım düzeyinde hem ağdan hem de birbirlerinden yalıtılmıştır: aralarında iletişim yoktur. Bu durumda geliştirici, hizmetleri üzerinde tam kontrol sahibi olur.
Unutulmamalıdır ki Dağıtılmış uygulamaların bir hizmet ağı ortamında güncellenmesi daha kolay hale gelir. Örneğin, kurulum için iki uygulama ortamının mevcut olduğu, biri güncellenmemiş ve bekleme modunda olan mavi/yeşil bir dağıtım. Başarısız bir sürüm durumunda önceki sürüme geri dönüş, Service Mesh'in iyi bir şekilde başa çıktığı özel bir yönlendirici tarafından gerçekleştirilir.. Yeni sürümü test etmek için şunu kullanabilirsiniz: kanarya salınımı — pilot müşteri grubundan gelen trafiğin veya isteklerin yalnızca %10'unu yeni sürüme geçirin. Ana trafik eski sürüme gidiyor, hiçbir şey bozulmuyor.
Ayrıca Service Mesh bize gerçek zamanlı SLA kontrolü sağlıyor. Dağıtılmış proxy sistemi, istemcilerden biri kendisine atanan kotayı aştığında hizmetin başarısız olmasına izin vermeyecektir. API verimi sınırlıysa, hiç kimse bunu çok sayıda işlemle bunaltamaz: Hizmet Ağı, hizmetin önünde durur ve gereksiz trafiğe izin vermez. Entegrasyon katmanında basitçe karşılık verecek ve hizmetler bunu fark etmeden çalışmaya devam edecek.
Bir şirket entegrasyon çözümlerinin geliştirilmesine yönelik maliyetleri azaltmak istiyorsa Service Mesh ayrıca şu konularda da yardımcı olur: Ticari ürünlerden açık kaynak versiyonuna geçebilirsiniz.. Enterprise Service Mesh'imiz, Service Mesh'in açık kaynaklı sürümünü temel alır.
Başka bir avantaj - tam teşekküllü tek bir entegrasyon hizmeti setinin kullanılabilirliği. Tüm entegrasyon bu ara katman yazılımı aracılığıyla oluşturulduğundan, şirketin iş çekirdeğini oluşturan uygulamalar arasındaki tüm entegrasyon trafiğini ve bağlantıları yönetebiliyoruz. Çok rahat.
Ve sonunda Service Mesh, bir şirketi dinamik bir altyapıya geçmeye teşvik eder. Artık birçoğu konteynerizasyona yöneliyor. Bir monolitin mikro hizmetlere bölünmesi, tüm bunların güzel bir şekilde uygulanması - konu artıyor. Ancak uzun yıllardır üretimde olan bir sistemi yeni bir platforma aktarmaya çalıştığınızda hemen bir takım sorunlarla karşılaşıyorsunuz: Hepsini konteynerlere itmek ve platforma dağıtmak kolay değil. Bu dağıtılmış bileşenlerin uygulanması, senkronizasyonu ve etkileşimi de çok karmaşık bir konudur. Birbirleriyle nasıl iletişim kuracaklar? Art arda başarısızlıklar yaşanacak mı? Service Mesh, ağ değişim mantığını unutabilmeniz nedeniyle bu sorunlardan bazılarını çözmenize ve eski mimariden yenisine geçişi kolaylaştırmanıza olanak tanır.
Neden Service Mesh özelleştirmesine ihtiyacınız var?
Şirketimizde yüzlerce sistem ve modül bir arada bulunmaktadır ve çalışma zamanı oldukça yüklüdür. Dolayısıyla bir sistemin diğerini çağırması ve yanıt alması şeklindeki basit bir model yeterli değildir, çünkü üretimde daha fazlasını isteriz. Kurumsal hizmet ağından başka neye ihtiyacınız var?
Olay işleme hizmeti
Müşterinin eylemlerini gerçek zamanlı olarak analiz eden ve ona hemen alakalı bir teklif sunabilen bir sistem olan gerçek zamanlı olay işleme yapmamız gerektiğini hayal edelim. Benzer işlevleri uygulamak için şunu kullanın: olay odaklı mimari (EDA) adı verilen mimari model. Mevcut Hizmet Ağlarının hiçbiri bu tür kalıpları yerel olarak desteklemiyor, ancak bu özellikle bir banka için çok önemlidir!
Uzaktan Yordam Çağrısının (RPC) Service Mesh'in tüm sürümleri tarafından desteklenmesi oldukça gariptir, ancak bunlar EDA ile uyumlu değildir. Çünkü Service Mesh, bir tür modern dağıtılmış entegrasyondur ve EDA, müşteri deneyimi açısından benzersiz şeyler yapmanıza olanak tanıyan çok alakalı bir mimari modeldir.
Kurumsal Hizmet Ağımız bu sorunu çözmelidir. Ek olarak, çeşitli filtreler ve şablonlar kullanarak garantili teslimat, akış ve karmaşık olay işlemenin uygulanmasını da görmek istiyoruz.
Dosya aktarım hizmeti
EDA'ya ek olarak dosyaları aktarabilmek de güzel olurdu: Kurumsal ölçekte çoğu zaman yalnızca dosya entegrasyonu mümkündür. Özellikle ETL (Extract, Transform, Load) mimari deseni kullanılmaktadır. Kural olarak, herkes yalnızca dosya alışverişinde bulunur: ayrı istekleri iletmek pratik olmayan büyük veriler kullanılır. Kurumsal Hizmet Ağı'nda dosya aktarımlarını yerel olarak destekleme yeteneği, size işletmenizin ihtiyaç duyduğu esnekliği sağlar.
Orkestrasyon hizmeti
Büyük organizasyonlarda neredeyse her zaman farklı ürünler üreten farklı ekipler bulunur. Örneğin bir bankada bazı ekipler mevduatla, bazıları ise kredi ürünleriyle çalışıyor ve bu tür durumların sayısı oldukça fazla. Bunlar, ürünlerini üreten, API'lerini geliştiren ve bunları başkalarına sağlayan farklı insanlar, farklı ekiplerdir. Ve çoğu zaman bu hizmetleri oluşturmaya ve bir dizi API'yi sırayla çağırmak için karmaşık mantığı uygulamaya ihtiyaç vardır. Bu sorunu çözmek için entegrasyon katmanında tüm bu bileşik mantığı basitleştirecek (birkaç API'yi çağırma, istek yolunu tanımlama vb.) bir çözüme ihtiyacınız var. Bu, Kurumsal Hizmet Ağı'ndaki düzenleme hizmetidir.
Yapay zeka ve makine öğrenimi
Mikro hizmetler tek bir entegrasyon katmanı aracılığıyla iletişim kurduğunda, Hizmet Ağı doğal olarak her hizmetin çağrılarıyla ilgili her şeyi bilir. Telemetri topluyoruz: Kim kimi, ne zaman, ne kadar süreyle, kaç kez aradı vb. Bu hizmetlerden yüzbinlerce ve milyarlarca çağrı olduğunda tüm bunlar birikerek Büyük Veriyi oluşturur. Bu veriler yapay zeka, makine öğrenimi vb. kullanılarak analiz edilebilir ve ardından analiz sonuçlarına göre bazı yararlı şeyler yapılabilir. Service Mesh'e entegre edilen tüm bu ağ trafiğinin ve uygulama çağrılarının kontrolünün en azından kısmen yapay zekaya devredilmesi uygun olacaktır.
API Ağ Geçidi Hizmeti
Tipik olarak bir Hizmet Ağı, güvenilir bir çevre içinde birbirleriyle konuşan proxy'lere ve hizmetlere sahiptir. Ancak dışarıdan karşı taraflar da var. Bu tüketici grubuna sunulan API'lere yönelik gereksinimler çok daha katıdır. Bu görevi iki ana bölüme ayırıyoruz.
- güvenlik. Ddos, protokollerin, uygulamaların, işletim sistemlerinin vb. güvenlik açığı ile ilgili sorunlar.
- ölçek. İstemcilere sunulması gereken API'lerin sayısı binlerce, hatta yüzbinlere ulaştığında, bu API kümesi için bir tür yönetim aracına ihtiyaç duyulur. API'yi sürekli izlemeniz gerekir: çalışıp çalışmadıkları, durumlarının ne olduğu, hangi trafiğin aktığı, hangi istatistikler vb. Bir API ağ geçidi, tüm süreci yönetilebilir ve güvenli hale getirirken bu görevi de üstlenmelidir. Bu bileşen sayesinde Enterprise Service Mesh, hem dahili hem de harici API'leri kolayca yayınlamayı öğrenir.
Belirli protokoller ve veri formatları için destek hizmeti (AS ağ geçidi)
Şu anda çoğu Hizmet Ağı çözümü yerel olarak yalnızca HTTP ve HTTP2 trafiğiyle veya TCP/IP düzeyinde azaltılmış modda çalışabilir. Kurumsal Hizmet Ağı, diğer birçok özel veri aktarım protokolüyle birlikte ortaya çıkıyor. Bazı sistemler mesaj aracılarını kullanabilir, bazıları ise veritabanı düzeyinde entegre edilmiştir. Şirketin SAP'si varsa kendi entegrasyon sistemini de kullanabilir. Üstelik tüm bunlar işe yarıyor ve işin önemli bir parçası.
Sadece şunu söyleyemezsiniz: "Eskiyi bırakalım ve Service Mesh'i kullanabilen yeni sistemler yapalım." Tüm eski sistemleri yenileriyle (mikro hizmet mimarisinde) bağlamak için, Service Mesh'i kullanabilen sistemlerin bir tür adaptöre, aracıya, ağ geçidine ihtiyacı olacaktır. Katılıyorum, servisle birlikte bir kutuda gelse güzel olurdu. AC ağ geçidi herhangi bir entegrasyon seçeneğini destekleyebilir. Enterprise Service Mesh'i yüklediğinizi ve ihtiyacınız olan tüm protokollerle etkileşime geçmeye hazır olduğunu hayal edin. Bu yaklaşım bizim için çok önemli.
Service Mesh'in (Enterprise Service Mesh) kurumsal versiyonunu kabaca bu şekilde hayal ediyoruz. Açıklanan özelleştirme, entegrasyon platformunun hazır açık kaynaklı sürümlerini kullanmaya çalışırken ortaya çıkan sorunların çoğunu çözmektedir. Sadece birkaç yıl önce tanıtılan Service Mesh mimarisi gelişmeye devam ediyor ve biz de onun gelişimine katkıda bulunabildiğimiz için heyecanlıyız. Deneyimlerimizin sizin için yararlı olacağını umuyoruz.
Kaynak: habr.com