Aracılığıyla paylaş


Mantıksal mimari ile fiziksel mimari karşılaştırması

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Bu noktada mantıksal mimari ile fiziksel mimari arasındaki ayrımı ve bunun mikro hizmet tabanlı uygulamaların tasarımı için nasıl geçerli olduğunu tartışmak yararlı olur.

Başlamak için mikro hizmetler oluşturmak için belirli bir teknolojinin kullanılması gerekmez. Örneğin, Mikro hizmet tabanlı mimari oluşturmak için Docker kapsayıcıları zorunlu değildir. Bu mikro hizmetler düz işlemler olarak da çalıştırılabilir. Mikro hizmetler mantıksal bir mimaridir.

Ayrıca, bir mikro hizmet fiziksel olarak tek bir hizmet, süreç veya kapsayıcı olarak uygulanabilse bile (basitlik açısından, eShopOnContainers'ın ilk sürümünde uygulanan yaklaşım budur), birçok düzine ve hatta yüzlerce hizmetten oluşan büyük ve karmaşık bir uygulama oluşturduğunuzda iş mikro hizmeti ile fiziksel hizmet veya kapsayıcı arasındaki bu eşlik her durumda gerekli değildir.

Burada uygulamanın mantıksal mimarisiyle fiziksel mimarisi arasında bir fark vardır. Bir sistemin mantıksal mimarisi ve mantıksal sınırları mutlaka fiziksel veya dağıtım mimarisiyle bire bir eşlenmez. Bu gerçekleşebilir, ancak genellikle gerçekleşmez.

Belirli iş mikro hizmetlerini veya Sınırlanmış Bağlamları tanımlamış olabilirsiniz ancak bu, bunları uygulamanın en iyi yolunun her zaman her iş mikro hizmeti için tek bir hizmet (ASP.NET Web API'si gibi) veya tek bir Docker kapsayıcısı oluşturmak olduğu anlamına gelmez. Her işletme mikro hizmetinin tek bir hizmet veya kapsayıcı kullanılarak uygulanması gerektiğini belirten bir kurala sahip olmak çok katıdır.

Bu nedenle, iş mikro hizmeti veya Sınırlanmış Bağlam, fiziksel mimariyle çakışabilen (veya çakışmayan) mantıksal bir mimaridir. Önemli nokta, bir iş mikro hizmetinin veya Sınırlanmış Bağlamın, kodun ve durumun bağımsız olarak sürümlendirilmesine, dağıtılmasına ve ölçeklendirilmesine izin vererek otonom olması gerektiğidir.

Şekil 4-8'de gösterildiği gibi, katalog iş mikro hizmeti birkaç hizmet veya işlemden oluşabiliyordu. Bunlar birden çok ASP.NET Web API'si hizmeti veya HTTP veya başka bir protokol kullanan başka bir hizmet türü olabilir. Daha da önemlisi, bu hizmetler aynı iş alanıyla uyumlu olduğu sürece hizmetler aynı verileri paylaşabilir.

Diagram of the Catalog business microservice with physical servers.

Şekil 4-8. Çeşitli fiziksel hizmetlerle iş mikro hizmeti

Web API hizmeti Arama hizmeti ile aynı verileri hedeflediğinden, örnekteki hizmetler aynı veri modelini paylaşır. Bu nedenle, iş mikro hizmetinin fiziksel uygulamasında, bu işlevleri bölerek bu iç hizmetlerin her birini gerektiği gibi artırıp azaltabilirsiniz. Web API hizmetinin genellikle Arama hizmeti daha fazla örneğe ihtiyacı olabilir veya tam tersi.

Kısacası, mikro hizmetlerin mantıksal mimarisinin her zaman fiziksel dağıtım mimarisiyle aynı olması gerekmez. Bu kılavuzda, bir mikro hizmetten her bahsetmemizde, bir veya daha fazla (fiziksel) hizmetle eşlenebilir bir iş veya mantıksal mikro hizmet anlamına gelir. Çoğu durumda, bu tek bir hizmet olacaktır, ancak daha fazla olabilir.