Có phải thực tế xấu đối với các dịch vụ chia sẻ cơ sở dữ liệu trong SOA?

Gần đây tôi đã đọc Mô hình tích hợp doanh nghiệp của Hohpe và Woolf, một số cuốn sách của Thomas Erl về SOA và xem các video và podcast khác nhau của Udi Dahan et al. trên CQRS và các hệ thống hướng sự kiện.

Hệ thống tại nơi tôi làm việc bị khớp nối cao. Mặc dù về mặt lý thuyết, mỗi hệ thống có cơ sở dữ liệu riêng, có rất nhiều sự tham gia giữa chúng. Trong thực tế điều này có nghĩa là có một cơ sở dữ liệu khổng lồ mà tất cả các hệ thống sử dụng. Ví dụ, có một bảng dữ liệu khách hàng.

Phần lớn những gì tôi đã đọc dường như đề xuất dữ liệu không chuẩn hóa để mỗi hệ thống chỉ sử dụng cơ sở dữ liệu của nó và mọi cập nhật cho một hệ thống sẽ được truyền tới tất cả các hệ thống khác bằng cách sử dụng tin nhắn.

Tôi nghĩ rằng đây là một trong những cách để thực thi các ranh giới trong SOA - mỗi dịch vụ nên có cơ sở dữ liệu riêng, nhưng sau đó tôi đọc được điều này:

/programming/4019902/soa-joining-data-across-mult Môn-service

và nó cho thấy đây là điều sai trái để làm.

Việc tách riêng các cơ sở dữ liệu có vẻ như là một cách tốt để tách các hệ thống, nhưng bây giờ tôi hơi bối rối. Đây có phải là một tuyến đường tốt để đi? Có bao giờ bạn nên phân tách một cơ sở dữ liệu trên, giả sử một dịch vụ SOA, bối cảnh giới hạn DDD, một ứng dụng, v.v.?

Decoupling chỉ hoạt động nếu thực sự có sự tách biệt. Xem xét nếu bạn có một hệ thống đặt hàng:

• Bảng: KHÁCH HÀNG
• Bảng: ĐẶT HÀNG

Nếu đó là tất cả những gì bạn có, không có lý do gì để tách chúng ra. Mặt khác, nếu bạn có điều này:

• Bảng: KHÁCH HÀNG
• Bảng: ĐẶT HÀNG
• Bảng: CUSTOMER_NEWSLETTER

Sau đó, bạn có thể lập luận rằng ĐẶT HÀNG và CUSTOMER_NEWSLETTER là một phần của hai mô-đun hoàn toàn riêng biệt (đặt hàng và tiếp thị). Có lẽ sẽ hợp lý khi chuyển chúng vào các cơ sở dữ liệu riêng biệt (một cho mỗi bảng) và có cả hai mô-đun chia sẻ quyền truy cập vào bảng KHÁCH HÀNG chung trong cơ sở dữ liệu riêng của mình.

Bằng cách đó, bạn đang đơn giản hóa từng mô-đun, nhưng bạn đang tăng độ phức tạp của lớp dữ liệu của mình. Khi ứng dụng của bạn ngày càng lớn hơn, tôi có thể thấy một lợi thế để phân tách. Sẽ có ngày càng nhiều "đảo dữ liệu" thực sự không liên quan đến nhau. Tuy nhiên, sẽ luôn có một số dữ liệu cắt ngang tất cả các mô-đun.

Quyết định đưa chúng vào các cơ sở dữ liệu vật lý khác nhau thường dựa trên các ràng buộc trong thế giới thực như tần suất sao lưu, hạn chế bảo mật, sao chép đến các vị trí địa lý khác nhau, v.v. Tôi sẽ không tách các bảng thành các cơ sở dữ liệu vật lý khác nhau chỉ vì tách biệt các mối quan tâm. Điều đó có thể được xử lý đơn giản hơn với các lược đồ hoặc khung nhìn khác nhau.

Nơi tôi làm việc, chúng tôi có ESBmà 6 ứng dụng khác nhau (hoặc tôi nên nói "điểm cuối") được kết nối. 6 ứng dụng này hoạt động với 3 lược đồ Oracle khác nhau trên 2 trường hợp cơ sở dữ liệu. Một số ứng dụng này cùng tồn tại trong cùng một lược đồ không phải vì chúng có liên quan mà vì cơ sở hạ tầng cơ sở dữ liệu của chúng tôi được quản lý bởi nhà cung cấp bên ngoài và có được một lược đồ mới chỉ mất mãi mãi (tất nhiên, chúng tôi không có quyền truy cập DBA) thực sự mất nhiều thời gian đến mức tại một thời điểm chúng tôi đã nghĩ đến việc sử dụng lại một lược đồ hiện có "tạm thời" để có thể tiếp tục phát triển. Để thực thi "tách" dữ liệu, tên bảng được thêm tiền tố, ví dụ "CST_" cho khách hàng. Ngoài ra, chúng tôi phải làm việc với một lược đồ mà vì một số lý do hợp lệ, chúng tôi không thể thay đổi tuyệt đối ... Thật lạ lùng tôi biết. Tất nhiên, như nó luôn xảy ra, "tạm thời"

Các ứng dụng khác nhau của chúng tôi kết nối với lược đồ cơ sở dữ liệu tương ứng của chúng và hoạt động với các gói PL / SQL của riêng chúng và chúng tôi tuyệt đối cấm bản thân tương tác trực tiếp với các bảng / dữ liệu nằm ngoài miền ứng dụng của chúng tôi.

Khi một trong các ứng dụng được kết nối với ESB cần thông tin bên ngoài miền của nó, nó sẽ gọi dịch vụ liên quan trên ESB để lấy dữ liệu, ngay cả khi thông tin đó thực tế nằm trong cùng một lược đồ, về lý thuyết chỉ cần một tuyên bố tham gia nhỏ trong một trong những yêu cầu SQL .

Chúng tôi làm điều đó để có thể phân chia miền ứng dụng của chúng tôi thành các lược đồ / cơ sở dữ liệu khác nhau và để các dịch vụ trên ESB vẫn hoạt động bình thường khi nó xảy ra (sắp đến Giáng sinh, chúng tôi sẽ xử lý các ngón tay)

Bây giờ, điều này có thể trông lạ và khủng khiếp từ bên ngoài nhưng có những lý do cho điều đó và tôi chỉ muốn chia sẻ kinh nghiệm cụ thể này để cho bạn thấy rằng một hoặc nhiều cơ sở dữ liệu không quan trọng. Đợi đã, nó là! , vì nhiều lý do (+1 cho Scott Whitlock, hãy xem đoạn cuối về sao lưu và điều đó khiến tôi gặp rắc rối) Nhưng điều quan trọng không kém là tôi nghĩ rằng các dịch vụ SOA của bạn được thiết kế đúng, ít nhất đó là ý kiến ​​của tôi và tôi Tôi không phải là một DBA. Cuối cùng, tất cả các cơ sở dữ liệu của bạn thuộc về "kho dữ liệu doanh nghiệp" của bạn, phải không?

Cuối cùng, tôi sẽ không viết lại đoạn cuối của Scott Whitlock, đặc biệt là đoạn này

Tôi sẽ không tách các bảng thành các cơ sở dữ liệu vật lý khác nhau chỉ vì các mối quan tâm riêng biệt.

là thực sự siêu quan trọng. Đừng làm điều đó nếu không có lý do.

Tôi đã nhìn thấy những cơn ác mộng tồi tệ nhất có thể có trong kiến ​​trúc phần mềm do tích hợp dữ liệu và vũ khí tốt nhất để chống lại loại lộn xộn này mà tôi gặp phải cho đến nay bối cảnh giới hạn theo kiểu DDD. Điều đó không xa lắm với "SOA được thực hiện đúng", theo một nghĩa nào đó.

Tuy nhiên, dữ liệu không phải là cách tốt nhất để tấn công vấn đề. Người ta nên tập trung vào hành vi dự kiến ​​/ cần thiết và mang dữ liệu đến nơi quan trọng. Chúng tôi có thể sẽ có một số trùng lặp theo cách này, nhưng đây thường không phải là vấn đề so với các khối để tiến hóa hệ thống hầu như luôn luôn liên quan đến các kiến ​​trúc tích hợp dữ liệu.

Nói một cách đơn giản: nếu bạn đang tìm kiếm các hệ thống được ghép lỏng lẻo, đừng kết nối dữ liệu. Sử dụng các hệ thống đóng gói weel và một kênh liên lạc có cấu trúc tốt ở giữa, hoạt động như "lingua franca".

Phân tách cơ sở dữ liệu và giữ dữ liệu nhất quán giữa chúng là một nhiệm vụ cấp chuyên gia. Rất dễ mắc sai lầm và kết thúc với các vấn đề trùng lặp, v.v., hệ thống hiện tại được thiết kế để tránh. Thành thật mà nói, có một hệ thống làm việc và làm điều này là khá nhiều đảm bảo giới thiệu các lỗi mới không có giá trị thực sự cho người dùng.

Nếu được thực hiện chính xác, tách các mối quan tâm kinh doanh vào các cơ sở dữ liệu khác nhau (hoặc ít nhất là các lược đồ khác nhau) là một ưu điểm .

Vui lòng xem mô tả của Martin Fowler về Mẫu CQRS :

Khi nhu cầu của chúng tôi trở nên tinh vi hơn, chúng tôi dần dần rời khỏi [xử lý một hệ thống thông tin như kho dữ liệu CRUD] ... Thay đổi mà CQRS đưa ra là chia mô hình khái niệm đó thành các mô hình riêng biệt để cập nhật và hiển thị ... Có chỗ cho sự thay đổi đáng kể đây. Các mô hình trong bộ nhớ có thể chia sẻ cùng một cơ sở dữ liệu, trong trường hợp đó, cơ sở dữ liệu đóng vai trò là giao tiếp giữa hai mô hình. Tuy nhiên, họ cũng có thể sử dụng các cơ sở dữ liệu riêng biệt , tạo hiệu quả cho cơ sở dữ liệu truy vấn-cơ sở dữ liệu bằng Báo cáo cơ sở dữ liệu thời gian thực. Trong trường hợp này cần có một số cơ chế giao tiếp giữa hai mô hình hoặc cơ sở dữ liệu của chúng.

Và NServiceBus Nguyên tắc kiến ​​trúc :

Phân tách truy vấn lệnh

Một giải pháp tránh vấn đề này phân tách các lệnh và truy vấn ở cấp hệ thống, thậm chí cao hơn so với máy khách và máy chủ. Trong giải pháp này, có hai "dịch vụ" trải rộng cả máy khách và máy chủ - một phụ trách các lệnh (tạo, cập nhật, xóa), còn lại là phụ trách truy vấn (đọc). Các dịch vụ này chỉ giao tiếp qua tin nhắn - người ta không thể truy cập cơ sở dữ liệu của ...

Và lệnh và truy vấn trách nhiệm Tách ly (CQRS)

Phân chia trách nhiệm lệnh và truy vấn

Hầu hết các ứng dụng đọc dữ liệu thường xuyên hơn chúng ghi dữ liệu. Dựa trên tuyên bố đó, sẽ là một ý tưởng tốt để tạo ra một giải pháp trong đó bạn có thể dễ dàng thêm nhiều cơ sở dữ liệu để đọc, phải không? Vậy điều gì sẽ xảy ra nếu chúng ta thiết lập một cơ sở dữ liệu dành riêng cho việc đọc? Thậm chí còn tốt hơn; Điều gì xảy ra nếu chúng ta thiết kế cơ sở dữ liệu theo cách để đọc nhanh hơn từ nó? Nếu bạn thiết kế các ứng dụng của mình dựa trên các mẫu được mô tả trong kiến ​​trúc CQRS, bạn sẽ có một giải pháp có thể mở rộng và nhanh chóng trong việc đọc dữ liệu.