Thiết kế microservice nhiều người thuê

Chúng tôi đang trong quá trình di chuyển một ứng dụng nguyên khối sang kiến ​​trúc microservice. Do một số yêu cầu quy định, chúng tôi phải giữ dữ liệu của khách hàng từ các quốc gia khác nhau trong cơ sở dữ liệu riêng biệt (quốc gia cụ thể). Tức là db Mỹ cho khách hàng Hoa Kỳ, db Anh cho khách hàng Vương quốc Anh ...

Các thiết kế sau đây mà chúng tôi đang xem xét như sau:

Tùy chọn 1: Một ứng dụng nhiều người thuê với sự hỗ trợ của nhiều người thuê ngủ đông có thể được thu nhỏ thành N số lần phụ thuộc vào nhu cầu (nghĩ về các nhóm kubernetes). Một phiên bản duy nhất của ứng dụng này sẽ có thể kết nối với tất cả các cơ sở dữ liệu.

Tùy chọn 2: Triển khai 1 phiên bản microservice cho mỗi cơ sở dữ liệu quốc gia. Với một cổng API ở phía trước chúng định tuyến lưu lượng

Nếu bạn thiết kế loại hệ thống này, lựa chọn của bạn là gì?

Tôi nghĩ rằng tùy chọn 2 không phải là một lựa chọn tồi, nhưng có thể không cần thiết. Các dịch vụ vi mô là để cho phép bạn giải quyết nhu cầu của nhiều ứng dụng.

Một yếu tố lớn ở đây, là nếu có bất kỳ sự khác biệt giữa hai lược đồ, và nếu có bao giờ sẽ có trong tương lai.

Thông thường, tôi nghĩ rằng sử dụng giao diện cho các kho lưu trữ là không cần thiết; tuy nhiên, nó có thể là giá trị nỗ lực trong trường hợp này. Các nhà máy lưu trữ sẽ rất quan trọng đối với bạn.

Vấn đề của tôi với tùy chọn 1 là nó quá cụ thể. Bạn sẽ có thể đi từ thiết lập mà bạn đã mô tả, đến hai trường hợp riêng biệt, mỗi trường hợp chỉ đến DB của chính nó một cách dễ dàng. Ứng dụng KHÔNG nên CHĂM SÓC Ở ĐÂU KHI NHẬN ĐƯỢC DỮ LIỆU.

Mặc dù lược đồ không khác nhau đối với hai cơ sở dữ liệu khác nhau của bạn, bạn có thể có một kho lưu trữ dễ dàng xử lý cả hai mà không cần ứng dụng biết sự khác biệt:

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

Nếu các lược đồ DB trở nên khác biệt giữa Hoa Kỳ và Vương quốc Anh, thì bạn sẽ chia chức năng thành hai kho hoàn toàn khác nhau. Điều này sẽ dễ dàng, vì tất cả những gì bạn sẽ phải làm là thay đổi nhà máy của bạn.

Tôi sẽ đi với tùy chọn thứ hai, nó cho ít ma sát hơn trong phát triển và triển khai.

Điều này sẽ cho phép khả năng mở rộng và tính sẵn sàng tốt hơn và các tùy chọn triển khai thời gian chết không tốt hơn, khi bạn phân phối ứng dụng của mình cho 1 (hoặc ít nhất một) cho mỗi khu vực, trái ngược với ít nhất một cho toàn thế giới.

Khi các yêu cầu thay đổi, bạn có thể có logic kinh doanh cụ thể theo vùng hơn và cũng có thể thay đổi dữ liệu, tôi sẽ thử phân tách mã và dữ liệu theo từng vùng và tránh chia sẻ logic kinh doanh cụ thể theo vùng (cuối cùng bạn có thể chia sẻ một số mã lõi).

Có lý?