Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Descomplicando Service Mesh
Semelhante a Descomplicando Service Mesh (20)
Mais de Roberto Alves
Mais de Roberto Alves (10)
Descomplicando Service Mesh
- 1. Descomplicando Service Mesh Roberto Alves Coordenador de Produtos Digitais @ Hospital Israelita Albert Einstein
- 2. O que exatamente é a Service Mesh?
- 3. Service Mesh? • Em tradução livre, é uma malha de serviços; • É uma tecnologia que gerencia como diferentes componentes compartilham dados entre si; • É uma camada de infraestruturada dedicada; • Surgiu por volta de 2016.
- 8. Use cases
- 9. Service Mesh vs API Gateway?
- 10. Principais benefícios? • Visibilidade do desempenho das interações entre os componentes do seu ecossistema; • Manipulações da rede como balanceamento de carga, disjuntores, retries, timeout, routing inteligente; • Aplicar técnicas de avançadas de implantação como Canary Deploy, Dark Launches, etc; • Circuit Breaker; • Fault Injection; • Incrementa o nível de segurança e confiabilidade de todo o ecossistema (man-in-the-middle, mTLS, AAA); • Observabilidade/rastreabilidade (métricas, traces distrubuídos, logs); • Etc.
- 11. Malefícios? • Adiciona complexidade ao seu ecossistema; • Com o Service Mesh haverá um acréscimo a sua latência (existirão dois passos extras na sua rede).
- 12. Como implementar a Service Mesh?
- 15. Instalação
- 16. Instalação
- 17. Instalação
- 18. Instalação
- 19. Instalação
- 20. Instalação
- 21. Instalação
- 22. Circuit Breaker
- 23. Circuit Breaker
- 24. Circuit Breaker
- 25. Circuit Breaker
- 26. Circuit Breaker
- 28. 0800.648.3300 senior.com.br (11) 95485-0300 senior.sistemas1 Obrigado! https://www.linkedin.com/in/robertosousa01/ https://www.slideshare.net/robertoalves95/ https://github.com/robertosousa1/
Notas do Editor
- Desenvolvedor desde os 14 anos Palestrante (Serverless Week, Dockercon, Elastic, TDC, etc) Contribuidor Open Source (95k downloads) Associado a Sociedade Brasileira de Informática em Saúde Membro do comitê público da Associação Nacional dos Profissionais de Privacidade de Dados AWS Community Builder Agradecimento ao Evandro
- Em poucas palavras, service mesh pode ser considerado uma "camada" de rede abstrata para comunicações de serviços.
- Diferente de outros sistemas de gerenciamento de comunicação, a service mesh é uma camada de infraestrutura dedicada Entre esses benefícios, conseguimos estruturar o pilar de observabilidade Mas pode seguir a pergunta: "Mas microsserviços já não fazem isso?"
- A chegada do service mesh deveu-se em grande parte a uma perfeita tempestade no cenário de TI Os desenvolvedores começaram a cada vez mais criar sistemas distribuídos As operações queriam/querem lidar com as inevitáveis falhas de comunicação e aplicar políticas de rede A essência dos microsserviços está na comunicação serviço a serviço (agora pense em um cenário com mais de 1 mil microsserviços) Quando falamos puramente de microsserviços, não é necessária uma camada de service mesh para que a comunicação ocorra, o serviço em si, é responsável por criar essa comunicação, logo o desenvolvedor é o responsável por tal, mas conforme a complexidade da comunicação aumenta Entretanto, quanto mais cresce os seus serviços, provavelmente mais você sentirá a necessidade de ter algo como a Service Mesh
- A service mesh não adiciona uma funcionalidade nova ao ambiente de execução da aplicação Em qualquer arquitetura, as aplicações precisam de regras para especificar como as solicitações partem do ponto A e são recebidas pelo ponto B A service mesh é diferente porque retira a lógica que rege a comunicação entre serviços e a transfere para uma camada de infraestrutura Para que isso seja possível, é necessário que a service mesh seja incorporada à aplicação como uma matriz de proxies de rede Proxy é um conceito já conhecido pela TI corporativa. Se você estiver usando seu computador do trabalho para acessar esta página, provavelmente utilizou um proxy Explicar exemplo do proxy
- Em uma service mesh, as solicitações são encaminhadas entre microsserviços utilizando proxies em uma camada de infraestrutura própria Por esse motivo, os proxies que compõem uma service mesh são, às vezes, chamados de "sidecars", pois são executados paralelamente a cada serviço, não dentro dele Juntos, esses proxies "sidecars", desacoplados de cada serviço, formam uma rede em malha Sem a service mesh, é necessário codificar cada microsserviço com a lógica que rege a comunicação de serviço a serviço, resultando em menos tempo para que os desenvolvedores se concentrem nas metas de negócios Além disso, a falta da malha dificulta a identificação de falhas na comunicação e alto acoplamento
- Um service mesh gerencia todo o tráfego de serviço a serviço "leste-oeste" em um sistema distribuído; Citar comparação com o EBS; Um API gateway gerencia todo o tráfego de entrada "norte-sul". Atua como o único ponto de entrada em um sistema;
- Man in the middle criptografia nas chamadas para ninguém capturar a chamada no meio do caminho mTLS para garantir TLS em todas as pontas (Open Banking) Triple AAA (authentication, authorization e audit) – criar regras com esses pilares
- Nem toda arquitetura de microsserviço necessita de um Service Mesh; O primeiro é do proxy que lida com a conexão de saída da fonte e o segundo é do proxy que lida com a conexão de entrada do destino;
- Istio é um projeto open-source que implementa Service Mesh visando diminuir a complexidade no gerenciamento de aplicações distribuídas independente de qual linguagem ou tecnologia foram desenvolvidas; Netflix OSS, Service Mesh na mão;
- O Istio Mesh é a Arquitetura do Istio (site oficial) Cada pod terá sempre dois containers Um container será o proxy, onde chamada naturalmente passará por esses proxy que terá a configuração de retry, timeout, etc Perceba que tanto o serviço A quanto o B tanto para receber quanto enviar depende do proxy O proxy utilizado pelo istio é o Envoy, bem completo e complexo E a configuração dos proxys, fica em um container chamada istioD e ele replica as configurações para todos os proxys Com isso, é possível obter métricas e ter um controle simplificado e todo esse processo é chamado de Data plane, o responsável por controlar o data plane é o Control pane Dentro do Control Pane, nós temos o Pilot que controla as configurações de forma geral, o Citadel que geralmente trabalha com a autenticação e identidade e o Galley que traduz a sua configuração para a forma como o Istio entende... isso porque vc pode estar o usando o kbs, ecs, etc; Antigamente isso tudo eram containers separados, agora fica tudo dentro do IstioD A grande sacada é o proxy
- O K3D é um projeto da Rancher Labs que facilita a criação de um cluster K3S de um ou vários nós para desenvolvimento de aplicações em sua máquina local para kubernetes
- Golang - go breaker Vou chamar esse cara e se ele demorar x segundos, eu paro de chamar isso
- Criar um arquivo yml - circuit-breaker.yaml O DestinationRule é aplicado quando chega em determinado destino – no caso para qual código/container irá encaminhar A outlier detection é o circuit breaker Base ejection é sempre dobrado o valor Explicar o erro 500
- Para trazer uma experiência legal, usaremos também o Kiali, que é um pacote que traz um admin para que você possa visualmente acompanhar o que está acontecendo com seu Istio.8 de nov. de 2018