การออกแบบ microservice แบบหลายผู้เช่า

เรากำลังอยู่ในขั้นตอนการโอนย้ายแอพพลิเคชั่นแบบเสาหินไปยังสถาปัตยกรรมไมโครเซอร์วิส เนื่องจากข้อกำหนดทางกฎหมายบางประการเราต้องเก็บข้อมูลลูกค้าจากประเทศต่างๆในฐานข้อมูลแยกต่างหาก (เฉพาะประเทศ) เช่น US db สำหรับลูกค้า US, UK db สำหรับลูกค้า UK ...

การออกแบบต่อไปนี้ที่เรากำลังพิจารณามีดังนี้:

ตัวเลือกที่ 1: แอปพลิเคชันผู้เช่าหลายคนพร้อมการสนับสนุนผู้เช่าหลายรายที่จำศีลที่สามารถปรับเป็นจำนวน N ครั้งขึ้นอยู่กับความต้องการ (คิดว่าฝัก kubernetes) อินสแตนซ์เดียวของแอปพลิเคชันนี้จะสามารถเชื่อมต่อกับฐานข้อมูลทั้งหมด

ตัวเลือก 2: ปรับใช้ 1 อินสแตนซ์ microservice ต่อฐานข้อมูลประเทศ ด้วยเกตเวย์ API ด้านหน้าการกำหนดเส้นทางทราฟฟิก

หากคุณต้องออกแบบระบบประเภทนี้ตัวเลือกของคุณจะเป็นอย่างไร

ฉันคิดว่าตัวเลือกที่ 2 ไม่ใช่ตัวเลือกที่แย่ แต่อาจไม่จำเป็น บริการไมโครช่วยให้คุณจัดการกับความต้องการของแอปพลิเคชั่นหลาย ๆ

ปัจจัยใหญ่ที่นี่คือถ้ามีความแตกต่างระหว่างทั้งสอง schema และถ้าเคยจะมีในอนาคต

โดยปกติฉันคิดว่าการใช้ส่วนต่อประสานสำหรับที่เก็บข้อมูลนั้นไม่จำเป็น อย่างไรก็ตามมันอาจจะคุ้มค่ากับความพยายามในกรณีนี้ โรงงานที่เก็บจะมีความสำคัญสำหรับคุณ

ปัญหาของฉันกับตัวเลือก 1 คือว่าเฉพาะเจาะจงเกินไป คุณควรจะสามารถไปจากการตั้งค่าที่คุณอธิบายไปยังสองอินสแตนซ์ที่แยกจากกันแต่ละชี้ไปยังฐานข้อมูลของตัวเองได้อย่างง่ายดาย แอปพลิเคชันไม่ควรใส่ใจว่าข้อมูลของคุณมาจากที่ใด

ในขณะที่สคีมานั้นไม่แตกต่างกันสำหรับฐานข้อมูลทั้งสองที่แตกต่างกันของคุณคุณสามารถให้ที่เก็บหนึ่งอันจัดการกับทั้งคู่ได้อย่างง่ายดาย

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);

หาก schemas DB แตกต่างกันระหว่างสหรัฐอเมริกาและสหราชอาณาจักรคุณจะแบ่งการทำงานออกเป็นสองที่เก็บที่ต่างกันโดยสิ้นเชิง นี่จะเป็นเรื่องง่ายเนื่องจากสิ่งที่คุณต้องทำคือเปลี่ยนโรงงานของคุณ

ฉันจะไปกับตัวเลือกที่สองมันให้แรงเสียดทานน้อยในการพัฒนาและการใช้งาน

วิธีนี้จะช่วยให้มีความยืดหยุ่นและความพร้อมใช้งานที่ดีขึ้นและตัวเลือกการปรับใช้ที่ไม่ต้องเสียเวลาศูนย์เนื่องจากคุณแจกจ่ายแอปของคุณไปยังอินสแตนซ์ 1 (หรืออย่างน้อยหนึ่ง) ต่อภูมิภาค

เนื่องจากความต้องการเปลี่ยนแปลงคุณอาจมีตรรกะทางธุรกิจเฉพาะภูมิภาคและมีการเปลี่ยนแปลงข้อมูลเช่นกันฉันจะลองแยกรหัสและเป็นข้อมูลต่อภูมิภาคและหลีกเลี่ยงการแบ่งปันตรรกะทางธุรกิจเฉพาะภูมิภาค (คุณอาจสิ้นสุดการแชร์รหัสหลัก)

ทำให้รู้สึก?