Microservices

APLICAÇÕES MONOLÍTICAS

Captura2r

  • Fornece Macro-funcionalidades;
  • Toda a capacidade do negocio/domínio esta em uma mesma funcionalidade ou serviço;
  • Aplicação dividida em camadas;
  • Arquitetura dependente;
  • Deploy simples;
  • Hospedado em um servidor especifico;
  • Desenvolvimento altamente dependente da plataforma;
  • Escalabilidade vertical;
  • Evolução comprometida;
  • Banco de dados integrado:
  • Deploy centralizado:

Capturar1

APLICAÇÕES EM MICRO-SERVIÇOS

Capturar

  • Fornece Micro-funcionalidade;
  • Isola responsabilidades;
  • Solução granular;
  • Divisão de responsabilidades entre projetos/serviços;
  • Alta disponibilidade e escalabilidade;
  • Escalabilidade na capacidade de negocio;
  • Altamente desacoplada;
  • Solução segmentada e distribuída;
  • A aplicação não é desenvolvida em termos de projetos e sim em serviços/produtos;
  • Monitoramento especifico por serviço;
  • Pode ser desenvolvimento em varias plataformas ao mesmo tempo;
  • Dados decentralizados;
  • Banco de dados segmentados;
  • Serviços específicos podem compartilhar bancos de dados distintos;
  • A integração entre serviços pode ser feita através de messageria (RabbitMQ);
  • Deploy descentralizado:

Captura2r

  • Componentização via serviços;

Capturar

 

Referência:
http://martinfowler.com/articles/microservices.html
http://martinfowler.com/microservices
http://microservices.io/

Anúncios

Padrões de projeto – SOLID

Em arquitetura de software devemos seguir alguns padrões para que nossos projetos possam crescer de forma segura, facilitando a manutenção do código e expansão do projeto. A seguir vou demonstrar um conceito muito conhecido de cinco princípios que devem ser seguidos para que o seu projeto tenha um nível alto de entendimento.

S O L I D

Single Responsability Principle – SRP (Responsabilidade única): Parte do principio que uma classe ou método deve ter uma única responsabilidade. Deve ter apenas uma razão para mudar.

Open Closed Principle – OCP (Aberto fechado): Uma classe deve sempre estar aberta para EXTENÇÃO e fechada para MODIFICAÇÃO.

Liskov Substitution Principle – LSP (Substituição Liskov): Deve ser possível substituir uma classe base por suas classes derivadas em quanquer ponto do código.

Interface Segregation Principle – ISP (Segregação de  interface): Clientes não devem ser obrigados a depender de interfaces que eles não utilizam. Muitas interfaces de um cliente especifico é melhor do que uma interface de uso geral.

Dependecy Inversion Principle – DIP (Inversão dependência): Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações. Abstrações não devem depender de detalhes, detalhes devem depender de abstrações, por exemplo, uma classe deve depender de uma interface ou classe abstrata e não de uma classe concreta.