Mikro Ön Uç Geçiş Yolculuğu - Bölüm 1: Tasarım

Çeviklik ve ölçeklenebilirliğin çok önemli olduğu günümüzün hızlı ilerleyen dijital dünyasında, işletmeler sürekli olarak web uygulamalarının performansını ve sürdürülebilirliğini iyileştirmenin yollarını arıyor.

Bu hedeflere ulaşmaya yönelik popüler yaklaşımlardan biri, monolitik bir mimariden dağıtılmış bir mimariye (veya mikro ön uç) geçiş yapmaktır. "Mikro-Ön Uç Geçiş Yolculuğu" başlıklı bu makale dizisi, AWS'de geçirdiğim süre boyunca bu tür bir geçişi gerçekleştirme konusundaki kişisel deneyimimi paylaşıyor.

SORUMLULUK REDDİ : Başlamadan önce, bu makale kişisel deneyimimi paylaşsa da, AWS'deki veya başka herhangi bir kuruluştaki araçlara, teknolojilere veya belirli süreçlere ilişkin herhangi bir tescilli veya dahili ayrıntıyı açıklayamayacağımı belirtmek önemlidir.

Yasal yükümlülüklere uymaya ve bu makalenin yalnızca mikro ön uç geçiş yolculuğunda yer alan genel kavram ve stratejilere odaklanmasını sağlamaya kararlıyım.

Amaç, herhangi bir gizli bilgiyi ifşa etmeden, daha geniş bir bağlamda uygulanabilecek içgörüleri ve öğrenilen dersleri sağlamaktır.

Göç Motivasyonu

Mikro ön uçları (sanırım çoğunuz gibi) Martin Fowler'ın blogundaki makaleden öğrendim. Mikro ön uç mimarisini çerçeveden bağımsız bir şekilde oluşturmanın farklı yollarını sundu.

Konunun derinliklerine indikçe mevcut monolitik mimarimizin ekibimizin üretkenliği açısından önemli bir darboğaz haline geldiğini ve uygulamamızın genel performansını engellediğini fark ettim.

Beni geçişi düşünmeye iten temel faktörlerden biri uygulamamızın artan paket boyutuydu.

2020 yazında kapsamlı bir paket analizi yaptıktan sonra, 2019'un başlarındaki ilk lansmanından bu yana paket boyutunun (gzip'li) 450 KB'den 800 KB'ye (neredeyse 4 MB ayrıştırılmıştır) çıktığını, yani orijinal boyutun neredeyse iki katına çıktığını keşfettim.

Hizmetimizin başarısı göz önüne alındığında ve sürekli büyümesini öngördüğümüzde, bu eğilimin devam edeceği ve uygulamamızın performansını ve sürdürülebilirliğini daha da etkileyeceği açıktı.

Mikro ön uçlar kavramı konusunda heyecanlı olsam da karşılaştığımız belirli zorluklar nedeniyle bunları benimsemeye henüz hazır olmadığımızı da fark ettim:

1. Küçük Organizasyon Yapısı: Analizim sırasında organizasyonumuz nispeten küçüktü ve takımdaki tek tam zamanlı ön uç mühendisiydim. Mikro ön uç mimarisine geçiş, organizasyon yapısı ve operasyonel temel açısından önemli bir yatırım gerektiriyordu.

   
   

   Dağıtılmış mimariyi etkili bir şekilde yönetebilecek ve farklı ön uç bileşenleri arasındaki bağımlılıkları yansıtabilecek olgun bir yapıya sahip olmak çok önemliydi.

   
   

2. Sınırlı İş Etki Alanı: Mikro ön uçlar sınırlı bağlamlara ve iş yeteneklerine göre bölünebilse de (" Mikro ön uç mimarisinde Etki Alanı Odaklı Tasarım" yazısında daha fazla bilgi edinin) temel iş alanımız, tamamen ayrılmayı haklı çıkaracak kadar kapsamlı değildi. çoklu mikro ön uçlar. Ancak uygulama içinde, dağıtılmış bir mimariye geçiş yapmak ve bu mimariye geçiş yapmak mantıklı olan görünür sınırlar vardı.

Bu faktörler göz önüne alındığında kademeli bir yaklaşımın gerekli olduğunu fark ettim. Mikro ön uçlara tam bir geçiş yapmak yerine, uygulamamız içinde dağıtılmış bir mimariden yararlanabilecek belirli alanları belirlemeyi hedefledim.

Bu, genel organizasyon yapısını bozmadan veya iş alanımızın bütünlüğünden ödün vermeden performans ve ölçeklenebilirlik endişelerini gidermemize olanak tanıyacaktır. Bu aynı zamanda bize ekibi büyütmek ve iş yönlerini gözlemlemek için biraz zaman tanıyacaktır.

Uygulamanın performans (paket boyutu) sorununu yalnızca mciro-ön uç mimarisini kullanarak çözmek istiyorsanız, bunun en iyi fikir olmayabileceğini lütfen unutmayın. Bunun yerine tembel yüklemeden (dinamik içe aktarma) yararlanacak dağıtılmış monolit mimariyle başlamak daha iyi olacaktır.

Dahası, mikro ön uç mimarisinin, satıcı parçalarına ayrılmayacak bazı paylaşılan kodlara sahip olma ihtimalinin çok yüksek olduğunu ve uygulama paketine yerleştirileceğini göz önünde bulundurarak, paket boyutu sorunlarını mikro ön uç mimarisinden daha incelikli bir şekilde ele alacağını düşünüyorum ( bu, bu tür dağıtılmış mimarinin dezavantajlarından biridir; neyi, ne zaman ve nasıl paylaşacağınız arasında bir denge kurmanız gerekir).

Ancak dağıtılmış monolit mimari, mikro ön uç kadar iyi ölçeklenmeyecektir. Kuruluşunuz hızlı büyüdüğünde ekibiniz de muhtemelen aynı hızda büyüyecektir.

Kod tabanını farklı ekipler tarafından kontrol edilen farklı sahiplik alanlarına bölmek önemli bir ihtiyaç olacaktır.

Ve her ekibin diğerlerinden bağımsız olan kendi sürüm döngülerine sahip olması gerekecektir; her ekip, kod tabanlarının yalnızca kendi alanlarına odaklanıp odaklanmayacağını takdir edecek ve hızlı bir şekilde oluşturacaktır (kod yalıtımı -> daha iyi bakım kolaylığı/sürdürülmesi gereken daha az kod ve build -> daha iyi test edilebilirlik/bakım ve yürütme için daha az test).

Başlangıç

Liderlikten destek almak için, web hayati ölçümleri de dahil olmak üzere kapsamlı bir performans analizini kapsayan ve dağıtılmış ön uçlara geçişin çeşitli aşamalarının ana hatlarını çizen ikna edici bir teknik vizyon belgesi hazırladım.

Bu geçişin ara aşamalarından biri, çekirdek hizmet ile widget'lar arasında S3 klasörü ve CDN gibi paylaşılan altyapıdan yararlanırken birden fazla modülün/widget'ın tembel yükleme teknikleri yoluyla eşzamansız olarak teslim edilebildiği dağıtılmış bir monolit mimari oluşturmaktı. .

Önceki makalemde de belirttiğim gibi, bu tür bir belgenin ana fikri, geleceği, hedeflere ulaşıldığında ve en büyük sorunlar çözüldükten sonra olmasını istediğiniz gibi tanımlamaktır. Bunun idam planıyla alakası yok!

Neredeyse 1 yıl sonra nihayet mikro ön uç geçiş planımı uygulamaya koymanın zamanı gelmişti. Yeni bir alana genişlemenin yaklaşması ve elimizde daha büyük bir ekip olması nedeniyle, geçişi gerçekleştirmek için iyi donanıma sahiptik.

Kaçırmayı göze alamayacağımız altın bir fırsat gibi geldi.

Sonuçta yekpare mimariyle sınırlı kalmak, sürekli olarak onun sınırlamalarıyla boğuşmak anlamına gelecektir.

Yeni bir alana genişlemeye yönelik sınırlı zaman çizelgesi, katalizör görevi görerek bizi kısa ve yavaş yinelemeler yerine daha ölçeklenebilir ve sürdürülebilir bir mimari oluşturmaya doğru itti!

Taşıma işlemini gerçekleştirmek ve aynı anda yeni alandaki çalışmayı yürütmek için ekipleri iki özel gruba ayırdık. Daha yüksek önceliğe sahip olan özellik çalışması daha fazla kaynak gerektiriyordu ve daha hızlı yinelenmesi gerekiyordu.

Geçiş sürecinin bütünlüğünü ve kapsamlı bir şekilde anlaşılmasını sağlamak için, özellikle geçişin yönetilmesinden sorumlu küçük bir özel ekibin atanması mantıklıydı.

Ancak mikro ön uç konseptinin başarılı olacağından emin olmadan özellik çalışmasına devam edemezdik.

Riskleri azaltmak ve net bir yol haritası sağlamak için kesin tahminler ve kapsamlı bir risk değerlendirmesi içeren düşük düzeyli bir tasarım belgesi oluşturmak çok önemliydi. Bu belge, geçiş için gerekli adımları ve dikkat edilmesi gereken noktaları özetleyen bir plan görevi gördü.

Bu süreçteki en önemli kilometre taşı, tüm bileşenlerin tasarıma göre başarılı bir şekilde entegre edildiğini gösteren bir kavram kanıtlamanın geliştirilmesiydi.

Uygun bir şekilde "Geri Dönüşü Olmayan Nokta" olarak adlandırılan bu dönüm noktası, mikro ön uç mimarisinin fizibilitesini ve etkinliğini doğrulamayı amaçlıyordu.

Geçişin başarısı konusunda iyimser olsam da beklenmedik durumlara karşı hazırlıklı olmak çok önemliydi. Sonuç olarak, başlangıçtaki konseptin istenen sonuçları vermemesi durumunda yedek strateji görevi görecek bir B Planı geliştirdim.

Bu, tahminlerde özellikle yastığa ağlamam için ek bir yedi gün ve tembel yükleme yoluyla çekirdeğe bağlanan yeni bir özellik modülü girişi için birkaç gün ayırmayı içeriyordu (dağıtılmış monoliti hatırladın mı?).

Dizayn

Mikro ön uçları tasarlarken kompozisyon için genellikle 3 yaklaşım vardır ve her biri çalışma zamanı uygulama çözünürlüğünün nerede gerçekleştiğine odaklanır. Bu yaklaşımların güzelliği, birbirlerini dışlamamaları ve gerektiğinde birleştirilebilmeleridir.

Sunucu Tarafı Kompozisyonu

Temel fikir, mikro ön uç paketlerini sayfa başına bölmek için bir ters proxy sunucusundan yararlanmak ve rota URL'sine göre sabit sayfa yeniden yüklemesi yapmaktır.

Artıları:

• Uygulaması basit

Eksileri:

• Küresel durum, mikro ön uç uygulamalar arasında senkronize edilmeyecektir. Bu bizim için kesinlikle yapılmaması gereken bir noktaydı çünkü müşteri tarafında uzun süredir devam eden arka plan operasyonlarımız vardı.

  
  

  Bu operasyonun "sırasının" anlık görüntüsünü yerel depolamaya saklayabileceğimizi ve donanımsal yeniden yüklemeden sonra buradan okuyabileceğimizi iddia edebilirsiniz, ancak güvenlik nedenlerinden dolayı bunu uygulayamadık.

  
  

  Bu, küresel durumun yalnızca bir örneğidir, ancak nasıl görünebileceğine dair başka bir örnek: sidenav panellerinin durumu (genişletilmiş/daraltılmış), tost mesajları vb.

• Mikro uygulamalar arasında gezinirken yapılan sert yenileme, müşteri dostu değildir. Hizmet çalışanlarını kullanarak paylaşılan HTML'yi önbelleğe almanın bir yolu vardır, ancak bunun sürdürülmesi ek karmaşıklıktır.

• Altyapı için ek işletme ve bakım maliyetleri: her mikro ön uç uygulaması için proxy sunucusu (doğrudan CDN'den okunursa bu önlenebilir), birden fazla sayfa tarafından yeniden kullanılacak ortak (satıcı) bağımlılıkları dağıtmak için ayrı altyapı ve uygun şekilde tarayıcılar tarafından önbelleğe alınır.

Kenar Tarafı Kompozisyonu

Mikro ön uç bileşimine yönelik başka bir yaklaşım, CDN gibi mikro ön uçların kenar katmanında birleştirilmesini içeren kenar yan bileşimidir. Örneğin Amazon CloudFront, Lambda@Edge entegrasyonunu destekleyerek mikro ön uç içeriğini okumak ve sunmak için paylaşılan bir CDN kullanımına olanak tanır.

Artıları:

• Bakımı gereken daha az altyapı parçası: proxy sunuculara gerek yok, her mikro uygulama için ayrı CDN'ler

• Sunucusuz teknolojiyi kullanarak neredeyse sonsuz ölçeklendirme

• Bağımsız proxy sunuculara kıyasla daha iyi gecikme süresi

Eksileri:

• Soğuk başlatma zamanı sorun haline gelebilir

• Çok bölgeli (yalıtımlı) altyapıya ihtiyacınız varsa Lambda@Edge tüm AWS bölgelerinde desteklenmez

İstemci Tarafı Kompozisyonu

İstemci tarafı kompozisyonu, sunucu uygulamasından ayrılmış, istemci tarafı mikro ön uç düzenleme tekniklerini kullanan, mikro ön uç mimarisine yönelik başka bir yaklaşımdır.

Bu mimarideki kilit oyuncu, aşağıdaki sorumluluklara sahip bir konteyner (kabuk) uygulamasıdır:

• Kesişen endişelerin ele alınması: Konteyner uygulaması, merkezi uygulama düzenini, site navigasyonunu, alt bilgiyi ve yardım panelini yönetir. Kesişen endişelere sahip mikro ön uçlarla entegrasyon, sentetik olayların küresel pencere kapsamında gönderildiği ve işlendiği bir Olay Veriyolu aracılığıyla gerçekleşir.

• Mikro ön uçların düzenlenmesi: Container uygulaması, uygulamanın gereksinimlerine ve kullanıcı etkileşimlerine göre hangi mikro ön uç paketinin ne zaman yükleneceğini belirler.

• Küresel bağımlılıkların oluşturulması: Konteyner uygulaması, React, SDK'lar ve UI kitaplıkları gibi tüm küresel bağımlılıkları oluşturur ve bunları mikro ön uçlar arasında paylaşılabilecek ayrı bir paket (vendor.js) olarak sunar.

Genel fikir, her bir mikro ön uç paketinin 2 tür varlık dosyası üreteceğidir:

• {hash}/index.js: Bu, mikro ön uç uygulaması için giriş noktası görevi görür ve karma, yapının tamamı için benzersiz bir tanımlayıcıyı temsil eder.

  
  

  Hash, S3 klasöründeki her paket için bir önek anahtarı görevi görür. Birden fazla giriş noktasının mevcut olabileceğini ancak hash'in hepsi için aynı kaldığını unutmamak önemlidir.

• manifest.json: Bu, mikro ön uç uygulamasının tüm giriş noktalarına giden yolları içeren bir bildirim dosyasıdır. Bu dosya her zaman S3 klasörünün kökünde kalır, böylece kapsayıcı onu kolayca bulabilir.

  
  

  Değişikliklerin daha iyi gözlemlenebilmesi için S3 klasöründe bu dosyanın sürümlendirmesini açmanızı öneririm. Projenizi oluşturmak için Webpack kullanıyorsanız, tüm ağır işleri sizin için yapan WebpackManifestPlugin'i şiddetle tavsiye ederim.

Kapsayıcı, aşamaya ve bölgeye bağlı olarak yalnızca mikro ön uç varlık kaynağı alan adı URL'sinden (CDN kaynağı) haberdar olur. İlk sayfa yüklemesi sırasında kapsayıcı, her mikro ön uç uygulamasının bildirim dosyasını indirir.

Bildiri dosyası, sayfa yükleme süresini etkilememek için küçük boyuttadır (~100 bayt) ve birden fazla mikro ön uç tek bir kapsayıcıda toplandığında bile iyi ölçeklenir. Agresif önbelleğe almayı önlemek için manifest dosyasını tarayıcının önbellek deposunda değişmez olarak kabul etmek çok önemlidir.

Doğru orkestrasyon kütüphanesini seçmek bu kompozisyondaki en büyük zorluktur ve bir sonraki bölümde tartışılacaktır.

Artıları:

• Sunucu uygulamasından bağımsız: Bu yaklaşım, herhangi bir özel sunucu gereksinimi olmadan uygulanabilir ve kullanılan arka uç teknolojisinde esneklik sunar. Yukarıdaki resimde gösterildiği gibi herhangi bir sunucunuz bile olmayabilir

• Küresel durumun korunması: Bir konteyner (kabuk) uygulaması kullanılarak mikro ön uçlar arasında geçiş yapılırken küresel durum korunabilir. Bu, kusursuz bir kullanıcı deneyimi sağlar ve geçişler sırasında bağlamın kaybolmasını önler.

• Merkezi olmayan yaklaşım: Her mikro ön uç, kendisini önyüklemek için tarayıcıya hangi verilerin gönderileceğine bağımsız olarak karar verebilir. Konteyner uygulaması iyi tanımlanmış bir sözleşmeyi takip ederek daha fazla özerklik ve modülerlik sağlar.

• Basit yerel kurulum: Varlık kaynakları, geliştirme ihtiyaçlarına göre üretim ve yerel URL'ler arasında kolayca ayarlanabilir. Bildiri dosyası, konteyner uygulamasının gerekli mikro ön uçları keşfetmesine ve yüklemesine yardımcı olur. Geliştiriciler yalnızca kapsayıcıyı ve üzerinde çalıştıkları belirli mikro ön uçları çalıştırmaya odaklanabilirler.

Eksileri:

• Bildiri dosyasını getirmek için daha fazla ağ atlıyor: Kapsayıcının her bir mikro ön uç için bildirim dosyasını alması gerektiğinden, diğer oluşturma yaklaşımlarına kıyasla ek ağ istekleri ve potansiyel gecikme olabilir. Bu durum, tüm bildirimlerin ilk sayfa yüklemesinde önceden yüklenmesiyle veya bazı ön yükleme tekniklerinin tanıtılmasıyla azaltılabilir.

• Ortak sözleşmeye uygunluk: Her mikro ön ucun, yapı üretmek için ortak bir sözleşmeye uyması gerekir. Bu, mikro ön uçlarda tutarlılığı sağlamak için paylaşılan yapılandırmalar ve standartlaştırılmış geliştirme uygulamaları yoluyla kolaylaştırılabilir (bununla ilgili daha fazla bilgi aşağıdaki bölümlerdedir).

Hibrit Kompozisyon

Bu bölümde daha önce bahsettiğim gibi, tüm bu kompozisyon desenleri aynı kabuk uygulamasında karıştırılabilir ve eşleştirilebilir. İşte neye benzeyebileceğinin bir örneği:

Öneri

Başlangıçta homojen bir yaklaşımla başlamanızı öneririm; size daha iyi uyan bir kompozisyon modeli seçin ve altyapıyı bunun etrafında oluşturmaya başlayın.

Bizim için istemci tarafı kompozisyonu en iyi seçenekti, ancak gelecek için bazı bölgeleri uç tarafı orkestrasyonuna geçirmeyi düşündük (Lambda@Edge'in kullanılabilirliğine bağlı olarak).

Düzenleme Kitaplığını Seçme

Mikro ön uç mimarisinde istemci tarafı kompozisyonunun uygulanması söz konusu olduğunda, doğru düzenleme kitaplığının seçilmesi kritik bir karardır.

Seçilen kitaplık, konteyner uygulaması içindeki mikro ön uçların dinamik yüklenmesini ve koordinasyonunu yönetmede çok önemli bir rol oynayacak.

Her birinin kendine özgü güçlü yönleri ve dikkate alınması gereken noktaları olan çeşitli popüler orkestrasyon kütüphaneleri mevcuttur.

Tek spa

Single-spa, mikro ön uç kompozisyonuna esnek ve genişletilebilir bir yaklaşım sağlayan, yaygın olarak benimsenen bir orkestrasyon kütüphanesidir. Geliştiricilerin birden fazla mikro ön ucun yüklenmesini ve boşaltılmasını düzenleyen bir kabuk uygulaması oluşturmasına olanak tanır.

Single-SPA, yaşam döngüsü olayları üzerinde ayrıntılı kontrol sağlar ve farklı çerçeveleri ve teknolojileri destekler.

Artıları:

• Çerçeveden bağımsız: Kitaplık, React, Angular, Vue.js ve daha fazlası gibi çeşitli ön uç çerçevelerle iyi çalışır.

• Esnek yapılandırma: Yönlendirme, tembel yükleme ve paylaşılan bağımlılıklar için güçlü yapılandırma seçenekleri sunar.

• Sağlam ekosistem: Single-SPA aktif bir topluluğa ve zengin bir eklenti ve uzantı ekosistemine sahiptir.

Eksileri:

• Öğrenme eğrisi: Single-spa'ya başlamak, başlangıçta bazı kavramların ve API'lerin öğrenilmesini ve anlaşılmasını gerektirebilir.

• Özelleştirme karmaşıklığı: Mikro ön uç mimarisinin karmaşıklığı arttıkça, orkestrasyonu yapılandırmak ve yönetmek zorlayıcı hale gelebilir.

Qiankun

Qiankun , Ant Financial (Alibaba) ekibi tarafından geliştirilen güçlü bir orkestrasyon kütüphanesidir. Kompozisyon için kısmi bir HTML yaklaşımı kullanır. Mikro ön uç uygulama tarafında, yüklenecek tüm giriş noktalarını içeren düz bir HTML pasajı üretir.

Bu HTML dosyasını kullandıktan sonra kapsayıcı tüm düzenlemeyi yapar ve uygulamayı bağlar. Bu konfigürasyonda kısmi HTML, önceki bölümde bahsettiğim manifest dosyası rolünü oynuyor.

Artıları:

• Çerçeveden bağımsız: Qiankun, React, Vue.js, Angular ve daha fazlası dahil olmak üzere çeşitli ön uç çerçevelerini destekler.

• Basitleştirilmiş entegrasyon: Qiankun, mikro ön uçlar oluşturmak ve yönetmek için bir dizi kullanımı kolay API ve araç sağlar.

• Ölçeklenebilirlik ve performans: Qiankun, kod korumalı alan oluşturma, durum izolasyonu ve mikro ön uçlar arasındaki iletişim için etkili mekanizmalar sunar.

Eksileri:

• Bağımlılık çatışmaları: Paylaşılan bağımlılıkları yönetmek ve mikro ön uçlar arasında uyumluluğu sağlamak, dikkatli yapılandırma ve değerlendirme gerektirebilir.

• Öğrenme eğrisi: Qiankun kapsamlı belgeler sağlarken, yeni bir kitaplığın benimsenmesi geliştirme ekibiniz için bir öğrenme eğrisi gerektirebilir.

• Kablo üzerinden gönderilen gereksiz veriler: Kısmi HTML pasajı, ağ üzerinden gönderilmesi gereken gereksiz verileri (gövde, meta, DOCTYPE etiketleri) içerir.

Modül Federasyonu

Webpack tarafından sağlanan bir özellik olan Modül Federasyonu , web geliştirme topluluğunda önemli bir ilgi ve heyecan kazandı. Bu teknoloji, geliştiricilerin çalışma zamanında birden fazla uygulama arasında kod paylaşmasına olanak tanır ve bu da onu mikro ön uçlar oluşturmak için çekici bir seçenek haline getirir.

Webpack ile kusursuz entegrasyonu ve çalışma zamanı esnekliği sayesinde Modül Federasyonu, mikro ön uçları yönetmek ve düzenlemek için popüler bir seçim haline geldi.

Artıları:

• Webpack ile kusursuz entegrasyon: Zaten oluşturma aracınız olarak Webpack'i kullanıyorsanız, Modül Federasyonu'ndan yararlanmak kurulum ve entegrasyon sürecini basitleştirir.

• Çalışma zamanı esnekliği: Modül Federasyonu, bağımlılıkların dinamik olarak yüklenmesine ve paylaşılmasına olanak tanıyarak mikro ön uçların yönetilmesinde esneklik sağlar.

Eksileri:

• Sınırlı çerçeve desteği: Modül Federasyonu birden fazla ön uç çerçevesiyle uyumlu olsa da, belirli kullanım durumları için ek yapılandırma veya geçici çözümler gerektirebilir.

• Topluluk desteği: Modül Federasyonu, Webpack 5'te çekirdek eklenti olarak piyasaya sürülen (ve daha sonra v4'e geri aktarılan) nispeten yeni bir teknolojidir. Next.js kütüphanesi de daha yenidir ve yakın zamanda açık kaynak olarak piyasaya sürülmüştür. Tüm yeni araçlarda olduğu gibi, daha küçük bir topluluk ve daha az destek mevcut olabilir. Teslim tarihleriniz kısıtlıysa veya yanıtları hazır olmayan sorularla karşılaşacağınızı öngörüyorsanız, bu faktörü göz önünde bulundurmanız önemlidir.

Çözüm

“Mikro-Ön Uç Geçiş Yolculuğu” serisinin bu ilk bölümünde, bir web monolitinden dağıtılmış bir mimariye geçişin ardındaki motivasyonu ve bu fikri liderliğe satmak için atılan ilk adımları tartıştık.

Ayrıntılı performans analizini gösteren ve geçişin farklı aşamalarını özetleyen bir teknik vizyon belgesinin önemini araştırdık.

Daha sonra üç yaklaşımı tartışarak mikro ön uçlara yönelik tasarım hususlarını derinlemesine inceledik: sunucu tarafı kompozisyonu, kenar tarafı kompozisyonu ve istemci tarafı kompozisyonu.

Her yaklaşımın artıları ve eksileri vardır ve seçim, küresel durumun senkronizasyonu, müşteri deneyimi, altyapı karmaşıklığı ve önbelleğe alma gibi çeşitli faktörlere bağlıdır.

Ayrıca single-spa, qiankun ve Modül Federasyonu gibi popüler orkestrasyon kütüphanelerini araştırarak bunların özelliklerini, faydalarını ve potansiyel zorluklarını vurguladık.

Mikro ön uç geçiş yolculuğumuza devam ederek daha ilginç ve değerli içgörüleri ortaya çıkarırken serinin sonraki bölümlerinde bana katılın!

İlk olarak 18 Nisan 2023'te https://thesametech.com'da yayınlandı .

Ayrıca beni Twitter'da takip edebilir ve yeni gönderiler hakkında bildirim almak için LinkedIn'e bağlanabilirsiniz !