rsxo / devcommerce2016-microservices-power-patterns-pains Goto Github PK

por Marcos Barbero

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

-- James Lewis and Martin Fowler

• Service Discovery & Registration
• Configurações centralizadas
• Edge Services: Micro Proxies e API Gateways
  • Roteamento e balanceamento
• Tolerância à falhas (Circuit Breakers)
• Security and Single Sign-On
• Complexidade Operacional
  • Monitoração
  • Distributed Tracing
• Cultura DevOps

Quebrar uma aplicação em vários serviços menores não significa que você esteja em uma arquitetura de micro-serviços. Esse é apenas o primeiro passo.

• Segundo cenário

Uma das boas praticas fornecidas pelo manifesto 12factor é a externalização de configurações do build, assim o mesmo build poderá ser promovido qualquer ambiente: Dev, QA, Prod.

Ferramentas:

• Spring Cloud Config
• Netflix Archaius
• Apache Zookeeper
• HashiCorp Consul

Novas aplicações (e instâncias) podem iniciar ou parar e o local dela pode mudar, é importante desacoplar do client o endereço do serviço. Pense no Service Discovery & Registration como um catálogo onde os endereços das instâncias são encontrados à partir do nome lógico.

Ferramentas:

• Netflix Eureka
• Apache Zookeeper
• HarshiCorp Consul

Um dos benefícios de usar um Service Discovery é o balanceamento do lado do client. Esse balanceamento permite a aplicação escolher uma instância mesmo que exista 10 ou 1000 instancias rodando.

Ferramentas

• Netflix Ribbon
• Netflix Feign

Balanceamento do lado do client é usado somente entre comunicações entre serviços. Serviços que vivem na borda do datacenter, expostos para o tráfego público, são expostos por um DNS.

Responsabilidades:

• Roteamento
• CORS
• Segurança
• Etc

Na arquitetura de micro-serviços é crítico que os serviços sejam escritos para serem tolerantes à falhas. Se alguma coisa acontecer o serviço deverá se degradar sem causar maiores impactos. Em sistemas distribuídos se o serviço não for desenhado para tolerar falhas isso poderá ocasionar um efeito dominó através de outros serviços.

Ferramentas

• Play Framework
• Netflix Hystrix

Segurança é difícil, e em sistemas distribuídos é crítico verificar a procedência e autenticidade de um request através de multiplos serviços. Nesse modelo arquitetural todas as requisições devem chegar através de um ponto único de entrada (API Gateway), centralizando em um único ponto as chances de ataque de um invasor. Existem muitas estratégias de segurança para APIs e tudo depende do modelo de negócio e estratégia de segurança que deverá ser adotada. OAuth2 é um padrão bem popular na segurança de APIs.

Ferramentas

• Spring Security OAuth

Uma das vantagens de se trabalhar com micro-serviços são os deploys independentes e serviços mais simples, por outro lado, sistemas distribuídos trazem algumas dificuldades em níveis operacionais.

Monitoração é uma parte importante para qualquer aplicação em qualquer modelo arquitetural, e se torna uma tarefa difícil se não forem tomados os devidos cuidados durante o desenvolvimento. Todo serviço deve nascer com pelo menos um monitoramento básico.

Ferramentas

• Spring Boot Actuator
• Dropwizard
• ELK
• Graylog
• Statsd
• Graphite

Outra tarefa difícil para micro-serviços é fazer a correlação dos requests através de multiplos serviços e entender onde alguma coisa possa estar falhando.

Ferramentas

• Spring Cloud Sleuth
• Apache HTrace
• Twitter Zipkin

A arquitetura de micro-serviços só é possível com uma cultura DevOps.
DevOps não é uma pessoa de Operações dedicada 100% do tempo em ajudar o time de desenvolvimento, é a cultura do desenvolvedor também pensar em operações no desenvolvimento da aplicação, porque quando a aplicação falhar quem deveria ser acionado é o desenvolvedor da aplicação, não a pessoa que criou uma VM no datacenter.

Não reinvente a roda. Claro, como desenvolvedores nós queremos reescrever a roda à nossa maneira e claro, algumas vezes é necessário. Mas acredite em mim, você não vai querer reinventar tudo isso sozinho. Olhando todos esses desafios e dificuldades, tem muita coisa que precisa se levar em conta e na maioria das vezes escrever um framework não é parte do core business da empresa em que trabalhamos. Mesmo empresas grandes como Netflix e Alibaba usam Spring Cloud Framework, porque isso remove muita complexidade no tempo de desenvolvimento e permitem que os desenvolvedores foquem na essêcia do negócio da empresa.

It is not necessary to change. Survival is not mandatory. -W. Edwards Deming

O ponto aqui é que você não é obrigado à mudar, mas a mudança é a chave para a sobrevivência.

{
 "microservices": {
    "definition": "http://martinfowler.com/microservices",
    "trade-offs": "http://martinfowler.com/articles/microservice-trade-offs.html",
    "prerequisites": "http://martinfowler.com/bliki/MicroservicePrerequisites.html",
    "12factor": "http://12factor.net",
    "security": "http://presos.dsyer.com/decks/oauth-rest.html",
    "inspiration": "https://dzone.com/articles/the-power-patterns-and-pains-of-microservices"
  },
 "email": "[email protected]"
 "linkedin": "http://linkedin.com/in/marcosbarbero"
}