Dịch vụ vi mô không trùng lặp dữ liệu

Tôi thấy khó tránh khỏi trùng lặp dữ liệu hoặc cơ sở dữ liệu dùng chung cho ngay cả thiết kế microservice đơn giản nhất, điều này khiến tôi nghĩ rằng tôi đang thiếu một cái gì đó. Đây là một ví dụ cơ bản về vấn đề tôi gặp phải. Giả sử ai đó đang sử dụng một ứng dụng web để quản lý kho, họ sẽ cần hai dịch vụ; một cho hàng tồn kho quản lý các mặt hàng và số lượng trong kho và dịch vụ người dùng sẽ quản lý dữ liệu người dùng. Nếu chúng tôi muốn kiểm toán ai đã lưu trữ cơ sở dữ liệu, chúng tôi có thể thêm ID người dùng vào cơ sở dữ liệu cho dịch vụ kiểm kê dưới dạng lưu trữ cuối cùng theo giá trị.

Sử dụng ứng dụng, chúng tôi có thể muốn xem tất cả các mặt hàng sắp hết và một danh sách những người đã dự trữ chúng lần trước để chúng tôi có thể yêu cầu họ bổ sung lại. Sử dụng kiến ​​trúc được mô tả ở trên, một yêu cầu sẽ được gửi đến dịch vụ kiểm kê để lấy chi tiết vật phẩm của tất cả các mặt hàng có số lượng ít hơn 5. Điều này sẽ trả về một danh sách bao gồm ID người dùng. Sau đó, một yêu cầu riêng sẽ được gửi đến dịch vụ người dùng để lấy tên người dùng và chi tiết liên hệ cho danh sách ID người dùng thu được từ dịch vụ kiểm kê.

Điều này có vẻ hết sức kém hiệu quả và không cần nhiều dịch vụ nữa trước khi chúng tôi thực hiện nhiều yêu cầu đối với các API dịch vụ khác nhau, lần lượt thực hiện nhiều truy vấn cơ sở dữ liệu. Một cách khác là sao chép chi tiết người dùng trong dữ liệu hàng tồn kho. Khi người dùng thay đổi chi tiết liên hệ của họ, chúng tôi sẽ cần sao chép thay đổi thông qua tất cả các dịch vụ khác. Nhưng điều này dường như không phù hợp với ý tưởng bối cảnh bị ràng buộc của microservice. Chúng tôi cũng có thể sử dụng một cơ sở dữ liệu duy nhất và chia sẻ điều này giữa các dịch vụ khác nhau và có tất cả các vấn đề của cơ sở dữ liệu tích hợp .

Cách chính xác / tốt nhất để thực hiện điều này là gì?

Tôi hoàn toàn bỏ lỡ nơi bạn được yêu cầu sao chép.

Một nguyên tắc trung tâm của các dịch vụ vi mô là để dịch vụ trở thành cơ quan duy nhất. Điều đó có nghĩa là hàng tồn kho và quản lý người dùng có thể hoàn toàn tách biệt. Tôi sẽ thiết kế quản lý người dùng để nó thậm chí không biết hệ thống hàng tồn kho.

Nhưng tôi sẽ thiết kế hệ thống kiểm kê để nó không bao giờ lưu trữ bất cứ thứ gì về người dùng ngoài ID người dùng. Điều đó quan tâm đến vấn đề tuyên truyền thay đổi thông tin người dùng của bạn.

Đối với những thứ cần cả thông tin hàng tồn kho và thông tin người dùng như nhật ký, kiểm toán và bản in, chúng không được cập nhật khi thay đổi thông tin. Họ là một kỷ lục của những gì đã được. Một lần nữa, bạn không tuyên truyền thay đổi.

Vì vậy, trong mọi trường hợp, khi bạn muốn thông tin người dùng mới nhất, bạn hãy hỏi dịch vụ thông tin người dùng.

Tôi thấy khó tránh khỏi trùng lặp dữ liệu ....

Theo ebook của Microsoft về kiến ​​trúc microservice , không có gì sai khi sao chép dữ liệu. Về cơ bản, sao chép dữ liệu làm tăng sự tách rời giữa các dịch vụ và do đó củng cố vai trò của chúng như một cơ quan duy nhất. Một đoạn có liên quan:

Và cuối cùng (và đây là nơi phát sinh hầu hết các vấn đề khi xây dựng microservice), nếu microservice ban đầu của bạn cần dữ liệu ban đầu được sở hữu bởi các dịch vụ siêu nhỏ khác, đừng dựa vào việc đưa ra yêu cầu đồng bộ cho dữ liệu đó. Thay vào đó, sao chép hoặc truyền dữ liệu đó (chỉ các thuộc tính bạn cần) vào cơ sở dữ liệu của dịch vụ ban đầu bằng cách sử dụng tính nhất quán cuối cùng (thường bằng cách sử dụng các sự kiện tích hợp ...

một yêu cầu sẽ được gửi đến dịch vụ kiểm kê để lấy chi tiết vật phẩm của tất cả các mặt hàng có số lượng ít hơn 5. Điều này sẽ trả về một danh sách bao gồm ID người dùng. Sau đó, một yêu cầu riêng sẽ được gửi đến dịch vụ người dùng để lấy tên người dùng và chi tiết liên hệ cho danh sách ID người dùng thu được từ dịch vụ kiểm kê.

Thật vậy, vâng.

Được cấp, trong một khối nguyên khối, bạn có thể có một mô hình Hàng tồn kho mà bạn truy vấn cho các mục có liên quan, đưa dữ liệu đó vào Mô hình người dùng và nhận cùng một dữ liệu.

Hoặc bạn có thể đưa nó đi xa hơn, nếu bạn có chúng trong cùng một cơ sở dữ liệu quan hệ và viết SQL và cơ sở dữ liệu sẽ lấy bảng kiểm kê và bảng người dùng, nó thực hiện một số phép thuật và bạn sẽ có được dữ liệu bạn đang theo dõi.

Bất kể bạn làm điều đó như thế nào, ở đâu đó sẽ có mã về cơ bản tìm nạp danh sách id người dùng từ hệ thống kiểm kê, đưa chúng vào hệ thống người dùng và biên dịch danh sách dữ liệu.

Câu hỏi bạn cần trả lời là về hiệu suất và bảo trì và các phẩm chất "mềm" khác.

Lợi ích chính của microservice là nhân rộng. Nếu bạn có mười nghìn người dùng trên một máy và hơi chậm chạp, bạn có thể thêm một máy khác và hệ thống trở nên nhanh gấp đôi. Thêm tám lần nữa và nó nhanh gấp mười lần. (Tỷ lệ tuyến tính có thể lạc quan, nhưng đó là lý tưởng và không phải là không hợp lý để hy vọng.)

Và đây là mỗi dịch vụ . Nếu hệ thống kiểm kê là nút cổ chai, nó được sử dụng cho nhiều hơn các báo cáo về người dùng, bạn có thể thêm nhiều máy hơn vào dịch vụ đó . Các máy cũng có thể được chuyên dụng; dịch vụ này cần rất nhiều bộ nhớ, dịch vụ đó thực hiện các phép tính nặng và cần nhiều cpu hơn.

Nếu bạn không cần mở rộng quy mô, có một lợi ích khác của microservice: chúng là mô-đun . Tất nhiên, các ứng dụng nguyên khối cũng có thể là mô-đun và bạn có cơ sở dữ liệu được chuẩn hóa và ... nhưng trên thực tế, các bức tường giữa các mô-đun giống như các bức tường kính trong trường hợp tốt nhất và trong các trường hợp xấu nhất. Microservice được phân tách bằng thép rắn.

Nếu hệ thống người dùng của bạn thực sự bắt lửa, điều đó sẽ không ảnh hưởng đến hệ thống hàng tồn kho của bạn một chút. Bạn sẽ không thể in các báo cáo đẹp về người đã dự trữ những gì, nhưng khách hàng sẽ có thể đặt hàng an toàn với kiến ​​thức rằng các mặt hàng được lưu trữ ở đó.

Và bạn không sao chép dữ liệu trong microservice , bất kỳ nhiều hơn bạn làm trong cơ sở dữ liệu quan hệ (*). Trong cơ sở dữ liệu quan hệ, bạn có thể thực hiện tham gia và tương đương là hợp nhất các danh sách theo mã như được mô tả.

Bạn cũng có thể thêm một chế độ xem , tương đương là thêm một dịch vụ mới hợp nhất cho bạn; điều đó sẽ dẫn đến ba yêu cầu; một đến dịch vụ mới và sau đó dịch vụ đó thực hiện hai dịch vụ ban đầu. Cơ sở dữ liệu quan hệ có những thứ ưa thích giúp tối ưu hóa các khung nhìn, phải được thực hiện ở cấp độ dịch vụ. Bạn không nhận được nó "miễn phí".

Bộ nhớ đệm khác với sao chép dữ liệu ở chỗ nếu hai giá trị không khớp bạn biết cái nào sai. Nó thường được sử dụng trong các dịch vụ siêu nhỏ để mang lại sự sẵn có với chi phí nhất quán (định lý CAP). Vì cơ sở dữ liệu quan hệ hoàn toàn có sẵn hàng thịt trên bàn thờ về tính nhất quán, nó ít phổ biến hơn trong chúng. Tôi muốn nói rằng không có gì vốn có về microservice giúp việc lưu trữ bộ đệm dễ dàng hơn, nhưng trong thực tế, bộ nhớ đệm là mối quan tâm chính và điều đó làm cho bộ nhớ đệm dễ dàng hơn trong microservice .

(*) Nếu việc sao chép dữ liệu trong một nhóm dịch vụ siêu nhỏ thì có lẽ sẽ có ý nghĩa trong cơ sở dữ liệu quan hệ tương đương.