Dịch vụ vi mô và sao chép dữ liệu


14

Tôi đang xây dựng một ứng dụng mới và đang đọc về kiến ​​trúc dịch vụ vi mô. Các kiến ​​trúc tự nó có rất nhiều ý nghĩa từ quan điểm phát triển, triển khai và quản lý vòng đời. Tuy nhiên, một vấn đề nảy sinh liên quan đến cách xử lý dữ liệu chủ.

Ví dụ: tôi có 2 ứng dụng - giả sử ứng dụng Bán hàng và ứng dụng Bán vé. Giả sử rằng cả hai ứng dụng này đều được xây dựng dưới dạng các dịch vụ vi mô riêng. Tuy nhiên, cả hai ứng dụng này, khi được triển khai (giả sử rằng chúng được triển khai riêng cho biết Bán hàng sử dụng MongoDB và Bán vé sử dụng MariaDB), sẽ cần có quyền truy cập vào cùng các trường hợp dữ liệu chính, ví dụ như Tài khoản, Sản phẩm. Điều này có nghĩa là sẽ có một ứng dụng chủ sở hữu cho một thực thể dữ liệu chính nhất định (ví dụ: đối với Tài khoản, đó có thể là ứng dụng Bán hàng) và một bên quan tâm (ví dụ: Ứng dụng bán vé sẽ cần có thông tin về Tài khoản).

Có nhiều cách để đạt được điều này: - Sao chép dữ liệu từ chủ sang bên quan tâm - Đọc đồng bộ từ bên quan tâm đến chủ (phụ thuộc đồng bộ hóa không được đề xuất bởi mô hình kiến ​​trúc dịch vụ vi mô) - Kho lưu trữ tập trung riêng

Ngoài ra, ngay cả trong Tài khoản, có thể có một phần cốt lõi chung cho cả Bán hàng và Bán vé (ví dụ: tên tài khoản, địa chỉ, v.v.). Tuy nhiên, một số khía cạnh của Tài khoản CHỈ có thể liên quan đến Bán hàng và những khía cạnh khác CHỈ liên quan đến Bán vé.

Bất kỳ suy nghĩ / thực tiễn tốt nhất / ý kiến ​​liên quan đến bất kỳ lựa chọn được đề cập ở trên?


Bạn không thể tạo Tài khoản và Sản phẩm dưới dạng dịch vụ vi mô sao? Hoàn toàn tách chúng ra khỏi một "thực thể dữ liệu chủ". Bán hàng sẽ chỉ biết về việc bán một loại thực thể nào đó, nhưng không cần biết liệu thực thể đó là Sản phẩm, Dịch vụ hay bất kỳ loại thực thể nào khác mà bạn có thể muốn thêm vào sau này.
Bleakgadfly

Vâng, điều đó sẽ có thể. Tuy nhiên, ở đây một lần nữa thách thức là dịch vụ 'Tài khoản' trung tâm sẽ phải được mô hình hóa theo kiểu siêu tập hợp (nghĩa là phải xem xét các thuộc tính cho Bán hàng, Đặt vé, v.v.). Điều này sẽ đi ngược lại mô hình SRP.
mithrandir

Câu trả lời:


12

Tôi là thành viên của một nhóm xây dựng thành công kiến ​​trúc microservice bằng cách sử dụng xe buýt dịch vụ.

Ban đầu, chúng tôi tin rằng microservice và kiến ​​trúc hướng sự kiện sẽ cho phép chúng tôi sửa cơ sở dữ liệu bóng dữ liệu được chia sẻ bên dưới.

Những gì chúng tôi đã học được là microservice và một kiến ​​trúc hướng sự kiện yêu cầu chúng tôi thoát khỏi cơ sở dữ liệu bóng dữ liệu được chia sẻ cơ bản.

Tôi tin rằng dữ liệu được chia sẻ là cực kỳ khó để làm tốt với microservice - đối với tôi nó cực kỳ khó. Tôi khuyên bạn không nên cho phép các dịch vụ xem dữ liệu của nhau. Nếu bạn không thể truy vấn nó, bạn không thể vô tình giới thiệu một phụ thuộc.

Nếu bạn làm chia sẻ dữ liệu, chắc chắn chỉ có một dịch vụ bao giờ có thể sở hữu một kỷ lục; đó là dịch vụ duy nhất ghi vào hồ sơ và bất kỳ người dùng nào khác có cùng dữ liệu nên có quyền truy cập chỉ đọc.

Thật không may, ngay cả số lượng chia sẻ được quản lý nhỏ này cũng giới thiệu sự kết hợp quan trọng giữa các dịch vụ của bạn. Điều gì xảy ra nếu một dịch vụ không muốn dữ liệu trong hình dạng đó? Có lẽ nó muốn một tập hợp. Bạn có nhận được dịch vụ "chủ sở hữu / ghi" của mình để ghi dữ liệu tổng hợp vì lợi ích của dịch vụ khác không? Tôi khuyên bạn không nên.

Điều gì xảy ra nếu chủ sở hữu muốn duy trì dữ liệu trong một hình dạng khác nhau? Sau đó, mọi dịch vụ đọc cần được cập nhật. Đó là một cơn ác mộng bảo trì.

Giải pháp tốt nhất chúng tôi có là sao chép và không chuẩn hóa dữ liệu của chúng tôi. Các dịch vụ vi mô duy trì các bản sao dữ liệu của riêng họ mà họ quan tâm.

Tin nhắn thường được xuất bản với đủ dữ liệu đi kèm để xử lý chúng.

Ví dụ: bạn có thể tưởng tượng rằng một dịch vụ gửi hàng qua bưu điện có thể cần theo dõi các thay đổi đối với địa chỉ khách hàng, trong trường hợp nó cần đăng một cái gì đó. Nhưng nếu thông báo "mục sẵn sàng gửi hàng" của bạn bao gồm địa chỉ đích là một phần của dữ liệu tin nhắn, thì dịch vụ gửi hàng không còn cần phải theo dõi các địa chỉ thay đổi liên quan đến khách hàng nữa; chỉ các địa chỉ tại thời điểm liên quan đến các mặt hàng khi chúng được gửi đi.

Tôi không thể đề xuất cách kiến ​​trúc sư giải pháp với dữ liệu được đồng bộ hóa. Các giải pháp dữ liệu của chúng tôi được xây dựng xung quanh ý tưởng về "tính nhất quán cuối cùng".

Vì vậy, khi khách hàng cập nhật địa chỉ của họ, dịch vụ Địa chỉ sẽ xử lý lệnh ban đầu từ UI. Khi dữ liệu của nó là chính xác, nó sẽ xuất bản một sự kiện để thông báo cho tất cả các dịch vụ quan tâm khác "Cập nhật địa chỉ khách hàng" - với địa chỉ đầy đủ được đính kèm dưới dạng dữ liệu. Những dịch vụ đó sẽ cập nhật các cửa hàng dữ liệu của riêng họ với các phần dữ liệu mà họ quan tâm.

Ý tưởng là bất cứ khi nào một dịch vụ phải thực hiện một hành động quan trọng, thì nó nên có một bản sao thông tin cập nhật - đủ để hành động chính xác, được theo dõi độc lập hoặc là một phần của thông điệp mà nó đang phản hồi.


Bạn có sử dụng giải pháp xây dựng riêng hoặc cái gì khác?
FrEaKmAn

2
Chúng tôi đã sử dụng NServiceBus - nơi giới thiệu các ý tưởng / cấu trúc để đối phó với các quy trình công việc xảy ra trong mỗi dịch vụ. Sự kiên trì có thể xảy ra thông qua RavenDB. Bạn có thể thấy rằng bạn không muốn chọn một công nghệ quá sớm - hoàn cảnh của bạn có thể khác và chúng tôi gặp vấn đề về mọc răng. Martin Fowler có một số lời khuyên thực sự tuyệt vời cho những người bắt đầu với microservice: martinfowler.com/articles/microservice.html - "... bạn không nên bắt đầu với kiến ​​trúc microservice. Thay vào đó hãy bắt đầu với một khối nguyên khối, giữ nguyên mô-đun và tách nó thành microservice một khi nguyên khối trở thành một vấn đề. "
cầu toàn

Tóm lại " Giải pháp tốt nhất chúng tôi có là sao chép và không chuẩn hóa dữ liệu đáng kể. Các dịch vụ vi mô duy trì các bản sao dữ liệu mà họ quan tâm. "
deFreitas

2

Lưu trữ dữ liệu được chia sẻ sẽ đi ngược lại kiến ​​trúc microservice. Vấn đề là nếu có Tài khoản, cần có một dịch vụ để xử lý chúng và không có cách nào khác để tương tác với các Tài khoản này ngoài việc triệt để dịch vụ. Các dịch vụ siêu nhỏ của bạn sẽ không độc lập nếu chúng chia sẻ lưu trữ chung và mọi thay đổi đối với cơ chế lưu trữ, xác thực hoặc các ràng buộc khác sẽ cần được thực hiện trong cả hai dịch vụ. Trong thực tế, điều này không bao giờ xảy ra và sớm dẫn đến cả hai ứng dụng bị ngăn chặn khỏi mọi thay đổi nghiêm trọng.

Vì vậy, sử dụng một dịch vụ như là cách duy nhất để truy cập dữ liệu của bạn, ví dụ: Tài khoản. Có thể xảy ra việc triển khai một tính năng trong một số dịch vụ khác yêu cầu thay đổi dịch vụ Tài khoản và điều đó ổn. Chỉ cần nhớ rằng logic cụ thể cho bất kỳ dịch vụ nào sẽ có trong dịch vụ đó và càng ít nội dung cụ thể càng tốt sẽ đi vào microservice Account.


0

sẽ cần có quyền truy cập vào cùng các trường hợp dữ liệu chủ, ví dụ: Tài khoản, Sản phẩm

Không giống nhau. Mỗi dịch vụ vi mô phải thực hiện ánh xạ riêng cho Tài khoản, Sản phẩm, v.v. Chúng tôi giả định rằng mỗi dịch vụ vi mô sẽ có một cách khác nhau để làm việc với các thực thể.

Trong Thiết kế hướng tên miền, điều này là phổ biến, trong đó mỗi bối cảnh giới hạn (trong cùng một ứng dụng!) Có thể ánh xạ cùng một thực thể theo một cách khác nhau.

Nếu bạn cần thêm thông tin, tôi giới thiệu cuốn sách Building microservice: Thiết kế hệ thống hạt mịn


0

Bạn đã xem xét khái niệm hồ sơ bộ xương dựa trên một bộ tổng thể?

Ví dụ: một microservice xử lý tài khoản và các sản phẩm khác xử lý. Một phần ba có thể giữ hồ sơ từ cả hai cho mục đích cụ thể tên miền của nó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.