çok eski okul yaklaşımlarına geri dönerek, mikro hizmetlerle dolu bir daire oluşturduk mu?

Yazılım mimarisi ve tasarımı açısından, mikro hizmetlerin ara katman yazılımına karşı nasıl "birikmesi" (pun planlı)? Java'dan geliyorum ve bir API olarak düz REST'ten uzaklaştığınız ve farklı katmanları ve bağlantı parametrelerini soyutladığınız gibi görünüyor, en azından Java'da, neredeyse çok eski okul fikirlerine geri dönüyorsunuz . Sanallaştırmaya geri döndük ... JVM zaten sanal.

Agnostik bir şekilde, RESTful API'yi CORBA'ya soyutlamanın avantajlarını tartışabilir ve tartışabilirim. Veya daha çok java merkezli bir şekilde JMS veya MDB.

Bir zamanlar EJB Java'da büyük bir anlaşma yaptı, o zaman biraz küme efekti olarak tanındı, ama şimdi başlangıca geri mi döndük?

Veya mikro hizmetler, CORBA'nın veya daha iyisi MDB'nin eksik olduğu bir şey sunuyor mu? Mikroservisleri açıklayan (TLDR) Martin Fowler'ı okuduğumda, kötü bir soruna iyi bir çözüm olarak karşımıza çıkıyor. Daha doğrusu, sadece sorunu zorlayan bir karmaşıklık düzeyi getiren kapalı fikirli bir yaklaşım. Hizmetler gerçekten mikro ve çok sayıdaysa, her birinin işletmesi ve bakımı için bir dolar maliyeti vardır.

Dahası, bir mikro servisin birçoğu API'sını değiştirirse, o hizmete bağlı olarak her şey bozulur. O değil gibi görünüyor bu gevşek bağlı görünüyor Çevik tersini. Yoksa bu kelimeleri yanlış mı kullanıyorum?

Tabii ki, bu uç noktalar arasında belirsiz bir seçenek vardır.

Goril'e karşı köpekbalığı ... git! (Bilgiçlik için, bunun ironik olması gerekiyordu ve niyetim hiç de değil. Soru yüz değerinde ele alınacak. Eğer soru geliştirilebiliyorsa, lütfen bunu yapın veya yorum yapın ve düzeltirim. )

Docker'da, hepsi bir makinede, birbirinizle konuşarak çalışan çok sayıda mikro hizmet düşünün ... delilik. Korunması veya yönetilmesi zordur ve hiçbir şeyi değiştirmek imkansızdır, çünkü herhangi bir değişiklik kademelendirilir ve öngörülemeyen hatalara neden olur. Bu hizmetlerin farklı makinelere dağılması nasıl bir şekilde daha iyi? Ve eğer dağıtılırlarsa, elbette bazı çok, çok eski okul teknikleri en azından bir dereceye kadar dağıtılmış bilgisayarları çözdü.

Yatay ölçeklendirme neden bu kadar yaygın veya en azından arzu edilir?

TL; DR. Çok sayıda Microserver aromalı Kool-Aid içmekten zevk aldım, bu yüzden onların arkasındaki nedenlerle biraz konuşabilirim.

Artıları:

• Hizmetler, bağımlılıklarının istikrarlı olduğunu ve pişirmek için zamanları olduğunu biliyor
• Yeni sürümlerin yuvarlanan dağıtımlarına izin ver
• Daha yüksek katmanları etkilemeden bileşenlerin geri döndürülmesine izin verin.

Eksileri:

• Bağımlılıklarınızın yeni ve parlak özelliklerini kullanamazsınız.
• API'yı hiçbir zaman geriye dönük uyumluluğu bozamazsınız (veya en azından pek çok geliştirme döngüsü için).

Bir mikro hizmet mimarisinin nasıl çalışması gerektiğini temelden yanlış anladığınızı düşünüyorum. Çalıştırılması gereken yol, her mikro hizmetin (buradan MS olarak anılacaktır) tüm müşterilerinin üzerinde anlaştığı katı bir API'ye sahip olmasıdır. MS'nin, API korunursa istediği değişiklikleri yapmasına izin verilir. MS, API korunduğu sürece sıfırdan atılabilir ve yeniden yazılabilir.

Gevşek kuplaja yardımcı olmak için, her MS bağımlılıklarının n-1 versiyonuna bağlıdır. Bu, hizmetin geçerli sürümünün daha az kararlı ve biraz daha riskli olmasını sağlar. Ayrıca sürümlerin dalgalar halinde çıkmasına izin verir. İlk 1 sunucu yükseltilir, sonra yarısı ve son olarak geri kalanı. Mevcut sürüm herhangi bir ciddi sorun geliştirirse, MS diğer katmanlarda işlevsellik kaybı olmadan önceki bir sürüme geri alınabilir.

API'nın değiştirilmesi gerekiyorsa, geriye dönük olarak uyumlu bir şekilde değiştirilmesi gerekir.

Şimdiye kadar icat ettiğimiz her yazılım geliştirme tekniği bir şekilde karmaşıklığı yönetmekle ilgilidir. Bunların büyük bir kısmı soyutlama, kapsülleme ve gevşek bağlanma ile ilgilidir ve olmaya devam etmektedir. Mikro hizmetler bu şeyleri yapmanın başka bir yoludur, bu yüzden muhtemelen yüksek teorik düzeyde çok sayıda eski tekniğe benzemektedir, ancak bu onu daha az kullanışlı veya alakalı hale getirmez.

Gevşek bağlantı ile ilgili olarak, hedefi biraz yanlış anladığınızı düşünüyorum. A görevinin B görevini çağırması gerekiyorsa, A ve B'yi% 100 ayrıştırmanın bir yolu olmayacaktır. Asla olmayacak. Yapabileceğiniz şey, B görevi C görevini çağırıyorsa, C görevi asla A'daki değişiklikler hakkında endişelenmek zorunda kalmamasını sağlamaktır. Bu üç görevin hepsi büyük bir damla halinde birbirine bağlanırsa, yapıları birbirine geçirirse, herhangi biri yaparsa hepsinin değişmesi gereken önemli bir şans. Ancak her üçü de mikro hizmetse, temel olarak A'daki bir değişikliğin B'yi yalnızca güncellemeye zorlayacağı garanti edilir (A'nın temel işlevinde büyük bir değişiklik olması, muhtemelen onu yepyeni bir hizmet haline getirmeniz gerekirdi). Bu, özellikle tüm mikro servis güncellemeleri olması gerektiği şekilde geriye dönük uyumlu bir şekilde yapılırsa geçerlidir.

Çevik yorum ile ilgili olarak, size kişisel deneyimlerden, mikro hizmet-y kodumuzun "büyük bir bloba bağlı" kodumuzdan çok daha iyi oynadığını söyleyebilirim. İkincisi, bir kişi düşük seviyeli bir işlevde bir hatayı düzelttiğinde, kelimenin tam anlamıyla tüm Ar-Ge departmanına "lütfen görevlerinizi yeniden bağlayın, yoksa Cuma günü çökecek" şeklinde bir e-posta göndermesi gerekir. Her hafta bir kaç tane alıyoruz . Kodu bir mikro hizmette olsaydı, yeni bir sürümü dağıtır yüklemez otomatik olarak düzeltmeden faydalanırdık.

COBRA ve MDB hakkındaki yorumu tam olarak anlamıyorum, çünkü bunlar yazılım mimarileri değil, bir bileşenidir; benim anlayışımla, mikro hizmetlerin mesajlaşma protokollerini tanımlamanın ve / veya söz konusu mikro hizmetlerin kendi başına ve mikro hizmetlere alternatif olarak değil, potansiyel yollardır.

Bu hizmetlerin farklı makinelere dağılması nasıl bir şekilde daha iyi?

Bulut yüzünden.

Henüz gülmüyor musun? Ciddi olsa da - birçok işletme için, yazılım için en büyük maliyet artık yazılım değil. Bu bant genişliği, donanım, CDN maliyetleri vb. Artık herkesin bir mobil cihazı olduğu için çok daha fazla trafik var. Ve sadece ekmek kızartma makineniz kendi internet bağlantısını aldığında daha da kötüleşecektir.

Dolayısıyla işletmeler bu maliyetleri yönetmek istiyor. Özellikle, "bu şey patlarsa, milyonlarca insana yazılımımı edinen / kullanan nasıl hizmet edebilirim - sunuculara milyonlarca insana yazılımımı alan / kullanan hizmet vermeden önceden ödeme yapmadan, ?".

Yatay ölçeklendirme neden bu kadar yaygın veya en azından arzu edilir?

Çünkü bu (büyük ve artan) iş sorununa cevap veriyor.

Bir düzine kullanıcınız olduğunda, tüm hizmetleri tek bir kutuya atabilirsiniz. Bu sadece bir kutu için ödeme yapmak istediğiniz için iyidir. Ayrıca, işletmeniz ölçeklendiğinde çeşitli hizmetleri bölmek için uygulamada yapılan değişiklikler için ödeme yapmak istemezsiniz. Bu günlerde, müşterilerin çetesi sunucularınızı ateşe vermeden önce bunu yapacak zamanınız yok.

Ayrıca iyidir, çünkü şunları yapabilmeniz için sunucu ayırmalarını dengelemenize izin verir:

1. "israf" için çok az bırakarak, sahip olduğunuz sunucuların çoğunu kullanın.
2. yazılımınızın bağımsız öğelerinin performansını ölçün.
3. sürümlerin neden olduğu dağıtım / arıza süresini azaltın.

Çok ayrıntılı dağıtımlara sahip olmak, bu iki şeyi daha kolay / daha iyi hale getirir (endişelerin daha iyi ayrılmasını sağlamanın yanı sıra).