As histórias de serrar monólitos geralmente se parecem. A equipe tinha um monólito pesado e desajeitado, eles decidiram dividi-lo em uma dispersão de microsserviços regulares e inteligentes, tudo ficou legal. As histórias diferem apenas no grau de horror "antes", alegria "depois" e várias características secundárias.
No RBK.money, também temos microsserviços. Mas chegamos a eles um pouco diferente da maioria. Tudo era ainda pior para nós do que o monólito - no começo, tudo era ruim.
Sob o ponto de vista de como construímos microsserviços, por que o OpenSource não é apenas ótimo em princípio, mas também funciona como um componente motivacional para escrever um bom código.
Então, tudo estava ruim. Tanto que consertá-lo não fazia sentido, mas fazia sentido concordar em nunca se lembrar desse horror e apenas escrever tudo do zero. E imediatamente em microsserviços. No primeiro estágio do desenvolvimento, imediatamente adotamos como regra manter constantemente em mente o fato de que um dia quereremos reabrir todo esse bem ou parte dele. Afinal, tudo é salvo na história dos commits, incluindo apelidos dos desenvolvedores, então nos sentamos e imediatamente tentamos escrever tudo de tal maneira que mais tarde não tenhamos vergonha do nosso código na frente da comunidade. Afinal, ninguém quer corar pelo código ou pela arquitetura do projeto, mais ou menos pela história.
Rápido vs bom
Em um mundo ideal, você sempre deseja escrever código rapidamente e bem. Bem, é como "Melhor ser rico e saudável do que pobre e doente". Portanto, os microsserviços se tornaram uma excelente maneira de sair da situação. O processo de escrever código foi desenvolvido em tarefas de negócios. Suponha que uma empresa precise de uma funcionalidade que levará em conta os fundos nas contas de contraparte ao efetuar pagamentos. Essa funcionalidade se transforma em um microsserviço, codinome Accounter, envolvido em ferramentas de contabilidade. Com outros microsserviços, a mesma história.
O principal aqui era garantir que cada funcionalidade comercial fosse tão concreta que uma pessoa pudesse escrevê-la. Depende muito das tarefas que estão chegando ao trabalho e de como o diretor ou projeto técnico traduz isso para a equipe. Conseguimos fazer isso, ele imediatamente oferece algumas boas vantagens significativas.
Em primeiro lugar, fornece uma grande paralelização do desenvolvimento. No início, tínhamos cerca de 10 pessoas e conseguimos escrever uma grande quantidade de código ao mesmo tempo (e escrever bem). Em segundo lugar, oferece a oportunidade de girar completamente. Mas isso já é um pouco mais importante do que parece à primeira vista.
Muitas vezes, uma pessoa começa a cagar, não porque ele conseguiu esse emprego para você, mas porque seus olhos se tornam bregas e seus olhos ficam sem graça e entediados. Se uma pessoa estiver constantemente sentada no mesmo microsserviço, poderá começar a gerar govnokod. E isso não é tanto uma questão de profissionalismo, mas uma questão de tempo. Depois de 7 a 8 meses, as pessoas se cansam de dar suporte ao mesmo microsserviço, olham em volta - e aí a vida, a primavera chegou depois do inverno, algum tipo de movimento veio dos colegas, mais uma vez um novo iPhone foi lançado e todos vocês estão sentados no mesmo microsserviço . É assim que um monólito nasce com um único ponto de falha na forma dessa pessoa cansada com bolsas debaixo dos olhos.
Ou, em geral, uma pessoa começa a pensar que tudo depende apenas dela e repousa sobre ela. Ela tentará tornar-se indispensável cercando seu trabalho com um monte de "conhecimento secreto" e procedimentos estranhos. No início da minha jornada, tive situações em que o legado era tão selvagem que era impossível descobrir sem esse conhecimento. Por exemplo, você teve que iniciar um serviço. Como você normalmente imagina isso:
- Inicie o serviço.
Como foi:
- Vá para o registro do Windows.
- Encontre uma chave específica lá.
- Altere para 1.
- Inicie o serviço.
- Redefina o valor da chave para 0.
Este é um exemplo clássico de complexidade por uma questão de complexidade e "Nada funciona aqui sem mim". De fato, sem isso, tudo funciona. Apenas mais rápido e melhor. Você pode se livrar disso por rotação - idealmente quando uma pessoa grava um microsserviço por cerca de alguns sprints e depois sai para realizar outra tarefa. Da mesma forma, apoiamos uma troca constante de conhecimentos em uma equipe.
Código do protocolo
Se você pegar qualquer TK nos negócios, traduza-o bem em humano, remova a casca e evapore - você obtém um protocolo, um idioma com o qual a máquina se comunicará. Ou seja, assumimos uma tarefa de negócios, entendemos por nós mesmos exatamente o que e como faremos isso e a transformamos em uma especificação para economia ou arrogância (os microsserviços dentro de comunicação via economia). O primeiro passo é descrever tudo em detalhes: o que o microsserviço fará, que tipos de dados ele receberá, o que responderá, que estruturas serão e assim por diante. Esse protocolo passa pela primeira revisão daqueles que têm uma ideia clara de como tudo funciona (arquitetos de fato). Funciona como um filtro grosso através do qual algumas besteiras francas não passam nem no nível do conceito.
Assim que o protocolo aparecer, você pode se sentar para escrever o código. E se o protocolo for completamente auditado por pessoas universais, o código em si estará em uma equipe de pessoas específicas. Escrevemos em três idiomas - JS, Java, Erlang. O principal é não apressar ninguém com uma revisão ou código de escrita. Sim, os negócios sempre e em qualquer lugar precisam ser rápidos e legais. Mas raramente apresso os caras como diretor técnico, porque entendo o que eles querem fazer bem. O resultado é uma situação que muitas vezes sou encorajada pelos clientes comerciais ao longo do tempo. Mas praticamente não precisa corar pela qualidade.
Só nos apressamos uma vez quando o jackpot foi superposto - um super cliente e prazos extremamente urgentes, que acabamos de criar nossa Carteira virtual. Então sim, abaixamos as mangas e fizemos tudo mais rápido do que planejamos (e pior do que queríamos, sim). Idealmente, tudo foi concebido como um monte de microsserviços puros. Acabou sendo um pedaço de monólito. As vantagens da situação são que mais uma vez percebemos por nós mesmos que não há necessidade de nos apressarmos. E o serviço em si já está sendo puxado lentamente para microsserviços separados, como eles queriam.
Existem 50 microsserviços no RBK Money, eles são escritos por cerca de 20 pessoas. O Thrift está em toda parte, para os desenvolvedores é um protocolo bastante complicado, a degradação é difícil, a documentação também é difícil de escrever. E se eu deixasse a economia em sua forma mais pura, eles me chamariam de palavrões. Portanto, não criamos nada - o resto do JSON, simples e intuitivo, além do OpenAPI, destaca-se alegremente. Para poder aceitar essas solicitações de fora, elas devem ser validadas, autorizadas e lançadas na plataforma por outros microsserviços. E também escrevemos tudo isso como um microsserviço independente, que:
- aceita ganhos externos;
- valida o esquema;
- autoriza o usuário;
- transforma tudo isso em uma solicitação de economia;
- Bem, ele escreve logs, é claro.
É conveniente escrever um sistema de pagamento em microsserviços? Claro - aqui você tem paralelização do trabalho, mantendo o interesse dos funcionários e a ausência de um único ponto de falha. Um único microsserviço quebrou ou, de repente, a pessoa que o fez ontem saiu - não há problema, você pode consertar rapidamente algo e colocar uma nova pessoa no banco do piloto durante o novo sprint.
Mas há uma opinião de que, se uma pessoa senta e corta cuidadosamente um microsserviço específico por um longo tempo, ele definitivamente faz bem. Desde que começamos a falar sobre isso, escreva nos comentários qual abordagem está mais próxima de você. E o mais importante - por quê.