Artigos Java Microservices RESTful com Spring Boot e Reactor

Por que eu devo ler este artigo:A Arquitetura Orientada a Serviços, ou SOA, tornou-se um padrão nas empresas quando existe a necessidade de integração entre sistemas.

Sem dúvidas, esse padrão tem sido a base para oferecer às organizações o poder de gerenciar o fluxo de informações e escolher a melhor maneira de tratá-las.

Porém, com o advento da Computação em Nuvem, houve um significativo aumento na flexibilidade com que recursos computacionais são disponibilizados às aplicações, facilitando bastante a criação de aplicações distribuídas.

Diante disso, surgiu uma nova forma de oferecer serviços dentro do padrão SOA. Conhecido como micro serviços, este novo conceito oferece boas vantagens frente às aplicações monolíticas encontradas nas empresas, principalmente com relação à escalabilidade.

Pensando nisso, este artigo tem como objetivo apresentar conceitos e demonstrar a criação de um micro serviço usando ferramentas que têm revolucionado o desenvolvimento ágil contemporâneo: Spring Boot, Reactor e Gradle.

Após uma série de escândalos financeiros em meados de 2001, quando grandes empresas americanas fraudaram demonstrações financeiras para encobrir prejuízos – o que fez com que muitos investidores tivessem grandes prejuízos – o congresso americano aprovou uma lei denominada Sarbanes-Oxley.

Também conhecida como SOX, esta lei penaliza, criminalmente, executivos de empresas com ações na bolsa de Nova York por fraudes ou desvios em demonstrações financeiras.

Diante deste novo contexto de responsabilidade financeira, houve um significativo aumento na pressão por uma maior transparência nos relacionamentos envolvendo acionistas, conselho, diretoria, auditoria independente e conselho fiscal. Para alcançar tal transparência, as empresas buscaram os princípios de uma metodologia conhecida como Governança Corporativa.

Esta busca alavancou também a adoção dos princípios de outra metodologia, denominada Governança de TI. De fato, a Governança de TI está muito ligada à gestão corporativa, porque sistemas de informação constituem uma peça fundamental na gestão de toda a complexidade encontrada nos processos de uma organização.

Deste modo, os holofotes voltaram-se para os departamentos de TI das grandes empresas, gerando uma reflexão sobre como os sistemas controlavam a informação e, principalmente, como trocavam tais informações entre si.

A partir daí guias como o COBIT (Control objectives for information and related technology) estabeleceram-se dentro das empresas e, analisando sob o âmbito do desenvolvimento de software, conceitos como BPM (Business Process Management) e SOA (Service-Oriented Architecture) se fortaleceram, ganhando cada vez mais espaço dentro das grandes corporações.

Nesta época, a prática de SOA mostrou-se como uma solução de baixo custo e com maior flexibilidade para integrar os sistemas monolíticos encontrados nas empresas. Além disso, o SOA proporcionava maior proximidade aos requisitos relacionadas à transparência demandados pelas novas políticas corporativas. Outro fato relevante, que contribuiu ainda mais para o desenvolvimento deste estilo arquitetural, foi o progresso de tecnologias relacionadas a web services na primeira década deste século, ocorrido a partir do esforço em conjunto de empresas como Microsoft, Sun, IBM e Oracle.

SOA – Arquitetura Orientada a Serviços

Por definição, Arquitetura Orientada a Serviços é um design pattern no qual componentes oferecem serviços a outros componentes através de um protocolo de comunicação. Geralmente, o método de integração usado para esta comunicação é conhecido como “Integração Horizontal”, ou Enterprise Service Bus (ESB), onde há um barramento central responsável por controlar o fluxo de eventos e informações entre os componentes.

O princípio básico da orientação a serviços é ser independente de qualquer software ou tecnologia específica. Sendo assim, SOA não é um padrão de tecnologia enterprise, que depende de um único protocolo de comunicação, como IIOP ou SOAP, ou de uma única linguagem de programação, como Java ou .NET.

Pelo contrário, muitas vezes incorpora diferentes tecnologias independente do protocolo de comunicação ou linguagem de programação. O foco da arquitetura SOA é a definição clara e objetiva de contratos de serviços orientados ao negócio, muito mais do que a tecnologias.

Por esse motivo, SOA tem sido, há alguns anos, um padrão de arquitetura predominante em grandes companhias.

Isto porque é possível, de forma estruturada, realizar integrações entre múltiplos sistemas heterogêneos, sejam eles de Business Intelligence, BPMs, portais corporativos, RH, ERP, CRM, entre outros.

Em meio a todas essas inovações “arquiteturais” que nasceram dentro das grandes corporações, surgiu um novo elemento que, além de transformar todo o universo da computação contemporânea, também contribuiu para a evolução da arquitetura SOA.

Tal elemento é a Computação em Nuvem, ou Cloud Computing. A Computação em Nuvem proporcionou o provisionamento dinâmico de recursos computacionais, o que trouxe uma nova perspectiva para a indústria da tecnologia da informação e também alavancou a criação de um novo padrão dentro do conceito de arquitetura orientada a serviços, denominado micro serviços.

De acordo com as definições de Anne Thomas, vice-presidente do Gartner Group: “Micro serviços é a prática de aplicar princípios da arquitetura orientada a serviços em um nível de granularidade menor”.

Pierre Fricke, diretor de marketing de produto da Red Hat JBoss Middleware, define micro serviços como: “Um nome que denota uma forma mais leve e mais rápida de desenvolver e distribuir do que o SOA tradicional”.

Micro serviços e o princípio da responsabilidade única

De um modo geral, pode-se dizer que micro serviços são softwares independentes com responsabilidades muito bem definidas e que expõem seus comportamentos através de uma API. Em conjunto, podem compor uma ou mais soluções tecnológicas. Uma vez que o princípio básico de um micro serviço é o da Responsabilidade Única (Single Responsible Principle – SRP), cada um deve limitar-se a um único escopo de trabalho.

Por exemplo, em uma loja virtual pode-se definir um micro serviço para consulta de CEPs, outro para calcular o frete com base naquele CEP e no peso dos produtos do carrinho de compras, um para processar o pedido e outro para emitir a Nota Fiscal eletrônica.

Todos esses micro serviços trabalhando em conjunto determinam o sistema de E-commerce da loja virtual.

Contudo, entre as inúmeras vantagens dessa arquitetura, existe uma que foi especialmente alavancada pela Computação Elástica: a possibilidade de escalar cada micro serviço individualmente.

Isto é possível porque um micro serviço possui um contexto individual de execução, que pode ser sua própria JVM, ou até mesmo seu próprio servidor virtual dedicado.

A Netflix, por exemplo, possui o seu sistema distribuído em micro serviços instalados em múltiplas instâncias da Amazon EC2, e por isso pode ser escalado muito facilmente.

Tal benefício também chamou a atenção de arquitetos Java EE. Isto porque o consumo de CPU do GC (Garbage Collector) é proporcional ao tamanho da memória Heap disponibilizada para a JVM. Isto é, o GC irá percorrer toda a memória Heap com o objetivo de eliminar objetos que não estão mais sendo usados.

Diante disso, quanto maior a memória Heap, maior o tempo que ele levará para percorrê-la, e com isso, maior será a quantidade de instruções enviadas para a CPU.

Sendo assim, dependendo do algoritmo escolhido para o GC e de sua frequência de execução, a opção por memórias Heap muito grandes pode causar contenção de CPU e comprometer todo o sistema.

Então, mesmo com servidores com capacidades de memória RAM cada vez maiores, é prudente ter cautela na alocação de mais do que 4GB par ...

Quer ler esse conteúdo completo? Tenha acesso completo