Zaawansowana obsługa protokołu KOLEJKOWANIA komunikatów (AMQP) 1.0 w usłudze Service Bus
Usługa w chmurze usługi Azure Service Bus używa protokołu AMQP 1.0 jako podstawowego środka komunikacji. Firma Microsoft jest zaangażowana w partnerów w całej branży, zarówno klientów, jak i dostawców konkurencyjnych brokerów obsługi komunikatów, aby rozwijać i rozwijać protokół AMQP w ciągu ostatniej dekady, a nowe rozszerzenia są opracowywane w komitecie technicznym OASIS AMQP. AMQP 1.0 jest normą ISO i IEC (ISO 19464:20149).
Protokół AMQP umożliwia tworzenie międzyplatformowych aplikacji hybrydowych przy użyciu neutralnego od dostawcy i neutralnego od implementacji otwartego protokołu standardowego. Aplikacje można tworzyć przy użyciu składników, które są tworzone przy użyciu różnych języków i struktur oraz które działają w różnych systemach operacyjnych. Wszystkie te składniki mogą łączyć się z usługą Service Bus i bezproblemowo wymieniać ustrukturyzowane komunikaty biznesowe wydajnie i w pełni wierność.
Wprowadzenie: Co to jest AMQP 1.0 i dlaczego jest to ważne?
Tradycyjnie produkty pośredniczące zorientowane na komunikaty używały zastrzeżonych protokołów do komunikacji między aplikacjami klienckimi i brokerami. Oznacza to, że po wybraniu brokera obsługi komunikatów określonego dostawcy należy użyć bibliotek tego dostawcy, aby połączyć aplikacje klienckie z tym brokerem. Powoduje to zależność od tego dostawcy, ponieważ przenoszenie aplikacji do innego produktu wymaga zmian kodu we wszystkich połączonych aplikacjach. W społeczności języka Java standardy interfejsu API specyficzne dla języka, takie jak Java Message Service (JMS) i abstrakcje platformy Spring Framework, nieco złagodziły ten ból, ale mają wąski zakres funkcji i wykluczają deweloperów przy użyciu innych języków.
Ponadto łączenie brokerów obsługi komunikatów z różnych dostawców jest trudne. Zwykle wymaga mostkowania na poziomie aplikacji, aby przenosić komunikaty z jednego systemu do innego i tłumaczyć między zastrzeżonymi formatami komunikatów. Jest to typowe wymaganie; na przykład, gdy musisz podać nowy ujednolicony interfejs dla starszych różnych systemów lub zintegrować systemy IT po połączeniu. Protokół AMQP umożliwia bezpośrednie łączenie się brokerów, na przykład przy użyciu routerów, takich jak Router apache Qpid Dispatch lub natywne "łopaty" brokera, takie jak jeden z RabbitMQ.
Branża oprogramowania jest szybko poruszającym się biznesem; nowe języki programowania i struktury aplikacji są wprowadzane w czasami zdumiewającym tempie. Podobnie wymagania systemów IT zmieniają się wraz z upływem czasu, a deweloperzy chcą korzystać z najnowszych funkcji platformy. Jednak czasami wybrany dostawca obsługi komunikatów nie obsługuje tych platform. Jeśli protokoły obsługi komunikatów są zastrzeżone, nie jest możliwe, aby inne osoby udostępniały biblioteki dla tych nowych platform. W związku z tym należy użyć metod, takich jak tworzenie bram lub mostków, które umożliwiają dalsze korzystanie z produktu do obsługi komunikatów.
Rozwój protokołu Advanced Message Queuing Protocol (AMQP) 1.0 był motywowany tymi problemami. Pochodzi z JP Morgan Chase, który, podobnie jak większość firm usług finansowych, są ciężkimi użytkownikami oprogramowania pośredniczącego zorientowanego na wiadomości. Celem było proste: utworzenie standardowego protokołu obsługi komunikatów, który umożliwił tworzenie aplikacji opartych na komunikatach przy użyciu składników utworzonych przy użyciu różnych języków, struktur i systemów operacyjnych, a wszystko to przy użyciu najlepszych składników rasy od różnych dostawców.
Funkcje techniczne protokołu AMQP 1.0
AmQP 1.0 to wydajny, niezawodny protokół obsługi komunikatów na poziomie przewodu, którego można użyć do tworzenia niezawodnych, międzyplatformowych aplikacji do obsługi komunikatów. Protokół ma prosty cel: zdefiniowanie mechaniki bezpiecznego, niezawodnego i wydajnego transferu komunikatów między dwiema stronami. Same komunikaty są kodowane przy użyciu przenośnej reprezentacji danych, która umożliwia heterogenicznym nadawcom i odbiornikom wymianę ustrukturyzowanych komunikatów biznesowych w pełnej wierności. Oto podsumowanie najważniejszych funkcji:
- Wydajne: AMQP 1.0 to protokół zorientowany na połączenie, który używa kodowania binarnego dla instrukcji protokołu i komunikatów biznesowych przesyłanych przez nie. Obejmuje zaawansowane schematy sterowania przepływem w celu zmaksymalizowania wykorzystania sieci i połączonych składników. Oznacza to, że protokół został zaprojektowany w celu zapewnienia równowagi między wydajnością, elastycznością i współdziałaniem.
- Niezawodne: Protokół AMQP 1.0 umożliwia wymianę komunikatów z szeregiem gwarancji niezawodności, od pożaru i zapomnienia do niezawodnej, dokładnie raz potwierdzonej dostawy.
- Elastyczny: AMQP 1.0 to elastyczny protokół, który może służyć do obsługi różnych topologii. Ten sam protokół może służyć do komunikacji klient-klient, klient-broker i broker-broker.
- Niezależny model brokera: specyfikacja protokołu AMQP 1.0 nie spełnia żadnych wymagań dotyczących modelu obsługi komunikatów używanego przez brokera. Oznacza to, że można łatwo dodać obsługę protokołu AMQP 1.0 do istniejących brokerów obsługi komunikatów.
AmQP 1.0 jest standardem (ze znakiem "S")
AMQP 1.0 jest międzynarodowym standardem zatwierdzonym przez ISO i IEC jako ISO/IEC 19464:2014.
AmQP 1.0 jest w rozwoju od 2008 roku przez podstawową grupę ponad 20 firm, zarówno dostawców technologii, jak i firm użytkowników końcowych. W tym czasie firmy użytkowników przyczyniły się do rzeczywistych wymagań biznesowych, a dostawcy technologii ewoluowali protokół, aby spełnić te wymagania. W całym procesie dostawcy uczestniczyli w warsztatach, w których współpracowali, aby zweryfikować współdziałanie między ich implementacjami.
W październiku 2011 r. prace programistyczne przeszły do komitetu technicznego organizacji na rzecz rozwoju ustrukturyzowanych standardów informacyjnych (OASIS) i OASIS AMQP 1.0 Standard został wydany w październiku 2012 roku. Następujące firmy uczestniczyły w komitecie technicznym podczas opracowywania standardu:
- Dostawcy technologii: Axway Software, Huawei Technologies, IIT Software, INETCO Systems, Kaazing, Microsoft, Mitre Corporation, Primeton Technologies, Progress Software, Red Hat, SITA, Software AG, Solace Systems, VMware, WSO2, Zenika.
- Firmy użytkowników: Bank of America, Credit Suisse, Deutsche Boerse, Goldman Sachs, JPMorgan Chase.
Obecne przewodniczący Komitetu Technicznego OASIS AMQP reprezentują Red Hat i Microsoft.
Niektóre z powszechnie cytowanych korzyści z otwartych standardów obejmują:
- Mniejsze prawdopodobieństwo zablokowania dostawcy
- Współdziałanie
- Szeroka dostępność bibliotek i narzędzi
- Ochrona przed przestarzałym okresem
- Dostępność kompetentnych pracowników
- Mniejsze ryzyko i możliwe do zarządzania
AmQP 1.0 i Service Bus
Obsługa protokołu AMQP 1.0 w usłudze Azure Service Bus oznacza, że można używać kolejkowania i publikowania/subskrybowania obsługiwanych przez brokera funkcji obsługi komunikatów z różnych platform przy użyciu wydajnego protokołu binarnego. Ponadto można tworzyć aplikacje składające się z składników utworzonych przy użyciu różnych języków, struktur i systemów operacyjnych.
Na poniższej ilustracji przedstawiono przykładowe wdrożenie, w którym klienci Java działający w systemie Linux, napisani przy użyciu standardowego interfejsu API usługi Java Message Service (JMS) i klientów platformy .NET działających w systemie Windows, wymiany komunikatów za pośrednictwem usługi Service Bus przy użyciu protokołu AMQP 1.0.
Rysunek 1. Przykładowy scenariusz wdrażania przedstawiający obsługę komunikatów międzyplatformowych przy użyciu usług Service Bus i AMQP 1.0
Wszystkie obsługiwane biblioteki klienta usługi Service Bus dostępne za pośrednictwem zestawu Azure SDK używają protokołu AMQP 1.0.
- Usługa Azure Service Bus dla platformy .NET
- Biblioteki usługi Azure Service Bus dla języka Java
- Dostawca usługi Azure Service Bus dla środowiska Java JMS 2.0
- Moduły usługi Azure Service Bus dla języków JavaScript i TypeScript
- Biblioteki usługi Azure Service Bus dla języka Python
Opcja protokołu AMQP-over-WebSockets działa na porcie TCP 443 podobnie jak w przypadku interfejsu API HTTP/REST, ale w przeciwnym razie jest funkcjonalnie identyczna z zwykłym protokołem AMQP. Ta opcja ma większe początkowe opóźnienie połączenia ze względu na dodatkowe uściski dłoni i nieco większe obciążenie w miarę kompromisu w przypadku udostępniania portu HTTPS. Jeśli ten tryb jest wybrany, port TCP 443 jest wystarczający do komunikacji. Poniższe opcje umożliwiają wybranie trybu protokołu WebSocket protokołu AMQP.
| Język | Opcja |
|---|---|
| .NET (Azure.Messaging.ServiceBus) | Utwórz element ServiceBusClient przy użyciu konstruktora, który przyjmuje parametr ServiceBusClientOptions . Ustaw parametr ServiceBusClientOptions.TransportType na wartość ServiceBusTransportType.AmqpWebSockets |
| .NET (Microsoft.Azure.ServiceBus) | Podczas tworzenia obiektów klienta użyj konstruktorów, które przyjmują parametry TransportType, ServiceBus Połączenie ion lub ServiceBus Połączenie ionStringBuilder. Dla konstrukcji, która przyjmuje W przypadku konstruktora, który przyjmuje Jeśli używasz |
| Java (com.azure.messaging.servicebus) | Podczas tworzenia klientów ustaw parametr ServiceBusClientBuilder.transportType na AmqpTransportType.AMQP.AMQP_WEB_SOCKETS |
| Java (com.microsoft.azure.servicebus) | Podczas tworzenia klientów ustaw transportType wartość com.microsoft.azure.servicebus.Client Ustawienia na com.microsoft.azure.servicebus.primitives.TransportType.AMQP_WEB_SOCKETS |
| JavaScript | Podczas tworzenia obiektów klienta usługi Service Bus użyj webSocketOptions właściwości ServiceBusClientOptions. |
| Python | Podczas tworzenia klientów usługi Service Bus ustaw ServiceBusClient.transport_type na Wartość TransportType.AmqpOverWebSocket |
30 września 2026 r. wycofamy biblioteki zestawu SDK usługi Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus i com.microsoft.azure.servicebus, które nie są zgodne z wytycznymi dotyczącymi zestawu Azure SDK. Zakończymy również obsługę protokołu SBMP, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu Azure SDK, które oferują krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.
Mimo że starsze biblioteki mogą być nadal używane poza 30 września 2026 r., nie będą już otrzymywać oficjalnej pomocy technicznej i aktualizacji od firmy Microsoft. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.
Ponadto można użyć usługi Service Bus z dowolnego stosu protokołu zgodnego z protokołem AMQP 1.0:
| Język | Biblioteka |
|---|---|
| Java | Apache Qpid Proton-J |
| C/C++ | Azure uAMQP C, Apache Qpid Proton-C |
| Python | Azure uAMQP for Python, Apache Qpid Proton Python |
| PHP | Azure uAMQP dla języka PHP |
| Ruby | Apache Qpid Proton Ruby |
| Go | Azure Go AMQP, Apache Qpid Proton Go |
| C#/F#/VB | AMQP .NET Lite, Apache NMS AMQP |
| JavaScript/Node | Rhea |
Podsumowanie
- AMQP 1.0 to otwarty, niezawodny protokół obsługi komunikatów, którego można użyć do tworzenia międzyplatformowych aplikacji hybrydowych. AMQP 1.0 jest standardem OASIS.
Następne kroki
Chcesz dowiedzieć się więcej? Odwiedź następujące linki: