Uzun zamandır mikro hizmet mimarisi konusunda bir makale yazmak istiyordum, ancak iki şey beni durdurdu: Konuya ne kadar daldım, bana bildiklerimin ve bilmediklerimin o kadar açık olduğu göründü. Bilmiyorum, çalışılması ve çalışılması gerekiyor. Öte yandan geniş bir kitlede zaten tartışılacak bir şeyin olduğunu düşünüyorum. Bu nedenle alternatif görüşlere açığız.
Conway Yasası ve iş, organizasyon ve bilgi sistemi arasındaki ilişki
Bir kez daha alıntı yapmama izin vereceğim:
“(Geniş anlamda) bir sistem tasarlayan herhangi bir kuruluş, yapısı o kuruluştaki ekiplerin yapısını kopyalayan bir tasarım alacaktır.”
- Melvyn Conway, 1967
Benim düşünceme göre, bu yasanın doğrudan bilgi sistemiyle ilgili olmaktan çok, bir işi organize etmenin fizibilitesiyle ilgili olması daha muhtemeldir. Bir örnekle açıklayayım. Diyelim ki, bir işletmeyi organize etmenin mantıklı olacağı kadar uzun bir yaşam döngüsüne sahip oldukça istikrarlı bir iş fırsatımız var (bu bir yazım hatası değil ama çaldığım bu terimi gerçekten çok seviyorum).Doğal olarak bu işin destek sistemi organizasyonel ve süreçsel olarak bu işe karşılık gelecektir.
Bilgi sistemlerinin iş yönelimi
Bir örnekle açıklayayım. Diyelim ki pizza satan bir işletme kurmak için bir iş fırsatı var. V1 versiyonunda (buna ön bilgi diyelim), şirket bir pizzacı, yazarkasa ve bir teslimat hizmetiydi. Bu sürüm, düşük çevresel değişkenlik koşullarında uzun ömürlü oldu. Daha sonra sürüm 2 onun yerini aldı; daha gelişmişti ve monolitik bir mimariyle iş için özünde bir bilgi sistemi kullanabiliyordu. Ve burada, bence, monolitlerle ilgili olarak korkunç bir adaletsizlik var - iddiaya göre yekpare mimari alan adı iş modeline uymuyor. Evet, eğer böyle olsaydı, aynı Conway yasasına ve sağduyuya aykırı olarak sistem hiçbir şekilde çalışamazdı. Hayır, monolitik mimari, iş geliştirmenin bu aşamasında iş modeliyle tamamen tutarlıdır - elbette sistemin zaten oluşturulduğu ve işletmeye alındığı aşamayı kastediyorum. Mimari yaklaşım ne olursa olsun, hem hizmet odaklı mimari sürüm 3'ün hem de mikro hizmet mimarisi sürüm N'nin eşit derecede iyi çalışacağı kesinlikle harika bir gerçektir. Amaç ne?
Her şey akıyor, her şey değişiyor, yoksa mikro hizmetler karmaşıklıkla mücadele etmenin bir yolu mu?
Devam etmeden önce mikro hizmet mimarisi ile ilgili bazı yanılgılara bakalım.
Mikro hizmet yaklaşımını kullanmanın savunucuları genellikle bir monolitin mikro hizmetlere bölünmesinin, bireysel hizmetlerin kod tabanını azaltarak geliştirme yaklaşımını basitleştirdiğini savunur. Bana göre bu ifade tamamen saçmalıktır. Cidden, monolit ve homojen bir kod içindeki bariz etkileşim karmaşık görünüyor mu? Durum gerçekten böyle olsaydı, tüm projeler başlangıçta mikro hizmetler olarak inşa edilirdi; ancak uygulamalar, monolitten mikro hizmetlere geçişin çok daha yaygın olduğunu gösteriyor. Karmaşıklık ortadan kalkmaz; yalnızca bireysel modüllerden arayüzlere (veri yolları, RPC, API'ler ve diğer protokoller) ve düzenleme sistemlerine geçer. Ve bu zor!
Heterojen bir yığın kullanmanın avantajı da sorgulanabilir. Bunun da mümkün olduğunu iddia etmeyeceğim, ancak gerçekte nadiren meydana gelir (İleriye baktığımızda - bunun olması gerekir - daha ziyade bir avantajdan ziyade bir sonuç olarak).
Ürün yaşam döngüsü ve hizmet yaşam döngüsü
Yukarıdaki şemaya bir kez daha bakın. Bir işletmenin ayrı bir versiyonunun azalan yaşam döngüsünü fark etmem tesadüf değil - modern koşullarda, bir işletmenin versiyonlar arasındaki geçişinin hızlanması, onun başarısı için belirleyicidir. Bir ürünün başarısı, içindeki iş hipotezlerinin test edilme hızıyla belirlenir.. Ve bence mikro hizmet mimarisinin temel avantajı burada yatıyor. Ama sırayla gidelim.
Bilgi sistemlerinin evrimindeki bir sonraki aşamaya, SOA'nın hizmet odaklı mimarisine geçelim. Yani, ürünümüzde vurguladığımız belirli bir noktada uzun ömürlü hizmetler - uzun ömürlü, yani bir ürünün versiyonları arasında geçiş yaparken, hizmetin yaşam döngüsünün ürünün bir sonraki versiyonunun yaşam döngüsünden daha uzun olma ihtimali vardır. Bunları hiç değiştirmemek mantıklı olacaktır - biz Önemli olan bir sonraki versiyona geçişin hızıdır. Ancak ne yazık ki, hizmetlerde sürekli değişiklikler yapmak zorunda kalıyoruz - ve burada her şey bizim için çalışıyor, DevOps uygulamaları, kapsayıcıya alma vb. - akla gelen her şey. Ancak bunlar hala mikro hizmetler değil!
Karmaşıklıkla mücadele etme aracı olarak mikro hizmetler... yapılandırma yönetimi
Ve burada nihayet mikro hizmetlerin belirleyici rolüne geçebiliriz; bu, ürün konfigürasyon yönetimini basitleştiren bir yaklaşımdır. Daha ayrıntılı olarak, her bir mikro hizmetin işlevi, etki alanı modeline göre ürünün içindeki iş işlevini tam olarak tanımlar - ve bunlar kısa ömürlü bir versiyonda değil, uzun ömürlü bir iş fırsatında yaşayan şeylerdir. Ve ürünün bir sonraki sürümüne geçiş, kelimenin tam anlamıyla fark edilmeden gerçekleşir - bir mikro hizmeti ve belki de yalnızca etkileşimlerinin şemasını değiştirirsiniz/eklersiniz ve birdenbire kendinizi gelecekte bulursunuz ve sürümleri arasında atlamaya devam eden ağlayan rakipleri geride bırakırsınız. onların monolitleri. Şimdi, önceden tanımlanmış arayüzlere ve iş yeteneklerine sahip oldukça büyük miktarda mikro hizmetin olduğunu hayal edin. Ve gelip ürününüzün yapısını hazır mikro hizmetlerden oluşturursunuz - örneğin sadece bir diyagram çizerek. Tebrikler - bir platformunuz var - ve artık kendinize iş çekebilirsiniz. Rüyalar Rüyalar.
Bulgular
- Sistemin mimarisi, bileşenlerinin yaşam döngüsüne göre belirlenmelidir. Bir bileşen bir ürün sürümünde yaşıyorsa, mikro hizmet yaklaşımını kullanarak sistemin karmaşıklığını arttırmanın bir anlamı yoktur.
- Mikro hizmet mimarisi etki alanı modeline dayanmalıdır - çünkü iş fırsatı en uzun ömürlü etki alanıdır
- Teslimat uygulamaları (DevOps uygulamaları) ve orkestrasyon, mikro hizmet mimarisi için en önemli uygulamalardan biridir; çünkü bileşenlerin değişim oranındaki artış, teslimatın hızı ve kalitesine yönelik talepleri artırır.
Kaynak: habr.com