SOA ve Microservices arasında gerçekten farklı olan şey

feragat

Umarım kimsenin parmaklarına basmıyorum ya da her iki kavramın meraklılarını rahatsız etmiyorum

Arka fon

Net bir cevap bulamadan, Servis Odaklı Mimari ve Mikro Hizmetler arasında gerçek farklılıklar arıyordum .

Ben şöyle okudum:

• SOA'nın yan etkileri
• SOA anti-patern oluşturuyor
• Mikro hizmetler SOA'nın hatalarını düzeltmek için geldi
• ESB'ler gerçekten ESB değil, EAI
• Message Brokers'a aşırı güvenme
• Satıcılar SOA kavramını kötüye kullanıyor ve ürünlerini satmaya çalışıyor
• SOA kontrolsüz bir şekilde büyüyor

Ancak yine de hiçbir şey Hizmet Odaklı Mimari (kavram olarak) ve Mikro hizmet (kavram olarak) arasındaki mimari farklılıkları açıkça tanımlamaz.

Anladığım kadarıyla, her ikisinin de var:

• Servis Sağlayıcılar, tek bir şey yapıyor
• Hizmet Ağ Geçidi / ESB, bu hizmetleri tüketicilere sunar
• Hizmet Tüketicileri, ESB / Hizmet Ağ Geçidi üzerinden hizmetlere erişme

Soru

Peki, SOA'yı Mikro Hizmetlere yeniden etiketlemekten başka bir şey var mı? Microservices'in makro haline gelmesini sınırlamak için uygulanan bir teknoloji kısıtı mı?

Not: Umarım mermi noktalarında fikirler, sadece zor gerçekler aramıyorum

Referanslar

• Yazılım Mühendisliği Soruları
• Martin Fowler Sitesi (Bence büyük zamandan nefret ediyor)
• Bilgi dünyası
• Michael Fethers'ın Web Sitesi
• Yığın Taşması Soruları

Güncelleme

Yığın taşması sorusunda benzer bir tartışma gerçekleşti, Mikro Hizmetlerin kılık değiştirerek Hizmet Odaklı Mimari olduğu ya da olmasın görüş ayrı.

SO sorusundan sonuç:

• MS, SOA'nın özel bir halidir
• MS, hizmet barındıran uygulamaların daha küçük boyutlarını onaylar
• MS teknolojiye bağlıdır (açık protokol seçenekleri yerine HTTP kullanımı)
• MS, disiplini uygulamak için teknolojiye güveniyor (hizmetlerin otomatik olarak konuşlandırılması)
• MS, ESB'leri (kötü) ele alır, ancak IMHO'nun bir ESB türü olduğu API Ağ Geçitlerini kullanır

Bu, eğer doğruysa MS'in SOA olduğu sonucuna varır:

• MS, Orkestrasyon kavramını destekliyor mu? Bir veya daha fazla ana işlem (ler) iş akışlarını yönetir
• MS'de bir Message Broker katmanı var mı? Servis üreticilerinin mesaj alanından servis tüketicilerine mesaj formatlarını çeviren bir dizi adaptör
• Mikro hizmetler yekpare kurumsal uygulamalardan veri okuyabilir mi? Monolitik bir uygulamanın API'leri olabilir mi? veya bağımsız çalışabilen bağımsız müstakil uygulamalar mı olmalı?

Son soruya verilen yanıtın hayır olduğu ortaya çıktıysa, Mikro Hizmetler, Kredi Kartı Yönetim Sistemleri veya mutabakat sistemleri gibi karmaşık iş akışı sistemlerini işleyemez.

Servis Sağlayıcılar, tek bir şey yapıyor

Projenin yaygın sonuçları olan temel fark, Microservices ile bu Servis Sağlayıcıların bağımsız olarak konuşlandırılabilir ve ölçeklendirilebilir olmasıdır .

Bu harika, çünkü daha çevik olabilirsiniz. Bir hizmetin değişmesi gerekiyorsa, bunu değiştirirsiniz, hiçbiri akraba değildir. Yeni bir çerçeve veya dil denemek istiyorsanız, o hizmet için bir yedek değiştirme yapmanız yeterlidir. Aniden 100x kapasiteye ihtiyacınız varsa, bu akını idare etmek için bazı yeni makineleri bu hizmetle döndürün. Bir şeyi sürümlendirmek istiyorsanız, tüm uygulamaya dokunmadan sürümlendirin. Ve işleri izlemek, enstrümanlamak, takımlar arasında bölmek, eskimiş ...

Ama bazı ağır sonuçları var:

• Birkaç hizmetin dağıtılması, birkaç düzine hizmetin dağıtılmasından çok farklı olduğu için sürüm sürecinizin değişmesi gerekiyor.
• Bir makineye bir hizmet dağıtmak birkaç düzine makineye dağıtmaktan çok farklı olduğundan, sürüm sürecinizin değişmesi gerekiyor.
• Veritabanı tasarımınızın, kullanımınızın ve dağıtımınızın değişmesi gerekiyor, çünkü bu büyük paylaşılan DB'yi çalışmak için dağıtması gerekiyorsa (diğer tüm hizmetlerinizi kırarak) bir hizmeti dağıtmak anlamsızdır.
• Kitaplık tasarımınızın ve kullanımınızın değişmesi gerekiyor, çünkü bu paylaşılan kitaplığı güncellemesi gerekiyorsa (diğer tüm hizmetlerinizi kırarak) bir hizmeti dağıtmak anlamsızdır.
• Değişime Kişisel günlüğü / yetkilendirme / oturum yönetimi / vb ihtiyaçlar sadece bir hizmet olduklarında bulunmasını payı şeyler oldukça kolaydır çünkü ancak ürünü oluşturan bağımsız küçük hizmetleri bir grup var olduğunda farklı - ve konum gidiş için bir şeyler paylaşmak istiyorum. Oh, ve tüm bu paylaşılan şeylerin potansiyel olarak farklı versiyonlarda olmakla uğraşması gerekiyor.
• İletişiminizin değişmesi gerekiyor. Az sayıda hizmetle, iletişimin sıkça gerçekleşmediği ve / veya yavaşça gerçekleşebileceği hatlar boyunca işleri bozabilirsiniz. Mikro hizmetlerle, birbirleriyle çok konuşacaklar ve yüksek gecikme bunu kesmeyecek.

Sonuç olarak SOA ve Microservices arasındaki en belirgin fark ,

Akıllı Uç Noktalar Aptal Boruları

Aksine SOA , o habersiz hizmet tüketiciler ve üreticiler, delege trafik yönetimi, ileti biçimi çeviri ve harici sistemlere hizmet orchestratoration, örneğin ESB, hizmet Orchestrator Mesaj broker güvenmek istiyorum.