Làm thế nào để bạn xử lý các khái niệm được chia sẻ trong một kiến ​​trúc microservice?


39

Tôi đang nghiên cứu các mẫu kiến ​​trúc cho một ứng dụng tôi đang phát triển và một cách tiếp cận microservice có vẻ như đó sẽ là một lựa chọn tốt nhưng tôi không chắc chắn làm thế nào để xử lý các tương tác giữa các dịch vụ.

Ứng dụng chủ yếu liên quan đến người dùng, hồ sơ thuộc sở hữu của người dùng, ảnh và thẻ đại diện cho một đến nhiều hồ sơ trong ảnh. Có thể hình dung sẽ có các phương pháp để trả lại ảnh do người dùng tải lên, trả lại ảnh có chứa một hồ sơ được gắn thẻ nhất định, v.v.

Đây là bước đầu tiên của tôi trong việc thiết kế một kiến ​​trúc dựa trên microservice và tôi đến từ một mô hình miền nguyên khối lấy cảm hứng từ lịch sử. Trong thế giới đó, các bộ điều khiển sẽ gắn các đối tượng miền này lại với nhau nhưng tôi gặp khó khăn trong việc xoay quanh việc làm thế nào điều này sẽ hoạt động theo cách thức vi mô.

Câu trả lời:


34

Thông thường, các dịch vụ gọi các dịch vụ khác khi họ cần truy cập dữ liệu của họ. Mỗi phần dữ liệu phải thuộc về một dịch vụ cụ thể sẽ là điểm nhập duy nhất để truy cập dữ liệu này và sửa đổi nó. Một số dịch vụ sẽ đơn giản và thường tương ứng chặt chẽ với mô hình miền của bạn (ví dụ: dịch vụ xử lý người dùng) trong khi các dịch vụ khác sẽ ở cấp độ cao và sử dụng dữ liệu từ các dịch vụ khác (ví dụ: hiển thị danh sách ảnh cùng với thông tin về người dùng đã tải lên chúng ).

Trong trường hợp sử dụng của bạn, bạn nên bắt đầu từ bên ngoài và nghĩ về những hoạt động bạn muốn cung cấp cho người dùng của mình thông qua API (nếu đó là dịch vụ phụ trợ) hoặc những hoạt động nào sẽ có sẵn trong GUI nếu đó là ứng dụng web. Lưu ý rằng phần GUI thường là một ứng dụng thông thường có bộ điều khiển riêng: các hoạt động có thể được gọi thông qua REST (như trong AngularJS), nhưng các điểm cuối này chỉ được sử dụng cho ứng dụng GUI và không phải là dịch vụ thông thường.

Giả sử bạn muốn hiển thị ảnh cùng với thông tin về người tải lên. Bạn có thể có một dịch vụ người dùng trả về thông tin về người dùng được cung cấp ID người dùng và dịch vụ ảnh có thể liệt kê ảnh (ví dụ: bằng cách tìm kiếm theo một số tiêu chí). Danh sách ảnh sẽ chứa cho mỗi ảnh ID của người dùng đang tải lên. Bằng cách này, hai dịch vụ này không được ghép nối - dịch vụ ảnh chỉ biết về ID người dùng chứ không biết gì về chính dữ liệu người dùng. Ngoài hai dịch vụ này, bạn có thể tạo một dịch vụ thứ ba với một thao tác như "liệt kê ảnh với thông tin về người tải lên" sẽ gọi hai dịch vụ khác và kết hợp dữ liệu họ trả về. Ngoài ra, hoạt động này có thể được thực hiện bởi ứng dụng web của bạn thay vì một dịch vụ.


1
Điều này đã giúp tôi rất nhiều. Tôi đã bắt đầu bằng cách viết một vài trường hợp sử dụng UI sẽ thực hiện ngăn xếp và mọi thứ chủ yếu rơi vào vị trí.
anjunatl

1
Trong ví dụ cụ thể này, chúng ta phải làm như vậy. 10 cuộc gọi đến dịch vụ người dùng để lấy dữ liệu người dùng nếu chúng tôi có 10 ảnh trong danh sách của chúng tôi? Nó sẽ không thêm nhiều chi phí?
Ricardo Souza

1
@rcdmk Bạn có thể thêm điểm cuối REST lấy danh sách nhiều ID làm đầu vào và trả về nhiều ảnh làm đầu ra. Điều này thường được thực hiện trong thực tế vì lý do hiệu suất. Đôi khi, thiết kế API là một sự thỏa hiệp giữa độ tinh khiết và những cân nhắc thực tế.
Michał Kosmulski

@ MichałKosmulski Tôi cần bắt đầu thảo luận, nhưng thiết kế StackExchange không khuyến khích họ :) Điều tôi không thích về cách tiếp cận microservice trong ví dụ cụ thể này là truy vấn trực tiếp đến cơ sở dữ liệu cơ bản (nơi lưu trữ người dùng và hình ảnh) có thể hiệu quả hơn nhiều. Hãy tưởng tượng nếu các dịch vụ ngược dòng này phụ thuộc vào các dịch vụ ngược dòng khác, v.v. Truy vấn trực tiếp đến cửa hàng dữ liệu an toàn hơn nhiều. chỉ 5 xu của tôi - không có gì hơn. Một lần nữa tôi thực sự muốn có cuộc thảo luận hiệu quả về chủ đề này, nhưng StackExachange không phải là nơi tốt cho điều đó (bạn có thể giới thiệu các diễn đàn thảo luận microservice không?)
ajukraine

@ajukraine Tôi nghĩ rằng có những cuộc trò chuyện trên stackexchange có thể là một nơi tốt để thảo luận. Về hiệu suất: 1. Dịch vụ vi mô đi kèm với chi phí hiệu suất và 2. Dịch vụ vi mô tốt cho một số trường hợp nhưng không phải cho các tình huống khác. Đối với các phụ thuộc: trong các kiến ​​trúc microservice, bạn thường tạo các bản sao dữ liệu cục bộ và sử dụng tin nhắn không đồng bộ để giảm số lượng phụ thuộc. Đó là một sự thay đổi kiến ​​trúc thực sự, không chỉ tự động thay đổi từng mô-đun của một ứng dụng thành một ứng dụng riêng biệt.
Michał Kosmulski

4

Ứng dụng chủ yếu liên quan đến người dùng, hồ sơ thuộc sở hữu của người dùng, ảnh và thẻ đại diện cho một đến nhiều hồ sơ trong ảnh. Có thể hình dung sẽ có các phương pháp để trả lại ảnh do người dùng tải lên, trả lại ảnh có chứa một hồ sơ được gắn thẻ nhất định, v.v.

Vâng, dịch vụ hồ sơ không nên làm việc với đối tượng người dùng. Nó có thể chỉ biết ID của người dùng được yêu cầu trả lại dữ liệu, không còn nữa. Bằng cách này, bạn sẽ không yêu cầu tương tác giữa dịch vụ người dùng và dịch vụ hồ sơ.

Nếu điều đó không trả lời câu hỏi của bạn, bạn có thể vui lòng làm rõ nó bằng cách mô tả chính xác tình huống bạn đang giải quyết không?


Câu trả lời này và của Michal đã giúp tôi hiểu điều đó nhưng gợi ý của anh ấy đã giúp tôi vạch ra những dịch vụ tôi cần. Tôi bị mắc kẹt trong một suy nghĩ cần phải đại diện cho một đối tượng đầy đủ thay vì chỉ tham chiếu đến đối tượng (đối tượng người dùng so với ID người dùng). Rất cảm kích, cảm ơn!
anjunatl

@anjunatl Chào mừng bạn;)
Vladislav Rastrusny
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.