Aracılığıyla paylaş

Mikro hizmet başına veri hakimiyeti

  • Makale

İ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.

PDF'i indirin

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

Mikro hizmetler mimarisi için önemli bir kural, her mikro hizmetin kendi etki alanı verilerine ve mantığına sahip olması gerektiğidir. Tam bir uygulamanın mantığına ve verilerine sahip olması gibi, her mikro hizmetin kendi mantığına ve verilerine mikro hizmet başına bağımsız dağıtım ile otonom bir yaşam döngüsü altında sahip olması gerekir.

Bu, etki alanının kavramsal modelinin alt sistemler veya mikro hizmetler arasında farklılık göstereceği anlamına gelir. Müşteri ilişkileri yönetimi (CRM) uygulamalarının, işlemsel satın alma alt sistemlerinin ve müşteri desteği alt sistemlerinin her birinin benzersiz müşteri varlığı öznitelikleri ve verileri üzerinde çağırdığı ve her birinin farklı bir Sınırlanmış Bağlam (BC) çalıştırdığı kurumsal uygulamaları göz önünde bulundurun.

Bu ilke, Her Sınırlanmış Bağlam veya otonom alt sistem veya hizmetin etki alanı modeline (veri artı mantık ve davranış) sahip olması gereken Etki alanı temelli tasarımda (DDD) benzerdir. Her DDD Sınırlanmış Bağlam, bir iş mikro hizmetiyle (bir veya birden çok hizmet) bağıntılı olur. Sınırlanmış Bağlam düzeniyle ilgili bu nokta sonraki bölümde genişletilir.

Öte yandan, birçok uygulamada kullanılan geleneksel (monolitik veriler) yaklaşımı tek bir merkezi veritabanına veya yalnızca birkaç veritabanına sahip olmaktır. Bu genellikle Şekil 4-7'de gösterildiği gibi uygulamanın tamamı ve tüm iç alt sistemleri için kullanılan normalleştirilmiş bir SQL veritabanıdır.

Diagram showing the two database approaches.

Şekil 4-7. Veri hakimiyeti karşılaştırması: Monolitik veritabanı ile mikro hizmetler karşılaştırması

Geleneksel yaklaşımda, genellikle katmanlı mimaride olmak üzere tüm hizmetler arasında paylaşılan tek bir veritabanı vardır. Mikro hizmetler yaklaşımında her mikro hizmet kendi modeline/verilerine sahiptir. Merkezi veritabanı yaklaşımı başlangıçta daha basit görünür ve her şeyi tutarlı hale getirmek için farklı alt sistemlerdeki varlıkların yeniden kullanılmasını mümkün kılmış gibi görünür. Ancak gerçek şu ki, birçok farklı alt sisteme hizmet veren ve çoğu durumda gerekli olmayan öznitelikleri ve sütunları içeren büyük tablolara sahip olursunuz. Bu, kısa bir patikada yürüyüş yapmak, bir günlük araba yolculuğu yapmak ve coğrafya öğrenmek için aynı fiziksel haritayı kullanmaya çalışmak gibidir.

Genellikle tek bir ilişkisel veritabanına sahip monolitik bir uygulamanın iki önemli avantajı vardır: ACID işlemleri ve SQL dili, hem tüm tablolarda hem de uygulamanızla ilgili verilerde çalışır. Bu yaklaşım, birden çok tabloya ait verileri birleştiren bir sorguyu kolayca yazmanın bir yolunu sağlar.

Ancak, bir mikro hizmet mimarisine geçtiğiniz zaman veri erişimi çok daha karmaşık hale gelir. Bir mikro hizmet veya Sınırlanmış Bağlam içinde ACID işlemleri kullanılırken bile, her mikro hizmetin sahip olduğu verilerin bu mikro hizmete özel olduğunu ve yalnızca API uç noktaları (REST, gRPC, SOAP vb.) üzerinden zaman uyumlu veya mesajlaşma (AMQP veya benzeri) aracılığıyla zaman uyumsuz olarak erişilmesi gerektiğini göz önünde bulundurmak önemlidir.

Verileri kapsüllemek, mikro hizmetlerin gevşek bir şekilde birbirine bağlı olmasını ve birbirinden bağımsız olarak gelişebilmesini sağlar. Aynı verilere birden çok hizmet erişiyorsa, şema güncelleştirmeleri tüm hizmetler için eşgüdümlü güncelleştirmeler gerektirir. Bu, mikro hizmet yaşam döngüsü özerkliğini bozar. Ancak dağıtılmış veri yapıları, mikro hizmetler arasında tek bir ACID işlemi yapamayabileceğiniz anlamına gelir. Bu da bir iş süreci birden çok mikro hizmete yayıldığında nihai tutarlılığı kullanmanız gerektiği anlamına gelir. Daha sonra açıklayacağımız gibi, bütünlük kısıtlamaları oluşturamadığınız veya ayrı veritabanları arasında dağıtılmış işlemler kullanamadığınız için bunu uygulamak basit SQL birleşimlerinden çok daha zordur. Benzer şekilde, diğer birçok ilişkisel veritabanı özelliği birden çok mikro hizmette kullanılamaz.

Daha da ileri giderek, farklı mikro hizmetler genellikle farklı türlerde veritabanları kullanır. Modern uygulamalar çeşitli veri türlerini depolar ve işler ve ilişkisel veritabanı her zaman en iyi seçenek değildir. Bazı kullanım örnekleri için Azure CosmosDB veya MongoDB gibi bir NoSQL veritabanı daha kullanışlı bir veri modeline sahip olabilir ve SQL Server veya Azure SQL Veritabanı gibi bir SQL veritabanından daha iyi performans ve ölçeklenebilirlik sunabilir. Diğer durumlarda ilişkisel veritabanı hala en iyi yaklaşımdır. Bu nedenle, mikro hizmet tabanlı uygulamalar genellikle bazen çok yönlü kalıcılık yaklaşımı olarak adlandırılan SQL ve NoSQL veritabanlarının bir karışımını kullanır.

Veri depolama için bölümlenmiş, çok yönlü kalıcı mimarinin birçok avantajı vardır. Bunlar arasında gevşek bir şekilde bağlanmış hizmetler ve daha iyi performans, ölçeklenebilirlik, maliyetler ve yönetilebilirlik bulunur. Ancak, bu bölümün devamında "Etki alanı modeli sınırlarını tanımlama" bölümünde açıklandığı gibi bazı dağıtılmış veri yönetimi zorluklarına neden olabilir.

Mikro hizmetler ile Sınırlanmış Bağlam düzeni arasındaki ilişki

Mikro hizmet kavramı, etki alanı temelli tasarımda (DDD) Sınırlanmış Bağlam (BC) deseninden türetilir. DDD, büyük modelleri birden çok BC'ye bölerek ve sınırları konusunda açık olarak ele alır. Her BC'nin kendi modeli ve veritabanı olmalıdır; benzer şekilde, her mikro hizmet ilgili verilere sahip olur. Buna ek olarak, yazılım geliştiricileriyle etki alanı uzmanları arasındaki iletişime yardımcı olmak için her BC'nin genellikle kendi yaygın dili vardır.

Yaygın dildeki bu terimler (çoğunlukla etki alanı varlıkları), farklı etki alanı varlıkları aynı kimliği (yani, varlığı depolama alanından okumak için kullanılan benzersiz kimlik) paylaştığında bile farklı Sınırlanmış Bağlamlarda farklı adlara sahip olabilir. Örneğin, kullanıcı profili Sınırlanmış Bağlam'da Kullanıcı etki alanı varlığı, Sınırlanmış Bağlam sıralamasında Alıcı etki alanı varlığıyla kimlik paylaşabilir.

Bu nedenle mikro hizmet, Sınırlanmış Bağlam gibidir, ancak bunun dağıtılmış bir hizmet olduğunu da belirtir. Her Sınırlanmış Bağlam için ayrı bir işlem olarak derlenir ve HTTP/HTTPS, WebSockets veya AMQP gibi daha önce belirtilen dağıtılmış protokolleri kullanması gerekir. Bununla birlikte, Sınırlanmış Bağlam düzeni, Sınırlanmış Bağlamın dağıtılmış bir hizmet olup olmadığını veya tek parçalı dağıtım uygulaması içindeki mantıksal bir sınır (genel alt sistem gibi) olup olmadığını belirtmez.

Her Sınırlanmış Bağlam için bir hizmet tanımlamanın başlamak için iyi bir yer olduğunu vurgulamak önemlidir. Ancak tasarımınızı buna kısıtlamanıza gerek yoktur. Bazen çeşitli fiziksel hizmetlerden oluşan bir Sınırlanmış Bağlam veya iş mikro hizmeti tasarlamanız gerekir. Ancak sonuçta, her iki desen de -Sınırlanmış Bağlam ve mikro hizmet- yakından ilişkilidir.

DDD, dağıtılmış mikro hizmetler biçiminde gerçek sınırlar elde ederek mikro hizmetlerden yararlanır. Ancak modeli mikro hizmetler arasında paylaşmama gibi fikirler, Sınırlanmış Bağlamda da istediğiniz şeylerdir.

Ek kaynaklar

Geriİleri