Không có giải pháp rõ ràng bởi vì điều này phụ thuộc hoàn toàn vào bối cảnh của bạn - đặc biệt, dọc theo kích thước mà hệ thống của bạn có nghĩa vụ phải mở rộng và vấn đề thực tế của bạn là gì. Là cơ sở dữ liệu thực sự tắc nghẽn của bạn?
Câu trả lời này (không may là khá dài) sẽ đọc một chút giống như micros microservice là xấu, nguyên khối cho cuộc sống!, Nhưng đó không phải là ý định của tôi. Quan điểm của tôi là microservice và cơ sở dữ liệu phân tán có thể giải quyết các vấn đề khác nhau, nhưng không phải không có một số vấn đề của riêng họ. Để đưa ra lập luận mạnh mẽ cho kiến trúc của bạn, bạn phải chỉ ra rằng những vấn đề này không được áp dụng, có thể được giảm thiểu và kiến trúc này là lựa chọn tốt nhất cho nhu cầu kinh doanh của bạn.
Dữ liệu phân tán là khó khăn.
Tính linh hoạt tương tự cho phép mở rộng quy mô tốt hơn là mặt trái của các đảm bảo yếu hơn. Đáng chú ý, các hệ thống phân tán khó hơn nhiều để lý do.
Cập nhật nguyên tử, giao dịch, tính nhất quán / tính toàn vẹn tham chiếu và độ bền là vô cùng quý giá và không nên từ bỏ một cách vội vàng. Có rất ít điểm trong việc có dữ liệu nếu nó không đầy đủ, lỗi thời hoặc hoàn toàn sai. Khi bạn có ACID như một yêu cầu nghiệp vụ nhưng đang sử dụng công nghệ cơ sở dữ liệu không thể cung cấp nó ngoài hộp (ví dụ: nhiều cơ sở dữ liệu NoQuery hoặc kiến trúc DB-per-microservice), thì ứng dụng của bạn phải lấp đầy khoảng trống và cung cấp các đảm bảo đó.
Điều này không phải là không thể làm được, nhưng khó khăn để có được quyền. Rất khôn lanh. Đặc biệt là trong một thiết lập phân tán, nơi có nhiều người viết cho mỗi cơ sở dữ liệu. Khó khăn này dẫn đến khả năng có nhiều lỗi, có thể bao gồm dữ liệu bị mất, dữ liệu không nhất quán, v.v.
Ví dụ, hãy xem xét việc đọc các phân tích của Jepsen về các hệ thống cơ sở dữ liệu phân tán nổi tiếng , có lẽ bắt đầu bằng việc phân tích Cassandra . Tôi không hiểu một nửa phân tích đó, nhưng TL; DR là các hệ thống phân tán rất khó khăn đến nỗi ngay cả các dự án dẫn đầu ngành đôi khi cũng hiểu sai, theo những cách có vẻ rõ ràng trong nhận thức muộn màng.
Hệ thống phân tán cũng ngụ ý một nỗ lực phát triển lớn hơn. Ở một mức độ nhất định, có sự đánh đổi trực tiếp giữa chi phí phát triển hoặc giảm tiền cho phần cứng mạnh hơn.
Ví dụ: tài liệu tham khảo lơ lửng
Trong thực tế, bạn không nên nhìn vào khoa học máy tính mà nhìn vào các yêu cầu kinh doanh của bạn để xem liệu ACID có thể được thư giãn hay không. Ví dụ, nhiều mối quan hệ khóa ngoại có thể không quan trọng như vẻ ngoài của chúng. Xem xét một sản phẩm - loại n: m mối quan hệ. Trong RDBMS, chúng tôi có thể sử dụng ràng buộc khóa ngoài để chỉ các sản phẩm hiện có và các danh mục hiện có có thể là một phần của mối quan hệ đó. Điều gì xảy ra nếu chúng tôi giới thiệu các dịch vụ sản phẩm và danh mục riêng biệt và một sản phẩm hoặc danh mục bị xóa?
Trong trường hợp này, đó có thể không phải là một vấn đề lớn và chúng tôi có thể viết ứng dụng của mình để nó lọc ra bất kỳ sản phẩm hoặc danh mục nào không còn tồn tại. Nhưng có sự đánh đổi!
Lưu ý rằng điều này có thể yêu cầu cấp độ ứng dụng JOINtrên nhiều cơ sở dữ liệu / microservice, chỉ đơn thuần là di chuyển xử lý từ máy chủ cơ sở dữ liệu sang ứng dụng của bạn. Điều này làm tăng tổng tải và phải di chuyển thêm dữ liệu qua mạng.
Điều này có thể gây rối với phân trang. Ví dụ: bạn yêu cầu 25 sản phẩm tiếp theo từ một danh mục và lọc ra các sản phẩm không có sẵn từ phản hồi đó. Bây giờ ứng dụng của bạn hiển thị 23 sản phẩm. Về lý thuyết, một trang không có sản phẩm cũng có thể!
Thỉnh thoảng bạn sẽ muốn chạy một tập lệnh dọn sạch các tham chiếu lơ lửng, sau mỗi thay đổi có liên quan hoặc theo các khoảng thời gian đều đặn. Lưu ý rằng các tập lệnh như vậy khá tốn kém vì chúng phải yêu cầu mọi sản phẩm / danh mục từ cơ sở dữ liệu / microservice sao lưu để xem liệu nó có còn tồn tại hay không.
Điều này là rõ ràng, nhưng để rõ ràng: không sử dụng lại ID. ID kiểu tự động có thể hoặc không thể tốt. GUID hoặc băm cho phép bạn linh hoạt hơn, ví dụ: bằng cách có thể gán ID trước khi mục được chèn vào cơ sở dữ liệu.
Ví dụ: đơn đặt hàng đồng thời
Bây giờ thay vì xem xét một mối quan hệ sản phẩm - đặt hàng. Điều gì xảy ra với một đơn đặt hàng nếu một sản phẩm bị xóa hoặc thay đổi? Ok, chúng ta chỉ cần sao chép dữ liệu sản phẩm có liên quan vào mục nhập đơn hàng để giữ cho nó có sẵn - không gian đĩa giao dịch cho đơn giản. Nhưng điều gì sẽ xảy ra nếu giá của sản phẩm thay đổi hoặc sản phẩm không có sẵn ngay trước khi đơn đặt hàng cho sản phẩm đó được thực hiện? Trong một hệ thống phân tán, các hiệu ứng cần có thời gian để lan truyền và thứ tự có thể sẽ đi qua với dữ liệu lỗi thời.
Một lần nữa, làm thế nào để tiếp cận điều này phụ thuộc vào yêu cầu kinh doanh của bạn. Có thể đơn hàng lỗi thời là chấp nhận được và sau đó bạn có thể hủy đơn hàng nếu không thể thực hiện được.
Nhưng có lẽ đó không phải là một lựa chọn, ví dụ cho các cài đặt đồng thời cao. Hãy xem xét 3000 người đổ xô mua vé buổi hòa nhạc trong vòng 10 giây đầu tiên và giả sử một sự thay đổi về tính khả dụng sẽ cần 10ms để tuyên truyền. Xác suất bán vé cuối cùng cho nhiều người là gì? Phụ thuộc vào cách xử lý các va chạm đó, nhưng sử dụng phân phối Poisson với λ = 3000 / (10s / 10ms) = 3chúng tôi sẽ có P(k > 1) = 1 - P(k = 0) - P(k = 1) = 80%cơ hội va chạm trên mỗi khoảng thời gian 10ms. Việc bán và sau đó hủy phần lớn các đơn đặt hàng của bạn là có thể mà không có hành vi gian lận có thể dẫn đến một cuộc trò chuyện thú vị với bộ phận pháp lý của bạn.
Chủ nghĩa thực dụng có nghĩa là chọn anh đào những tính năng tốt nhất.
Tin vui là bạn không phải chuyển sang mô hình cơ sở dữ liệu phân tán, nếu điều đó không bắt buộc. Sẽ không ai thu hồi tư cách thành viên Câu lạc bộ microservice của bạn nếu bạn không thực hiện microservice đúng cách, bởi vì không có câu lạc bộ nào như vậy - và không có cách nào thực sự để xây dựng microservice.
Chủ nghĩa thực dụng chiến thắng mọi lúc, vì vậy hãy trộn và kết hợp các cách tiếp cận khác nhau khi chúng giải quyết vấn đề của bạn. Điều này thậm chí có thể có nghĩa là microservice với một cơ sở dữ liệu tập trung. Thực sự, đừng trải qua nỗi đau của cơ sở dữ liệu phân tán nếu bạn không phải làm vậy.
Bạn có thể mở rộng mà không cần microservice.
Dịch vụ vi mô có hai lợi ích chính:
- Lợi ích tổ chức mà họ có thể được phát triển và triển khai độc lập bởi các nhóm riêng biệt (do đó đòi hỏi các dịch vụ phải cung cấp giao diện ổn định).
- Lợi ích hoạt động mà mỗi microservice có thể được thu nhỏ độc lập .
Nếu không cần mở rộng quy mô độc lập, microservice sẽ kém hấp dẫn hơn rất nhiều.
Một máy chủ cơ sở dữ liệu đã là một loại dịch vụ mà bạn có thể chia tỷ lệ (phần nào) một cách độc lập, ví dụ: bằng cách thêm các bản sao đọc. Bạn đề cập đến các thủ tục lưu trữ. Việc giảm chúng có thể có tác động lớn đến mức mọi cuộc thảo luận về khả năng mở rộng khác đều phải tranh luận.
Và hoàn toàn có thể có một khối nguyên khối có thể mở rộng bao gồm tất cả các dịch vụ như thư viện. Sau đó, bạn có thể mở rộng quy mô bằng cách khởi chạy thêm các phiên bản của khối, điều này tất nhiên đòi hỏi mỗi trường hợp phải không trạng thái.
Điều này có xu hướng hoạt động tốt cho đến khi khối nguyên khối quá lớn để được triển khai hợp lý hoặc nếu một số dịch vụ có yêu cầu tài nguyên đặc biệt để bạn có thể muốn mở rộng chúng một cách độc lập. Các miền vấn đề liên quan đến tài nguyên bổ sung có thể không liên quan đến một mô hình dữ liệu riêng biệt.
Bạn có một trường hợp kinh doanh mạnh mẽ?
Bạn nhận thức được nhu cầu kinh doanh của tổ chức của mình và do đó có thể tạo một đối số cho kiến trúc cơ sở dữ liệu trên mỗi microservice, dựa trên phân tích:
- rằng cần phải có một quy mô nhất định và kiến trúc này là cách tiếp cận hiệu quả nhất về chi phí để có được khả năng mở rộng đó, có tính đến nỗ lực phát triển gia tăng cho một giải pháp thay thế và thiết lập như vậy; và
- rằng các yêu cầu kinh doanh của bạn cho phép các đảm bảo ACID có liên quan được nới lỏng, mà không dẫn đến các vấn đề khác nhau như những vấn đề được thảo luận ở trên.
Ngược lại, nếu bạn không thể chứng minh điều này, đặc biệt nếu thiết kế cơ sở dữ liệu hiện tại có thể hỗ trợ đủ quy mô trong tương lai (như các đồng nghiệp của bạn dường như tin tưởng), thì bạn cũng có câu trả lời của mình.
Ngoài ra còn có một thành phần YAGNI lớn cho khả năng mở rộng. Trước sự không chắc chắn, đây là một quyết định kinh doanh chiến lược về xây dựng khả năng mở rộng (tổng chi phí thấp hơn, nhưng liên quan đến chi phí cơ hội và có thể không cần thiết) so với trì hoãn một số công việc về khả năng mở rộng (tổng chi phí cao hơn nếu cần, nhưng bạn có tốt hơn ý tưởng của quy mô thực tế). Đây không phải là một quyết định kỹ thuật.