Analyse de robustesse

Particione o Sistema Funcionalmente.Particionamento Funcional foi um dos primeiros pas- sos realizados. Foram identificadas as funcionalidades mais relacionadas que foram agrupadas com o objetivo de criar subsistemas coesos que pudessem ser escalados separadamente. Os principais subsistemas identificados foram o Receptor e o Motor de Processamento, que juntos têm responsabilidade pela maioria dos requisitos funcionais.

Ao invés de dois subsistemas poder-se-ia ter feito apenas um módulo que agregasse todas as funcionalidades, entretanto decidiu-se separar as funcionalidades consideradas de suporte ao processamento no módulo Receptor e o processamento em si em outro módulo, pois as necessidades computacionais das atividades realizadas em cada módulo são diferentes; o pro- cessamento dos dados das requisições exige mais memória e capacidade de processamento.

A intenção também era que o Receptor fosse uma barreira de proteção para o módulo de Motor de Processamento. Os módulos Coletor de Logs e Pós-processador não surgiram a partir do particionamento funcional, mas sim como uma resposta à necessidade de desempenho e escalabilidade (estes módulos serão discutidos mais a frente).

Particione o Sistema Horizontalmente para distribuir a carga.Todos os módulos do sistema foram construídos para não armazenarem estado, assim qualquer módulo é capaz de atender a

134 Capítulo 5. Exemplo de uma Arquitetura de um Sistema Escalável

uma requisição, sem a necessidade dos usuários estarem “amarrados” a uma instância. Na seção sobre a aplicação do padrão Shared Nothing haverá uma mais detalhada discussão deste tópico.

Particione o sistema funcionalmente e horizontalmente. Como foi apresentado nas duas diretrizes anteriores o sistema foi particionado funcional e horizontalmente, dando ao sistema o melhor dos dois.

Faça balanceamento da carga de trabalho. Para balancear as requisições, decidiu-se pelo uso de um hardware balanceador de cargas. Seu uso é feito para balancear as requisições dos usuários enviadas ao Receptor e as requisições delegadas pelos Receptores para os Motores de Processamento. O módulo Coletor de Logs é o responsável pelo balanceamento de carga dos Pós-processadores.

Faça com que os nós de processamento sejam os mais independentes possíveis. Para pro- cessar uma requisição, a única dependência reside entre os módulos ‘Receptor’ e ‘Motor de Processamento’, que mesmo assim possui baixo acoplamento. O Receptor apenas delega a requisição. Cada um dos módulos é capaz de tomar decisões sem a necessidade de entrar em acordo com outros módulos. Por exemplo, para realizar um processamento o Motor de Proces- samentos não precisa se comunicar com outras instâncias dele mesmo ou algum outro módulo para então poder tomar uma decisão sobre o processamento de uma transação.

Construa o sistema objetivando um baixo acoplamento. Todos os módulos possuem baixo acoplamento uns com os outros. O acoplamento entre Receptor e Motor de Processamento é apenas para que um delegue trabalho para outro. O Receptor salva em disco os logs dos pro- cessamentos que são depois consumidas pelo Coletor de Logs e Pós-processador de transações. Os caches distribuídos são utilizados apenas como armazenamento em memória.

Use comunicação assíncrona. Todas as comunicações entre Receptor e Motor de Proces- samento, Receptor e camada de caches e Motor de Processamento e caches distribuídos são assíncronas. A única comunicação síncrona é com os bancos de dados.

Evite o uso de transações distribuídas.Todas as transações realizadas são locais, transações distribuídas são utilizadas em um único local, no Pós-processador. O Receptor e o Motor de Pro- cessamentos têm integração com alguns outros sistemas externos (que não podem ser apresen- tados aqui) e nenhuma destas transações é distribuída. No Pós-processador o uso de transações distribuídas é feito devido à facilidade de implementação e não há a necessidade de se ter o mais alto desempenho possível, já que é um módulo que processa as transações em segundo plano de maneira assíncrona e desacoplado dos processamentos de requisições e não há problema se este processamento não for imediato.

5.4. Aplicabilidade dos Padrões e Diretrizes 135

Faça a maior quantidade de trabalho possível de maneira assíncrona. Duas atividades im- portantes foram retiradas do fluxo principal do sistema e são feitas de maneira assíncrona: o armazenamento das transações e a atualização da base histórica de informações. Estas duas operações têm um custo computacional e de I/O altos e, do ponto de vista dos requisitos de negócios, fazê-las no momento do atendimento de uma requisição não afetaria o negócio. Além disso, o requisito de ter um tempo de resposta pequeno é mais importante, por isso estas ativi- dades são feitas em segundo plano de maneira assíncrona.

Faça um uso correto de cache. As duas camadas de cache do sistema são utilizadas apenas como um mecanismo de armazenamento distribuído em memória, evitando grande parte dos acesso aos bancos de dados. O sistema funciona normalmente sem as camadas de cache.

Separe a política do mecanismo. No uso dos caches distribuídos, estes são usados apenas como mecanismo, toda a política é implementada pelos usuários dos caches. No caso do Pós- processador, a política de balanceamento de carga foi separada em um outro módulo.

Se não for possível escalar então escale ao redor. O sistema integra-se com outros mó- dulos, que não podem ser apresentados aqui, e que têm escalabilidade e desempenho impre- visíveis. Assim, o sistema foi projeto para escalar independentemente destes sistemas externos, utilizando como principais estratégias, realizar o cache dos dados destes sistemas e realizar um processamento em segundo plano assíncrono.

Planeje para um ambiente heterogêneo. O sistema foi desenvolvido em linguagem Java para que pudesse funcionar em qualquer ambiente que suporte a plataforma Java.

Use operações idempotentes. O Pós-processador é capaz de processar o mesmo arquivo de log várias vezes, sempre com o mesmo efeito, se um resultado já foi armazenado e o histórico atualizado com seus dados, pode-se processá-lo novamente com o mesmo efeito.

Escale apenas o que deve ser escalável. Dos requisitos do sistema há muitos outros que não têm a necessidade de serem altamente escaláveis. Os subsistemas web de administração, por exemplo, são aplicações web comuns com uma arquitetura de 3 camadas (Apresentação, Negócios, Acesso a dados), onde não foram aplicados padrões de escalabilidade além de uma arquitetura Shared Nothing e caches locais. O módulo de Pós-processador é outro que possui requisitos de escalabilidade e desempenho mais fracos, portanto foi permitido a ele o uso de transações distribuídas.

136 Capítulo 5. Exemplo de uma Arquitetura de um Sistema Escalável

5.4.2 Aplicabilidade dos padrões