Çok kiracılı mikro hizmet tasarımı

Mikro hizmet mimarisine monolitik bir uygulamayı taşıma sürecindeyiz. Bazı yasal gereksinimler nedeniyle, müşterinin verilerini farklı ülkelerden ayrı (ülkeye özgü) veritabanlarında tutmamız gerekir. Yani ABD müşterileri için ABD db, İngiltere müşterileri için İngiltere db ...

Düşündüğümüz aşağıdaki tasarımlar aşağıdaki gibidir:

Seçenek 1: İsteğe bağlı olarak N defaya kadar ölçeklendirilebilen hazırda bekleme çoklu kiracı desteğine sahip çok kiracılı bir uygulama (kubernet podlarını düşünün). Bu uygulamanın tek bir örneği tüm veritabanlarına bağlanabilir.

Seçenek 2: Her ülke veritabanı için 1 mikro hizmet örneği dağıtın. Önlerinde bir API ağ geçidi ile trafiği yönlendiriyor

Bu tür bir sistem tasarlayacak olsaydınız, seçimleriniz ne olurdu?

microservices

— Selam Dünya
kaynak

Bence bu sizin özel fonksiyonel ve fonksiyonel olmayan gereksinimlerinizin ne olduğuna bağlı olacaktır.

— Robert Harvey

Farklı veritabanları ama aynı örnek onu okuyor? Bu yasal gerekliliği de ihlal etmiyor mu?

— Jimmy T.

Seçenek 1, Microservices mimari stiliyle çok uyumlu görünmüyor.

— Laiv

Kebernetes'ten bahsediyorsunuz, ancak konteyner kullanıp kullanmadığınız belli değil. Bunu Docker ile yapıyorsanız (örneğin) bir veritabanına bağlanan bir uygulama oluşturmanız yeterlidir. Ardından kapsayıcıyı başlattığınızda ve parametreler ve / veya yapılandırma yoluyla bağlantı ayrıntılarını belirttiğinizde. Birçok veritabanına bağlanan bir uygulamaya sahip olmak yalnızca potansiyel sorunlar yaratır. Tasarıma iyi bir şey eklemez.

— JimmyJames

Yanıtlar:

Seçenek 2'nin kötü bir şey olmadığını düşünüyorum, ancak gerekli olmayabilir. Mikro hizmetler, birden fazla uygulamanın ihtiyaçlarını karşılamanıza izin verir.

Burada büyük bir faktör, iki şema arasında herhangi bir fark olup olmadığı ve gelecekte de olup olmayacağıdır.

Genellikle, veri havuzları için arayüzler kullanmak gereksizdir; ancak, bu örnekte çabaya değebilir. Depo fabrikaları sizin için önemli olacaktır.

Seçenek 1 ile ilgili sorunum çok spesifik olması. Açıkladığınız kurulumdan, her biri kendi DB'sini kolayca gösteren iki ayrı örneğe geçebilmelisiniz. Uygulama VERİLERİNDEN VERİLEN YERLERDE BAKMAMALIDIR.

Şema iki farklı veritabanınız için farklı olmasa da, uygulama farkını bilmeden bir havuzun her ikisiyle de kolayca başa çıkmasını sağlayabilirsiniz:

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

DB şemaları ABD ve İngiltere arasında hiç de farklılaşırsa, işlevselliği tamamen farklı iki depoya bölebilirsiniz. Bu kolay olurdu, çünkü tek yapmanız gereken fabrikanızı değiştirmek.

— TheCatWhisperer
kaynak

Neden bu fabrikaya ihtiyacın olduğunu anlamıyorum. Neden başlangıçta yapılandırma ayrıntılarının yolunu geçmiyorsunuz? Bununla her yeni bölge / ülke eklemek istediğinizde kodu değiştirmeniz gerekir.

— JimmyJames

Buradaki sorun ayrı ülkelerdeki kullanıcılarla ilgilenmiyor ... farklı veritabanlarıyla ilgileniyor. farklı şemalar varsa? Tüketici sınıfı neden DB bağlantı dizesinin nereden alınacağını bulmaktan sorumlu olmalıdır?

— TheCatWhisperer

Ne demek istediğini bilmiyorum. Koddaki hiçbir şey bağlantı dizesinin nereden alınacağını 'anlamaktan' sorumlu olmamalıdır. Bu yapılandırma. Bunun neden QA veritabanları ve üretim için yapılandırma kullanmaktan farklı olduğunu anlamıyorum. Bunun için kodlar halinde if ifadeleri koymazsınız, değil mi?

— JimmyJames

Bu iki veritabanına konuşan bir uygulamadır.

— TheCatWhisperer

Sorunu yanlış anladığınızı düşünüyorum: "farklı ülkelerden gelen müşteri verilerini ayrı (ülkeye özgü) veritabanlarında tutmamız gerekiyor" Tek bir uygulama "örneği" nin iki veritabanıyla konuşmasına gerek yoktur. Sadece iki DB olduğundan şüpheliyim. OP "ie" yazdıklarında muhtemelen "örneğin" demekti

— JimmyJames

İkinci seçenekle giderdim, geliştirme ve dağıtımda daha az sürtünme verir.

Bu, uygulamanızı tüm dünya için en az bir tane yerine bölge başına 1 (veya en az bir) örneğe dağıttığınız için daha iyi ölçeklenebilirlik ve kullanılabilirlik ve daha iyi sıfır kesinti dağıtım seçenekleri sağlar.

Gereksinimleri değiştikçe daha fazla bölgeye özgü iş mantığı ve muhtemelen veri değişiklikleri de olabilir, kodu ve bölge başına verileri bölmeyi dener ve bölgeye özgü iş mantığını paylaşmaktan kaçınırım (bazı temel kodları paylaşabilirsiniz).

Mantıklı olmak?

— Sean Farmar
kaynak