🍨 🎑 👨🏽‍🚒 Microsserviços ou sistemas modulares? Como um cliente pode escolher uma abordagem para a arquitetura de TI de um produto 🐋 ↙️ 🐵

Sistemas microsserviços e modulares são tipos de arquitetura de soluções de TI.

Ao trabalhar com módulos, estamos finalizando uma versão em caixa de um produto de TI existente.

Pela versão em caixa, queremos dizer um monólito, um sistema pronto com um núcleo que é entregue a todos os clientes da mesma maneira "como está".

O refinamento consiste na criação de módulos com falta de funcionalidade.

Obtemos novos módulos reutilizando partes do monólito (núcleo ou outros módulos).
A lógica de negócios é escrita dentro do monólito: para um programa (aplicativo, site, portal), há um ponto de entrada e um ponto de saída.

Ao trabalhar com microsserviços, criamos um produto de TI do zero, compondo-o de “tijolos” - microsserviços atômicos responsáveis por um pequeno processo separado (envie uma carta, receba dados do pedido, altere o status do pedido, crie um cliente etc.).
Um conjunto desses blocos é combinado pela lógica de negócios em um sistema comum (por exemplo, usando BPMS). Apesar da presença de conexões, cada bloco é autônomo e possui seus próprios pontos de entrada e saída.

A maioria dos produtos de TI para nossos clientes começa com o desenvolvimento modular. Alguns deles evoluem ao longo do tempo para microsserviços. Por outro lado, não são necessários microsserviços. Neste artigo, examinaremos por que exatamente é assim e quais critérios ajudam a determinar se é necessário implementar microsserviços ou se você deve continuar trabalhando com módulos.

imagem

Benefícios da arquitetura modular

Todos os sistemas CMS (Bitrix, Magento, Drupal, Hybris etc.), CRM, ERP, WMS e muitos outros possuem versões in a box. Eles vendem bem e estão em alta demanda.
Vejamos essas razões objetivas pelas quais os clientes geralmente escolhem trabalhar com uma arquitetura modular e compram voluntariamente soluções em caixa.

Alta velocidade de implementação A

instalação, configuração e preenchimento de diretórios para esse software leva um pouco de tempo. É realista para uma empresa de médio porte começar a trabalhar com uma caixa três a quatro meses após o início, às vezes até um pouco antes.

Para pequenas empresas, esse período pode ser de apenas alguns dias.
. , enterprise- .
. . , , , .
,

. , .

Existem outros fatores subjetivos que podem ser enganosos e influenciar a decisão de usar caixas e módulos.

1. Corrida dos fabricantes

Os vendedores de software convencem calorosamente os clientes de que sua solução pronta é a certa: ela foi testada por anos, e na moda, e empresa, e popular e marketing ... Qualquer fornecedor: Bitrix, Magento, SAP, Oracle, OpenCart, O Django e todos os outros estão trabalhando duro em técnicas de marketing e vendas.

2. Equívoco sobre a complexidade das melhorias

Os clientes geralmente estão cheios de otimismo. Eles escolhem o software in a box e pensam: “Sim, serão necessárias melhorias. Mas é fácil: você não precisa inventar algo novo. Temos uma versão popular, mas milhões de usuários não podem cometer erros e comprar um produto ruim. ”
Na visão deles, o processo de refinamento se parece com o seguinte: existe uma funcionalidade principal (em caixa). Para "terminar" algo nele, os desenvolvedores terão que "apenas" redefinir o módulo ou escrever rapidamente seus próprios. Nesse caso, não é necessário usar métodos repetidos, porque tudo é supostamente pensado no monólito: métodos comuns para calcular impostos são prescritos, existem regras claras para escrever métodos de entrega e pagamento, fluxo de trabalho claro de pedidos etc.

Na vida real, as coisas são diferentes. E após emoções agradáveis desde o início fácil de trabalhar com a caixa, os clientes ainda enfrentam uma dura realidade. Na maioria das vezes, isso acontece com empresas de médias e grandes empresas, cujos projetos têm uma lógica de negócios exclusiva e são necessárias melhorias em larga escala.

Se sua empresa é uma pequena empresa e o software não é seu principal ativo, provavelmente uma solução popular em caixa (ou melhor - uma nuvem) é mais adequada para você.

Vejamos quais problemas você pode encontrar ao trabalhar com uma arquitetura modular e como os microsserviços ajudam a evitar isso.

Problemas de sistemas modulares

O principal problema é que todos os sistemas modulares não foram projetados para redefinir seriamente a funcionalidade. Eles têm uma caixa, módulos prontos - é melhor usá-los.

Quanto mais próximo do nível da empresa for o tamanho do projeto e a complexidade de suas personalizações, mais problemas haverá com a conclusão dos módulos. Vamos falar sobre os principais.

Problema nº 1. O núcleo do sistema se torna um ponto de desaceleração e a modularidade se torna uma complicação desnecessária.

Digamos que seu projeto esteja associado à lógica complexa do armazém. Se você escolher uma arquitetura modular, os desenvolvedores não precisam apenas criar funcionalidades para gerenciar esses armazéns - eles precisam redefinir ou expandir o módulo multicore, que, por sua vez, usa métodos de kernel.

Nesse caso, é necessário levar em consideração a lógica complexa dos retornos aos armazéns: dependência de eventos do sistema CRM, movimentação de mercadorias entre catálogos, etc. Também vale a pena considerar a lógica oculta que está associada ao retorno de fundos, pontos de bônus, etc.

Quando ocorrem muitas redefinições, o monólito muda significativamente. É importante lembrar que a relação entre o volume de novas funcionalidades e o número de módulos é não linear: para adicionar uma função, você deve fazer alterações em vários módulos, cada um dos quais altera a operação da outra, ou redefinir um grande número de métodos de outros módulos no novo módulo, que não altera a essência.

Depois de todas as alterações, o sistema se torna tão complicado que será necessário um número indecentemente grande de horas para adicionar as seguintes personalizações.

imagem

Problema nº 2. O princípio da auto-documentação não é suportado em sistemas modulares.

A documentação para sistemas modulares é difícil de manter atualizada. É muito disso, e fica desatualizado a cada mudança. O refinamento de um módulo implica alterações em vários outros documentos (no usuário, documentação técnica) e todos eles precisam ser reescritos.

Como regra, não há ninguém para fazer esse trabalho: gastar tempo com valiosos especialistas em TI nisso significa simplesmente esgotar o orçamento. Mesmo o uso de armazenamento de documentação em código (PHPDoc) não garante sua confiabilidade. No final, se a documentação puder ser diferente da implementação, ela será necessariamente diferente.

Problema nº 3. Maior coerência do código - o caminho para a regressão: "eles mudaram aqui, caiu"

Os problemas clássicos dos sistemas modulares estão na luta contra a regressão.

O desenvolvimento do TDD é difícil de usar para monólitos devido à grande coerência de diferentes métodos (você pode facilmente passar 30 linhas de testes em cinco linhas de código, além de acessórios).
Portanto, no combate à regressão, é necessário cobrir o funcional com testes de integração.
Mas, tendo em vista o desenvolvimento já lento (afinal, você precisa desenvolvê-lo com cuidado para fornecer muitas substituições), os clientes não querem pagar por testes de integração complexos.

Os testes funcionais tornam-se tão grandes quanto sem sentido. Eles correm por horas, mesmo em paralelo.

Sim, uma frente moderna como o PWA pode ser testada em termos de API. Porém, os testes geralmente dependem do recebimento de dados do circuito externo - e, portanto, começam a falhar se, por exemplo, o teste do SAP estiver atrasado no supermercado por N meses e o teste "1C" enviar dados incorretos.

Quando você precisa fazer o upload de uma edição pequena para algum módulo, os desenvolvedores devem escolher entre dois males: iniciar uma execução completa do IC e gastar muito tempo em uma implantação ou definir um hotfix sem executar um teste, correndo o risco de quebrar algo. É muito dramático quando essas edições chegam do departamento de marketing na Black Friday. Obviamente, mais cedo ou mais tarde, regressão e erro humano acontecerão. Isso é familiar?

Por fim, para cumprir os objetivos de negócios, a equipe entra no modo de operação de emergência, habilmente manipula os testes e analisa cuidadosamente os painéis dos logs - Kibana, Grafana, Zabbix ... E o que conseguimos no final? Esgotamento.

Você deve admitir que tal situação com regressão não é como a "empresa estável", como deveria estar nos sonhos e sonhos do cliente.

Edição # 4: Conectividade de código e atualização de plataforma

Outro problema com a conectividade de código é a dificuldade em atualizar a plataforma.

Por exemplo, o Magento contém dois milhões de linhas de código. Onde quer que olhemos, há muito código em todos os lugares (Akeneo, Pimcore, Bitrix). Ao adicionar funcionalidade ao kernel, seria melhor levar em consideração as alterações nos seus módulos personalizados.

Aqui está um exemplo ao vivo para o Magento.
No final de 2018, uma nova versão da plataforma Magento 2.3 foi lançada. Multistores e Elasticsearch foram adicionados à Open Source Edition. Além disso, milhares de bugs foram corrigidos no kernel e alguns brindes no OMS foram adicionados.

O que os projetos de comércio eletrônico enfrentam que já criaram multistores no Magento 2.2? Eles precisavam reescrever um monte de lógica no processamento de pedidos, checkout, cartões de produtos para usar a funcionalidade in a box. De fato, "tão certo" - por que duplicar a funcionalidade da versão em caixa nos módulos? Reduzir o volume do código personalizado em um projeto grande é sempre útil - afinal, todos os métodos de caixa levam em consideração esses multi-armazéns, e a atualização da caixa sem essa refatoração pode ser inútil (observe os problemas de segurança por simplicidade, especialmente porque eles podem ser acumulados sem atualização).

Agora imagine: quanto tempo será gasto em tal atualização e como isso pode ser testado sem testes de integração, difíceis de escrever?

Não é de surpreender que, para muitos, a atualização da plataforma ocorra sem refatoração, mas com um aumento na duplicação ou (se a equipe quiser fazer tudo pelo feng shui) com "sair" por um longo tempo na refatoração e restauração da ordem.

Problema nº 5. Opacidade dos processos de negócios

Um dos problemas mais importantes no gerenciamento de projetos é que o cliente não vê toda a lógica e todos os processos de negócios do projeto. Eles só podem ser restaurados a partir do código ou da documentação (cuja relevância, como dissemos anteriormente, é problemática de manter em sistemas modulares).

Sim, o Bitrix possui uma parte do BPM, enquanto o Pimcore possui uma visualização do fluxo de trabalho. Mas essa tentativa de gerenciar módulos através de processos de negócios sempre entra em conflito com a presença de um kernel. Além disso, eventos, cronômetros complexos, operações transacionais - tudo isso não ocorre nos monólitos do BPM. Repito: isso se aplica a empresas de médio e grande porte. Para uma empresa pequena, os recursos dos sistemas modulares são suficientes. Mas se estivermos falando sobre o segmento corporativo, essa solução ainda não possui um único centro de controle, onde você pode ver o diagrama de qualquer processo, qualquer status, exatamente como algo acontece, quais são as exceções, temporizadores, eventos e coroas . Não há oportunidade suficiente para alterar processos de negócios, mas não módulos. O gerenciamento de processos do projeto está se afogando na velocidade da mudança e na coerência da lógica.

Problema 6. Complexidade do dimensionamento do sistema

Se você implantar um monólito, ele será implantado na íntegra com todos os módulos em cada servidor de aplicativos. Essa. você não pode aumentar separadamente o serviço de processamento de pedidos e bônus em uma temporada, separadamente do restante do código.

Precisa de mais memória e processadores, o que aumenta muito o custo do cluster.

Como os microsserviços salvam os clientes das falhas típicas do desenvolvimento modular. Orquestração de microsserviços em Camunda e jBPM

Desmancha prazeres: A solução para os problemas listados no último parágrafo é possível usando BPMS e orquestrando sistemas de microsserviços.

BPMS (sistema de gerenciamento de processos de negócios em inglês) é um software para gerenciar processos de negócios em uma empresa. Os BPMS populares com os quais trabalhamos são Camunda e jBPM.

A orquestração descreve como os serviços devem interagir entre si usando o sistema de mensagens, incluindo a lógica de negócios e uma sequência de ações. Usando o BPMS, não apenas desenhamos esquemas abstratos - nosso processo de negócios será executado de acordo com o desenho. Garantimos que o que vemos no diagrama está correlacionado com o funcionamento do processo, quais microsserviços são usados, quais parâmetros, de acordo com quais tabelas de decisão, uma lógica específica é selecionada.

Como exemplo, adotamos um processo frequentemente encontrado - o envio de um pedido para entrega.

Por qualquer mensagem ou chamada direta, iniciamos o processamento de pedidos com o processo de escolha de um método de entrega. A lógica de seleção está definida.

Como resultado, processos, serviços e desenvolvimento:

tornar-se rapidamente legível;
auto-documentação (eles funcionam exatamente como são desenhados, e não há rassincronismo entre a documentação e o trabalho real do código);
apenas depurado (é fácil ver como é esse ou aquele processo e entender qual é o erro).

Vamos nos familiarizar com os princípios pelos quais os sistemas de gerenciamento de processos de negócios funcionam.

Princípio BPMS No. 1. Desenvolvimento torna-se visual e processo

O BPMS permite criar um processo de negócios no qual a equipe do projeto (desenvolvedor ou usuário comercial) determina a sequência de lançamento dos microsserviços, bem como as condições e ramificações pelas quais se move. Nesse caso, um processo de negócios (sequência de ações) pode ser incluído em outro processo de negócios.

Tudo isso é apresentado claramente no BPMS: em tempo real, você pode assistir a esses esquemas, editá-los e colocá-los de maneira produtiva. Aqui, o princípio de um ambiente de auto-documentação é cumprido ao máximo - o processo funciona exatamente como é visualizado.

Todos os microsserviços se tornam cubos de processo que podem ser adicionados de um snap a um usuário comercial. Os negócios gerenciam o processo e o desenvolvedor é responsável pela disponibilidade e operação correta de um microsserviço específico. Além disso, todas as partes entendem a lógica e o objetivo gerais do processo.

Princípio No. BPMS 2. Cada serviço possui entradas e saídas claras.

O princípio parece muito simples e pode parecer a um desenvolvedor ou usuário comercial inexperiente que o BPMS não aprimore a estratégia de gravar microsserviços de forma alguma. Assim, microsserviços normais podem ser gravados sem BPMS.

Sim, é possível, mas difícil. Quando um desenvolvedor escreve um microsserviço sem BPMS, ele inevitavelmente deseja economizar em abstração. Os microsserviços tornam-se francamente grandes e, às vezes, até começam a reutilizar outros. Há um desejo de economizar na transparência da transferência do resultado de um microsserviço para outro.

O BPMS encoraja você a escrever de maneira mais abstrata. O desenvolvimento é realizado com precisão, com a definição de entrada e saída.

Princípio BPMS No. 3. Concorrência do Processamento de Filas

Imagine o processo de processamento de pedidos: precisamos ir a algum mercado, pegar todos os bons pedidos e começar a processá-los.

imagem

Veja o diagrama (parte do diagrama). Aqui é determinado que a cada 10 minutos verificamos todos os pedidos do mercado e, em seguida, executamos em paralelo (conforme indicado pelo “hambúrguer” vertical na Ordem de Processo) o processamento de cada pedido. Se for bem-sucedido, transfira todos os dados para o ERP e conclua o processamento.

Se subitamente precisarmos aumentar os logs para processar uma ordem específica, no Camunda, no JBoss ou em qualquer outro BPMS, poderemos restaurar completamente todos os dados e ver em qual fila estava e com quais parâmetros de entrada / saída.

Princípio BPMS nº 4. Erro e escalação

Imagine que ocorreu um erro durante o processo de entrega. Por exemplo (a propósito, esse é um caso real), a empresa de transporte aceitou o pedido e o armazém foi incendiado. Outra história real: a pressa da véspera de Ano Novo, o produto foi adiado primeiro e depois, talvez, foi perdido.

Nesse caso, os eventos são acionados pelo mouse no BPMS, por exemplo, a notificação de um cliente caso o tempo de entrega tenha passado. Se você recebeu um erro da empresa de transporte, pode iniciar o processo em sua própria filial e interromper tudo: notifique, dê um desconto no próximo pedido, devolva o dinheiro.

Todas essas exceções são difíceis não apenas de programar fora do BPMS (por exemplo, um timer em um timer), mas também de serem entendidas no contexto de todo o processo.

Princípio BPMS nº 5. A escolha de ações para um dos eventos e opções de interprocesso

Envie o mesmo pedido na entrega.

No total, temos três cenários:

as mercadorias foram entregues como esperado;
as mercadorias não foram entregues como esperado;
item foi perdido.

Diretamente no BPMS, podemos determinar o procedimento para o envio de mercadorias para a transportadora e esperar um dos eventos por pedido:

entrega bem-sucedida (mensagens do processo de entrega do produto de que tudo foi entregue);
ou o início de algum tempo.

Se o tempo não passou, você precisa iniciar outro serviço: analisando esse pedido específico com o operador (você precisa definir uma tarefa para ele no sistema OMS / CRM para descobrir onde está o pedido) com uma notificação adicional do cliente.

Porém, se durante a investigação o pedido foi entregue, você precisará interromper a investigação e concluir o pedido.

No BPMS, todas as interrupções e exceções estão no lado do BPMS. Você não sobrecarrega o código com essa lógica (e a própria presença dessa lógica no código tornaria os microsserviços grandes e pouco reutilizados em outros processos).

Princípio BPMS nº 6. Na sua Camunda, você verá todos os logs

Usando eventos e a opção entre processos, você:

Você vê toda a sequência de eventos em uma janela (o que está acontecendo com o pedido, em qual ramo das exceções ele passou, etc. - é fácil ver);
Você pode coletar todas as análises para BI apenas com base nos logs do BPMS (sem a necessidade de sobrecarregar os microsserviços com eventos de log).

Como resultado, você poderá coletar estatísticas especificamente sobre os problemas de processamento, taxas de transição e todos os processos da empresa. Há uma unificação das informações de registro - é fácil vincular o evento na entrega à ação do operador ou ao evento de qualquer outro sistema de informação.

Preste atenção à diferença com o sistema modular: logs universais também podem ser feitos lá, mas ao interagir com outros sistemas, você precisará fazer algo com a unificação do log neles também, e isso nem sempre é possível.

Conclusões: uma comparação entre microsserviço e arquitetura modular

Cada tipo de arquitetura tem suas vantagens e desvantagens. Não há solução universal.

Não defendemos uma mudança maciça nos microsserviços. Pelo contrário, para uma pequena empresa ou ao usar um número muito pequeno de personalizações, uma abordagem modular será mais adequada.

Além disso, não nos opomos a nenhuma solução de TI (Bitrix, Magento, frameworks como Symfony ou Django, etc.), porque desenvolvemos mais de seis mil horas de código todos os meses apenas nesses frameworks e com a mesma quantidade de front'a e microsserviços. Portanto, estamos convencidos de que é importante procurar uma solução técnica adequada e não promover o uso de uma plataforma específica (para a qual, infelizmente, uma parte significativa das vendas em TI está rolando para baixo).

Nas seções anteriores do artigo, você aprendeu sobre as desvantagens e vantagens da arquitetura modular. Esperamos que isso já tenha ajudado a avaliar se o refinamento da versão em caixa ou a criação de microsserviços a partir do zero seria mais adequado. Se não foi possível decidir, vamos ver como os diferentes tipos de arquitetura mudam dependendo da vida do projeto.

No início do projeto:

com microsserviços - você tem zero funcionalidade e precisa escrever tudo para começar a trabalhar;
com um sistema modular - a partir da versão em caixa, uma grande quantidade de funcionalidade está imediatamente disponível para você e você pode começar a usar o produto logo após a compra.

Após os primeiros 3-4 meses de desenvolvimento (esta é a data média de lançamento do primeiro MVP) e além:

com microsserviços - o volume da funcionalidade é gradualmente alinhado em comparação com a versão em caixa. Para empresas de médio porte, a arquitetura de microsserviços alcançará o modular rápido o suficiente, mas para os grandes - geralmente instantaneamente. E no futuro, a manutenção e o desenvolvimento de um sistema modular em termos de uma unidade funcional aumentará;
com um sistema modular - a velocidade de desenvolvimento da funcionalidade será significativamente menor do que nos microsserviços.

Em conclusão, vamos ver como a orquestração de microsserviços se parece com exemplos específicos.

Exemplos de visualização de orquestração de serviços

Considere a orquestração de serviços usando o Camunda. A partir das imagens a seguir, você pode avaliar como é conveniente gerenciar microsserviços usando BPMS com um orquestrador. Todos os processos são visuais, a lógica é óbvia.

Os processos de negócios têm a seguinte aparência:
imagem

Exemplo (pedido, serviço de disponibilidade):

imagem

pode-se ver que, nesse pedido, havia uma filial “Sem mercadorias”.

Outra cópia do pedido (foi para a montagem): O

imagem

pedido foi mais além e, de acordo com a tabela de decisão (DMN), foi para a filial de processamento por um determinado operador de serviço de entrega (Boxberry):

imagem

Cuidado com o processo aninhado: O

imagem

processo aninhado funcionou:

imagem

Histórico dos processos de negócios:

imagem

Propriedades desta visualização:

os processos de negócios são fáceis de ler, mesmo por um usuário despreparado;
eles são executáveis, ou seja, funcionam exatamente como são desenhados, não há rassincronismo entre a "documentação" e o trabalho real do código;
os processos são transparentes: é fácil ver como foi uma importação, pedido e processamento em particular, é fácil ver onde o erro foi cometido.

Lembre-se de que nós do kt.team usamos o desenvolvimento modular e de microsserviços, escolhendo a opção certa para cada produto individualmente. Mas se a escolha já foi feita em favor da arquitetura de microsserviços, estamos firmemente convencidos de que é impossível ficar sem sistemas de BPM como Camunda ou jBPM.

Veja também: vídeo sobre o tópico “Microservice ou arquitetura monolítica: o que escolher?”

Microsserviços ou sistemas modulares? Como um cliente pode escolher uma abordagem para a arquitetura de TI de um produto