Aprenda como é possível integrar o WebSphere Message Broker na topologia HTTP e as consequências de diferentes configurações no balanceamento de carga, failover e administração.
A configuração do
WebSphere Message Broker em cada cenário descrito neste tópico está intimamente ligada à sua
escolha do listener de HTTP. É possível escolher entre listeners de todo o broker e listeners do grupo
de execução (integrados). Para compreender as diferenças entre esses listeners, como configurá-los e como as portas são
alocadas para eles, consulte
Listeners HTTP.
Aprenda sobre topologias de HTTP comuns e como configurar o
WebSphere Message Broker em cada caso. Compreenda as implicações de sua opção de configuração de topologia e do
broker.
Os cenários a seguir são listados a fim de aumentar a complexidade.
- Cenário um: máquina única, broker único; facilidade de uso é a prioridade mais alta; balanceamento de carga é relativamente importante; failover da máquina e alto rendimento não são altas prioridades
Esse cenário usa um listener de broker inteiro, atendendo na porta 7080 e toda a comunicação de HTTP dos clientes é processada por esse listener. O balanceamento de carga é obtido pela existência de instâncias adicionais de fluxos de mensagens dentro dos grupos de execução e usando a mesma URL nos fluxos de mensagens em todos os grupos de execução.
Forças:- Simplicidade de administração e descoberta de serviços da web: todas as solicitações de entrada
(e quaisquer respostas) são roteadas por meio de uma única porta para HTTP (e uma segunda para HTTPS, se necessário).
- Balanceamento de carga por meio de fluxos de mensagens e grupos de execução: uma solicitação para um serviço da web específico (URL) pode ser processada por qualquer fluxo de mensagens registrado para manipular essa URL. Os fluxos de mensagens (MF1, MF2) podem estar em grupos de execução separados (ExGp1, ExGp2) e as solicitações têm a carga balanceada. Como de costume, dentro de cada grupo de execução é possível implementar
instâncias adicionais de cada fluxo, conforme necessário. Essa configuração oferece
uma solução com balanceamento de carga escalável com algum grau de failover;
se um grupo de execução falhar, os outros continuam a processar a carga de trabalho
enquanto o primeiro grupo de execução é reinicializado.
Fraquezas: - Failover: há um único ponto de falha (broker ou máquina).
Se o failover da máquina estiver implementado, será complicado: a máquina secundária deverá obter o endereço IP da máquina primária.
- Particionamento de atividades: não há particionamento entre as atividades
gerenciadas pelo broker.
- Rendimento: um único listener manipula todas as mensagens HTTP e HTTPS
enviadas por meio de duas portas no broker. Esse ponto de processamento único e a
manipulação de erros podem causar gargalos se um alto rendimento de mensagens for
necessário.
- Cenário dois: máquina única, broker único; alto rendimento é a prioridade mais
alta; failover da máquina e balanceamento de carga não são altas prioridades;
Esse cenário usa listeners do grupo de execução para melhorar o rendimento da mensagem.
Forças:
- Alto rendimento: é possível implementar fluxos de mensagens em grupos de execução diferentes para que as mensagens HTTP (ou HTTPS) possam ser manipuladas por vários listeners em várias portas para atender aos requisitos de alto rendimento
- Configuração simples: esses listeners se comunicam diretamente com a rede de transporte
HTTP; nenhuma fila intermediária é necessária
- Particionamento de atividades: atividades gerenciadas pelo broker são particionadas
em grupos de execução separados
Fraquezas: - Failover: há um ponto único de falha (grupo de execução,
broker ou máquina). Se o failover da máquina estiver implementado, será complicado e dependerá de a máquina secundária obter o endereço IP da máquina primária
- Você deve incluir os nós de entrada e de resposta no mesmo fluxo de mensagens ou implementar fluxos de mensagens separados para o mesmo grupo de execução, para que
eles usem o mesmo listener; a correspondência de mensagens de entrada e de resposta
deve ser processada pelo mesma porta
- Cenário três: várias máquinas, vários brokers, failover
é a prioridade mais alta; balanceamento de carga e segurança também são importantes
Esse cenário usa listeners do broker inteiro. Há também um servidor que age como um balanceador de carga e um network dispatcher, além de simplificar a interface do cliente.
A configuração de fluxos de
mensagens e grupos de execução é replicada por vários brokers e o servidor de balanceamento de carga é configurado para gerenciar multiprocessamento de cluster de alta disponibilidade (HACMP)
em todos os brokers.
Forças:
- Balanceamento de carga: ter um servidor que age como um network dispatcher
e um balanceador de carga fornece capacidade de balanceamento de carga adicional para este cenário
- Failover: a distribuição de brokers nos sistemas permite o failover de
máquinas e brokers
- Configuração do cliente simplificado: o servidor de balanceamento de carga fornece um único ponto de contato para clientes
Fraquezas: - Complexidade: o cenário é complexo, embora a complexidade possa ser oculta dos clientes e gerenciada em locais centralizados