Para alguns, microsserviços é a capacidade de refazer e refatorar um aplicativo para um estilo relativamente moderno. Essa solução arquitetural não é adequada para outras pessoas devido às peculiaridades da interação de várias partes do aplicativo. De qualquer forma, escolhendo uma arquitetura, é útil estudar a experiência de outras pessoas, desde a transição de um monólito para um conjunto de serviços.
Pedimos para compartilhar nosso estudo de caso do desenvolvimento e fornecimento de microsserviços Alexei Baitov, engenheiro líder do 2GIS. Vamos falar sobre soluções arquitetônicas, implantação e escalabilidade. Vamos perguntar sobre tendências e apenas ferramentas convenientes para o trabalho.
- Alexey, conte-nos um pouco sobre você e sobre sua equipe no 2GIS . No que você está trabalhando agora?
Eu vim para a TI em 2003 como administrador de sistemas, mergulhei no desenvolvimento em 2011. Durante esse período, ele trabalhou em PHP, JavaScript, implementou uma série de serviços RESTful e um driver Python para o Git. Trabalho no 2GIS desde 2015.
Ele participou do desenvolvimento de duas arquiteturas de microsserviço. O primeiro consistia em um serviço. Era um proxy reverso assíncrono com um cache. Na verdade, ele estava envolvido no envio de mensagens. Eu era o único envolvido na elaboração dos requisitos, no desenvolvimento e na criação de DevOps, mas os especialistas da nossa empresa 2GIS me ajudaram.
O serviço foi escrito em Go. A compilação rápida me permitiu não esperar e pude me concentrar na Implantação Contínua. Então estávamos começando a usar o
GitLab CI ,
Prometheus ,
Grafana e
Deis (análogo de código aberto do
Heroku ). Temos uma equipe de infraestrutura e operações que, no momento do meu desenvolvimento, trouxe todas essas soluções de infraestrutura para o nível pronto para produção. Decidi tentar tudo isso e implementei com sucesso um microsserviço independente.
Há dois anos, mudei para outra equipe em um novo projeto, onde comecei a me engajar em programação funcional no Scala. Nossa equipe do zero desenvolveu uma arquitetura de microsserviço para o armazenamento de materiais de publicidade 2GIS em Scala, C # e JavaScript. Estabeleci a base de todos os serviços com as ferramentas e a experiência obtidas na construção de práticas de DevOps (implantação e manutenção contínuas). A arquitetura passou de protótipo para operação industrial. Ela absorveu dois monólitos, agora consiste em 15 serviços e está em constante expansão.
- Você concorda que os microsserviços são essencialmente um conjunto de serviços implantados de forma independente e que possuem características comuns, ou seja, um conjunto de determinados recursos oferece a aparência de um microsserviço? Essa definição precisa ser expandida? Ou, de fato, as empresas têm um entendimento diferente da arquitetura de microsserviços?Eu gosto da seguinte
definição . A arquitetura de microsserviço é um estilo de arquitetura que estrutura um aplicativo como uma coleção de serviços vagamente acoplados que implementam uma lógica comercial específica. Os serviços em uma arquitetura de microsserviço podem não ter características comuns, mas são combinados dentro de uma lógica comercial comum.
Obviamente, cada empresa terá seu próprio microsserviço. Este é um conjunto de práticas: arquitetura distribuída, integração e entrega contínuas, e assim por diante. Se você expandir o conceito de prática para as ferramentas usadas, as opções para implementar microsserviços serão muito diversas.
- Existem opiniões diferentes sobre a composição da equipe, que devem estar envolvidas na criação e suporte de microsserviços. O que você acha disso? Qual é o tamanho ideal da equipe e como deve ser construído pela interação dentro dela ao desenvolver uma arquitetura de microsserviço? Existe um bom exemplo de trabalho em equipe em sua prática?Considera-se correto desenvolver um serviço de forma que toda a sua área de assunto possa caber na cabeça de um desenvolvedor. Ao mesmo tempo, várias pessoas podem participar do desenvolvimento deste serviço. Isso ajudará a evitar o fator de ônibus quando o desenvolvedor saiu de férias ou adoeceu. A divisão correta dos serviços permite que uma nova pessoa entre rapidamente no contexto.
A arquitetura de microsserviço nos diz que geralmente inclui vários serviços. Assim, um desenvolvedor não pode fazer. A arquitetura de microsserviço se baseia no modelo do produto (ou lógica comercial comum). Os desenvolvedores são selecionados para implementar esse modelo e, ao mesmo tempo, focar no cliente.
O foco no cliente é organizado através do contato direto entre o desenvolvedor e o cliente. Os desenvolvedores precisam ver como seu produto é usado. A partir disso, deseja-se conhecimento no campo tecnológico, a capacidade de entregar o produto ao cliente e acompanhá-lo o mais rápido possível.
É difícil dizer sobre o tamanho da equipe. Todo mundo provavelmente já conhece a afirmação de Jeff Bezos, fundador da Amazon, de que o tamanho da equipe no desenvolvimento orientado a serviços deve ser pequeno o suficiente para que todos possam receber duas pizzas. Nos comentários sobre Habré, houve uma discussão sobre esse tópico, e eles escreveram que uma pessoa pode não ter uma pizza suficiente e, portanto, uma equipe deve consistir em uma ou duas pessoas. Martin Fowler, citando um comunicado sobre duas pizzas, disse que se tratava de grandes pizzas americanas, depois das quais especificou que a equipe não deveria ter 50, mas cerca de 12 pessoas. Acredito que tudo depende do modelo do produto. Mas o esclarecimento de Fowler sobre "não mais que 12 pessoas" ganhou em minha prática até agora. Percebi que dentro da equipe é desejável dividir de acordo com os interesses tecnológicos, encontrar pessoas com a mesma opinião.
Não é necessário que todos na equipe conheçam bem todas as áreas tecnológicas utilizadas no trabalho, mas o conhecimento total da equipe deve ser uniformemente profundo. Por exemplo, duas pessoas estão envolvidas na construção inicial de uma implantação e, no futuro, provavelmente, elas também a melhorarão significativamente. Mas, ao mesmo tempo, toda a equipe deve ter um bom entendimento do processo de implantação. Isso permitirá que ela expresse seus desejos e faça alterações. Por que duas pessoas? Porque às vezes uma pessoa pode cair em um estupor criativo. E na discussão, a verdade nasce.
Nós naturalmente construímos sobre esse princípio, unidos por interesses tecnológicos. Ao mesmo tempo, o desenvolvedor também pode estabelecer práticas de DevOps e o engenheiro de controle de qualidade pode desenvolver um serviço auxiliar de não produção (por exemplo, aquecer o cache ou o serviço de procurar anomalias nos dados em diferentes ambientes).
- Quase todos os relatórios sobre microsserviços começam com a história de que “aqui tínhamos um iceberg e serramos, serramos, serramos ... Novas partes do aplicativo foram feitas com base em microsserviços, e então começamos a separar as“ peças ”do mecanismo principal ... "
Diga-me, você é um defensor do desenvolvimento do zero ou pode haver situações em que valha a pena concluir gradualmente um monólito? Como determinar a estratégia de saída?Eu sou um defensor do desenvolvimento a partir do zero. Mas isso só funciona se o conjunto de funções não for muito complicado. Geralmente, é feito um pequeno monólito MVP. E, às vezes, é necessário alterar radicalmente sua implementação interna várias vezes. Isso pode ser causado tanto por uma alteração na tarefa técnica quanto pelo fato de haver uma compreensão da implementação - abstrações de alto nível aparecem no nível do modelo de negócios. Depois disso, você pode seguir para a arquitetura de microsserviço.
Mas se você elaborar essas abstrações no início e desenhá-las em diferentes notações (UML, BPMN, IDEF), para que todos os participantes do processo entendam com o que estão trabalhando, é bem possível implementar uma arquitetura de microsserviço imediatamente.
Nosso caminho para a arquitetura de microsserviços não foi reto. No começo havia um monólito. Ele processou materiais publicitários textuais. Há três anos e meio, precisávamos trabalhar com materiais de publicidade gráfica (imagens, logotipos). Havia um desejo de introduzir na lógica de negócios o que faltava ao trabalhar com materiais de publicidade em texto.
Para testar um novo modelo de negócios, implementamos o trabalho com materiais de publicidade gráfica como o segundo monólito em outra pilha de tecnologia. Após um ano e meio de operação, percebemos que essa abordagem estava correta.
Durante esse período, recebemos muita lista de desejos, revelando a aspereza da lógica de negócios.
A implementação do segundo monólito foi difícil de expandir para o primeiro. Portanto, decidimos não conduzir o desenvolvimento em dois monólitos ao mesmo tempo, mas combiná-los na estrutura da terceira arquitetura, de acordo com o modelo de negócios muito novo. Foi criada uma equipe de sete desenvolvedores, um engenheiro de QA e dois analistas. Dois desenvolvedores dessa equipe criaram e deram suporte ao primeiro monólito e mais um - o segundo monólito. Ou seja, nossa equipe já na entrada conhecia bem as armadilhas dos monólitos anteriores.
O primeiro monólito foi escrito em C #. O segundo é em PHP. Não queríamos perder as volumosas partes de código depuradas do primeiro monólito e, ao mesmo tempo, eram necessários multithreading, código seguro e digitação forte. O código PHP parcialmente não se enquadra nesses requisitos. Portanto, o C # permaneceu como base e implementou o que fez bem no âmbito do primeiro monólito - trabalhando com o conteúdo dos materiais de publicidade - mas com base em outro armazenamento: armazenamento compatível com S3 e Kafka.
Para trabalhar com o novo modelo de negócios, o Scala e o banco de dados PostgreSQL foram selecionados desta vez. A Scala atendeu aos nossos requisitos técnicos. Além disso, os desenvolvedores do Scala estavam localizados no mesmo andar dos desenvolvedores de C #. Isso reduziu o tempo para a comunicação da equipe. A lei de Conway funcionou - a estrutura da empresa ditou a estrutura do aplicativo. O desenvolvedor do PHP se tornou um desenvolvedor Scala. Acabei de terminar um trabalho em um microsserviço independente em Golang com um ciclo completo de CI / CD, após o qual entrei para a equipe e também me tornei desenvolvedor da Scala.
É interessante o que exatamente eu propus usar para trabalhar com a lógica de negócios Scala, e não o C #. O fato é que não tínhamos desenvolvedores de C # suficientes. O PHP-shnik e eu queríamos treinar novamente para o Scala. Além disso, tivemos a oportunidade de atrair um desenvolvedor experiente do Scala. Outro ponto: se implementássemos tudo em C #, poderíamos obter uma arquitetura de microsserviço ou outro monólito na saída. A divisão em Scala e C #, diferentes necessidades de armazenamento e a disponibilidade de desenvolvedores experientes em cada uma das áreas necessárias - tudo isso apontou diretamente para a arquitetura de microsserviço. E nós apenas nos beneficiamos disso. Há um ano, a arquitetura de microsserviços para trabalhar com materiais gráficos e textuais entrou em operação comercial e está operando com sucesso até hoje.
Para a questão de saber se é possível criar uma arquitetura de microsserviço a partir do zero. Há um ano e meio, no processo de trabalhar na arquitetura de microsserviços, surgiu uma demanda para apoiar uma nova direção em nossos produtos - materiais de publicidade em vídeo. Era necessário testar rapidamente um novo modelo de vendas. Nossa arquitetura estava em sua infância. O trabalho com materiais de vídeo cobriu uma nova área de tecnologia. Decidimos não alterar o vetor de desenvolvimento e implementamos o MVP para materiais de vídeo como uma arquitetura de microsserviço independente em C # e hospedagem de vídeo confiável. Esta é uma experiência bem-sucedida e temos um
relatório sobre esse tópico. Portanto, temos duas arquiteturas de microsserviço existentes em paralelo. O MVP não desenvolveu muito, o Wishlist também acumulou e, em breve, combinaremos tudo dentro da estrutura de uma única arquitetura de microsserviço - teremos um repositório único de textos publicitários, gráficos e materiais de vídeo.
- Imediatamente, existem dois fatores importantes que falam em favor dos microsserviços. A primeira é a capacidade de produzir partes individuais para a nuvem e, como resultado, uma escalabilidade colossal. O segundo é a capacidade de criar um serviço separado em outro idioma. Quais outras vantagens da mudança para microsserviços você vê? Bem, dos pontos negativos, é claro, eu também quero ouvir.Se falamos sobre o componente tecnológico, as vantagens, além do acima, incluem a possibilidade de usar outra pilha de tecnologias. E se ele não nos convém, escolheremos outro. Novas tecnologias ignoram os problemas de soluções antigas. A arquitetura de microsserviço também oferece estabilidade e independência: a degradação de um serviço não deve levar à degradação completa de todo o sistema. A composição do serviço permite a reutilização da funcionalidade do serviço em outras arquiteturas de microsserviço. Do ponto de vista do componente organizacional, a divisão em serviços permite dividir o desenvolvimento em equipes distribuídas ou em uma equipe grande.
As principais desvantagens da arquitetura de microsserviço: é muito mais complicada e sua implementação é mais cara.
Você também precisa estar preparado para oferecer suporte a contratos de serviço, selecionar o protocolo de acesso remoto correto, resolver problemas de interação entre serviços segura, possíveis falhas, além de desduplicar e gerenciar transações distribuídas.
Em geral, no domínio público, você pode encontrar muitas informações e materiais sobre como trabalhar com ele. Mas, na verdade, tudo depende da tarefa. Na minha prática, as vantagens sempre foram mais significativas que as desvantagens.
Ainda vale lembrar as palavras de Sam Newman: quanto menos o serviço, mais todas as vantagens e desvantagens da arquitetura de microsserviços são manifestadas.
- Você tem alguns relatórios interessantes sobre microsserviços. Implantação de microsserviços e a Abordagem de implantação contínua na arquitetura de microsserviços . Em um dos slides do primeiro, existem modelos de implantação e, no relatório, você diz que, para você, a abordagem de tendência é a distribuição por contêineres. Durante esse tempo, nada mudou? Um monte de Docker + Kubernetes não perdeu sua relevância?Estamos transferindo cada vez mais serviços para este pacote. Penso que escolhemos a direção certa e, por enquanto, pretendemos aderir a ela. Se algo mudar, eu falarei sobre isso em um novo relatório ou entrevista.
- Quão suave é a implantação e transferência contínuas de microsserviços para prod?Tudo depende de como construir o processo. A princípio, parece que tudo é simples. Os serviços são independentes, implantados separadamente. A fraca coerência é assegurada por diferentes abordagens para trabalhar com a evolução do contrato. E aqui você tem que escolher. Por exemplo, você pode implementar a versão de um contrato ou adicionar um serviço para desconectar um contrato (dissociação de contrato).
Se em uma arquitetura de microsserviço em desenvolvimento ativo, existem 10 ou mais serviços ao mesmo tempo e cada um tem seu próprio controle de versão, existe um problema de consistência de versão. Devemos tentar não nos confundir na compatibilidade de serviços de versões diferentes.
A implantação contínua significa que podemos entregar o aplicativo a qualquer momento em qualquer ambiente.
Um aplicativo na arquitetura de microsserviço é uma coleção de serviços. Portanto, a qualquer momento, precisamos conhecer uma combinação estável de versões de serviço. E em outro lugar, devemos ter um conjunto de endereços de domínio e outros parâmetros específicos para diferentes ambientes para configurar serviços e vinculá-los um ao outro.
Tudo isso precisa ser armazenado em algum lugar, para corrigir alterações em vários locais (afinal, os microsserviços são independentes) e para não ficar confuso.
Implantação contínua significa a capacidade de reverter para qualquer versão a qualquer momento. Portanto, pode ser que você precise reverter vários serviços de uma só vez e observe a ordem inversa correta da implantação do serviço.
Em um dos meus relatórios, falo sobre nossa abordagem à evolução dos contratos, como eles resolveram o problema da consistência das versões e como eles criaram o processo de implantação na arquitetura de microsserviço de mais de dez serviços. Uma implantação contínua pode não estar livre de problemas, mas tudo é solucionável.
- Qual poderia ser o conjunto inicial de ferramentas para uma implantação contínua de microsserviços? Quais opções você recomendaria usar para trabalhar com microsserviços?A implantação contínua é uma sequência de pipelines, incluindo integração contínua, testes de integração e entrega de serviços ao ambiente de orquestração. As ferramentas mais populares de seqüenciamento de etapas são
Jenkins 2 Pipelines ,
TeamCity Build Chains ,
Bitbucket Pipelines e
GitLab CI Pipelines . Primeiro, você precisa automatizar a integração contínua (IC). Precisamos de um servidor de IC remoto para criar e executar testes neste assembly.
As ferramentas listadas oferecem suas soluções. Nós usamos o GitLab CI, e os GitLab Runners agem como esses servidores. O artefato de construção é a imagem do
Docker . Como parte dos testes de integração, você pode realizar testes de carga e capacitivos usando
Gatling , em particular, para determinar os recursos necessários (processador e memória) para funcionar em um ambiente de orquestração (por exemplo,
Kubernetes ).
O Helm é amplamente utilizado para implantação, permitindo descrever a arquitetura de microsserviço para diferentes ambientes. Em nossa empresa, não usamos Helm. Temos nossa própria ferramenta de implantação, criada quando o Helm estava na versão clássica e não suportava ambientes diferentes. Ambas as ferramentas têm qualidades úteis semelhantes, mas a implementação e a distribuição são diferentes. E nossa própria ferramenta nos permite fazer melhorias e adaptar tudo à nossa infraestrutura.
- Quais tecnologias são ideais para pequenas e médias empresas que desejam implementar microsserviços? É um prazer muito caro para eles?Cada vez mais, encontro confirmações de que pequenas e médias empresas são inadequadas para criar seu próprio ambiente de orquestração (por exemplo,
Kubernetes ,
Docker Swarm ou
Apache Mesos ). . (
Google Cloud Platform ,
Amazon Web Services ,
Microsoft Azure Oracle Cloud ) .
GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .
, , , open source, .
Spinnaker Heroku — , , .
— , , , . . ?, . , , .
( ) . .
. . , (package). .
( ) Docker-, Git. , . ,
. , .
, . : API. . : . , API. , API , — . , API, .
. , ; API, ; , , .
, , . , ?— - .
, API, , . . .
, , . , , . , , .
— , . 2. , ? ?. .
Mesosphere ,
OpenShift PaaS IaaS . Deis
,
Deis . open source
Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .
Deis2 . Deis, Kubernetes.
Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.
— , , , ? ?Helm. , . Helm .
Helm , — : , .
Helm chart' chart, , .
2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.
API
API Gateway . , — .
, : . , , .
DevOps , . DevOpsConf Russia .
DevOpsConf Russia 1 2 RootConf, , , , . DevOps , .
DevOps , , – . 15 .