Arquitetura lógica versus arquitetura física

Dica

Esse conteúdo é um trecho do eBook, arquitetura de microsserviços do .NET para aplicativos .NET em contêineres, disponível em do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

Neste momento, é útil parar e discutir a distinção entre arquitetura lógica e arquitetura física e como isso se aplica ao design de aplicativos baseados em microsserviço.

Para começar, a criação de microsserviços não requer o uso de nenhuma tecnologia específica. Por exemplo, os contêineres do Docker não são obrigatórios para criar uma arquitetura baseada em microsserviço. Esses microsserviços também podem ser executados como processos sem formatação. Os microsserviços são uma arquitetura lógica.

Além disso, mesmo quando um microsserviço pode ser implementado fisicamente como um único serviço, processo ou contêiner (para simplificar, essa é a abordagem adotada na versão inicial do eShopOnContainers), essa paridade entre o microsserviço empresarial e o serviço físico ou contêiner não é necessariamente necessária em todos os casos quando você cria um aplicativo grande e complexo composto por muitas dezenas ou até mesmo centenas de serviços.

É aí que há uma diferença entre a arquitetura lógica e a arquitetura física de um aplicativo. A arquitetura lógica e os limites lógicos de um sistema não necessariamente correspondem diretamente à arquitetura física ou à arquitetura de implantação. Pode acontecer, mas muitas vezes não acontece.

Embora você possa ter identificado determinados microsserviços empresariais ou Contextos Limitados, isso não significa que a melhor maneira de implementá-los é sempre criando um único serviço (como uma API Web ASP.NET) ou um único contêiner do Docker para cada microsserviço empresarial. Ter uma regra informando que cada microsserviço empresarial precisa ser implementado usando um único serviço ou contêiner é muito rígido.

Portanto, um microsserviço de negócios ou contexto limitado é uma arquitetura lógica que pode coincidir (ou não) com a arquitetura física. O ponto importante é que um microsserviço de negócios ou Contexto Delimitado deve ser autônomo, permitindo que o código e o estado sejam versionados, implantados e dimensionados de forma independente.

Como mostra a Figura 4-8, o microsserviço comercial do catálogo pode ser composto por vários serviços ou processos. Eles podem ser vários ASP.NET serviços de API Web ou qualquer outro tipo de serviço usando HTTP ou qualquer outro protocolo. Mais importante, os serviços podem compartilhar os mesmos dados, desde que esses serviços sejam coesos em relação ao mesmo domínio empresarial.

Figura 4-8. Microsserviço empresarial com vários serviços físicos

Os serviços no exemplo compartilham o mesmo modelo de dados porque o serviço de API Web tem como destino os mesmos dados que o serviço de Pesquisa. Portanto, na implementação física do microsserviço de negócios, você está dividindo essa funcionalidade para que possa dimensionar cada um desses serviços internos para cima ou para baixo conforme necessário. Talvez o serviço de API Web geralmente precise de mais instâncias do que o serviço de Pesquisa ou vice-versa.

Em suma, a arquitetura lógica dos microsserviços nem sempre precisa coincidir com a arquitetura de implantação física. Neste guia, sempre que mencionamos um microsserviço, queremos dizer um microsserviço comercial ou lógico que pode ser mapeado para um ou mais serviços (físicos). Na maioria dos casos, esse será um único serviço, mas pode ser mais.

AnteriorPróximo