Thực hiện đa thuê nhà cho một ứng dụng doanh nghiệp trưởng thành

Question

Tôi đã được giao nhiệm vụ làm cho một người thuê nhiều ứng dụng doanh nghiệp. Nó có một BLL Java/Glassfish sử dụng các dịch vụ web SOAP và một chương trình phụ trợ PostgreSQL. Mỗi người thuê nhà có cơ sở dữ liệu riêng của mình, vì vậy (trong trường hợp của tôi ít nhất) "đa người thuê" có nghĩa là hỗ trợ nhiều cơ sở dữ liệu cho mỗi máy chủ ứng dụng.

Máy chủ ứng dụng một người thuê hiện tại khởi tạo một nhóm kết nối C3P0 với chuỗi kết nối mà nó nhận được từ tệp cấu hình. Suy nghĩ của tôi là bây giờ sẽ cần phải có một hồ bơi kết nối cho mỗi khách hàng/cơ sở dữ liệu được phục vụ bởi các máy chủ ứng dụng.

Sau khi người dùng đăng nhập, tôi có thể ánh xạ nó tới đúng hồ bơi kết nối bằng cách tìm kiếm người thuê nhà của nó. Vấn đề chính của tôi là làm thế nào để có được điều này đến nay - khi người dùng đăng nhập lần đầu tiên, bảng User của chương trình phụ trợ được truy vấn và đối tượng User tương ứng được phục vụ. Có vẻ như tôi sẽ cần biết cơ sở dữ liệu nào để sử dụng chỉ với một tên người dùng để làm việc.

Ý tưởng duy nhất của tôi là sẽ cần phải có cơ sở dữ liệu "cấu hình" - cơ sở dữ liệu tập trung để quản lý thông tin về người thuê nhà như chuỗi kết nối. BLL có thể truy vấn cơ sở dữ liệu này để có đủ thông tin để khởi tạo các nhóm kết nối cần thiết. Nhưng kể từ khi tôi chỉ có một tên người dùng để làm việc với, có vẻ như tôi sẽ cần một tra cứu tên người dùng tập trung là tốt, nói cách khác là một bảng UserName với một khóa nước ngoài vào bảng Tenant.

Đây là nơi mà kế hoạch thiết kế của tôi bắt đầu có mùi, khiến tôi nghi ngờ. Bây giờ tôi sẽ có thông tin người dùng trong hai cơ sở dữ liệu riêng biệt, cần phải được duy trì đồng bộ (bổ sung, cập nhật và xóa người dùng). Ngoài ra, tên người dùng bây giờ sẽ phải là duy nhất toàn cầu, trong khi trước khi chúng chỉ cần duy nhất cho mỗi đối tượng thuê.

Tôi thật sự nghi ngờ tôi đang phát minh lại bánh xe hoặc ít nhất có thể có kiến ​​trúc tốt hơn. Tôi chưa bao giờ làm điều này trước đây, cũng như không có ai trong nhóm của tôi, vì thế sự thiếu hiểu biết của chúng tôi. Thật không may, ứng dụng này ít sử dụng các công nghệ hiện có (ví dụ ORM đã được cuộn ở nhà), vì vậy đường dẫn của chúng tôi có thể khó khăn.

Tôi đang yêu cầu sau:

• chỉ trích kế hoạch thiết kế hiện tại của tôi, và gợi ý để cải thiện hay sửa đổi các kiến ​​trúc.
• Đề xuất các công nghệ hiện có cung cấp giải pháp cho vấn đề này. Tôi hy vọng cho một cái gì đó có thể dễ dàng cắm vào cuối trong trò chơi, mặc dù điều này có thể không thực tế. Tôi đã đọc khoảng jspirit, nhưng đã tìm thấy rất ít thông tin về nó - mọi phản hồi về nó hoặc các khung công tác khác sẽ hữu ích.

CẬP NHẬT: Giải pháp đã được triển khai và triển khai thành công và đã vượt qua thử nghiệm ban đầu. Cảm ơn @mikera vì câu trả lời hữu ích và yên tâm của anh ấy!

Answer 1

Vài suy nghĩ nhanh chóng:

• Bạn chắc chắn sẽ cần một số hình thức chỉ số quản lý người dùng chia sẻ (nếu không bạn không thể liên kết đăng nhập của khách hàng với các trường hợp cơ sở dữ liệu mục tiêu bên phải). Tuy nhiên tôi khuyên bạn nên làm điều này rất nhẹ, và chỉ sử dụng nó để đăng nhập ban đầu. Đối tượng người dùng của bạn vẫn có thể được kéo từ cơ sở dữ liệu khách hàng cụ thể khi bạn đã xác định cơ sở dữ liệu này là gì.
• Bạn có thể tạo khóa chính [clientID, tên người dùng] để tên người dùng không cần phải là duy nhất trên các ứng dụng khách.
• Ngoài lớp chỉ mục người dùng mỏng này, tôi sẽ giữ phần lớn thông tin người dùng ở nơi nó nằm trong cơ sở dữ liệu khách hàng cụ thể. Tái cấu trúc lại điều này ngay bây giờ có thể sẽ gây rối, bạn sẽ có được khả năng đa bên thuê cơ bản làm việc trước tiên.
• Bạn cần phải giữ chỉ mục được chia sẻ đồng bộ với các cơ sở dữ liệu khách hàng riêng lẻ. Nhưng tôi không nghĩ điều đó quá khó. Bạn cũng có thể "kiểm tra" đồng bộ hóa và sửa bất kỳ lỗi nào với một lệnh batch, có thể chạy qua đêm hoặc bởi DBA của bạn theo yêu cầu nếu có bất kỳ điều gì không đồng bộ. Tôi muốn xử lý các cơ sở dữ liệu máy khách như là chủ, và sử dụng nó để xây dựng lại chỉ mục người dùng được chia sẻ theo yêu cầu.
• Cùng với thời gian, bạn có thể cấu trúc lại hướng tới một lớp quản lý người dùng chia sẻ hoàn toàn (và thậm chí vào cuối chia sẻ đầy đủ cơ sở dữ liệu khách hàng nếu bạn muốn. Nhưng tiết kiệm này cho một sự lặp lại trong tương lai .....