Arquitetura lógica versus arquitetura física
Gorjeta
Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Neste ponto, é ú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ços.
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ços. Esses microsserviços também podem ser executados como processos simples. Microsserviços é uma arquitetura lógica.
Além disso, mesmo quando um microsserviço pode ser fisicamente implementado como um único serviço, processo ou contêiner (para simplificar, essa é a abordagem adotada na versão inicial do eShopOnContainers), essa paridade entre microsserviço empresarial e 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é centenas de serviços.
É aqui que há uma diferença entre a arquitetura lógica de um aplicativo e a arquitetura física. A arquitetura lógica e os limites lógicos de um sistema não necessariamente mapeiam um para um para a arquitetura física ou de implantação. Pode acontecer, mas muitas vezes não acontece.
Embora você possa ter identificado determinados microsserviços de negócios ou contextos limitados, isso não significa que a melhor maneira de implementá-los seja sempre criando um único serviço (como uma API Web ASP.NET) ou um único contêiner do Docker para cada microsserviço de negócios. Ter uma regra dizendo que cada microsserviço empresarial deve ser implementado usando um único serviço ou contêiner é muito rígido.
Portanto, um microsserviço de negócios ou Contexto Delimitado é 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 de negócios do catálogo pode ser composto por vários serviços ou processos. Estes podem ser vários ASP.NET serviços de API Web ou qualquer outro tipo de serviços usando HTTP ou qualquer outro protocolo. Mais importante ainda, os serviços podem partilhar os mesmos dados, desde que sejam coesos em relação ao mesmo domínio de negócio.
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 alvo os mesmos dados que o serviço de Pesquisa. Portanto, na implementação física do microsserviço empresarial, 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 da Web geralmente precise de mais instâncias do que o serviço de Pesquisa, ou vice-versa.
Em resumo, 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, este será um serviço único, mas pode ser mais.
