19 Eylül Moskova'da mikro hizmetlere adanan ilk tematik toplantı HUG (Highload++ Kullanıcı Grubu). Flant'ın mikro hizmet mimarisiyle proje yürütme konusundaki kapsamlı deneyimini paylaştığımız "Mikro Hizmetleri Çalıştırmak: Kubernetes'iniz Olsa Bile Boyut Önemlidir" adlı bir sunum vardı. Öncelikle bu yaklaşımı mevcut veya gelecekteki projelerinde kullanmayı düşünen tüm geliştiriciler için faydalı olacaktır.
tanıtım (50 dakika, makaleden çok daha bilgilendirici) ve ayrıca metin biçimindeki ana alıntı.
Not: Bu yazının sonunda video ve sunum da mevcuttur.
Giriş
Genellikle iyi bir hikayenin bir başlangıcı, bir ana konusu ve bir çözümü vardır. Bu rapor daha çok bir başlangıç niteliğinde ve trajik bir rapor. Ayrıca dışarıdan birinin mikro hizmetlere ilişkin bakış açısını sağladığını da belirtmek önemlidir. Çalışma.
Yazarı (2015'te) olan bu grafikle başlayacağım. Martin Fowler:
Monolitik bir uygulamanın belirli bir değere ulaşması durumunda verimliliğin nasıl düşmeye başladığını gösteriyor. Mikro hizmetler, başlangıçtaki üretkenliğin daha düşük olması bakımından farklıdır, ancak karmaşıklık arttıkça, verimlilikteki bozulma onlar için o kadar fark edilmez.
Kubernetes kullanma durumu için bu grafiğe şunu ekleyeceğim:
Mikro hizmetlere sahip bir uygulama neden daha iyidir? Çünkü böyle bir mimari, mimari için ciddi gereksinimler ortaya koyuyor ve bunlar da Kubernetes'in yetenekleriyle mükemmel bir şekilde karşılanıyor. Öte yandan, bu işlevselliğin bir kısmı bir monolit için faydalı olacaktır, özellikle de günümüzün tipik monoliti tam olarak bir monolit olmadığı için (detaylar raporun ilerleyen kısımlarında yer alacaktır).
Gördüğünüz gibi son grafik (hem monolitik hem de mikroservis uygulamaları Kubernetes ile altyapıda olduğunda) orijinalinden çok da farklı değil. Daha sonra Kubernetes kullanılarak çalıştırılan uygulamalardan bahsedeceğiz.
Yararlı ve zararlı mikro hizmetler
Ve işte ana fikir:
Bir nedir normal mikro hizmet mimarisi? İş verimliliğinizi artırarak size gerçek faydalar sağlamalıdır. Grafiğe geri dönersek, işte burada:
Eğer onu ararsan kullanışlı, o zaman grafiğin diğer tarafında olacak zararlı mikro hizmetler (işe müdahale eder):
“Ana fikre” dönersek: Deneyimlerime güvenmeli miyim? Bu yılın başından beri bakıyorum 85 proje. Bunların hepsi mikro hizmetler değildi (yaklaşık üçte biri ila yarısı kadarı böyle bir mimariye sahipti), ancak bu yine de büyük bir sayı. Biz (Flant şirketi) dış kaynak sağlayıcılar olarak hem küçük şirketlerde (5 geliştiricili) hem de büyük şirketlerde (~500 geliştiricili) geliştirilen çok çeşitli uygulamaları görmeyi başarıyoruz. Ek bir fayda da bu uygulamaların yıllar içinde yaşadığını ve geliştiğini görmemizdir.
Neden mikro hizmetler?
Mikro hizmetlerin yararları hakkındaki soruya şu var: daha önce bahsedilen Martin Fowler'dan:
- modülerliğin net sınırları;
- bağımsız dağıtım;
- teknolojileri seçme özgürlüğü.
Yazılım mimarları ve geliştiricileriyle çok konuştum ve neden mikro hizmetlere ihtiyaç duyduklarını sordum. Ben de onların beklentilerinin listesini yaptım. İşte olanlar:
"Duyulardaki" bazı noktaları tanımlarsak:
- modüllerin net sınırları: burada korkunç bir monolitimiz var ve şimdi her şey, her şeyin "raflarda" olduğu, sıcak ve yumuşakın karışmadığı Git depolarında düzgün bir şekilde düzenlenecek;
- Dağıtım bağımsızlığı: Geliştirmenin daha hızlı ilerlemesi için hizmetleri bağımsız olarak sunabileceğiz (yeni özellikleri paralel olarak yayınlayacağız);
- Geliştirme bağımsızlığı: Bu mikro hizmeti bir ekibe/geliştiriciye verebiliriz ve bu sayede daha hızlı gelişebiliriz;
- боdaha fazla güvenilirlik: kısmi bozulma meydana gelirse (20 mikro hizmetten biri düşerse), o zaman yalnızca bir düğme çalışmayı durduracak ve sistem bir bütün olarak çalışmaya devam edecektir.
Tipik (zararlı) mikro hizmet mimarisi
Gerçekliğin neden beklediğimiz gibi olmadığını açıklamak için şunları sunacağım: toplu Birçok farklı projeden elde edilen deneyimlere dayanan bir mikro hizmet mimarisinin görüntüsü.
Bir örnek, Amazon veya en azından OZON ile rekabet edecek soyut bir çevrimiçi mağaza olabilir. Mikro hizmet mimarisi şuna benzer:
Çeşitli nedenlerden dolayı bu mikro hizmetler farklı platformlarda yazılmıştır:
Her mikro hizmetin özerkliğe sahip olması gerektiğinden çoğunun kendi veritabanına ve önbelleğine ihtiyacı vardır. Son mimari aşağıdaki gibidir:
Sonuçları nelerdir?
Fowler'da da bu var — mikro hizmetlerin kullanımına ilişkin “ödeme” hakkında:
Bakalım beklentilerimiz karşılanacak mı?
Modüllerin sınırlarını temizleyin...
Ancak Aslında kaç tane mikro hizmeti düzeltmemiz gerekiyor?değişikliği yaymak için? Dağıtılmış bir izleyici olmadan her şeyin nasıl çalıştığını bile anlayabilir miyiz (sonuçta, herhangi bir istek mikro hizmetlerin yarısı tarafından işlenir)?
Bir model var"“ve burada dağılmış bir kir yığını olduğu ortaya çıktı. Bunu doğrulamak için aşağıda isteklerin nasıl gittiğine dair yaklaşık bir örnek verilmiştir:
Dağıtım bağımsızlığı...
Teknik olarak bu başarıldı: Her bir mikro hizmeti ayrı ayrı kullanıma sunabiliyoruz. Ancak pratikte bunun her zaman ortaya çıktığını dikkate almanız gerekir. birçok mikro hizmetve dikkate almamız gerekiyor piyasaya sürülme sırası. İyi bir anlamda, sürümü doğru sırayla yayınlayıp yayınlamadığımızı genellikle ayrı bir devrede test etmemiz gerekir.
Teknolojiyi seçme özgürlüğü...
O. Sadece özgürlüğün çoğu zaman kanunsuzlukla sınırlandığını unutmayın. Burada teknolojileri sadece “oynamak” için seçmemek çok önemli.
Kalkınmanın bağımsızlığı...
Uygulamanın tamamı için (bu kadar çok bileşenle) bir test döngüsü nasıl yapılır? Ancak yine de güncel tutmanız gerekiyor. Bütün bunlar şu gerçeği ortaya çıkarıyor: gerçek test devresi sayısıprensipte içerebileceğimiz, minimal olduğu ortaya çıkıyor.
Tüm bunları yerel olarak dağıtmaya ne dersiniz?.. Geliştiricinin işini genellikle bağımsız olarak ancak "rastgele" yaptığı ortaya çıktı, çünkü devre test için serbest olana kadar beklemek zorunda kaldı.
Ayrı ölçeklendirme...
Evet, ancak kullanılan DBMS'nin alanıyla sınırlıdır. Verilen mimari örneğinde Cassandra'nın sorunları olmayacak, ancak MySQL ve PostgreSQL'in sorunları olacak.
Боdaha fazla güvenilirlik...
Gerçekte yalnızca bir mikro hizmetin başarısızlığı tüm sistemin doğru işleyişini bozmakla kalmıyor, aynı zamanda yeni bir sorun da ortaya çıkıyor: Her mikro hizmeti hataya dayanıklı hale getirmek çok zordur. Mikro hizmetler farklı teknolojiler (memcache, Redis vb.) Kullandığından, her biri için her şeyi düşünmeniz ve uygulamanız gerekir ki bu elbette mümkündür, ancak büyük kaynaklar gerektirir.
Ölçülebilirliği yükle...
Bu gerçekten iyi.
Mikro hizmetlerin "hafifliği"...
Sadece çok büyük değil ağ yükü (DNS talepleri çoğalıyor vb.) ama aynı zamanda başlattığımız birçok alt sorgu nedeniyle verileri çoğalt (mağaza önbellekleri), bu da önemli miktarda depolama alanına yol açtı.
Ve işte beklentilerimizi karşılamanın sonucu:
Ama hepsi bu kadar değil!
Çünkü:
- Büyük olasılıkla bir mesaj veriyoluna ihtiyacımız olacak.
- Doğru zamanda tutarlı bir yedekleme nasıl yapılır? Tek bir gerçek seçenek bunun için trafiği kapatmaktır. Peki bunu üretimde nasıl yapmalı?
- Birkaç bölgeyi desteklemekten bahsediyorsak, her birinde sürdürülebilirliği organize etmek çok emek yoğun bir iştir.
- Merkezi değişiklik yapma sorunu ortaya çıkıyor. Örneğin, PHP sürümünü güncellememiz gerekiyorsa, her depoya taahhütte bulunmamız gerekir (ve düzinelerce var).
- Operasyonel karmaşıklıktaki artış, beklenmedik bir şekilde katlanarak artıyor.
Bütün bunlarla ne yapmalı?
Monolitik bir uygulamayla başlayın. Fowler'ın deneyimi Neredeyse tüm başarılı mikro hizmet uygulamaları tek parça olarak başladı, çok büyüdü ve sonra bozuldu. Aynı zamanda, en başından beri mikroservis olarak inşa edilen hemen hemen tüm sistemler, er ya da geç ciddi sorunlarla karşılaştı.
Bir diğer değerli düşünce ise, mikro hizmet mimarisine sahip bir projenin başarılı olabilmesi için şunları çok iyi bilmeniz gerektiğidir. ve konu alanı ve mikro hizmetlerin nasıl yapılacağı. Ve bir konu alanını öğrenmenin en iyi yolu monolit yapmaktır.
Peki ya zaten bu durumdaysak?
Herhangi bir sorunu çözmenin ilk adımı, onunla aynı fikirde olmak ve bunun bir sorun olduğunu, artık acı çekmek istemediğimizi anlamaktır.
Aşırı büyümüş bir monolit durumunda (bunun için ek kaynak satın alma fırsatımız bittiğinde), onu kesersek, bu durumda tam tersi bir hikaye ortaya çıkar: aşırı mikro hizmetler artık yardımcı olmadığında, ancak engellediğinde - fazlalığı kesin ve büyütün!
Örneğin yukarıda tartışılan kolektif imaj için...
En şüpheli mikro hizmetlerden kurtulun:
Ön uç oluşturmadan sorumlu tüm mikro hizmetleri birleştirin:
... tek bir dilde/çerçevede (sizin düşündüğünüz gibi modern ve normal) yazılmış tek bir mikro hizmete:
Bir ORM'ye (bir DBMS) ve ilk olarak birkaç uygulamaya sahip olacaktır:
... ama genel olarak oraya çok daha fazlasını aktarabilir ve aşağıdaki sonucu elde edebilirsiniz:
Üstelik Kubernetes'te tüm bunları ayrı örneklerde çalıştırıyoruz, bu da yükü hâlâ ölçebildiğimiz ve ayrı ayrı ölçeklendirebildiğimiz anlamına geliyor.
özetleme
Büyük resme bakın. Çoğu zaman, mikro hizmetlerle ilgili tüm bu sorunlar, birisinin görevini üstlenmesi ancak "mikro hizmetlerle oynamak" istemesi nedeniyle ortaya çıkar.
"Mikro hizmetler" sözcüğündeki "mikro" kısım gereksizdir.. Bunlar yalnızca devasa bir monolitten daha küçük oldukları için “mikro”durlar. Ama bunları küçük bir şey olarak düşünmeyin.
Son olarak, orijinal tabloya dönelim:
Üzerine yazılmış bir not (sağ üst) şu gerçeği özetliyor Projenizi yapan ekibin becerileri her zaman ön plandadır — mikro hizmetler ile monolit arasındaki seçiminizde önemli bir rol oynayacaklar. Ekip yeterli beceriye sahip değilse ancak mikro hizmetler yapmaya başlarsa hikaye kesinlikle ölümcül olacaktır.
Videolar ve slaytlar
Konuşmadan video (~50 dakika; ne yazık ki, raporun ruh halini büyük ölçüde belirleyen, ziyaretçilerin sayısız duygusunu aktarmıyor, ama bu böyle):
Raporun sunumu:
PS
Blogumuzdaki diğer raporlar:
- «» (Dmitry Stolyarov; 28 Mayıs 2018, RootConf'ta);
- «» (Dmitry Stolyarov; 7 Kasım 2017, HighLoad++'da);
- «» (Dmitry Stolyarov; 6 Haziran 2017, RootConf'ta);
- «» (Dmitry Stolyarov; 8 Kasım 2016, HighLoad++'da);
- «» (Dmitry Stolyarov; 31 Mayıs 2016, RootConf'ta).
Aşağıdaki yayınlar da ilginizi çekebilir:
- «";
- «";
- «'.
Kaynak: habr.com