Existem muitas vantagens nos microsserviços. Se alguém nunca ouviu falar da arquitetura de microsserviços, pode aprender mais sobre ela aqui . Este artigo fala principalmente sobre se vale a pena refatorar a arquitetura monolítica em uma arquitetura de microsserviço.
Arquitetura de microsserviço é um estilo arquitetônico que foca na eficiência de P&D de software, principalmente incluindo a realização de mais funções por unidade de tempo, ou todo o processo de entrega contínua de software, da ideia à online. No ambiente atual da Internet, mudanças rápidas nos negócios também promoveram a popularização da arquitetura de microsserviços. Essa estrutura obriga a equipe a reagir rapidamente e implementá-la rapidamente, foi colocada em operação antes que o plano expirasse e resistiu a inspeções e testes de mercado.
Actualmente, a maior parte das empresas nacionais são sistemas operativos com uma arquitectura única e é inegável que estes sistemas têm desempenhado um papel insubstituível no processo de desenvolvimento da empresa, garantindo o normal funcionamento da empresa e criando muito valor. No entanto, com a expansão gradual do sistema, funções cada vez mais integradas, a eficiência do desenvolvimento torna-se cada vez menor e leva cada vez mais tempo para uma função ir da ideia à realização. Mais seriamente, devido ao emaranhado de módulos de código, muitas arquiteturas antigas ou funções obsoletas se tornaram obstáculos para novas funções.
Como todos sabemos, com o aumento de funções em uma única arquitetura, é inevitável que a eficiência de P&D diminua: o ciclo de P&D torna-se mais longo e o uso de recursos de P&D aumenta. A situação resultante é: o tempo de treinamento de novos funcionários aumenta, os funcionários trabalham mais horas extras, os funcionários pedem aumentos salariais ou mudam de emprego. Quando isso acontece, significa que a arquitetura monolítica não pode mais atender às necessidades de desenvolvimento empresarial, neste momento é necessário atualizar a arquitetura para melhorar a eficiência de P&D, como a arquitetura de microsserviços.
Para ilustrar os benefícios da arquitetura de microsserviço, você pode usar uma analogia. Construímos uma estação espacial. Para isso, precisamos transportar pessoas, mercadorias e equipamentos até a estação espacial. No momento, os veículos de lançamento são uma escolha melhor. Embora os veículos de lançamento sejam caros, eles são lançados em intervalos de alguns meses. Capazes para atender a demanda. Com a expansão da estação espacial, o intervalo entre os lançamentos de foguetes ficou mais curto, o custo de transporte é ridiculamente alto e ela está cada vez mais incapaz de atender às necessidades operacionais da estação espacial. Neste momento, você pode tentar outra maneira, por exemplo, o elevador espacial. Claro, o custo de um elevador espacial é maior do que o custo de um vôo, mas enquanto ele for concluído, o custo futuro será muito reduzido.
Essa metáfora também ilustra as boas expectativas trazidas pelos microsserviços e também ilustra um problema.A implementação da arquitetura de microsserviços trará um grande investimento. Portanto, precisamos pensar antes de construir o elevador espacial, precisamos muito desse tipo de investimento, senão pode ser um desperdício.
Ser ou não ser
Ao decidir fazer o upgrade de uma arquitetura monolítica para uma arquitetura de microsserviço, primeiro pergunte-se o seguinte:
- Se o produto ou sistema foi testado pelo mercado
- Você precisa de mais de uma equipe para garantir o lançamento do produto
- O sistema tem altos requisitos de confiabilidade e escalabilidade
Arquitetura de microsserviço
O que é uma arquitetura de microsserviço? Sam Newman acredita que é: "Um conjunto de serviços pequenos e autônomos que são modelados em torno do domínio de negócios e funcionam juntos".
Os serviços na arquitetura de microsserviço são módulos de negócios extraídos com base em recursos de negócios, desenvolvidos e implantados de forma independente, mas precisam cooperar uns com os outros para completar a função de negócios inteira. O serviço não é apenas um componente de armazenamento de dados, é um banco de dados. Não é apenas uma unidade de função lógica, é uma função. Somente incluindo dados + lógica ao mesmo tempo, é um serviço no verdadeiro sentido.
Limite de serviço
No processo de desmontagem do serviço, DDD (Domain Driven Design) pode ser usado como uma diretriz para a arquitetura de microsserviço. Como os microsserviços definem serviços em torno de funções de negócios e definem equipes com base em serviços, isso é exatamente o mesmo que a metodologia DDD de desmontar domínios de negócios em subdomínios de negócios e definir contextos definidos, então o DDD, como uma diretriz para microsserviços, define rapidamente vários componentes de serviço Conclua a migração da arquitetura monolítica para a arquitetura de microsserviço.
Alberto Brandolini propôs o método de identificação do contexto do serviço denominado "Event Storming". A primeira etapa é identificar eventos que ocorrem no domínio do negócio, ou seja, nosso foco está no comportamento, não na estrutura de dados. A vantagem disso é que os diferentes serviços no sistema são fracamente acoplados e um único serviço pode ser autônomo.
Depois que o lado do serviço é definido, o limite da transação precisa ser definido. No passado, nosso serviço estava em um processo com um banco de dados por trás dele, e a transação poderia escolher uma transação de consistência forte, ou seja, ACID. Quando os serviços aumentam e cooperam entre si, a eventual transação de consistência pode ser usada neste momento, que é BASE. Ao contrário do ACID, o BASE é mais flexível, desde que os dados possam ser mantidos consistentes no final. Esse intervalo de tempo final, dependendo dos diferentes cenários de negócios, pode ser minutos, horas, dias ou mesmo semanas ou meses.
Pronto para trabalhar
A visão da arquitetura de microsserviço é bela, uma arma pesada com muitas vantagens e desvantagens óbvias. Com o aumento dos serviços, aumenta a dificuldade de operação e manutenção e aumenta a dificuldade de depuração de erros. Portanto, construção, configuração, teste e implantação automatizados são necessários, e ferramentas como coleta de logs, monitoramento de indicadores e monitoramento de cadeia de chamadas são necessárias, o que significa que as práticas de DevOps são necessárias. O método de trabalho de três etapas para realizar DevOps explica as três etapas para realizar a cultura DevOps.
Além da base acima mencionada, também é necessário determinar como os serviços são integrados e como chamar uns aos outros no estágio inicial.Também é necessário determinar o sistema de dados, incluindo a consistência das transações e métodos de confiabilidade dos dados. À medida que os serviços aumentam, muitos componentes, como gerenciamento de configuração e descoberta de serviço, também são necessários. Consulte o trabalho de infraestrutura de microsserviços para os componentes básicos específicos necessários .
Esses serviços e projetos básicos são mais bem definidos no início da manhã, caso contrário, mais recursos serão necessários para melhorar a arquitetura posteriormente. Se estiver faltando no estágio inicial e não for compensado no estágio posterior, o resultado será o fracasso da migração da arquitetura de microsserviço, e o sistema final é apenas uma arquitetura monolítica coberta por microsserviços.
Evolução ou revolução?
Depois de definir o limite de serviço, ainda há um problema que precisa ser resolvido: evoluir e atualizar gradualmente o sistema ou reconstruir todo o sistema.
O segundo método é muito tentador e está mais de acordo com o pensamento da maioria dos programadores.O sistema não é bom e é reconstruído, chamado refatoração. Mas, na maioria dos casos, essa abordagem não pode ser permitida, porque o mercado está mudando rapidamente e a concorrência é feroz, e a maioria das empresas não vai parar seus negócios e esperar para reconstruir um sistema que pode funcionar, mas tem algumas deficiências. Portanto, extrair e atualizar gradualmente o sistema é rei, e a maioria das empresas também pode aceitá-lo. Este método também é denominado modo de estrangulamento.
Transformação
Como fazer a transição gradual para a arquitetura de microsserviço? Vamos mostrar passo a passo:
[Falha na transferência da imagem do link externo. O site de origem pode ter um mecanismo de link anti-leech. Recomenda-se salvar a imagem e carregá-la diretamente (img-iMdUUCj7-1584889654137) (https://www.howardliu.cn/images/ microservice / from_monolith_to_microservice_0.png)]
A primeira etapa é separar a camada de visão do usuário da camada de serviço. A lógica de negócios é delegada à camada de serviço e a consulta exibida na página tem suporte para ser direcionada ao banco de dados. Neste estágio, não modificamos o próprio banco de dados.
Na segunda etapa, a camada de visão do usuário é completamente separada do banco de dados, contando com a camada de serviço para operar o banco de dados.
[Falha na transferência da imagem do link externo. O site de origem pode ter um mecanismo de link anti-leech. Recomenda-se salvar a imagem e enviá-la diretamente (img-Iiu0S778-1584889654138) (https://www.howardliu.cn/images/ microservice / from_monolith_to_microservice_2.png)]
A terceira etapa é dividir a camada de visão do usuário e a camada de serviço em serviços diferentes e criar uma camada de API na camada de serviço para se comunicar entre a camada de visão do usuário e a camada de serviço.
A quarta etapa é dividir o banco de dados, dividir dados de negócios diferentes em bancos de dados diferentes e dividir a camada de serviço de negócios correspondente em serviços diferentes. A camada de visualização do usuário se comunica com os componentes API de diferentes camadas de serviços de negócios por meio de um gateway API. Neste momento, você precisa prestar atenção, se a equipe não tiver experiência em desenvolvimento de microsserviço, você pode primeiro extrair serviços de domínio de negócios simples, porque o negócio é simples e a implementação é simples, para que você possa praticar e acumular experiência.
A última etapa é dividir a camada de visualização do usuário.
[Falha na transferência da imagem do link externo. O site de origem pode ter um mecanismo anti-hotlink. Recomenda-se salvar a imagem e carregá-la diretamente (img-BjwOquVB-1584889654139) (https://www.howardliu.cn/images/microservice /from_monolith_to_microservice_5.png)]
A vantagem do modelo de estrangulamento é que podemos ajustar o plano a qualquer momento conforme o negócio muda, sem interromper todo o processo de evolução do negócio.
Critérios de sucesso
Quando tivermos concluído todo o processo de atualização, precisamos verificar se alcançamos os resultados esperados. O objetivo da introdução de microsserviços é primeiro melhorar o processo de desenvolvimento, que pode ser medido por indicadores simples:
- Ciclo de desenvolvimento: a duração do conceito ao lançamento
- Eficiência de desenvolvimento: funções ou histórias de usuários concluídas por equipes ou indivíduos dentro do tempo da unidade
- Escalabilidade do sistema
- Tempo médio de reparo: o tempo necessário para encontrar e solucionar problemas
Comparando esses valores característicos da arquitetura antiga e da nova arquitetura, o efeito do processo de atualização pode ser avaliado. Claro, esses indicadores devem ser monitorados durante o processo de atualização.
coisa mais importante
Como um leão de cerco, temos orgulho de poder resolver ou melhorar o mundo ao nosso redor e somos obcecados em fornecer soluções. Ao mesmo tempo, devemos também perceber que todo esforço que fazemos deve ser recompensado. Refatorar e atualizar que não traz nenhuma recompensa é uma perda de tempo.
Página pessoal: https://www.howardliu.cn
postagem no blog pessoal: da arquitetura monolítica à arquitetura de
microsserviço Página inicial CSDN: http://blog.csdn.net/liuxinghao
Postagem do blog CSDN: da arquitetura monolítica à arquitetura de microsserviço