Các dịch vụ có nên nói chuyện trực tiếp với nhau trong kiến ​​trúc microservice không?

Tôi có một số dịch vụ web tạo thành một ứng dụng web. Khách hàng có thể truy cập các dịch vụ này thông qua các lệnh gọi API REST.

Những dịch vụ này có thể nói chuyện trực tiếp với nhau không? Nếu vậy thì điều đó có khiến họ trở thành cặp đôi đi ngược lại khái niệm trên microservice không?

Khách hàng có nên gọi họ trực tiếp lần lượt để lấy dữ liệu cần thiết để tải lên một trang web trên máy khách không?

Hoặc tôi nên có một lớp khác trên đầu các dịch vụ của mình, xử lý một yêu cầu từ máy khách, lấy dữ liệu cho yêu cầu đó và sau đó gửi lại cho máy khách?

Nếu bạn muốn các dịch vụ của mình trông giống như trong bức tranh này, thì có: Không phải là bạn không thể làm điều đó, nhưng hầu hết thời gian nó sẽ có hậu quả xấu. Giao tiếp thông qua REST sẽ không tách rời đáng kể các dịch vụ của bạn. Khi một số giao diện dịch vụ thay đổi, tất cả các dịch vụ phụ thuộc rất có thể phải được thay đổi và triển khai lại. Ngoài ra, trong khi triển khai lại dịch vụ, bạn sẽ phải đặt tất cả các dịch vụ phụ thuộc xuống, đây không được coi là một thiết kế tốt cho các tiêu chuẩn sẵn sàng cao.

Cuối cùng, bạn sẽ có ứng dụng microservice chậm hơn ứng dụng nguyên khối thay thế, nhưng có hầu hết các vấn đề tương tự!

Tôi phải không đồng ý với @Robert Harvey

Tuy nhiên, trên thực tế, một hoặc nhiều dịch vụ siêu nhỏ của bạn (có lẽ là tất cả trong số họ) sẽ nói chuyện với một số kho dữ liệu trung tâm như cơ sở dữ liệu SQL.

Cơ sở dữ liệu tích hợp là antipotype nổi tiếng

Một giải pháp tốt hơn nhiều là sử dụng mẫu đăng ký xuất bản để làm cho giao tiếp giữa các dịch vụ của bạn không đồng bộ:

Xin hãy xem cách CQRS / ES thực hiện phương thức giao tiếp này, Greg Young và những người khác cung cấp hàng tấn video hay về chủ đề này. Chỉ cần google cho từ khóa "CQRS / ES". Theo cách tiếp cận này, mỗi dịch vụ sẽ trở thành nhà xuất bản và người đăng ký cùng một lúc, cho phép các dịch vụ được kết nối ít hơn nhiều.

Dưới đây là một loạt các bài viết hay về microservice làm sáng tỏ những tranh cãi xung quanh chủ đề này. Giải thích rất chi tiết với hình minh họa đẹp.

Bạn sẽ nhận được rất nhiều ý tưởng rất hay từ việc đọc những gì Udi Dahan nói về SOA .

Một dịch vụ là cơ quan kỹ thuật cho một khả năng kinh doanh cụ thể. Bất kỳ phần dữ liệu hoặc quy tắc phải được sở hữu bởi chỉ một dịch vụ.

Điều này có nghĩa là ngay cả khi các dịch vụ xuất bản và đăng ký vào các sự kiện của nhau, chúng tôi luôn biết nguồn sự thật có thẩm quyền là gì cho mỗi phần dữ liệu và quy tắc.

Ngoài ra, khi nhìn vào các dịch vụ từ lăng kính về khả năng kinh doanh, điều chúng ta thấy là nhiều giao diện người dùng trình bày thông tin thuộc các khả năng khác nhau - giá của sản phẩm cùng với việc có tồn kho hay không. Để chúng tôi tuân thủ định nghĩa dịch vụ ở trên, điều này dẫn đến chúng tôi hiểu rằng các giao diện người dùng như vậy thực sự là một bản hòa trộn - với mỗi dịch vụ có đoạn UI xử lý dữ liệu cụ thể của nó.

Cụ thể liên quan đến thành phần UI, bài viết của Mauro Servienti về Thành phần UI là một điểm khởi đầu tốt. Xem thêm video của Udi, có sẵn ở đây .

Những dịch vụ này có thể nói chuyện trực tiếp với nhau không? Nếu vậy thì điều đó có khiến họ trở thành cặp đôi đi ngược lại khái niệm trên microservice không?

Nếu hai dịch vụ trao đổi tin nhắn với nhau, thì bạn sẽ nhận được một số khớp nối. Câu trả lời chính là họ kết hợp với API của dịch vụ kia - hợp đồng mà dịch vụ hứa hẹn sẽ giữ ổn định ngay cả khi nội bộ của nó đang thay đổi.

Ngoài ra, các kỹ thuật như khám phá dịch vụ có thể giảm bớt sự phụ thuộc vào một nhà cung cấp dịch vụ cụ thể và các nhà môi giới tin nhắn có thể tách rời các nhà sản xuất và người tiêu dùng (họ vẫn cần hiểu các thông điệp của nhau và cách tương tác với API của nhà môi giới tin nhắn - không có phép thuật nào ).

Nó phụ thuộc vào những gì bạn có nghĩa là "trực tiếp".

Theo kiến ​​trúc microservice, việc có các dịch vụ siêu nhỏ gọi các dịch vụ siêu nhỏ khác, trên máy chủ của bạn hoặc thậm chí trên các máy chủ bên ngoài, thông qua một số giao diện như REST.

Điều không tốt, là để một microservice gọi một dịch vụ khác bằng cách sử dụng các phương thức trực tiếp; điều đó sẽ làm cho cả hai microservice trở thành một phần của cùng một khối.

Những dịch vụ này có thể nói chuyện trực tiếp với nhau không? Nếu vậy thì điều đó có khiến họ trở thành cặp đôi đi ngược lại khái niệm trên microservice không?

Khớp nối không phải là một từ xấu. Mỗi ứng dụng đã có một mức độ khớp nối nhất định; các ứng dụng nói chuyện với microservice của bạn đã được ghép nối với microservice, nếu không chúng sẽ không hoạt động.

Những gì bạn thực sự sau với microservice là khớp nối lỏng lẻo ; bạn có thể đạt được điều đó bằng cách đơn giản là có một microservice thẩm vấn người kia thông qua API công khai hoặc sử dụng xe buýt sự kiện.

Trong thực tế, tuy nhiên, một hoặc nhiều dịch vụ siêu nhỏ của bạn (có lẽ là tất cả chúng) sẽ nói chuyện với một số kho dữ liệu trung tâm như cơ sở dữ liệu SQL. Tùy thuộc vào cách bạn muốn thực hiện mục tiêu của mình, bạn có thể chỉ cần một microservice thay đổi dữ liệu cơ sở dữ liệu theo một cách nào đó, mà microservice khác sẽ truy vấn để nhận thay đổi.

Dường như khi nói về kiến ​​trúc và kiến ​​trúc nói chung, mọi người bị cuốn vào ngữ nghĩa và biệt ngữ. Điều gì làm cho một dịch vụ "vi mô"? Cuối cùng, có một số đặc điểm mà trong bất kỳ "hệ thống tính điểm" nào bạn đang sử dụng, rõ ràng không làm cho dịch vụ trở nên "không vi mô". Tòa án tối cao nói gì về sự không đứng đắn? "Tôi sẽ biết nó khi tôi nhìn thấy nó."

Tôi chắc rằng một số người sẽ nói đây là câu trả lời không đúng, nhưng sau đó họ đang thiếu điểm. Kiến trúc vi dịch vụ nhằm tránh một số vấn đề, trong số đó có vấn đề "khớp nối chặt chẽ". Vì vậy, nếu bạn kết thúc việc tạo ra một mớ dịch vụ vi mô phụ thuộc vào quá nhiều chi tiết tốt của nhau, bạn đã tạo ra một khớp nối chặt chẽ - cho dù bạn đang sử dụng xe buýt tin nhắn quán rượu / phụ hoặc cuộc gọi trực tiếp - phá hủy khả năng của bạn để soạn các giải pháp mới từ các mảnh, cấu hình lại các mảnh riêng lẻ mà không làm giảm toàn bộ hệ thống, v.v.

Khách hàng có nên gọi họ trực tiếp lần lượt để lấy dữ liệu cần thiết để tải lên một trang web trên máy khách không?

Nó phụ thuộc; tuy nhiên, tôi khuyên bạn nên cung cấp các khả năng có thể sử dụng trực tiếp cho khách hàng và ẩn (đóng gói) các chi tiết về cách kết quả được lắp ráp (ví dụ: thông qua nhiều dịch vụ vi mô).

Nếu có quá nhiều logic liên quan đến việc kết hợp các kết quả dịch vụ vi mô riêng lẻ của khách hàng, điều đó có thể vô tình khiến một số logic kinh doanh len vào máy khách. Nó cũng có thể hiển thị nhiều kiến ​​trúc nội bộ của bạn cho khách hàng hơn bạn muốn, cản trở việc tái cấu trúc các dịch vụ sau này.

Vì vậy, điều đó có nghĩa là với microservice, đôi khi thật hữu ích khi có một microservice bao bọc cung cấp cho khách hàng một điểm cuối có sự trừu tượng hữu ích và thực hiện sự phối hợp ở cấp độ cao hơn của các dịch vụ siêu nhỏ khác (có lẽ là nội bộ hơn).

(Hơn nữa, các chuyến đi khứ hồi đến khách hàng có thể đắt hơn so với từ các dịch vụ siêu nhỏ của bạn cho nhau.)

Ví dụ, nếu bạn nhìn vào hướng được thực hiện bởi GraphQL, bạn sẽ thấy các khách hàng đưa ra các truy vấn có liên quan trực tiếp đến điểm cuối, có thể hoặc không thể được triển khai dưới dạng tập hợp các dịch vụ micrs. Vì kiến ​​trúc của microservice bị ẩn đằng sau GraphQL, điều đó làm cho kiến ​​trúc dễ tái cấu trúc hơn và cũng thân thiện hơn với máy khách. Xem, ví dụ: /programming//a/38079681/471129 .

Mục đích chính của các dịch vụ vi mô là làm cho ứng dụng của bạn được kết nối lỏng lẻo. Do đó, các dịch vụ không thể gọi cho nhau. Nếu không, nó sẽ được gắn chặt. Nhưng chúng ta sẽ làm gì nếu có hai dịch vụ cần chia sẻ dữ liệu? Câu trả lời là Message Broker. Vì vậy, dịch vụ nhận dữ liệu từ máy khách có thể chia sẻ dữ liệu cho nhà môi giới tin nhắn trung tâm, sau đó các dịch vụ phải sử dụng dữ liệu đó có thể sử dụng dữ liệu đó, chuyển đổi dữ liệu và đưa vào lưu trữ dữ liệu của chính nó. Tôi khuyên bạn nên Kafka vì bạn có thể tham gia dữ liệu từ các chủ đề khác nhau khi đang di chuyển với Kafka Stream. Tái bút tốt hơn để phân tách các dịch vụ vi mô của bạn theo tính năng.