Các hiệp hội nhiều-nhiều trong microservice

Tôi hiện có hai dịch vụ siêu nhỏ. Chúng tôi sẽ gọi cho họ Avà B.

Cơ sở dữ liệu trong microservice Acó bảng sau:

A
|-- users

Cơ sở dữ liệu trong microservice Bcó bảng sau:

B
|-- trackers

Các yêu cầu nêu rõ usersvà trackerscó mối quan hệ nhiều-nhiều.

Tôi không chắc chắn làm thế nào để xử lý đúng cách trong kiến ​​trúc microservice.

Tôi có thể thấy điều này hoạt động theo một trong ba cách:

1. Một user_trackersbảng được thêm vào microservice A. Điều này hoạt động tương tự như một bảng tham gia có chứa "khóa ngoại" đến usersvà trackers.
2. Một ownersbảng được thêm vào microservice B. Bảng này hoạt động tương tự như một bảng tham gia đa hình. Điều này sẽ cho phép bất kỳ dịch vụ nào tạo liên kết với trình theo dõi. Điều này có thể trông giống như thế này: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. Giữ hồ sơ cho usersvà trackerstrong mỗi microservice. Giữ chúng đồng bộ với một số loại hệ thống pubsub.

Ban đầu tôi sẽ chọn tùy chọn 2 vì tôi thích nó bảo toàn ranh giới giao dịch. Tôi có thể tạo một trình theo dõi và liên kết nó với một cái gì đó nguyên tử. Tuy nhiên, nó có vẻ ngoài phạm vi cho microservice B. Tại sao microservice nên Bchăm sóc mà microservice Amuốn tạo ra một hiệp hội?

Tôi cảm thấy có lẽ có một mô hình tốt ở đây mà tôi không biết. Có bất kỳ lựa chọn tôi đặt ra có ý nghĩa? Có một lựa chọn khác có thể có ý nghĩa hơn?

Trước hết, tôi sẽ bắt đầu với mô tả tên miền. Bạn đã không đề cập đến những gì nó nói về (tôi có thể đoán, nhưng nó chỉ là một phỏng đoán). Sau đó, tôi sẽ cố gắng phân tách nó bằng cách sử dụng phân tích chuỗi giá trị hoặc ánh xạ khả năng kinh doanh . Và chỉ sau đó tôi sẽ nghĩ về việc thực hiện.

Xem xét vấn đề của bạn, điều đầu tiên tôi nghĩ đến là bạn đã xác định sai ranh giới dịch vụ của mình, đơn giản vì họ cần dữ liệu của nhau. Bạn không muốn kết thúc với nguyên khối phân tán , phải không?

Điều thứ hai là bạn có thể chưa làm việc thông qua tên miền của mình đủ tốt. Khái niệm nào được biểu diễn với usersbảng? Có phải là registered user, với tất cả các thông tin và hành vi cần thiết để đăng ký? Bạn có chắc chắn đó là khái niệm phù hợp để giao tiếp với trackers(dù đó là gì)? Vì vậy, nếu tôi hiểu đúng, tùy chọn 2 của bạn chính xác là về điều đó: giới thiệu ownerkhái niệm gần với miền của bạn hơn nhiều. Nếu nó thực sự là như vậy, tôi cũng cho tùy chọn 2.

Tuy nhiên, dường như nằm ngoài phạm vi của microservice B. Tại sao microservice B quan tâm rằng microservice A muốn tạo liên kết?

Đó là tất cả về ranh giới. Tôi đoán bạn muốn hình thành các dịch vụ siêu nhỏ xung quanh các thực thể. Đó là nơi mà SOA thất bại với kiến trúc dịch vụ lớp . Cách tiếp cận tốt hơn là tạo ra các dịch vụ đại diện cho một số chức năng kinh doanh, để chúng gói gọn cả dữ liệu và hành vi. Từ quan điểm thực tế hơn, đó là về việc tạo ra các dịch vụ xung quanh quy trình kinh doanh hoặc trường hợp sử dụng. Ví dụ: bạn có thể có một dịch vụ để đăng ký người dùng. Nó chứa dữ liệu và hành vi của người dùng cần thiết để đăng ký người dùng. Do đó, khái niệm về userđược hình thành một cách tự nhiên và nó chỉ thuộc về dịch vụ A. Và điều này đưa tôi đến điểm tiếp theo: cách nghĩ khác về dịch vụ là bối cảnh bị ràng buộc . Đó là một thực tiễn tốt để sắp xếp các dịch vụ và bối cảnh bị ràng buộc.

Khi người dùng được đăng ký, UserCreatedsự kiện có thể được phát ra. Dịch vụ thứ hai của bạn tôi đoán là quan tâm đến nó. Vì vậy, khi nhận được nó, một thực thể hoàn toàn khác có thể được tạo ra, giả sử, Ownerthực thể (bất kể đó là gì). Tôi khá chắc chắn rằng có rất nhiều sự hợp tác thú vị giữa nó và trackerthực thể - giữ chúng trong một dịch vụ duy nhất.

Hãy cực kỳ thận trọng với tùy chọn 3. Nếu bạn sao chép dữ liệu, chức năng sẽ tuân theo. Nó dẫn đến khớp nối chặt chẽ. Và không bao gồm thuật ngữ CQRS , đây không phải là về đồng bộ hóa dữ liệu giữa các dịch vụ thông qua các sự kiện.

Câu trả lời của Zapadlo có rất nhiều thông tin và lý luận tốt trong đó. Tôi sẽ thêm một lời khuyên thực tế ở đây có thể giúp bạn giải quyết các vấn đề của mình dễ dàng hơn và lời khuyên trong câu trả lời đó.

Cách bạn đóng khung câu hỏi thiết kế của bạn là xung quanh các cấu trúc cơ sở dữ liệu và làm thế nào để phù hợp với yêu cầu mới cho các cấu trúc của bạn vào đó. Điều này ngụ ý rằng bạn đang xây dựng thiết kế dịch vụ từ mô hình dữ liệu của bạn. Ví dụ: những gì tôi không thấy là mối quan hệ giữa người dùng và trình theo dõi sẽ được truy cập hoặc sử dụng như thế nào.

Trong thiết kế dịch vụ, cấu trúc của giao diện là điều quan trọng nhất về thiết kế. Trong thực tế, việc thực hiện gần như không liên quan so với trường hợp của microservice. Lý do là một khi bạn đặt dịch vụ của mình vào vị trí, tất cả các phụ thuộc vào dịch vụ của bạn sẽ tồn tại trên giao diện một mình. Nếu bạn làm đúng, bạn sẽ có thể viết lại hoàn toàn việc thực hiện mà không cần bất kỳ người tiêu dùng nào. Và đó là lợi ích chính của tự chủ. Không ai quan tâm làm thế nào bạn xây dựng nó. Họ chỉ cần nó hoạt động theo cách bạn đã truyền đạt.

Trước khi bất cứ ai có thể xác định giao diện này trong cơ sở dữ liệu hoặc nơi bạn muốn, bạn thực sự cần phải giải thích thông tin này sẽ được sử dụng như thế nào. Đây có phải là thứ gì đó sẽ được phơi bày thông qua một dịch vụ hay nó là một loại dữ liệu bạn muốn xáo trộn để phân tích?

Bên cạnh đó, tôi sẽ tránh được sự phụ thuộc hai chiều với hầu hết các chi phí. Nếu bạn có sự phụ thuộc, bạn thực sự chỉ muốn một bên biết về bên kia. Một khi các phụ thuộc ở cả hai hướng, chúng sẽ trở thành một đơn vị nguyên tử.

Rất nhiều trong số đó đi xuống tên miền chính nó. Nếu người dùng không có trình theo dõi không có ý nghĩa thì dịch vụ người dùng cần biết về trình theo dõi. Nếu một trình theo dõi phải có người dùng thì trình theo dõi cần biết về người dùng. Nếu một cái gì đó như có một trình theo dõi có nhiều chủ sở hữu hoặc có thể chuyển một trình theo dõi từ người dùng này sang người dùng khác thì có lẽ thông tin này thuộc về một dịch vụ khác.

Câu hỏi: Tại sao dữ liệu của bạn được phân tách dọc theo Dữ liệu?

Tôi có xu hướng đi với tùy chọn 3: các dịch vụ hoàn toàn riêng biệt và có thể trả lời các câu hỏi tương ứng mà họ có thể cần trả lời. Hơn nữa, họ kiên cường hơn rất nhiều. Nhưng hãy cẩn thận, các dịch vụ của bạn có thể không đồng bộ hóa nếu chúng bỏ lỡ các sự kiện, nhưng điều đó có thể được giải quyết thông qua tính nhất quán cuối cùng.

Ngoài ra, bạn có thể xem xét hợp nhất cả hai dịch vụ - nếu cả hai không thể trả lời mà không biết về nhau, tôi sẽ chỉ hợp nhất chúng vì chúng có thể là một phần của một tên miền.