Truyền tệp / dữ liệu lớn trong Kiến trúc microservice

Công ty của tôi hiện đang làm việc để áp dụng một kiến ​​trúc microservice nhưng chúng tôi đang gặp phải một số cơn đau ngày càng tăng (sốc!) Trên đường đi. Một trong những điểm tranh chấp quan trọng mà chúng tôi đang phải đối mặt là làm thế nào để truyền đạt số lượng lớn dữ liệu giữa các dịch vụ khác nhau của chúng tôi.

Để có một chút nền tảng, chúng tôi có một kho lưu trữ tài liệu đóng vai trò là kho lưu trữ cho bất kỳ tài liệu nào chúng tôi có thể cần xử lý trên toàn công ty. Tương tác với cửa hàng nói trên được thực hiện thông qua một dịch vụ cung cấp cho khách hàng một ID duy nhất và một vị trí để truyền phát tài liệu. Vị trí của tài liệu sau đó có thể được truy cập thông qua tra cứu với ID được cung cấp.

Vấn đề là ở đây - Liệu có hợp lý khi tất cả các dịch vụ siêu nhỏ của chúng tôi chấp nhận ID duy nhất này như một phần của API của họ cho mục đích tương tác với tài liệu hay không? Đối với tôi điều này cảm thấy sai lầm - các dịch vụ không còn độc lập và phụ thuộc vào dịch vụ của cửa hàng tài liệu. Mặc dù tôi thừa nhận điều này có thể đơn giản hóa thiết kế API và thậm chí có thể có một số hiệu suất đạt được kết quả khớp nối nhiều hơn so với các lợi ích.

Có ai biết làm thế nào kỳ lân cầu vồng (Netflix, Amazon, Google, v.v.) xử lý các tệp / trao đổi dữ liệu lớn giữa các dịch vụ của họ không?

Có ai biết làm thế nào kỳ lân cầu vồng (Netflix, Amazon, Google, v.v.) xử lý các tệp / trao đổi dữ liệu lớn giữa các dịch vụ của họ không?

Thật không may, tôi không biết làm thế nào họ đối phó với các vấn đề như vậy.

Vấn đề là ở đây - Liệu có hợp lý khi tất cả các dịch vụ siêu nhỏ của chúng tôi chấp nhận ID duy nhất này như một phần của API của họ cho mục đích tương tác với tài liệu hay không?

Nó vi phạm Nguyên tắc Trách nhiệm duy nhất, vốn có trong kiến ​​trúc microservice của bạn. Một microservice - logic một, thể chất nhiều trường hợp đại diện cho một - Nên đối phó với một chủ đề .

Trong trường hợp lưu trữ tài liệu của bạn, bạn có một điểm, nơi tất cả các truy vấn cho tài liệu đi (tất nhiên bạn có thể chia đơn vị logic này thành nhiều kho lưu trữ tài liệu cho một số loại tài liệu).

• Nếu "ứng dụng" của bạn cần hoạt động trên một tài liệu, nó sẽ hỏi microservice tương ứng và xử lý (các) kết quả của nó.

• Nếu một dịch vụ khác cần một tài liệu thực tế hoặc các bộ phận của nó, nó phải yêu cầu dịch vụ tài liệu đó.

Một trong những điểm tranh chấp quan trọng mà chúng tôi đang phải đối mặt là làm thế nào để truyền đạt số lượng lớn dữ liệu giữa các dịch vụ khác nhau của chúng tôi.

Đây là một vấn đề kiến ​​trúc:

1. Giảm nhu cầu chuyển lượng lớn dữ liệu

   Lý tưởng nhất, mỗi dịch vụ có tất cả dữ liệu của nó và không cần chuyển để chỉ phục vụ các yêu cầu. Là một phần mở rộng của ý tưởng này - nếu bạn có nhu cầu chuyển dữ liệu, hãy nghĩ đến sự dư thừa (* theo cách tích cực_): Có ý nghĩa gì khi có dữ liệu dư thừa ở nhiều nơi (nơi cần thiết)? Hãy nghĩ về sự không nhất quán có thể có thể gây hại cho các quy trình của bạn. Không có chuyển nhanh hơn như thực tế không có .

2. Giảm kích thước của dữ liệu

   Hãy nghĩ về cách bạn có thể nén dữ liệu của mình: Bắt đầu với các thuật toán nén thực tế cho đến các cấu trúc dữ liệu thông minh . Càng ít đi qua dây, bạn càng nhanh.

Nếu ID được trả về bởi cửa hàng tài liệu của bạn là những cách để tài liệu tham khảo trên toàn hệ thống, sau đó nó làm cho tinh thần cho tất cả các dịch vụ phải chấp nhận rằng 'Document ID' trên API của họ khi nhu cầu dịch vụ để biết được tài liệu cần thiết để làm việc với.

Điều này không nhất thiết tạo ra sự kết hợp chặt chẽ hơn giữa các dịch vụ hơn mức cần thiết. Các dịch vụ cần truy cập tài liệu cần phải truy cập dịch vụ lưu trữ tài liệu và họ cần ID đó để thông báo cho cửa hàng biết tài liệu nào sẽ truy cập.
Các dịch vụ không truy cập trực tiếp vào tài liệu có thể cần phải chuyển ID tài liệu cùng, nhưng với các dịch vụ đó, đó chỉ là một chuỗi tùy ý không tạo ra sự phụ thuộc.

Cá nhân, tôi không muốn sử dụng một dịch vụ lưu trữ tài liệu và id tài liệu riêng biệt mà là một URL để truy cập các tài liệu (với xác thực tiêu đề phù hợp). Với cách tiếp cận này, bạn sẽ không cần các dịch vụ khác dựa vào dịch vụ tài liệu thay vì chỉ có thể sử dụng URL đầy đủ để truy cập tài liệu. Và cũng có ý nghĩa khi nói đến việc mở rộng quy mô, bạn cũng có thể sử dụng nhiều cửa hàng tài liệu khi lưu trữ phát triển và cung cấp URL.

Tuy nhiên, bạn có thể cần một dịch vụ để tải lên một tài liệu và để có được URL đó.

Có ai biết làm thế nào kỳ lân cầu vồng (Netflix, Amazon, Google, v.v.) xử lý các tệp / trao đổi dữ liệu lớn giữa các dịch vụ của họ không?

Kiểm tra thông số API Amazon S3 REST, dường như chúng trả về đối tượng đầy đủ theo byte. Có vẻ không có nhiều lựa chọn nếu bạn đang thiết kế một microservice. Liên kết định dạng phản hồi Amazon S3