Dịch vụ lưu trữ và dữ liệu

Tôi đang xem xét chuyển API REST nguyên khối sang kiến ​​trúc microservice và tôi cảm thấy hơi bối rối về việc lưu trữ dữ liệu. Theo tôi thấy, một số lợi ích của microservice sẽ là:

• Có thể mở rộng theo chiều ngang - Tôi có thể chạy nhiều bản sao dự phòng của microservice để đối phó với tải và / hoặc máy chủ bị hỏng.
• Kết hợp lỏng lẻo - Tôi có thể thay đổi triển khai nội bộ của microservice mà không phải thay đổi các dịch vụ khác và tôi có thể độc lập triển khai và thay đổi chúng, v.v ...

Vấn đề của tôi là với lưu trữ dữ liệu. Theo tôi thấy có một số tùy chọn:

1. Một dịch vụ cơ sở dữ liệu duy nhất được chia sẻ bởi tất cả các dịch vụ siêu nhỏ - điều này dường như sẽ loại bỏ hoàn toàn bất kỳ lợi ích nào của khớp nối lỏng lẻo.
2. Một phiên bản cơ sở dữ liệu được cài đặt cục bộ trên mỗi microservice - Tôi không thể thấy một cách mở rộng theo chiều ngang này, vì vậy tôi không nghĩ rằng nó sẽ là một tùy chọn.
3. Mỗi microservice đều có dịch vụ cơ sở dữ liệu riêng - điều này có vẻ hứa hẹn nhất, vì nó bảo tồn các lợi ích của khớp nối lỏng lẻo và chia tỷ lệ theo chiều ngang (sử dụng các bản sao cơ sở dữ liệu dự phòng và / hoặc chuyển qua nhiều lần)

Đối với tôi, lựa chọn thứ ba dường như là lựa chọn duy nhất, nhưng nó dường như vô cùng nặng nề đối với tôi, và là một giải pháp rất áp đảo. Nếu tôi hiểu đúng, thì đối với một ứng dụng đơn giản với 4-5 microservice tôi sẽ phải chạy 16-20 máy chủ - hai trường hợp microservice thực tế cho mỗi microservice (trong trường hợp máy chủ bị lỗi và để triển khai mà không có thời gian chết) và hai trường hợp dịch vụ cơ sở dữ liệu cho mỗi microservice (trong trường hợp máy chủ bị lỗi, v.v ...).

Điều này, khá thẳng thắn, có vẻ hơi vô lý. 16-20 máy chủ để chạy API đơn giản, lưu ý rằng một dự án thực tế có thể sẽ có nhiều hơn 4-5 dịch vụ? Có một số khái niệm cơ bản mà tôi đang thiếu sẽ giải thích điều này?

Một số điều có thể giúp trong khi trả lời:

• Tôi là nhà phát triển duy nhất trong dự án này và sẽ trong tương lai gần.
• Tôi đang sử dụng Node.js và MongoDB, nhưng tôi quan tâm đến câu trả lời không biết ngôn ngữ - một câu trả lời thậm chí có thể là tôi chỉ sử dụng sai công nghệ!

Trong ba tùy chọn của bạn, thứ nhất (một cơ sở dữ liệu chung, duy nhất) và thứ ba (một "dịch vụ cơ sở dữ liệu") là phổ biến nhất.

Đầu tiên được gọi là cơ sở dữ liệu tích hợp . Điều này thường không được xem là một giải pháp tốt trong kiến ​​trúc microservice. Nó không thêm khớp nối với các dịch vụ của bạn. Nó cũng giúp cho một dịch vụ dễ dàng bỏ qua các dịch vụ khác và truy vấn trực tiếp vào cơ sở dữ liệu. Bạn có thể mất bất kỳ loại toàn vẹn hoặc xác thực dữ liệu nào được cung cấp bởi cấp ứng dụng không được thi hành ở cấp cơ sở dữ liệu.

Ý tưởng thứ ba của bạn được gọi là cơ sở dữ liệu ứng dụng . Và bạn đã đúng - nó cho phép bạn thực thi khớp nối lỏng lẻo ở cấp API giữa các dịch vụ và cho phép bạn dễ dàng mở rộng quy mô dịch vụ hơn ở cấp cơ sở dữ liệu. Nó cũng giúp dễ dàng thay thế công nghệ cơ sở dữ liệu cơ bản thành thứ gì đó phù hợp với từng dịch vụ, giống như bạn có thể thay đổi công nghệ hoặc các chi tiết triển khai khác của từng dịch vụ. Rất linh hoạt.

Tuy nhiên, tôi đề xuất một giải pháp trung gian.

Thay vì đứng lên một dịch vụ cơ sở dữ liệu cho mọi dịch vụ siêu nhỏ, hãy dựng một lược đồ cho mọi dịch vụ. Nếu bạn đang sử dụng nhiều công nghệ cơ sở dữ liệu, bạn có thể cần phải phân tách một chút khác nhau, nhưng ý tưởng sẽ là giảm thiểu số lượng máy chủ cơ sở dữ liệu mà bạn đang chạy, nhưng làm cho việc phân tách một dịch vụ thành máy chủ cơ sở dữ liệu của nó rất dễ dàng nếu và khi nó trở nên cần thiết Miễn là bạn chỉ cho phép một cơ sở dữ liệu truy cập vào lược đồ riêng của mình, bạn có những lợi thế của cơ sở dữ liệu ứng dụng nhưng không có chi phí hoạt động của các máy chủ cơ sở dữ liệu hiện có cho mọi ứng dụng hoặc dịch vụ.

Tuy nhiên, với tư cách là một nhà phát triển solo, tôi sẽ thách thức toàn bộ khái niệm microservice tại thời điểm này - Martin Fowler viết về Monolith First và microservice Premium , Simon Brown nói về các khối nguyên khối mô đun , và DHH nói về Majestic Monolith. Tôi không chắc chắn nguyên khối của bạn được tổ chức tốt như thế nào, nhưng tái cấu trúc và sắp xếp nó. Xác định các thành phần và phân tách rõ ràng giữa chúng để trích xuất các mảnh vào dịch vụ một cách dễ dàng. Điều tương tự cũng xảy ra với cấu trúc cơ sở dữ liệu của bạn. Tập trung vào kiến ​​trúc tốt, sạch, dựa trên thành phần có thể hỗ trợ tái cấu trúc thành các dịch vụ. Microservice thêm rất nhiều chi phí cho một nhà phát triển để xây dựng và hỗ trợ trong các hoạt động. Tuy nhiên, một khi bạn thực sự có nhu cầu mở rộng một phần của hệ thống, hãy sử dụng hệ thống giám sát và báo cáo của bạn để xác định các tắc nghẽn, trích xuất dịch vụ và mở rộng quy mô khi cần thiết.

Mỗi microservice đều có dịch vụ cơ sở dữ liệu riêng - điều này có vẻ hứa hẹn nhất, vì nó bảo tồn các lợi ích của khớp nối lỏng lẻo và chia tỷ lệ theo chiều ngang (sử dụng các bản sao cơ sở dữ liệu dự phòng và / hoặc chuyển qua nhiều lần)

Đồng ý. Các thứ ba tùy chọn là sự lựa chọn tự nhiên cho các dịch vụ vi. Nếu dịch vụ vi mô được dự định là thực sự độc lập (và không phải là một phần của khối nguyên khối phân tán ), thì mỗi cơ sở dữ liệu đều có cơ sở dữ liệu.

[...] hai trường hợp microservice thực tế cho mỗi microservice (trong trường hợp máy chủ bị lỗi và để triển khai mà không có thời gian chết) và hai trường hợp dịch vụ cơ sở dữ liệu cho mỗi dịch vụ micros (trong trường hợp máy chủ bị lỗi, v.v.).

Bạn đúng về số lượng dịch vụ vi mô đang chạy nếu bạn muốn có số dư tải. Nếu bạn dự định có 4 dịch vụ vi mô, bạn cần chuẩn bị ít nhất 2 trường hợp cho mỗi dịch vụ vi mô (tổng cộng 8 dịch vụ), như bạn đã giải thích.

Nhưng hai cơ sở dữ liệu cho mỗi dịch vụ vi mô? Điều này thực sự đáng nghi ngờ. Tôi không biết chi tiết về vấn đề kinh doanh mà các dịch vụ vi mô của bạn sẽ tham gia, nhưng có sự dư thừa cơ sở dữ liệu, nó có khá nhiều đối với hầu hết các sản phẩm / dự án. Tôi sẽ khuyên bạn nên bắt đầu với một cơ sở dữ liệu duy nhất có bản sao lưu tốt và giảm thiểu (ít nhất là ban đầu) sự phức tạp của cơ sở hạ tầng của bạn.

Điều này, khá thẳng thắn, có vẻ hơi vô lý. 16-20 máy chủ để chạy API đơn giản, lưu ý rằng một dự án thực tế có thể sẽ có nhiều hơn 4-5 dịch vụ? Có một số khái niệm cơ bản mà tôi đang thiếu sẽ giải thích điều này?

Đối với một API đơn giản , con số này không khớp. Hãy chú ý nếu bạn không rơi vào một trong những cái bẫy "Đầu tiên của microservice" .

Microservice là một hình thức của Kiến trúc hướng dịch vụ, có lẽ là cực kỳ. Mục đích chung của họ là giảm khớp nối và cho phép phát triển & triển khai độc lập.

Nói một cách đại khái về mặt kiến ​​trúc, microservice là một thuật ngữ áp dụng, giả sử, ở mức độ logic. Các microservice được phân tách hợp lý với nhau. Từ quan điểm này, microservice nên tự sở hữu và cung cấp cho bộ lưu trữ của riêng mình, chúng nên được tách rời khỏi bộ lưu trữ của các dịch vụ siêu nhỏ khác. Đối với microservice, tính độc lập của lưu trữ này là chìa khóa cho mục tiêu của họ là mô đun hóa và khớp nối lỏng lẻo.

Từ góc độ kiến ​​trúc, tỷ lệ ngang áp dụng ở cấp độ thấp hơn, gần với việc triển khai hơn, giả sử, ở cấp độ vật lý. Ở cấp độ này, chúng tôi đang triển khai một dịch vụ siêu nhỏ và chúng tôi có thể phân tách dịch vụ siêu nhỏ này, bên trong, thành một thành phần không trạng thái có thể mở rộng theo chiều ngang và một thành phần trạng thái được chia sẻ bởi tất cả các thành phần không trạng thái.  Nhưng chúng ta đừng nhầm lẫn chỉ một phần phi trạng thái với chính microservice.

Vì vậy, khi chúng ta nói về các dịch vụ siêu nhỏ riêng lẻ, chúng ta ở cấp độ logic nói về API và các trách nhiệm riêng biệt và các chu kỳ phát triển / triển khai riêng biệt. Và khi chúng ta nói về quy mô ngang, chúng ta ở cấp độ vật lý nói về việc triển khai một dịch vụ siêu nhỏ (đơn) và phân tách thành các thành phần không trạng thái và trạng thái.

Khi triển khai nhiều dịch vụ siêu nhỏ, chúng tôi có các lựa chọn để sử dụng lại công nghệ cơ sở dữ liệu cho các thành phần trạng thái:

• cơ sở dữ liệu riêng biệt trên mỗi dịch vụ
• cơ sở dữ liệu được chia sẻ với:
  • lược đồ riêng / riêng cho mỗi microservice
  • bảng riêng / riêng cho mỗi microservice

Xem thêm tại đây .

Một dịch vụ cơ sở dữ liệu duy nhất được chia sẻ bởi tất cả các dịch vụ siêu nhỏ - điều này dường như sẽ loại bỏ hoàn toàn bất kỳ lợi ích nào của khớp nối lỏng lẻo.

Đồng ý, nếu bạn muốn chia sẻ các hàng và cột của bảng, đó sẽ không thực sự là microservice.

Nếu chúng ta có thể tách rời - trong các quy trình suy nghĩ của chúng ta - khái niệm logic của microservice từ khái niệm vật lý hơn về các thành phần trạng thái và không trạng thái của microservice, chúng ta có thể thấy dễ dàng hơn để đạt được khớp nối lỏng lẻo được cung cấp bởi microservice, trong khi vẫn giữ được hiệu quả của việc chia sẻ cơ sở dữ liệu.

Nói chung, có một số tiền khá lớn được viết về microservice và sự kiên trì có trạng thái, xem thêm tại đây .

Chà, tôi đã đọc qua tất cả các bài viết trong chủ đề này và có thể nói với bạn rằng tôi bối rối với câu hỏi: nó trộn microservice (MS) với các dịch vụ với dịch vụ truy cập dữ liệu (dịch vụ DB) với cơ sở dữ liệu và máy chủ ...

Nếu MS là một thành phần độc lập (có thể triển khai) giải quyết một nhiệm vụ đơn giản nhất theo cách không trạng thái, thì cơ sở dữ liệu cần gì? Nếu một nhiệm vụ phức tạp hơn cần giải quyết, đòi hỏi nhiều hơn một nhiệm vụ phụ đơn giản nhất (MS?) Để được giải quyết cùng nhau, đó có phải là MS không? Trong SOA, nó được gọi là Dịch vụ phối hợp. Nó thực hiện "quy trình" và điều phối việc gọi MS, do đó, nó cần duy trì trạng thái của nó (tất cả các dàn nhạc / nhà tổ chức / nhà soạn nhạc / v.v. đều có trạng thái) và cần một kho dữ liệu cá nhân: không ai khác có thể tiết chế trạng thái của người điều phối.

Tuy nhiên, chúng tôi không nói về cơ sở dữ liệu mà về Cơ sở dữ liệu MS / Dịch vụ truy cập và đây là một vấn đề hoàn toàn khác. Một MS có thể cần một số dữ liệu được thu thập trong công ty (không phải trong Ứng dụng mà nó hoạt động bên trong) và nó không thể yêu cầu một MS khác thông qua API / giao diện của nó cho dữ liệu. Đây là kịch bản phổ biến và thực tế nhất. Và một MS khác từ cùng hoặc khác ứng dụng có thể cần dữ liệu này hoặc thậm chí thay đổi nó. Vâng, họ cạnh tranh dữ liệu như mọi khi trước khi MS xuất hiện.

Tại sao chúng ta lại sập 'cánh cửa', vốn nổi tiếng và rộng mở? Sự khác biệt về vấn đề này giữa một MS và một đối tượng tự tồn tại thường xuyên là gì? Tại sao chúng ta cần một cơ sở dữ liệu riêng cho MS nếu nó phải (vì mục đích linh hoạt và khả năng kết hợp) tham gia Dịch vụ truy cập dữ liệu (DAS) của nó bằng mọi cách? Đừng quên rằng DAS bảo vệ MS với nhiệm vụ kinh doanh khỏi nhận thức về kết nối vật lý với cơ sở dữ liệu. Sự kết hợp lỏng lẻo và linh hoạt này mà MS nên giữ để tự do tham gia vào nhiều Ứng dụng mà không có cơ sở dữ liệu neo trên đó.