Apache Camel z klastrem ActiveMQ

Question

Próbuję określić opcje łączenia w klastry mojej aplikacji ServiceMix 3.3.1/Camel 2.1/AMQ 5.3. Zajmuję się przetwarzaniem dużych ilości wiadomości i potrzebuję klastrowania dla wysokiej dostępności i poziomej skalowalności.

Oto zasadzie to, co robi mój wniosek ... protokole HTTP> QUEUE-> proces-> od bazy danych> Wątek

z ("pomost: http://0.0.0.0/inbound ") .Aby (" ActiveMQ: inboundQueue");

z ("ActiveMQ: inboundQueue maxConcurrentConsumers = 50") .process dekodowania (()) .process (transformacji()) .process (walidacji()) .process (saveToDatabase()) . to ("activemq: topic: ouboundTopic");

Tak, czytałem wszystkie strony grupujące ServiceMix i AcitveMQ, ale nadal nie jestem pewien, w którą stronę pójść.

Wiem, że mogę używać konfiguracji Master/Slave dla HA, ale to nie pomaga w skalowalności.

Przeczytałem o sieci brokerów, ale nie jestem pewien, w jaki sposób ma to zastosowanie. Na przykład, jeśli rozmieszczę identyczne trasy wielbłądów na wielu węzłach w klastrze, w jaki sposób będą one "współdziałać" dokładnie? Jeśli wskażę mojego producenta HTTP w jednym węźle (NodeA), które wiadomości zostaną wysłane do NodeB? Czy kolejki/tematy będą wspólne dla Węzła A/B ... jeśli tak, to czy wiadomości są dzielone lub duplikowane? W jaki sposób klient zewnętrzny subskrybowałby mój "outboundTopic" dokładnie (i otrzymywałby wszystkie wiadomości, itp.)?

Alternatywnie, myślałem, że powinienem po prostu udostępniać brokera między wieloma instancjami ServiceMix. Byłoby to czystsze, ponieważ byłby tylko jeden zestaw kolejek/tematów do zarządzania i mogłem skalować, dodając więcej instancji. Ale teraz ograniczam się do skalowalności pojedynczego brokera i wracam do pojedynczego punktu awarii ...

Jeśli ktoś może wyjaśnić mi kompromisy ... Byłbym wdzięczny .

Answer 1

Istnieje wiele strategii zwiększania skali podczas korzystania z ServiceMix/Camel/ActiveMQ. Ponieważ każde oprogramowanie oferuje tak wiele opcji, istnieje wiele różnych ścieżek, które można zastosować w zależności od tego, jaka część aplikacji ma być skalowana. Poniżej znajduje się lista wysoki poziom kilku strategii:

• Zwiększenie liczby przychodzących instancji Jetty - Wymaga to począwszy więcej wystąpień serwera WWW i albo żądania równoważenia obciążenia w poprzek wielu instancji lub wystawiając wiele adresów URL i wysyłanie wszystkie żądania do tej samej kolejki wejściowej w ActiveMQ.

• Zwiększ liczbę instancji ActiveMQ - uruchamiając dodatkowe instancje ActiveMQ i łącząc je w sieć, tworzysz sieć brokerów. W niektórych kręgach jest to określane jako kolejki rozproszone, ponieważ dana kolejka może zostać udostępniona wszystkim brokerom w sieci. Ale jeśli zamierzasz uruchomić wiele instancji ActiveMQ, powinieneś rozważyć uruchomienie dodatkowych instancji ServiceMix.

• Zwiększ liczbę instancji ServiceMix - Każda instancja ServiceMix osadza instancję ActiveMQ. Zwiększając liczbę wystąpień ServiceMix, nie tylko zwiększasz liczbę instancji ActiveMQ (które mogą być połączone w sieć w celu utworzenia sieci brokerów), ale także możesz wdrożyć więcej kopii aplikacji w tych wystąpieniach ServiceMix .Jeśli potrzebujesz zwiększyć liczbę instancji ActiveMQ lub ServiceMix, możesz wdrożyć aplikację zużywającą z odpowiednią liczbą jednoczesnych klientów dla każdej instancji. Wiadomości nie są dzielone ani duplikowane, są dystrybuowane w sposób okrągły dla wszystkich konsumentów w kolejce, niezależnie od tego, gdzie się znajdują, w oparciu o zapotrzebowanie klientów. Oznacza to, że jeśli jedna instancja ActiveMQ w sieci nie ma klientów, nie będzie miała żadnych komunikatów dotyczących instancji kolejki, która ma zostać zużyta. Prowadzi to do mojej ostatniej sugestii, zwiększając liczbę konsumentów odpytujących kolejkę wejściową.

• Zwiększenie liczby klientów JMS w kolejce przychodzących - jest to prawdopodobnie najłatwiejszy, najpotężniejszy i najłatwiejszy w zarządzaniu sposób zwiększenia przepustowości. Jest to najłatwiejsze, ponieważ wdrażasz dodatkowe instancje aplikacji zużywającej, aby konkurować o komunikaty z kolejki wejściowej (niezależnie od tego, czy konkurują o lokalną kolejkę, czy kolejkę dystrybuowaną przez sieć brokerów). Może to być tak proste, jak zwiększenie liczby równoczesnych klientów lub nieco bardziej zaangażowane poprzez rozdzielenie części aplikacji zawierającej klientów i wdrożenie jej w wielu instancjach ServiceMix. Jest najpotężniejszy, ponieważ zwykle nie jest trudny, a aplikacje oparte na zdarzeniach ze skalowaniem zawsze odbywają się poprzez zwiększenie liczby użytkowników. Jest to najłatwiejsze w zarządzaniu, ponieważ masz możliwość zmiany sposobu pakowania aplikacji, dzięki czemu aplikacja zużywająca jest całkowicie oddzielna, co umożliwia dystrybucję.

Ta ostatnia propozycja to najpotężniejszy sposób na skalowanie aplikacji. Tak długo, jak przychodzący punkt końcowy HTTP może obsługiwać duży ruch, może być konieczne zwiększenie liczby klientów w kolejce wejściowej. Wielkim tego powodem jest to, że albo konsumenci, albo fasola, z której pochodzą, wykonują wszystkie ciężkie operacje, znaczną ilość przetwarzania i walidacji. Zazwyczaj jest to proces, który ostatecznie potrzebuje najwięcej zasobów.

Mamy nadzieję, że dostarcza to informacji potrzebnych do rozpoczęcia pracy w jednym kierunku lub ewentualnie kilku, w zależności od tego, która część aplikacji rzeczywiście jest potrzebna do skalowania. Jeśli masz jakieś pytania, daj mi znać.

Bruce