Share via


Kapsayıcılı Mikro Hizmetler

Not

Bu e-Kitap 2017 baharında yayımlanmıştır ve o zamandan beri güncelleştirilmemiştir. Kitapta değerli kalan çok şey var, ancak bazı malzemeler güncelliğini yitirmiş.

İstemci-sunucu uygulamaları geliştirmek, her katmanda belirli teknolojileri kullanan katmanlı uygulamalar oluşturmaya odaklandı. Bu tür uygulamalar genellikle monolitik uygulamalar olarak adlandırılır ve en yüksek yükler için önceden ölçeklendirilmiş donanımlara paketlenir. Bu geliştirme yaklaşımının temel dezavantajları, her katmandaki bileşenler arasında sıkı bir bağlantı olması, tek tek bileşenlerin kolayca ölçeklendirilememesi ve test maliyetidir. Basit bir güncelleştirme katmanın geri kalanında öngörülemeyen etkilere sahip olabilir ve bu nedenle bir uygulama bileşeninde yapılan bir değişiklik, katmanın tamamının yeniden test edilmesi ve yeniden dağıtılması gerektirir.

Özellikle bulutun yaşıyla ilgili olarak, tek tek bileşenlerin kolayca ölçeklendirilememeleridir. Monolitik uygulama etki alanına özgü işlevler içerir ve genellikle ön uç, iş mantığı ve veri depolama gibi işlevsel katmanlara bölünür. Tek parçalı bir uygulama, Şekil 8-1'de gösterildiği gibi uygulamanın tamamını birden çok makineye kopyalayarak ölçeklendirilir.

Monolithic application scaling approach

Şekil 8-1: Monolitik uygulama ölçeklendirme yaklaşımı

Mikro hizmetler

Mikro hizmetler, modern bulut uygulamalarının çeviklik, ölçek ve güvenilirlik gereksinimlerine uygun bir yaklaşım olan uygulama geliştirme ve dağıtıma farklı bir yaklaşım sunar. Mikro hizmetler uygulaması, uygulamanın genel işlevselliğini sunmak için birlikte çalışan bağımsız bileşenlere ayrılır. Mikro hizmet terimi, her mikro hizmetin tek bir işlev uygulaması için uygulamaların bağımsız endişeleri yansıtacak kadar küçük hizmetlerden oluşması gerektiğini vurgular. Buna ek olarak, diğer mikro hizmetlerin iletişim kurabilmesi ve veri paylaşabilmesi için her mikro hizmetin iyi tanımlanmış sözleşmeleri vardır. Tipik mikro hizmetlere örnek olarak alışveriş sepetleri, envanter işleme, satın alma alt sistemleri ve ödeme işlemleri verilebilir.

Mikro hizmetler, birlikte ölçeklendirilen dev monolitik uygulamalara kıyasla bağımsız olarak ölçeği genişletebilir. Bu, talebi desteklemek için daha fazla işlem gücü veya ağ bant genişliği gerektiren belirli bir işlevsel alanın, uygulamanın diğer alanlarını gereksiz yere ölçeklendirmek yerine ölçeklendirilebileceği anlamına gelir. Şekil 8-2'de, mikro hizmetlerin bağımsız olarak dağıtıldığı ve ölçeklendirildiği ve makineler arasında hizmet örnekleri oluşturduğu bu yaklaşım gösterilmektedir.

Diagram shows two apps with tiles representing different functional areas and six rectangles hosting various functional areas from both apps.

Şekil 8-2: Mikro hizmetler uygulaması ölçeklendirme yaklaşımı

Mikro hizmet ölçeği neredeyse anında genişletilebilir ve uygulamanın değişen yüklere uyum sağlamasına olanak sağlar. Örneğin, uygulamanın web'e yönelik işlevselliğindeki tek bir mikro hizmet, uygulamadaki ek gelen trafiği işlemek için ölçeği genişletmesi gereken tek mikro hizmet olabilir.

Uygulama ölçeklenebilirliği için klasik model, kalıcı verileri depolamak için paylaşılan dış veri deposuna sahip yük dengeli, durum bilgisi olmayan bir katmana sahip olmaktır. Durum bilgisi olan mikro hizmetler, ağ erişimi yükünü ve hizmetler arası işlemlerin karmaşıklığını önlemek için kendi kalıcı verilerini yönetir ve genellikle yerleştirildikleri sunucularda yerel olarak depolar. Bu, verilerin mümkün olan en hızlı şekilde işlenmesini sağlar ve önbelleğe alma sistemlerine olan ihtiyacı ortadan kaldırır. Ayrıca, ölçeklenebilir durum bilgisi olan mikro hizmetler, veri boyutunu yönetmek ve tek bir sunucunun desteklenebileceği aktarım hızını aktarmak için genellikle verileri örnekleri arasında bölümler.

Mikro hizmetler bağımsız güncelleştirmeleri de destekler. Mikro hizmetler arasındaki bu gevşek bağlantı, hızlı ve güvenilir bir uygulama evrimi sağlar. Bağımsız, dağıtılmış doğası, tek bir mikro hizmetin örneklerinin yalnızca bir alt kümesinin herhangi bir zamanda güncelleştirileceği sıralı güncelleştirmeleri destekler. Bu nedenle, bir sorun algılanırsa, tüm örnekler hatalı kod veya yapılandırmayla güncelleştirilmeden önce bir buggy güncelleştirmesi geri alınabilir. Benzer şekilde, mikro hizmetler genellikle şema sürümü oluşturmayı kullanır, böylece istemciler güncelleştirmeler uygulanırken hangi mikro hizmet örneğiyle iletişim kuruluyor olursa olsun tutarlı bir sürüm görür.

Bu nedenle mikro hizmet uygulamalarının monolitik uygulamalara göre birçok avantajı vardır:

  • Her mikro hizmet nispeten küçüktür, yönetilmesi ve gelişmesi kolaydır.
  • Her mikro hizmet, diğer hizmetlerden bağımsız olarak geliştirilebilir ve dağıtılabilir.
  • Her mikro hizmetin ölçeği bağımsız olarak genişletilebilir. Örneğin, bir katalog hizmetinin veya alışveriş sepeti hizmetinin ölçeğinin bir sipariş hizmetinden daha fazla genişletilmesi gerekebilir. Bu nedenle, elde edilen altyapı ölçeği genişletirken kaynakları daha verimli bir şekilde kullanır.
  • Her mikro hizmet sorunları yalıtıyor. Örneğin, bir hizmette bir sorun varsa bu yalnızca bu hizmeti etkiler. Diğer hizmetler istekleri işlemeye devam edebilir.
  • Her mikro hizmet en son teknolojileri kullanabilir. Mikro hizmetler otonom olduğundan ve yan yana çalıştırıldığından, monolitik bir uygulama tarafından kullanılabilecek eski bir çerçeveyi kullanmak zorunda kalmak yerine en son teknolojiler ve çerçeveler kullanılabilir.

Ancak mikro hizmet tabanlı bir çözümün olası dezavantajları da vardır:

  • Bir uygulamanın mikro hizmetlere nasıl bölümlendiğini seçmek zor olabilir çünkü her mikro hizmetin veri kaynaklarının sorumluluğu da dahil olmak üzere tamamen otonom, uçtan uca olması gerekir.
  • Geliştiricilerin, uygulamaya karmaşıklık ve gecikme süresi ekleyen hizmetler arası iletişim uygulaması gerekir.
  • Birden çok mikro hizmet arasındaki atomik işlemler genellikle mümkün değildir. Bu nedenle, iş gereksinimlerinin mikro hizmetler arasındaki nihai tutarlılığı benimsemesi gerekir.
  • Üretimde, birçok bağımsız hizmetten ödün veren bir sistemin dağıtılması ve yönetilmesinde operasyonel bir karmaşıklık vardır.
  • Doğrudan istemciden mikro hizmete iletişim, mikro hizmet sözleşmelerinin yeniden düzenlenmesini zorlaştırabilir. Örneğin, zaman içinde sistemin hizmetlere bölümlenme şeklinin değişmesi gerekebilir. Tek bir hizmet iki veya daha fazla hizmete bölünebilir ve iki hizmet birleştirilebilir. İstemciler mikro hizmetlerle doğrudan iletişim kurarken, bu yeniden düzenleme çalışması istemci uygulamalarıyla uyumluluğu bozabilir.

Konteyner kullanımı

Kapsayıcıya alma, bir uygulamanın ve sürüme alınmış bağımlılık kümesinin yanı sıra dağıtım bildirim dosyaları olarak soyutlanmış ortam yapılandırmasının bir kapsayıcı görüntüsü olarak birlikte paketlendiği, birim olarak test ettiği ve bir konak işletim sistemine dağıtıldığı yazılım geliştirme yaklaşımıdır.

Kapsayıcı, bir uygulamanın diğer kapsayıcıların veya konağın kaynaklarına dokunmadan çalışabildiği yalıtılmış, kaynak denetimli ve taşınabilir bir işletim ortamıdır. Bu nedenle, kapsayıcı yeni yüklenen bir fiziksel bilgisayar veya sanal makine gibi görünür ve davranır.

Şekil 8-3'te gösterildiği gibi kapsayıcılarla sanal makineler arasında birçok benzerlik vardır.

Diagram shows a comparison between Virtual Machines and Containers, where virtual machines have three apps each siloed on a guest O S, with a hypervisor and a host O S, and the containers have three apps hosted in a container engine on a single OS.

Şekil 8-3: Sanal makinelerin ve kapsayıcıların karşılaştırması

Kapsayıcı bir işletim sistemi çalıştırır, dosya sistemine sahiptir ve bir ağ üzerinden fiziksel veya sanal makineymiş gibi erişilebilir. Ancak kapsayıcılar tarafından kullanılan teknoloji ve kavramlar sanal makinelerden çok farklıdır. Sanal makineler uygulamaları, gerekli bağımlılıkları ve tam konuk işletim sistemini içerir. Kapsayıcılar uygulamayı ve bağımlılıklarını içerir, ancak konak işletim sisteminde yalıtılmış işlemler olarak çalışan (kapsayıcı başına özel bir sanal makinenin içinde çalışan Hyper-V kapsayıcıları dışında) işletim sistemini diğer kapsayıcılarla paylaşır. Bu nedenle kapsayıcılar kaynakları paylaşır ve genellikle sanal makinelerden daha az kaynak gerektirir.

Kapsayıcı odaklı geliştirme ve dağıtım yaklaşımının avantajı, tutarsız ortam kurulumlarından kaynaklanan sorunların çoğunu ve bunlarla birlikte gelen sorunları ortadan kaldırmasıdır. Ayrıca kapsayıcılar, gerektiğinde yeni kapsayıcılar oluşturarak hızlı uygulama ölçeğini artırma işlevine izin verir.

Kapsayıcı oluştururken ve kapsayıcılarla çalışırken temel kavramlar şunlardır:

  • Kapsayıcı Konağı: Kapsayıcıları barındırmak için yapılandırılan fiziksel veya sanal makine. Kapsayıcı konağı bir veya daha fazla kapsayıcı çalıştırır.
  • Kapsayıcı Görüntüsü: Görüntü, üst üste yığılmış katmanlı dosya sistemlerinin birleşiminden oluşur ve kapsayıcının temelini oluşturur. Görüntünün durumu yoktur ve farklı ortamlara dağıtıldığından hiçbir zaman değişmez.
  • Kapsayıcı: Kapsayıcı, görüntünün çalışma zamanı örneğidir.
  • Kapsayıcı İşletim Sistemi Görüntüsü: Kapsayıcılar görüntülerden dağıtılır. Kapsayıcı işletim sistemi görüntüsü, kapsayıcıyı oluşturan birçok görüntü katmanının ilk katmanıdır. Kapsayıcı işletim sistemi sabittir ve değiştirilemez.
  • Kapsayıcı Deposu: Kapsayıcı görüntüsü her oluşturulduğunda, görüntü ve bağımlılıkları yerel bir depoda depolanır. Bu görüntüler kapsayıcı ana bilgisayarında birçok kez yeniden kullanılabilir. Kapsayıcı görüntüleri, farklı kapsayıcı konaklarında kullanılabilmesi için Docker Hub gibi genel veya özel bir kayıt defterinde de depolanabilir.

Kuruluşlar mikro hizmet tabanlı uygulamalar uygularken kapsayıcıları giderek daha fazla benimsiyor ve Docker, çoğu yazılım platformu ve bulut satıcısı tarafından benimsenen standart kapsayıcı uygulaması haline geldi.

eShopOnContainers başvuru uygulaması, Şekil 8-4'te gösterildiği gibi dört kapsayıcılı arka uç mikro hizmetini barındırmak için Docker kullanır.

eShopOnContainers reference application back-end microservices

Şekil 8-4: eShopOnContainers başvuru uygulaması arka uç mikro hizmetleri

Başvuru uygulamasındaki arka uç hizmetlerinin mimarisi, mikro hizmetler ve kapsayıcılarla işbirliği yapmak biçiminde birden çok otonom alt sistem olarak ayrıştırılır. Her mikro hizmet tek bir işlevsellik alanı sağlar: kimlik hizmeti, katalog hizmeti, sipariş hizmeti ve sepet hizmeti.

Her mikro hizmetin kendi veritabanı vardır ve diğer mikro hizmetlerden tamamen ayrıştırılabilir. Gerektiğinde, uygulama düzeyinde olaylar kullanılarak farklı mikro hizmetlerden veritabanları arasında tutarlılık elde edilir. Daha fazla bilgi için bkz . Mikro hizmetler arasındaki iletişim.

Başvuru uygulaması hakkında daha fazla bilgi için bkz . .NET Mikro Hizmetleri: Kapsayıcılı .NET Uygulamaları için Mimari.

İstemci ve Mikro Hizmetler Arasındaki İletişim

eShopOnContainers mobil uygulaması, Şekil 8-5'te gösterilen doğrudan istemciden mikro hizmete iletişimi kullanarak kapsayıcılı arka uç mikro hizmetleriyle iletişim kurar.

Diagram shows an app hosted on a mobile device connected to three Backend Microservices, each with its own Web A P I Container.

Şekil 8-5: Doğrudan istemciden mikro hizmete iletişim

Doğrudan istemciden mikro hizmete iletişim sayesinde mobil uygulama, mikro hizmet başına farklı bir TCP bağlantı noktasıyla her mikro hizmete doğrudan genel uç noktası üzerinden istekte bulunur. Üretimde uç nokta genellikle istekleri kullanılabilir örnekler arasında dağıtan mikro hizmetin yük dengeleyicisine eşlenecektir.

İpucu

API ağ geçidi iletişimlerini kullanmayı göz önünde bulundurun. Doğrudan istemciden mikro hizmete iletişimin büyük ve karmaşık bir mikro hizmet tabanlı uygulama oluştururken dezavantajları olabilir, ancak küçük bir uygulama için fazla yeterlidir. Onlarca mikro hizmet içeren büyük bir mikro hizmet tabanlı uygulama tasarlarken API ağ geçidi iletişimini kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz . .NET Mikro Hizmetleri: Kapsayıcılı .NET Uygulamaları için Mimari.

Mikro Hizmetler Arasındaki İletişim

Mikro hizmet tabanlı uygulama, birden çok makinede çalışan dağıtılmış bir sistemdir. Her hizmet örneği genellikle bir işlemdir. Bu nedenle, hizmetlerin her hizmetin niteliğine bağlı olarak HTTP, TCP, Gelişmiş Message Queuing Protokolü (AMQP) veya ikili protokoller gibi işlemler arası iletişim protokolü kullanarak etkileşim kurması gerekir.

Mikro hizmet-mikro hizmet iletişimi için iki yaygın yaklaşım, verileri sorgularken HTTP tabanlı REST iletişimi ve güncelleştirmeleri birden çok mikro hizmet arasında iletişim kurarken basit zaman uyumsuz mesajlaşmadır.

Zaman uyumsuz mesajlaşma tabanlı olay odaklı iletişim, değişiklikleri birden çok mikro hizmete dağıtırken kritik önem taşır. Bu yaklaşımla, bir mikro hizmet, örneğin bir iş varlığını güncelleştirdiğinde önemli bir şey olduğunda bir olay yayımlar. Diğer mikro hizmetler bu olaylara abonedir. Daha sonra bir mikro hizmet bir olay aldığında kendi iş varlıklarını güncelleştirir ve bu da daha fazla olayın yayımlanmasına neden olabilir. Bu yayımlama-abone olma işlevi genellikle bir olay veri yolu ile elde edilir.

Olay veri yolu, Şekil 8-6'da gösterildiği gibi bileşenlerin birbirini açıkça tanımasını gerektirmeden mikro hizmetler arasında yayımlama-abone olma iletişimine olanak tanır.

Publish-subscribe with an event bus

Şekil 8-6: Olay veri yolu ile yayımlama-abone olma

Uygulama açısından bakıldığında, olay veri yolu yalnızca bir arabirim aracılığıyla kullanıma sunulan bir yayımlama-abone ol kanalıdır. Ancak, olay veri yolunun uygulanma biçimi farklılık gösterebilir. Örneğin, bir olay veri yolu uygulaması RabbitMQ, Azure Service Bus veya NServiceBus ve MassTransit gibi diğer hizmet otobüslerini kullanabilir. Şekil 8-7'de bir olay veri yolunun eShopOnContainers başvuru uygulamasında nasıl kullanıldığı gösterilmektedir.

Asynchronous event-driven communication in the reference application

Şekil 8-7: Başvuru uygulamasında zaman uyumsuz olay odaklı iletişim

RabbitMQ kullanılarak uygulanan eShopOnContainers olay veri yolu, bire çok zaman uyumsuz yayımlama-abone olma işlevselliği sağlar. Bu, bir olayı yayımladıktan sonra aynı olayı dinleyen birden çok abone olabileceği anlamına gelir. Şekil 8-9'da bu ilişki gösterilmektedir.

One-to-many communication

Şekil 8-9: Bire çok iletişim

Bu bire çok iletişim yaklaşımı, olaylar kullanarak birden çok hizmete yayılan iş işlemlerini uygular ve hizmetler arasında nihai tutarlılık sağlar. Nihai tutarlı işlem, bir dizi dağıtılmış adımdan oluşur. Bu nedenle, kullanıcı profili mikro hizmeti UpdateUser komutunu aldığında, veritabanındaki kullanıcının ayrıntılarını güncelleştirir ve UserUpdated olayını olay veri yolu için yayımlar. Hem sepet mikro hizmeti hem de sipariş mikro hizmeti bu olayı almak için abone oldu ve yanıt olarak ilgili veritabanlarındaki alıcı bilgilerini güncelleştirdi.

Not

RabbitMQ kullanılarak uygulanan eShopOnContainers olay veri yolu, yalnızca kavram kanıtı olarak kullanılmak üzere tasarlanmıştır. Üretim sistemleri için alternatif olay veri yolu uygulamaları dikkate alınmalıdır.

Olay veri yolu uygulaması hakkında daha fazla bilgi için bkz . .NET Microservices: Architecture for Containerized .NET Applications.

Özet

Mikro hizmetler, modern bulut uygulamalarının çeviklik, ölçek ve güvenilirlik gereksinimlerine uygun bir uygulama geliştirme ve dağıtım yaklaşımı sunar. Mikro hizmetlerin temel avantajlarından biri, ölçeğin bağımsız olarak genişletilebiliyor olmasıdır; bu da talebi desteklemek için daha fazla işlem gücü veya ağ bant genişliği gerektiren belirli bir işlevsel alanın ölçeklendirilebileceği ve uygulamanın artan taleple karşılaşmayan alanlarını gereksiz yere ölçeklendirmemesidir.

Kapsayıcı, bir uygulamanın diğer kapsayıcıların veya konağın kaynaklarına dokunmadan çalışabildiği yalıtılmış, kaynak denetimli ve taşınabilir bir işletim ortamıdır. Kuruluşlar mikro hizmet tabanlı uygulamalar uygularken kapsayıcıları giderek daha fazla benimsiyor ve Docker, çoğu yazılım platformu ve bulut satıcısı tarafından benimsenen standart kapsayıcı uygulaması haline geldi.