Dicas de SOA - resolva gargalos de escalabilidade com cache distribuído

Por Iqbal Khan

Após a explosão de aplicativos da Web para acomodar o uso de alto tráfego, a próxima grande onda tornou-se a arquitetura orientada a serviços (SOA). A SOA está destinada a se tornar uma maneira padrão de desenvolver aplicativos extremamente escaláveis, e as plataformas de computação em nuvem como o Windows Azure representam um salto gigantesco na movimentação da SOA para atingir esse objetivo.

A SOA permite que os usuários distribuam aplicativos para vários locais, vários departamentos dentro de uma organização e vários negócios pela Internet. Além disso, permite a reutilização de código existente dentro de uma organização e, mais importante, a colaboração entre diferentes unidades de negócios.

Um aplicativo SOA geralmente é implantado em um farm de servidores em um ambiente com balanceamento de carga. O objetivo é permitir que o aplicativo lide com tanta carga quanto você joga nele. A questão então se torna: Quais são algumas das considerações que você deve ter em mente para melhorar o desempenho e a escalabilidade de seu aplicativo SOA?

Embora SOA, por design, se destine a fornecer escalabilidade, há muitos problemas que você deve resolver antes de realmente alcançar a escalabilidade. Alguns desses problemas envolvem como você codifica seu aplicativo SOA, mas os gargalos mais importantes geralmente estão relacionados a como você armazena e acessa seus dados. Vou explorar esses problemas e fornecer algumas soluções neste artigo.

Encontre gargalos de escalabilidade

Um verdadeiro aplicativo SOA deve ser facilmente dimensionado no que diz respeito à arquitetura do aplicativo. Uma aplicação SOA possui dois componentes: componentes de serviço e aplicações cliente. A aplicação cliente pode ser uma aplicação Web, outro serviço ou qualquer outra aplicação que dependa dos componentes do serviço SOA para realizar seu trabalho.

Uma das principais ideias por trás da SOA é dividir a aplicação em pequenos pedaços para que esses componentes possam ser executados em vários servidores como serviços separados.

Idealmente, estes serviços deveriam ser, tanto quanto possível, apátridas. Sem estado significa que eles não retêm nenhum dado em várias chamadas, permitindo que você execute os serviços em vários computadores. Não há dependência de onde os dados estavam da última vez, portanto, não há dados sendo mantidos em nenhum servidor específico durante várias chamadas de serviço.