Kiến trúc microservice chia sẻ mô hình miền


12

Giả sử rằng chúng ta có ứng dụng Spring Boot sử dụng kiến ​​trúc microservice. Mỗi dịch vụ có các mô hình miền riêng, nhưng mỗi dịch vụ phải tham chiếu một đối tượng miền Người dùng. Điều gì sẽ là cách tiếp cận tốt nhất về cách giải quyết vấn đề này? Sẽ tốt hơn cho mỗi dịch vụ chỉ cần có userId và sau đó, khi cần, hãy hỏi dịch vụ người dùng để biết chi tiết người dùng, hoặc sẽ tốt hơn nếu có một thư viện miền dùng chung cho tất cả các dịch vụ?


1
Luôn luôn tốt hơn để có một nguồn sự thật , bất cứ khi nào có thể.
Robert Harvey

@RobertHarvey Điều đó sẽ ảnh hưởng đến sự tồn tại của polyglot như thế nào? Việc sử dụng một thư viện chia sẻ cho tất cả các đối tượng miền vẫn có nghĩa là mỗi microservice có thể có cơ sở dữ liệu riêng?
dùng1176999

Chưa bao giờ nghe cụm từ đó trước đây, nhưng nhìn vào định nghĩa của nó, tôi nói rằng nó hoàn toàn không ảnh hưởng đến sự tồn tại của polyglot, ngoại trừ công nghệ mà bạn chọn cho kho lưu trữ dữ liệu mà bạn dự định đưa người dùng vào.
Robert Harvey

Câu trả lời:


12

Nếu bạn đã sử dụng microservice để hưởng lợi từ khả năng mở rộng, khớp nối lỏng lẻo và sửa đổi độc lập dễ dàng của từng dịch vụ, bạn nên tuân thủ nó ở mức tối đa có thể.

Kiến trúc tổng thể

Tôi nghĩ rằng cách tiếp cận tốt nhất sẽ là:

  • có một dịch vụ siêu nhỏ để quản lý thông tin người dùng nói chung;
  • giữ thông tin người dùng cụ thể của microservice (ví dụ: hồ sơ, ủy quyền, tùy chọn) trong mỗi microservice (sử dụng giới thiệu của id chung)

Đọc thêm:

  • Bài viết này mô tả rất tốt loại kiến ​​trúc và lý do này, với trường hợp ủy quyền cụ thể.
  • Bài viết này mô tả các thách thức và giải pháp để quản lý danh tính người dùng, để tránh tất cả các dịch vụ truy cập vào cùng một kho lưu trữ.
  • Bài viết này mô tả ho sử dụng JWT để chuyển danh tính của người dùng giữa các dịch vụ (lưu ý rằng một số thông tin cơ bản có thể được cung cấp trong mã thông báo id, để tránh phải truy vấn dịch vụ người dùng thêm một lần nữa sau khi đăng nhập, ít nhất là rất cơ bản thông tin).

Chia sẽ mã

Bây giờ nếu bạn đồng ý với giải pháp trên, chúng tôi có microservice người dùng (mô hình miền đóng gói cho người dùng) và tất cả các dịch vụ khác là người tiêu dùng của cùng một dịch vụ. Câu hỏi là sau đó để biết nếu bạn muốn:

  • hoặc mỗi dịch vụ siêu nhỏ để phát minh lại mã người tiêu dùng, tuân theo tín điều tách biệt mạnh mẽ để cho phép các chu kỳ phát hành linh hoạt và khác biệt,
  • hoặc để chia sẻ mã người tiêu dùng như một phần của thư viện, xem xét rằng thông tin cơ bản này là một phần mở rộng của mẫu cơ sở hạ tầng "khung gầm" .

Tôi sẽ không có một vị trí cắt giảm rõ ràng về điều đó, vì có những cuộc chiến ý kiến ​​về chủ đề chia sẻ mã này và tôi không nghĩ rằng tôi đang ở một vị trí để có một vị trí khách quan. Đây là một số đọc thêm:

  • Bài viết này cho rằng không có giải pháp tốt nhất và tất cả phụ thuộc vào mục tiêu của bạn
  • Vị trí bài viết này là chia sẻ mã chỉ xấu nếu nó tạo ra sự kết hợp mạnh mẽ và chia sẻ mã có thể mang lại một số sức mạnh tổng hợp
  • Bài viết này (của những người đã triển khai microservice ở quy mô) nhấn mạnh vào sự cần thiết phải có các bản dựng riêng biệt và các vấn đề ngừng hoạt động tiềm năng của mã cũ. Có một thư viện dùng chung để tiêu thụ với quản lý phiên bản vững chắc không ngăn cản những thực tiễn tốt này.

Ý kiến ​​riêng của tôi về điều đó là bạn KHÔNG NÊN CHIA SẺ mã giữa nhà cung cấp người dùng và người tiêu dùng, để tránh sự liên kết chặt chẽ. Tuy nhiên, bạn CÓ THỂ CHIA SẺ mã tiêu dùng người dùng giữa người tiêu dùng nếu bạn có quản lý phiên bản mạnh. Cách tiếp cận này sẽ có một số lợi thế:

  • Các dịch vụ siêu nhỏ tiêu thụ người dùng khác nhau có thể được xây dựng với các phiên bản khác nhau của mã tiêu dùng người dùng chung (miễn là các phiên bản tương thích với nhà cung cấp người dùng độc lập). Cùng một sự linh hoạt mà phát minh lại bánh xe nhưng năng suất cao hơn.
  • Bạn có thể thay đổi dịch vụ nhà cung cấp người dùng một cách độc lập mà không ảnh hưởng đến người tiêu dùng.
  • Nếu một lỗi được tìm thấy ở phía tiêu dùng, bạn có thể sửa nó một lần và triển khai tất cả người tiêu dùng là phù hợp nhất (nhờ quản lý phiên bản). Điều này thậm chí có thể dẫn đến chất lượng dịch vụ cao hơn.
  • Nếu vì một lý do nào đó, bạn bắt buộc phải cập nhật API nhà cung cấp người dùng, bạn có thể triển khai mức tiêu thụ người dùng được cập nhật nhiều hơn quiclkly. Nếu bạn giữ dịch vụ nhà cung cấp cũ và mới hoạt động trong quá trình chuyển đổi, khả năng chia sẻ này có thể cho phép ngừng hoạt động nhanh hơn phiên bản cũ của nhà cung cấp người tiêu dùng.

1

Tôi sẽ tránh một thư viện chia sẻ nếu có thể. Hãy tự hỏi những tính chất của người dùng mà mỗi dịch vụ cần? Thường có một miền cốt lõi, nơi hầu hết các hành vi xung quanh người dùng sẽ sống, với các miền hỗ trợ thường chỉ cần một userId.

Nếu dịch vụ của bạn cần một số chi tiết khác liên quan đến người dùng, hãy xem một số đề xuất ở đây về cách xử lý các tình huống như vậy

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.