Olá Habr!
Estamos começando a traduzir o livro
Microservices Patterns de Chris Richardson,
com exemplos em Java . Passou meio ano antes da estréia em russo, mas gostaríamos de oferecer a você um tipo de trailer - uma resenha um pouco resumida deste livro de Ben Nadel, que leu a versão MEAP. A revisão cita ativamente o texto da versão Kindle de Richardson.
Bem-vindo ao gato!
Eu aprendi sobre Chris Richardson quando conheci seu recurso on-line
Microservices.io . Onde, para ser honesto, há uma quantidade impressionante de informações - que decidi adiar para mais tarde, porque naquela época eu não sabia como abordá-las, especialmente considerando que eu praticamente não tinha relações com microsserviços. Eu gosto de ler mais Portanto, quando soube que Chris estava publicando o livro do autor
Microservices Patterns: With Examples In Java , fiquei simplesmente inspirado. Tanto que ele mal podia esperar pela saída dela. Então, adquiri e li a "versão inicial" de Manning (MEAP). Na semana passada, acabei de fazer o que estudei neste livro e acho que este é um estudo fascinante, pragmático e holístico da abordagem de desenvolvimento de microsserviços.
O livro inteiro foi construído na forma da história de Mary - CTO (CTO) da Food To Go, Inc (FTGO). A empresa busca expandir os negócios lançando a refatoração de seu antigo aplicativo monolítico e transformando-o em uma arquitetura de microsserviço. Mary assume esse projeto, porque a velocidade de desenvolvimento diminuiu e os chefes estão ficando cada vez mais irritados com o fato de os programadores sob a liderança de Mary não conseguirem produzir novos recursos de uma forma de alta qualidade.
Claro, o principal problema de Mary é o chamado "inferno monolítico" na terminologia de Richardson. Embora o monólito seja uma aplicação grande e crescente, Richardson se concentra em um aspecto bastante sutil da migração do FTGO, para que seja mais conveniente expor e transmitir todos os conceitos. Nesse caso, o conteúdo do livro é incrivelmente digerível. A maioria das considerações de arquitetura geralmente é excessivamente simplificada ou complicada demais. No entanto, Richardson conseguiu encontrar um meio termo, construindo um modelo de domínio que (quase) se encaixa na cabeça, mas é ao mesmo tempo complexo o suficiente para ilustrar fluxos interessantes de tarefas entre serviços.
Desde o início, eu esperava que Richardson fosse pragmático em todos os detalhes. Nenhum aspecto do livro é apresentado como uma "bala de prata" ou "a única solução". Em todos os lugares, vemos uma escolha calculada, um conjunto de compromissos claramente definidos. Por exemplo, o autor ainda submete a ideia de microsserviços nesse sentido: a arquitetura de microsserviços deve sempre ser evitada, exceto nos casos em que é absolutamente necessário:
Outro desafio associado ao uso da arquitetura de microsserviço é decidir em que momento do ciclo de vida do aplicativo começar a usar essa arquitetura. Ao desenvolver a primeira versão de um aplicativo, muitas vezes você ainda não encontra problemas resolvidos por essa arquitetura. Além disso, o uso de uma arquitetura distribuída bem equilibrada apenas atrasará o desenvolvimento. Esse dilema pode surgir em startups, onde o desafio mais importante geralmente reside no rápido desenvolvimento de um modelo de negócios e em sua própria aplicação. Ao usar a arquitetura de microsserviço, é muito mais difícil organizar iterações rápidas. O desenvolvimento da inicialização definitivamente deve começar com um aplicativo monolítico. (Versão Kindle, endereço 416)
Richardson também considera os microsserviços em uma perspectiva holística, discutindo a dinâmica da equipe como um círculo completamente independente de problemas, construído na parte tecnológica. Obviamente, ele considera tópicos como
a Lei de Conway e a "Manobra Reversa de
Conway ", mas, ao mesmo tempo, também aborda o fato de que os programadores são personagens de pathos emocionais com os quais você deve "vender" a idéia de microsserviços:
Mudando para o paradigma de microsserviço, você é forçado a mudar sua arquitetura, sua organização e processos de desenvolvimento. No entanto, no final, o ambiente de trabalho muda, as condições em que as pessoas trabalham e as pessoas, como já mencionado, são emocionais. Se as emoções humanas são ignoradas, a introdução de microsserviços em uma organização pode se transformar em uma rota íngreme. (Versão Kindle, endereço 718)
As estratégias descritas pelo autor dizem respeito a todo o negócio, afetam gerentes e executivos que talvez não se atrevam a iniciar uma grande refatoração, retirando recursos valiosos, pessoas que poderiam desenvolver ativamente novos recursos:
Um benefício significativo da refatoração passo a passo em direção à arquitetura de microsserviço é que essa estratégia começa a render imediatamente. Essa não é a situação em que “revisar” um código que não traz nenhum benefício até que seja completamente concluído ...
Outra vantagem da situação em que o valor da transição é adquirido em um estágio inicial é que podemos atrair suporte comercial para garantir a migração. Esse suporte contínuo é crucial, pois quanto mais ativa a refatoração, menos tempo você poderá gastar no desenvolvimento de recursos. Em algumas organizações, é difícil se livrar da dívida técnica, pois as tentativas anteriores podem se mostrar excessivamente ambiciosas e não trazem os benefícios desejados. Como resultado, os negócios relutam em continuar investindo na “limpeza”. A natureza passo a passo da refatoração no caso de microsserviços significa que uma equipe pode mostrar resultados valiosos com muita frequência. (Endereço da versão do Kindle 10769)
Do ponto de vista tecnológico, no livro “Microsserviços. Padrões de desenvolvimento e refatoração ”examinaram uma ampla gama de tópicos: de arquiteturas hexagonais, testes e integração contínua a padrões de mensagens e a criação de sistemas observáveis. Essa cobertura implica que alguns tópicos do livro sejam abordados com mais detalhes que outros. No entanto, novamente, Richardson consegue perfeitamente equilibrar tudo e fornecer tantos detalhes para que se possa discutir razoavelmente o tópico sem desencorajar o leitor.
De fato, o conteúdo do livro é organizado de tal maneira que você mesmo pode escolher quais tópicos se aprofundar. Em cada capítulo, antes de uma imersão detalhada no tópico, é fornecida uma lista de TL; DR, que lista brevemente todos os prós e contras. Assim, você consegue captar os pontos mais importantes do capítulo sem ler cada palavra.
Honestamente, acabei de ler dois capítulos sobre o teste de microsserviços e um capítulo sobre a implantação de microsserviços. Estou certo de que o autor elaborou esses tópicos perfeitamente, mas me pareceu que simplesmente havia mais informações do que eu poderia digerir. A implantação não é uma tarefa diária urgente para mim. Ele escreveu vários testes em sua vida.
Assim, eu queria deixar espaço suficiente em minha consciência de caverna pouco clara para colocar material de todos os outros capítulos: sobre design orientado ao assunto (DDD), comunicação entre processos e sincronização de dados.
Uma das seções que me impressionou especialmente diz sobre qual serviço deve lidar com solicitações de um tipo especializado, a saber: encontre restaurantes adequados perto da localização atual do usuário:
No entanto, pode ser difícil implementar até mesmo as solicitações locais em termos de um serviço específico. Isso é possível por vários motivos. Em primeiro lugar, porque (como descrito abaixo), às vezes não é razoável implementar uma solicitação no serviço que possui os dados. Outro motivo é que, às vezes, o banco de dados do serviço (ou modelo de dados) não suporta com eficiência a solicitação (versão do Kindle, endereço 5659)
... Se no aplicativo FTGO as informações sobre restaurantes estiverem armazenadas em [algum outro] banco de dados, a implementação da consulta findAvailableRestaurant() será muito mais complicada. Uma réplica dos dados do restaurante deve ser armazenada em um formulário que suporte consultas geoespaciais. Por exemplo, um aplicativo pode usar a Biblioteca de Indexação Geoespacial para DynamoDB, onde a tabela é usada como um índice geoespacial. Alternativa: o aplicativo pode armazenar uma réplica dos dados do restaurante em um tipo completamente diferente de banco de dados. Uma situação semelhante ocorre quando usamos consultas de texto com um banco de dados para pesquisa de texto. (Versão Kindle, endereço 5675)
... Nesse caso, é aconselhável (pelo menos à primeira vista) que a operação de solicitação seja implementada pelo próprio serviço que possui os dados. No entanto, além da propriedade dos dados, outros fatores devem ser considerados.
Também é necessário levar em consideração a necessidade de separação de tarefas e evitar sobrecarregar os serviços com muitos recursos. Por exemplo, a principal responsabilidade da equipe que desenvolve o serviço de Restaurante é ajudar os gerentes de restaurante a servirem o trabalho do estabelecimento. Esta tarefa não é de todo o plano que a implementação de uma solicitação crítica para trabalhar com grandes quantidades de dados. Além disso, se a equipe de desenvolvimento fosse responsável pela operação findAvailableRestaurants() , estaria constantemente com medo de introduzir essas alterações que poderiam impedir os consumidores de fazer pedidos. (Versão Kindle, endereço 5675)
Aqui, meu cérebro explodiu um pouco porque vi um serviço cuja única função era otimizar os dados de outro serviço para executar uma tarefa específica. No entanto, como Richardson aponta, essa é apenas uma abstração mais generalizada da própria ideia subjacente à pesquisa de texto completo, por exemplo, no Apache Lucene (essa ferramenta fornece indexação de texto completo em cima de outro data warehouse).
Eu suspeito - ou melhor, eu espero - que, tendo visto uma divisão de responsabilidades, o leitor comece a traçar uma nova linha entre os serviços. Ele pensará não apenas na “propriedade dos dados”, mas também começará a levar em consideração as “oportunidades de negócios” - isto é, um fator de valor real para que o banco de dados não pareça ser apenas o local onde o estado está armazenado.
Outro aspecto destacado nesta discussão é a importância absoluta da sincronização e replicação de dados, além de mensagens assíncronas na arquitetura de microsserviços. Este tópico percorre todo o livro de Richardson com um fio vermelho, não importa o que eles falem: a criação de um microsserviço do zero ou a refatoração gradual de um monólito em microsserviços (um capítulo separado é dedicado a esse tópico). Ele deixa bem claro que a sincronização é a força principal que realmente permite que muitas coisas sejam realizadas.
Eu poderia mencionar muitas coisas interessantes. Por que vale, por exemplo, o fato de Richardson falar adequadamente sobre autenticação e autorização em um sistema distribuído? Acho que esse tópico ainda não foi totalmente explorado, para dizer o mínimo. O autor explica o design orientado ao assunto da maneira mais acessível. Ele também demonstra que mesmo classes muito simples podem ter comportamento.
Há mais de um ano, venho tentando entender adequadamente a arquitetura de sistemas distribuídos e padrões de microsserviços (o que é especialmente difícil, pois meu trabalho diário está relacionado à manutenção do monólito). Muitos dos textos que li sobre esses tópicos são excessivamente superficiais ou muito estreitos e, ao mesmo tempo, aprofundados. O livro "Microsserviços. Padrões de desenvolvimento e refatoração ”é de fato o meio termo entre esses dois extremos.
Eu recomendo vivamente este livro a todos (em negrito) que estão tentando (inclusive, até agora sem êxito) mudar de uma arquitetura monolítica para um sistema distribuído.