Microservice REST hoặc AMQP, trường hợp nào

Tôi đã đọc nhiều bài viết liên quan đến kiến ​​trúc microservice và tôi đã tự hỏi khi nào nên sử dụng AMQP hoặc REST.

Tôi đã đọc rằng khớp nối lỏng lẻo giữa các dịch vụ là một điều tốt và AMQP dường như là một lựa chọn tốt trong trường hợp đó. Nhưng nếu chúng ta sử dụng AMQP, điều này có nghĩa là chúng ta không cần các điểm cuối REST nữa (nhưng điều đó có nghĩa là chúng ta mất khái niệm HATEOAS).

Nhưng REST có thực sự là một cách tốt để xây dựng dịch vụ của tôi không? Vì tôi sẽ không sử dụng bất kỳ điểm cuối nào ... Trong trường hợp nào thì tốt hơn điểm cuối khác?

Khi nào tôi nên sử dụng cái này hay cái kia?

Bằng cách loại bỏ REST, bạn sẽ mất nhiều hơn là chỉ HATEOAS. Nếu các dịch vụ siêu nhỏ của bạn là công khai (và đó là một ý tưởng tốt để chúng được công khai hoặc ít nhất là có xu hướng công khai một ngày nào đó), thì việc sử dụng bất cứ thứ gì khác ngoài REST và SOAP sẽ là vấn đề:

• Một số nhà phát triển không bao giờ sử dụng AMQP,

• Một số người đã sử dụng AMQP, nhưng thường quen thuộc hơn với REST và SOAP,

• Thư viện AMQP cho một số ngôn ngữ không đặc biệt đơn giản,

• Thử nghiệm thủ công với dịch vụ rất hạn chế: Tôi có thể sử dụng CURL để thực hiện bất kỳ yêu cầu nào đối với Amazon S3; Tôi nên cài đặt gì trên máy nếu muốn chơi với biến thể AMQP của S3?

• Gỡ lỗi REST và SOAP rất dễ dàng. Tôi chỉ theo dõi các trao đổi HTTP và phân tích chúng. Không chắc chắn những công cụ nào tôi nên sử dụng để xem để gỡ lỗi trao đổi AMQP.

AMQP là tuyệt vời, nhưng nó được thực hiện cho một mục đích trao đổi dựa trên các sự kiện rất cụ thể. Mặc dù về mặt kỹ thuật có thể thực hiện RPC với AMQP, nhưng đó không phải là mục đích chính của nó.

Các khía cạnh không đồng bộ cũng quan trọng. Đôi khi, đó là một lợi ích: Tôi không muốn chặn giao diện người dùng của ứng dụng trong khi yêu cầu máy chủ. Đôi khi, điều đó chỉ khiến mọi thứ trở nên khó khăn hơn mức cần thiết: nếu tôi cần khôi phục bản sao lưu tệp từ Amazon S3 vì tệp cục bộ bị hỏng, sau đó khôi phục bản sao lưu, tệp bó của tôi nhất thiết cần phải hoàn thành công việc trước khi tiếp tục, và một hoạt động đồng bộ (với thời gian chờ cụ thể) có ý nghĩa hoàn hảo.

Giữ REST cho các hoạt động chính:

• Lấy một sản phẩm,

• Lưu trữ hóa đơn,

và sử dụng AMQP cho các tác vụ trong đó nhắn tin thực sự có ý nghĩa:

• Xử lý tất cả các hóa đơn từ tháng 9 và thông báo cho ứng dụng khi báo cáo đã sẵn sàng để hiển thị (với điều kiện là hoạt động thường mất từ ​​hai đến mười phút),

  ^{Lợi ích của AMQP ở đây là khía cạnh không đồng bộ của nó. Một yêu cầu HTTP đang chờ xử lý trong mười phút có khả năng gây ra thời gian chờ và các vấn đề khác.}

• Gửi thông tin rằng các bản sao lưu bị hỏng cho mọi người có thể quan tâm, chẳng hạn như người hỗ trợ, quản trị viên cơ sở dữ liệu, nhóm giám sát, nhà phát triển ứng dụng sử dụng cơ sở dữ liệu này, v.v.

  ^{Lợi ích của AMQP ở đây là, trong số những người khác, khả năng thêm người đăng ký mà không thay đổi ứng dụng theo dõi các bản sao lưu và kích hoạt cảnh báo khi phát hiện thấy lỗi.}

^{Dịch vụ web công cộng không nhất thiết phải được sử dụng bởi người dùng bên ngoài công ty. Trong các công ty lớn hoặc vừa, dịch vụ của bạn thường được sử dụng bởi các bộ phận khác trong cùng công ty và có các yêu cầu giống như yêu cầu của bất kỳ bên thứ ba nào: nó sẽ không tin tưởng bất kỳ cuộc gọi nào (thực tế là một số người bạn không bao giờ nghe nói ai gọi dịch vụ của bạn làm việc trong cùng một công ty bạn không có nghĩa là anh ta sẽ không khai thác các vấn đề bảo mật của nó), nó nên được ghi lại đúng cách (vì cùng một người Ấn Độ không nhất thiết phải biết số điện thoại của bạn và không nhất thiết phải biết biết tiếng anh)}

Sử dụng cả hai.

Các dịch vụ web JSON kiểu REST rất phù hợp với khả năng tương tác với javascript, ios, v.v.

AMQP rất tốt cho các quy trình, sự kiện và điều phối các dịch vụ siêu nhỏ.

Nhưng cả hai chỉ là trình bao bọc truyền thông cho dịch vụ thực tế, bạn có thể hiển thị cùng một dịch vụ theo nhiều cách và có lẽ nên.

AMPQ có thể hoạt động tốt trên các Websockets, có thể trông khá giống điểm cuối REST nếu bạn nheo mắt nhìn nó.

REST là một công nghệ tiêu chuẩn đặc biệt phù hợp với khả năng tương tác giữa các thành phần - đây là phần quan trọng, tuyệt vời để tạo ra một dịch vụ web mà người khác có thể sử dụng. Tuy nhiên, nó bị các vấn đề thông thường về khả năng tương tác như vậy ở chỗ nó kém hiệu quả hơn một giao thức tùy chỉnh.

Nếu bạn đang viết một kiến ​​trúc back-end trong đó các dịch vụ chỉ được sử dụng bởi chính bạn, thì bạn có thể sử dụng bất kỳ giao thức nào bạn thích - bạn không còn bị hạn chế bởi việc sử dụng một giao thức tương thích. Bạn có thể sử dụng MQ hoặc một cái gì đó kết hợp chặt chẽ hơn và biểu diễn. Cái nào bạn sử dụng phụ thuộc vào trường hợp sử dụng của bạn, bus tin nhắn rất tốt cho bộ dịch vụ phân tán xử lý dữ liệu mà khách hàng không quan tâm ai nhận được tin nhắn mà nó gửi đi.

AMQP cũng hỗ trợ giao tiếp điểm-điểm (ví dụ, xem python-qpid-protonhướng dẫn). Bạn có thể thực hiện giao diện RESTful bằng cách sử dụng giao thức đó, vì REST !=HTTP.

AMQP cũng thực hiện tốt hơn rất nhiều so với HTTP.