Escrevemos recentemente sobre como trabalham os arquitetos de TI e agora contaremos os detalhes de um de nossos casos e mostraremos o esquema do sistema. Neste projeto, ajudamos a substituir um aplicativo bancário "box" por um RBS de microsserviço, ao mesmo tempo em que estabelecemos uma liberação rápida de lançamentos - em média, uma vez por semana.
: , , -. NDA – , , , -.
«»
Entre as médias e pequenas empresas, há demanda por soluções de TI prontas, que podem ser customizadas e lançadas com logotipo próprio. Contras - as funções dos aplicativos "prontos para uso" são limitadas e as atualizações geralmente precisam ser feitas por um longo tempo e exclusivamente através do fornecedor.
Um de nossos clientes usou exatamente esse sistema de "caixa" de serviços de banco remoto (RBS). O banco online era um aplicativo monolítico com um conjunto bastante pequeno de funções.
Para não ser inferior aos concorrentes, o banco precisava constantemente introduzir melhorias e novidades. No entanto, mesmo para simplesmente mover os botões do aplicativo, era necessário entrar em contato com o fornecedor. As atualizações foram lançadas em média uma vez por trimestre.
Assim, era difícil desenvolver o produto devido a uma série de restrições:
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
Com isso, o banco decidiu abandonar gradativamente o “box” e desenvolver seu próprio sistema bancário remoto, com arquitetura de microsserviços, de forma a acelerar o desenvolvimento de funções e proporcionar comodidade e segurança aos usuários.
Onde começamos
A criação de um banco online começou com o desenho de uma arquitetura de alto nível, a contratação de desenvolvedores para a equipe e a conexão de nossa equipe dedicada. Ao mesmo tempo, a arquitetura teve que ser executada com uma margem de segurança, contando com futuras expansões.
No início, nossa equipe de desenvolvimento de Backend estava envolvida na implementação de certas funções básicas: por exemplo, transferências de dinheiro. No entanto, tínhamos bastante experiência em trabalhar com bancos online, um de nossos projetos nessa época entrou no rating de indústria de Markswebb, então oferecemos o auxílio do banco no projeto arquitetônico - e recebemos o sinal verde.
Arquitetura
Junto com o product owner, decidimos usar Spring Cloud, que fornece todas as funções necessárias para implementar uma arquitetura de microsserviço: esta é a descoberta de serviço - Eureka, Api Gateway - Zuul, servidor de configuração e muito mais. O OpenShift foi escolhido como o sistema de contêiner para imagens Docker, porque a infraestrutura do banco foi aprimorada para essa ferramenta.
Também analisamos quais recursos da "caixa" antiga podem complicar a experiência do usuário. Uma das principais desvantagens era que o sistema funcionava de forma síncrona por meio do barramento de dados, e cada ação do usuário causava um acesso ao barramento. Devido a cargas pesadas, o ônibus frequentemente falhava e todo o aplicativo parava de funcionar. Além disso, como em muitos produtos bancários antigos, o legado se acumulou - "legado" na forma do antigo e pesado CORE ABS, que seria difícil e caro de reescrever.
Propusemos uma série de melhorias:
- Controle de versão
Anteriormente, a "caixa" suportava apenas uma versão, mas no novo banco online propusemos uma nova arquitetura que nos permitirá suportar várias versões diferentes ao mesmo tempo e substituí-las se necessário.
O esquema de controle de versão é o seguinte: se a versão secundária no serviço foi alterada, o serviço é automaticamente reconstruído e implantado, substituindo a versão desatualizada. Se colocarmos a versão principal, uma nova cópia do serviço com a nova versão será implantada. Dessa forma, o desenvolvimento de novas funções com mudança na API do serviço não afeta a aplicação móvel, enquanto o tempo de teste é reduzido. Esse sistema possibilitou dar suporte até mesmo para versões desatualizadas do aplicativo móvel, caso o usuário não tivesse a oportunidade de atualizar.
- Assincronia
Implementamos uma biblioteca que pode ser usada em serviços que requerem trabalho assíncrono. A biblioteca implementa a execução de tarefas assíncronas, é adequada para uso em qualquer número de cópias de serviços e não interferem entre si. A sincronização entre as diferentes cópias é feita usando a fila de mensagens Kafka.
Esta solução ajudou a melhorar a estabilidade do aplicativo. O aplicativo mobile agora é independente do barramento, duplicamos os dados solicitados pelo usuário em nossos serviços e os atualizamos em background quando houver acesso ao barramento do banco. Todas as ações do usuário são enfileiradas para execução, assim que estiverem prontas, notificações PUSH sobre os resultados são recebidas.
- Cache
Para agilizar a aplicação e reduzir a carga nos recursos bancários internos, o armazenamento em cache de dados é organizado usando o Redis. O KeyDB funciona como um cache, que mostra bons resultados e é compatível com muitos sistemas que usam Redis. Os dados são armazenados em cache não após uma solicitação do usuário, mas quando os dados do usuário são alterados, o que permite acesso a eles independentemente dos sistemas bancários internos.
O que mudou no sistema
Conforme observado acima, no antigo banco online, o back-end foi implementado em uma arquitetura monolítica, o aplicativo foi implementado em uma máquina separada. Conforme a carga aumentou, novos servidores tiveram que ser implantados. Quando o servidor travou, o aplicativo móvel não funcionou para alguns usuários.
A nova solução usa uma arquitetura de microsserviço, que permite implantar quantas cópias de serviços forem necessárias para uma funcionalidade específica. Adicionamos o armazenamento em cache de dados baseado em KeyDB não apenas para aumentar a velocidade de recuperação de informações, mas também para reduzir a carga no banco de dados.
Vejamos um exemplo de obtenção de dados sobre contas de usuário na nova arquitetura. A solicitação do usuário do aplicativo móvel passa pelo balanceador para o Gateway, que entende para qual dos serviços enviar a solicitação. Em seguida, chegamos à API de serviço da conta. O serviço primeiro verifica se há dados reais do usuário no Cache. Se for bem-sucedido, ele retorna os dados, caso contrário, ele envia uma solicitação ao serviço de conta do meio.
A atualização de dados no serviço pode ocorrer em vários casos. Por exemplo, mediante solicitação direta do usuário, o serviço cria uma tarefa de atualização de dados que é executada de forma assíncrona e os dados recebidos do ESB são atualizados. O serviço também recebe mensagens da fila de mensagens e responde a elas. Por exemplo, um serviço recebe uma mensagem sobre o login de um usuário em um aplicativo e atualiza imediatamente os dados da conta, recebe dados sobre as transações da conta de outros serviços e atualiza seus dados. Assim, o usuário sempre vê os dados atualizados de suas contas.
Entre as mudanças mais importantes estão as seguintes:
- Flexibilidade de dimensionamento
Para aumentar a tolerância a falhas do sistema, os serviços são distribuídos em diferentes servidores. Isso permite que você mantenha o sistema em funcionamento no caso de queda de um deles. Para uma resposta oportuna a situações fora do padrão, implementamos um sistema de monitoramento, que ajudou a aumentar os serviços, se necessário. Conectamos o DevOps para configurar CI / CD do zero em servidores clientes, desenvolvemos processos de implantação e suporte para o aplicativo futuro em vários servidores.
- Aceleração de lançamentos devido ao controle de versão
Anteriormente, ao atualizar a versão mobile, alguns usuários já aplicavam a nova versão, enquanto outros não, mas o número desta última era mínimo. Ao desenvolver um novo RBS, implementamos o controle de versão e a capacidade de lançar lançamentos sem o risco de o aplicativo parar de funcionar para grande parte dos clientes. Agora, ao implementar funcionalidades individuais em novas versões, não quebramos as versões antigas, o que significa que não há necessidade de regredir. Isso ajudou a acelerar a frequência de lançamentos em pelo menos 15 vezes - agora os lançamentos são lançados em média uma vez por semana. As equipes de back-end e móvel podem trabalhar de forma simultânea e independente em novas funcionalidades.
Resumindo
Neste exemplo, falamos sobre o projeto de uma arquitetura de microsserviço para um banco, que substituiu a solução monolítica "em caixa". Uma equipe distribuída trabalhou neste projeto, que incluía desenvolvedores internos e terceirizados.
Ao desenvolver um banco online, tentamos implementar o mesmo escopo de funções na nova aplicação e em uma caixa, e gradualmente desenvolvê-lo.
Para evitar a rotatividade do cliente, era necessário estabelecer um funcionamento do aplicativo sem problemas, sem falhas e tempo de inatividade, e lançamento regular de releases e atualizações. Isso foi feito graças a melhorias na arquitetura. Em particular, após reduzir a carga no banco de dados, alcançamos disponibilidade constante do aplicativo e, devido ao versionamento, reduzimos o tempo de teste, garantimos a possibilidade de trabalho independente na funcionalidade e lançamento de releases uma vez por semana.
A arquitetura do aplicativo é baseada no crescimento adicional do produto e nas ferramentas de desenvolvimento usadas pela equipe bancária interna, para que o proprietário do produto possa fazer qualquer melhoria no RBS de forma independente. Os termos de desenvolvimento ativo da versão alfa foram cerca de um ano, após mais 3 meses a versão beta foi lançada para todos os usuários.
Esperamos que o esquema de trabalho descrito possa ser útil ao criar outros produtos fintech.
Obrigado pela atenção!