turuncukafalikiz
New member
Mikro Ön Uç: Ön uçtaki mikro hizmetler
Mikro ön uçlar, yalnızca tamamen farklı bir ortamda mikro hizmetlere benzer bir yaklaşım benimser. Bu nedenle, kavram ve uygulamaya yönelik değiştirilmiş bir yaklaşımın yanı sıra başka avantajlar ve dezavantajlar da vardır.
Sunucu tarafında, mikro hizmetler mimarisi modeli, özellikle büyük uygulamalar için yekpare bir yaklaşıma alternatif olarak kendini kanıtlamıştır. Geliştiriciler artık mikro ön uçlarda da benzer bir hedefi ön uçta takip ediyor. Bunun arkasındaki fikir, mikro hizmetlerin bazı faydalarını ön uçta da kullanılabilir hale getirmektir. Ancak, mikro önyüzlerin web önyüz geliştirme için yeni standart haline gelip gelmeyeceği sorusuna geçmeden önce, mikro hizmet mimarisine bir göz atalım.
Mikro hizmetler ve ön uçla ne yapmaları gerektiği
Mikro hizmetlerin arkasındaki fikir, büyük bir sorunu birkaç alt soruna bölmek ve bunları ayrı ayrı ele almaktır. Bu mimari yaklaşım, uygulamaların olağan modülerleştirilmesinden bir adım daha ileri gider, çünkü bir uygulama içindeki teknik sınırlarda kesim yapılmaz, ancak her şey daha da ileri gider ve alanları arayüzlerle birbirine bağlanan bağımsız bağımsız sistemlere böler. Böyle bir mikro hizmet mimarisinden elde edilen avantajlar şunlardır:
- Ölçeklenebilirlik: Tek parçadan farklı olarak, bireysel mikro hizmetler birbirinden bağımsız olarak ölçeklenebilir. Bir hizmet yük altındaysa ek bulut sunucuları başlatılır, diğer tüm hizmetler bu değişiklikten etkilenmez.
- Sağlamlık: Bir hizmetin başarısız olması, tüm sistemin başarısız olmasına yol açmayabilir. Servisler birbirinden net bir şekilde ayrıldığı için arızalanan servisi yeniden başlatmak veya alternatifler sunmak mümkündür.
- Basitlik: Küçük bir hizmetin karmaşıklığı, bir uygulamanın tüm fonksiyonlarını kapsayan bir monolitin karmaşıklığından önemli ölçüde daha azdır. Bu, geliştiricilere, büyük ve tutarlı bir yapıyla mümkün olandan çok daha iyi bir genel bakış sağlar.
- Esneklik: Göz ardı edilmemesi gereken, bir mikro hizmet mimarisinde bir görev için en iyi aracı seçme yeteneğidir. Hizmetler birbirinden bağımsız olduğundan, örneğin bir hizmeti Go’da, başka bir hizmeti JavaScript’te ve üçüncüsünü Kotlin’de uygulamanın yanlış bir tarafı yoktur.
Mikro ön uçlar, mikro hizmetlere benzer bir yaklaşım sergiler, ancak tamamen farklı bir ortamda. Bu, mimari formun farklı bir şekilde değerlendirilmesine neden olur. Çok sayıda uygulama için bir mikro hizmet mimarisinin faydalı olduğu durumlarda, mikro ön uçlar için kullanım durumları çok daha sınırlıdır.
Ama önce, ön uç ile arka uç arasındaki temel farklara ve bunların mimariyi nasıl etkilediklerine bakalım. Tarayıcı, bir uygulamayı tek bir örnek olarak çalıştırır. Tersine, arka uç hizmetleri birbirinden bağımsızdır (böylece birden çok örneğiniz olur). Bu, esas olarak uygulamanın ölçeklenebilirliğini etkiler. En yüksek yük durumunda, arka uç altyapısı etkilenen hizmetlerin ek örneklerini başlatır ve yükü buna göre dağıtır. Elbette, tarayıcı yük altındaysa, uygulamanın yeni bir örneğiyle başka bir tarayıcı penceresi açmanın çok az anlamı vardır. Tarayıcı, yalnızca işlemeden izole edilmiş ve yalnızca hesaplamalar ve sunucuyla iletişim için kullanılabilen çalışan işlemlere erişebilir.
Ön ucun ve arka ucun ölçeklendirme davranışı bu nedenle temelde farklıdır. Dayanıklılık söz konusu olduğunda da ciddi farklılıklar vardır – burada genellikle evcil hayvanlara karşı sığır imajı kullanılır, yani evcil hayvanlar ve çiftlik hayvanları arasındaki fark. Bir mikro hizmet mimarisinde, bireysel örnekler, platform operatörlerinin biraz mesafeli bir ilişki sürdürmesi gereken sığır gibidir. Bir hizmet çökerse, yeni bir örnekle değiştirilir. Bu yaklaşım, yalnızca bir ana işlem olduğundan tarayıcıda uygulanamaz. Bu nedenle, geliştiriciler, kapsamlı hata işleme özelliğine sahip bir evcil hayvan gibi onu sevmeli ve ona özen göstermelidir.
Sadelik teması hem ön uç hem de arka uç için geçerlidir. Kendi başlarına duran daha küçük birimlerin her iki dünyada da yönetilmesi, iç içe geçmiş büyük ölçekli yapılardan çok daha kolaydır. Bir mikro hizmet mimarisinin dil ve teknoloji seçimi konusunda arka uçta sunduğu esnekliğin ön uçta da farklı görülmesi gerekir. Arka uçta, geliştiriciler ilgili problem için doğru programlama dili, çerçeve ve kitaplık kombinasyonunu seçebilirler. Tarayıcı, bu seçimi ön uçta ciddi şekilde sınırlar. JavaScript ve küçük bir ölçüde WebAssembly dışında, diğer programlama dillerine doğrudan izin vermez. Buradaki tek istisna, Blazor biçimindeki TypeScript, CoffeeScript veya C# gibi JavaScript’e veya WebAssembly’ye çevrilmiş dillerdir.
Geriye kalan tek şey, bu alanda kesinlikle çok geniş olan kitaplıkların ve çerçevelerin seçimidir. Bir uygulama birden çok küçük parçadan oluşuyorsa ve bunlar farklı kitaplıklar ve çerçeveler kullanılarak uygulanıyorsa, tarayıcı, uygulamayı görüntülemek için gereken kaynakları sunucudan yükler; bu, geleneksel olarak yekpare bir uygulamaya kıyasla çok fazla ek yük olabilir.
Mikro ön uç uygulaması oluşturma
Bir mikro ön uç mimarisinde, uygulama birkaç bağımsız mikro ön uçtan oluşur. Bu bireysel bileşenler bir entegrasyon katmanında birleştirilir. Bu gereklidir, çünkü tarayıcının başlangıçta sunucudan yüklemesi için her zaman bir belge vardır. Bir ön uç mikro mimarisi kurarken, aynısı arka uçtaki mikro hizmetler için de geçerlidir: onu uygulamanın doğru bir yolu yoktur, bunun yerine bu tür mimarinin çok sayıda yönü vardır.
En kolay seçenek, iFrame’leri kullanarak bireysel mikro ön uçları yerleştirmektir. Bu varyant özellikle zarif olmasa da, uygulamanın ayrı parçalarının etkin bir şekilde birbirinden bağımsız olmasını sağlar. Diğer seçenekler arasında web bileşenlerinde mikro ön uçların kapsanması veya farklı ön uç çerçevelerinin tek bir uygulamada barış içinde bir arada var olmasına izin veren single-spa gibi ek kitaplıkların kullanılması yer alır.
Farklı kitaplıklara sahip mikro ön uçları uygularken büyük bir sorun, daha önce belirtilen paket boyutudur, çünkü en kötü durumda birkaç tam çerçevenin paralel olarak sağlanması gerekir. Bu sorun yalnızca iki şekilde çözülebilir: ya daha büyük kitaplıklar kullanılmaz ya da bireysel mikro ön uçların geliştirme ekipleri belirli kurallar üzerinde anlaşırlar. Bu şekilde, yalnızca bir çerçevenin kullanımını belirlemek mümkündür ve bu nedenle ekipler tamamen bağımsız uygulamalar geliştirmez, bunun yerine entegrasyon katmanının bir araya getirdiği modüller geliştirir. Bu tür bir mimarinin geliştirme süreci bu nedenle tavizler ve tam esneklik ile konvansiyon tarafından dayatılan kısıtlamalar arasında bir dengeleme hareketi ile karakterize edilir. Prosedürün somut yönü, büyük ölçüde kullanım amacına ve genel uygulamanın genel koşullarına bağlıdır.
Mikro ön uç veya mikro ön uç yok, soru bu
Geliştirilmekte olan hemen hemen her konuda olduğu gibi, mikro ön uçlar da tutkulu tartışmaların konusudur. Ve çoğu zaman olduğu gibi, herkes bu mimari forma var olma hakkını vermeli. Elbette, mikro ön uçlar tüm web geliştirme sorunlarını çözen sihirli değnek değildir. Ancak bir mikro ön uç mimarisi, özellikle birden fazla ekibin dahil olduğu büyük uygulamalar için potansiyel bir çözüm olabilir.
Mikro ön uçların gerçekten güçlü yanlarını gösterdiği bir senaryo, geçişlerdir. Mevcut bir uygulama zirve noktasını geçtiyse, bakım ve daha fazla geliştirme maliyetleri önemli ölçüde artar ve bu tür yetişkin yazılımlar üzerinde çalışmak artık geliştirici için gerçek bir zevk değildir. Yani bir noktada yeniden yazma sorusu ortaya çıkıyor. Bununla birlikte, bir uygulamayı yeniden yazmak, girişimin başarısız olmasına bile yol açabilecek önemli riskler içerir.
Mikro ön uç mimarisi kullanarak eski yazılımı yeni sürüme geçirmek, riski yönetmenin bir yoludur. Bunu yapmak için, geliştiriciler önce mevcut yazılımın gömülü olduğu entegrasyon katmanını oluşturur ve böylece eskisi gibi çalışır. Ardından, özellikleri kademeli olarak yeni sürümlerle değiştirmeye başlayabilirler. Entegrasyon katmanı daha sonra kullanıcıların yeni sürümü almasını sağlar ve eski sürüm devre dışı bırakılır.
Tüm işlevler taşınır taşınmaz, eski uygulama silinebilir ve artık ihtiyaç duyulmadığında entegrasyon katmanı da kaldırılabilir. Bu yaklaşımın avantajı, büyük bir patlama olmaması, geçişin kademeli olması ve yeni özelliklerin geliştirilmesinin durması gerekmemesidir.
Son olarak, söylenecek tek şey, her ekibin uygulamalarının mimarisi hakkında kendi kararlarını vermesi gerektiğidir. Ancak, mümkün olduğu kadar çok alternatif bilmek ve en iyisini seçmek yardımcı olur. Bu nedenle, keskin modüler bir monolit mi yoksa mikro ön uç mimarisi mi olduğu, soruna ve geliştiricilerin tercihlerine bağlıdır.
()
ana sayfaya