Chúng tôi đang xây dựng một nền tảng web kết hợp nhiều dịch vụ, mỗi dịch vụ có dữ liệu cơ bản riêng. Các dịch vụ này đang được xây dựng độc lập theo các nguyên tắc của Kiến trúc hướng dịch vụ , nhưng chúng giao dịch với các dữ liệu có khả năng liên quan. Chúng tôi đang xem xét liệu các dịch vụ này nên chia sẻ một cơ sở dữ liệu lớn hay mỗi cơ sở dữ liệu đều có cơ sở dữ liệu riêng. (Chúng tôi đang có kế hoạch sử dụng SQL Server 2008 Enterprise trên cụm Windows 2008.)

Một số ưu điểm của từng phương pháp chúng tôi đã xem xét bao gồm:

Cơ sở dữ liệu đơn

• Dữ liệu liên quan từ các dịch vụ khác nhau có thể được liên kết với nhau bằng các ràng buộc khóa ngoài
• Trích xuất phân tích đơn giản hơn để viết và thực hiện nhanh hơn
• Trong trường hợp xảy ra thảm họa, việc khôi phục nền tảng về trạng thái nhất quán sẽ dễ dàng hơn
• Đối với dữ liệu được tham chiếu bởi nhiều dịch vụ, dữ liệu được lưu trong bộ nhớ cache của một dịch vụ có thể sẽ được sử dụng ngay sau đó bởi một dịch vụ khác
• Quản trị và giám sát đơn giản hơn và rẻ hơn trước

Nhiều cơ sở dữ liệu

• Công việc bảo trì, sự cố phần cứng, vi phạm bảo mật và vv không nhất thiết ảnh hưởng đến toàn bộ nền tảng
• Giả sử mỗi cơ sở dữ liệu nằm trên phần cứng riêng biệt, nhân rộng nhiều máy mang lại nhiều lợi ích hiệu suất hơn so với nhân rộng một cơ sở dữ liệu lớn

Từ góc độ hoạt động, có lợi hơn không khi mỗi dịch vụ trong nền tảng này có được cơ sở dữ liệu riêng hoặc tất cả chúng đều đi trong cùng một cơ sở dữ liệu? Những yếu tố chính thông báo một câu trả lời cho câu hỏi này?

Theo tôi, điểm khác biệt chính của các hệ thống SOA thực sự (trên các hệ thống giả, hệ thống phân tán / giả mạo đang trở nên phổ biến) là không nên có sự tương tác giữa các dịch vụ rời rạc. Khi đạt được điều này, bất kỳ ứng dụng nào bạn soạn từ các dịch vụ này đều có thể và nên được xây dựng để chịu đựng sự thất bại của bất kỳ phần nhất quán nào. Một thất bại làm giảm chức năng nhưng dịch vụ được duy trì.

Trong kịch bản này, logic, hoặc bắt buộc, để tách cơ sở dữ liệu cơ bản cho từng dịch vụ. Tuy nhiên, nếu bạn có các dịch vụ phụ thuộc lẫn nhau, có rất ít (có lẽ không có gì) có được từ việc phân tách.

Tôi khuyên bạn nên đọc các trang web như HighScalability.com đào sâu vào các kiến ​​trúc được chấp nhận bởi các trang web loại không bao giờ thất bại. Một trong những điều yêu thích cuối cùng của tôi là câu chuyện về chú khỉ hỗn loạn Netflix đã được đề cập trên Coding H khiếp sợ .

Giải quyết một vài điểm trong câu hỏi của bạn:

Trong trường hợp xảy ra thảm họa, việc khôi phục nền tảng về trạng thái nhất quán sẽ dễ dàng hơn.

Điều này là đúng nhưng có lẽ bạn nên suy nghĩ về cách giải mã tốt hơn các dịch vụ này để điều này không còn là vấn đề nữa. Ngoài ra, có các phương pháp để đảm bảo đồng bộ hóa trên nhiều cơ sở dữ liệu, dấu giao dịch trong SQL Server chẳng hạn.

Đối với dữ liệu được tham chiếu bởi nhiều dịch vụ, dữ liệu được lưu trong bộ nhớ cache của một dịch vụ có thể sẽ được sử dụng ngay sau đó bởi một dịch vụ khác.

Các giải pháp bộ nhớ cache phân tán (memcached et al) có thể giúp đỡ ở đây nhưng bạn sẽ vi phạm các nguyên tắc độc lập dịch vụ. Điều này có thể so sánh với việc hai dịch vụ liên lạc trực tiếp với nhau hoặc tệ hơn là có dịch vụ truy cập kho dữ liệu của bà mẹ, bỏ qua giao diện dịch vụ hoàn toàn. Dữ liệu chắc chắn sẽ liên quan và sẽ được trao giữa các dịch vụ bởi nền tảng gọi điện, các quyết định khó khăn có xu hướng xoay quanh dịch vụ nào sẽ sở hữu phần dữ liệu nào. Các trang web StackOverflow hoặc Lập trình viên có thể được đặt tốt hơn để giúp giải quyết các vấn đề chung hơn về SOA.

Giả sử mỗi cơ sở dữ liệu là trên phần cứng riêng biệt, nhân rộng sẽ mang lại nhiều lợi ích hiệu suất hơn.

Chắc chắn có thể rẻ hơn khi mở rộng quy mô trên nhiều máy spec thấp hơn so với mở rộng một máy. Mặc dù, chi phí phần cứng thấp hơn có thể bị lấn át trong tổng chi phí sở hữu khi chi phí mềm cho nỗ lực phát triển bổ sung và độ phức tạp hoạt động được tính đến.

Nếu đây không phải là SOA và bạn chỉ gặp trường hợp các dịch vụ thành phần của nền tảng này được xây dựng bởi các nhóm / nhà cung cấp khác nhau vì lý do hậu cần, hãy gắn bó với một cơ sở dữ liệu duy nhất và hoàn toàn bỏ qua mọi thứ ở trên! :)