Quais são as considerações importantes ao alternar da arquitetura monolítica para microsserviços no .NET? [fechadas]

Estamos pensando em dividir nossos monstros monolíticos em arquitetura baseada em microsserviços progressivamente. Temos 5 equipes, cada equipe contendo 2-3 desenvolvedores de C #, pelo menos 1 desenvolvedor de banco de dados e 2 engenheiros de controle de qualidade. Além da enorme mudança de cultura e paradigma que passa de uma arquitetura monolítica para microsserviços, também existem os desafios técnicos. Gostaria de pedir à comunidade alguma sabedoria e conselhos para evitarmos cometer os mesmos erros.

Existem bons exemplos da indústria em que os microsserviços baseados no .NET foram utilizados com sucesso em um sistema de produção? Qual foi a estratégia para o seguinte?

• Org : como você organizou as soluções / projetos .NET?
• Planejamento de desenvolvimento : em termos de planejamento de desenvolvimento, como você dividiu o trabalho entre equipes? Qual foi a estratégia geral para garantir que a conformidade do contrato entre microsserviços fosse negociada entre as equipes?
• Balanceamento de carga / roteamento / gateway de API : qual era a estratégia para balanceamento de carga, redundância e dimensionamento? Você acabou de usar uma arquitetura assíncrona completa e usou uma fila para comunicação por microsserviços ou fez ponto a ponto através de um gateway de API / balanceador de carga? E porque?
• Automação de teste : como você lidou com a automação de teste. Isso, juntamente com a integração contínua, parece absolutamente necessário para a arquitetura de microsserviços. Como você fez isso?
• Implantação : como você está implantando? Uma VM / microsserviço ou um contêiner / microsserviço ou algo totalmente diferente? Como você lidou com o fato de agora ter dezenas de bancos de dados, se não mais, considerando que cada microsserviço teria seu armazenamento de dados, o que isso fez com sua infraestrutura e como seus DBAs lidaram com isso?
• Infraestrutura : como sua infraestrutura foi dimensionada com essa arquitetura. Foi super falador e você teve que ajustá-lo ou a rede o tratou sem problemas? São auto-hospedados ou na nuvem?
• Monitoramento : qual é a sua estratégia de monitoramento? Como você está acompanhando dezenas, senão centenas, de microsserviços? É principalmente através de registro e monitoramento central?

Já trabalhei em vários projetos de microsserviços. Inevitavelmente, as empresas seguiram o caminho porque sua grande abordagem de DB não pode ser ampliada ainda mais. Aqui estão minhas experiências / recomendações.

Org. Uma solução por microsserviço. pacotes nuget para bibliotecas compartilhadas

Desenvolvimento. equipes maiores 5-6 desenvolvem uma área de funcionalidade por vez. Refatorar em um serviço com interface. Substitua o serviço de memória por um cliente para o microsserviço.

Teste. testes de integração usando dados reais de entrada / saída. Você deseja acioná-los contra qualquer instância em execução para verificar se estão ativas e corretas, instâncias locais, ambientes de teste / uat e em instâncias de memória para teste de unidade. Verifique se você pode testar a versão da instância por meio de uma interface de verificação de integridade ou similar

Dimensionamento. Baseado em fila é melhor, pois pode lidar com processos distribuídos em vários estágios. Rabbit MQ, Zero MQ, MSMQ etc. Mas os serviços REST com balanceamento de carga são bons para chamadas no estilo rpc e podem ser um ponto de partida fácil.

Desdobramento, desenvolvimento. Polvo. projetos db, auto-criando no-sql.dbs como o Mongo. Embora eu ache que você está seguindo o caminho errado se tiver vários dbs. Em vez disso, tenha mensagens pesadas que contêm os dados necessários para o processo e alguns dbs maiores para armazenamento de dados ocultos atrás de suas próprias APIs.

Sem DBAs! Se você tem um DBA wrting sql, está fazendo errado.

A infraestrutura. Sem problemas. Leia de uma fila. Faça processo. Escreva para uma fila. Você pode se safar de mais de uma instância por caixa, mesmo nas micro instâncias da nuvem, para serviços pequenos ou raramente chamados

Monitoramento. As interfaces de verificação de integridade para todos os serviços chamados regularmente, monitorando o software e em alta escala.

O failover e a recuperação automáticos são importantes; as instâncias devem girar quando necessário e não ter estado, para que uma falha não mantenha o serviço offline.

O principal problema não é a queda de muitos serviços, pois a própria natureza dos microsserviços os torna robustos nesse aspecto. É como você lida com mensagens que não podem / não foram processadas.

Use logstash ou similar para acompanhar o fluxo de mensagens e descobrir onde e quais são os problemas. Verifique se você pode executar novamente as mensagens com falha, para que um processo fixo possa continuar de onde parou.

Nota final. versão tudo, dlls, pepitas, dados, interfaces. Com várias instâncias de vários serviços e mensagens históricas flutuando, pode ser uma das principais causas de problemas.

Nos últimos 2 anos, dividimos um monólito em microsserviços, então aqui estão algumas das coisas que estamos fazendo

Organização : cada serviço será uma solução por si só, sem projetos comuns com qualquer outro serviço. E acabamos os contratos sendo uma solução separada por si só, onde cada versão é um pacote .nuget.

Desenvolvimento : cada equipe estava trabalhando em uma parte do aplicativo, para cada novo serviço que começamos com a criação do contrato e, em seguida, separamos o serviço, mas ainda o mantemos parte do aplicativo / solução principal (portanto, nenhuma chamada HTTP ainda). E em uma etapa futura, separaríamos totalmente esse serviço.

Roteamento : todos os nossos serviços estão atrás de um balanceador de carga e cada serviço é implantado em algumas vms. Estamos compartilhando a mesma VM para vários serviços. Ir com uma VM por serviço me pareceu um desperdício de recursos, porque os serviços são pequenos, enquanto uma VM do Windows precisa de cerca de 2G para funcionar bem. Alguns serviços que não estão relacionados à interação do usuário (como o envio de e-mails / notificações) estão funcionando com filas.

Teste : Inicialmente, pensamos que a unidade de teste do serviço e a compatibilidade de contratos entre diferentes versões dos clientes e o serviço com o Pact.Net seriam suficientes. Mas tivemos problemas quando uma nova versão de um serviço não foi implantada e trabalhamos com a anterior. Todos os testes foram aprovados, mas a plataforma inteira não estava funcionando bem. Então, adicionamos alguns testes de alto nível (integração) nos principais fluxos.

Implantação : toda a plataforma está instalada em algumas vms, estamos usando uma combinação de TFS para compilação, AWS S3 para artefatos, Ansible para criação, implantação e configuração de vm. O Ansible desempenha um grande papel aqui, é sem agente e usa o sistema remoto do PowerShell para conectar-se ao Windows. Paramos de usar a transformação xml de web.config e nos mudamos para modelos Ansible, para que possamos ter toda a configuração nos arquivos Ansible. E a parte boa é de código aberto e gratuito, comparando com o polvo. Vms completamente novos são usados ​​para novas versões; atualizamos os serviços apenas quando precisamos implantar correções.

Escalonamento : nessa implantação, você pode escalar apenas o vms e não o serviço em si. Portanto, monitore seu desempenho (CPU, RAM), número de solicitações que você recebe ou mesmo com base no tempo (como no final de semana, há menos tráfego), você inicia e interrompe novos vms

Monitoramento : estamos na AWS e temos o CloudWatch para alertas de séries temporais, mas estamos planejando ir para Grafana e Prometheus (um passo a mais para ir ao docker, agora com o Server 2016). No registro, estamos usando o Graylog (que está usando o ElastiSearch atrás). Era fácil adotá-lo, porque estamos estavam usando Log4Net com appenders arquivo antes e há uma appender especialmente para Graylog. Você pode criar muitos alertas com base nele, percebemos que, na verdade, é um processo contínuo.