¶ Integrações - ISESC
Definir soluçoes de integração com sistemas legados e ecossistemas de parceiros, propondo as boas práticas e os padrões que servirão de fundação para oferta de uma capacidade de integração abrangente e distribuída que atenda os desafios da Globo.
Grafico com as integrações suportadas pelo nosso time
¶ Princípios de integração
-
Desacoplamento entre aplicações
As aplicações devem sempre que possível estar desacopladas para permitir evolução futura da arquitetura sem maiores impactos. -
API's e eventos
O foco deve ser menos centrado na integração ponto a ponto e mais na exposição de api's e eventos, que garantem maior poder de composição e reuso dos serviços. -
Governança e monitoração
A governança e monitoração das API's e eventos potencializa o reuso, protege as aplicações clientes através dos contratos de interface e traz visibilidade sobre o consumo. -
Descentralização e autonomia
Responsabilidade distribuída entre os times permite a escala e agilidade necessária para uma empresa digital.
¶ Arquitetura de integração
¶ APIs e Eventos
Aplicações legadas estarão acessíveis para aplicações modernas através de um decoupling layer. O objetivo desta camada será expor eventos e APIs em torno dos legados e ecossistemas, para que seus serviços possam ser consumidos sem fricção.
¶ Governança e Mediação
As ferramentas de API Manager e Event Bus garantem o desacoplamento entre as aplicações, além de permitir a governança de APIs e eventos.
O Event Bus garante a integração por eventos entre as aplicações, permitindo que uma aplicação possa funcionar independentemente da outra estar operante.
O API Manager garante a integração governada através de APIs, permitindo que uma aplicação consuma serviços de outra de maneira segura, moderna e com insights de consumo.
¶ Adapter
Os Adapters são componentes de software que se acoplam a uma aplicação com limitações de integração e permitem que ela possa interagir com outras aplicações através da exposição e consumo de interfaces, sejam elas APIs ou eventos.
Os Adapters de serviço plugam suas interfaces na camada de governança e mediação (decoupling layer), realizando um papel técnico para conversão de protocolos de comunicação e um papel funcional na conversão entre linguagens sistêmicas e de negócio.
¶ Batch
Indicado quando uma aplicação provedora não dispõe de interfaces modernas para coleta de eventos ou carga de dados para processamento em lote.
¶ Governança e Mediação
O data hub tem o papel principal de desacoplar o provedor do consumidor dos dados. Ele pode ser composto por um conjunto de ferramentas que vão ingestar o dado, armazená-lo e prepará-lo para consumo externo.
Dentro desta camada, o modelo de dados deve abstrair e simplificar a complexidade da relação entre os dados das origens e usar uma linguagem de negócio.
¶ Adapter
Os Adapters numa arquitetura Batch são componentes de software que se acoplam a uma aplicação para extrair ou carregar dados processados em lote. Eles se encarregam de movimentar o dado entre o data hub e a origem/destino de dados.
O Adapter deve se encarregar de converter o modelo de dados sistêmico no modelo de dados de negócio, onde a informação poderá ser consumida por diversos consumidores sem que cada um precise entender o modelo de dados interno da aplicação provedora.
¶ BOAS PRÁTICAS E PADRÕES
- Buscar uma arquitetura que estruture a solução de software através de um conjunto de serviços colaborativos e fracamente acoplados, onde cada serviço seja desenvolvido, mantido e testado por um único time através de entregas ágeis e sucessivas.
- Cada serviço deverá expor a possibilidade de ação sobre os conceitos de negócio que mantem fazendo o uso de APIs.
- Serviços expõe mudanças de estado sobre os conceitos que mantem através de eventos.
- Consumidores que estejam interessados em consumir eventos publicados se subscrevem para receber suas notificações.
- Consumidores que possuam restrições tecnológicas para consumir eventos farão uso de adaptadores capazes de consumir e de propagar o evento gerado através da exposição ou consumo de APIs.
- Integrações com sistemas legados que possuam restrições tecnológicas serão expostas através de adaptadores capazes de abstrair essas restrições.
- O desenho das integrações deverá fazer uso de padrões de integração (EIP -Enterprise Integration Patterns) para garantir a aderência aos princípios de arquitetura de integração.
¶ PRINCÍPIOS
- Contrato de Interface Padronizado – Serviços devem aderir a um padrão e protocolo de comunicação que descreva como enviam e processam mensagens.
- Baixo Acoplamento – Serviços devem manter relacionamentos que minimizem a dependência e que apenas requeiram manter o conhecimento da sua existência e propósito.
- Abstração – Apenas o conhecimento do serviço e de seu contrato de interface deve ser necessário para sua utilização.
- Reutilização – O desenho e estratégia de composição dos serviços devem promover a sua reutilização.
- Autonomia – Serviços devem ser autocontidos, sendo capazes de controlar sua lógica de forma independente.
- Ausência de Estado – Serviços devem minimizar o consumo de recursos evitando o gerenciamento de estados da informação.
- Capacidade de Descoberta – Serviços devem usar protocolos e metadados que padronizem e facilitem sua identificação e interpretação.
- Granularidade – O desenho dos serviços de prover um nível de granularidade e escopo adequados para ofertar funcionalidades de negócio.
- Capacidade de Composição – Serviços devem ser efetivos para compor capacidades de negócio independentemente do tamanho e complexidade desta composição.
- Normalização – Serviços devem ser decompostos ou consolidados em níveis de normalização que minimizem a redundância ou promovam a melhorias de desempenho ou acesso.
- Relevância – As funcionalidades ofertadas devem ter significado e utilidade reconhecidos para o negócio.
- Transparência - Se refere à habilidade de uma aplicação consumidora de um serviço em consumi-lo sem a necessidade de conhecimento de sua localização na rede.
¶ DIRETRIZES
¶ APIs
- As APIs devem usar uma linguagem de negócio, específica de cada contexto, se desacoplando da linguagem interna da aplicação provedora. Isso garante maior desacoplamento entre as aplicações e maior longevidade nas integrações já que a linguagem de negócio muda numa frequência menor que uma aplicação.
- As APIs devem usar protocolos de comunicação interoperáveis (Ex.: HTTPS).
- APIs restritas (B2B) devem ser expostas através de um API Manager para fins de governança e segurança.
- Aplicações que necessitem ser acessadas por aplicações de outros domínios de negócio, precisam publicar suas APIs através de um API Manager para fins de governança e segurança.
- APIs governadas devem estar divulgadas através de um Portal de Desenvolvedores dando visibilidade para outros times e promovendo seu reuso.
- APIs com informações sensíveis devem requerer autenticação para serem consumidas, onde cada aplicação cliente precisará ter sua própria credencial. Deve-se usar mecanismos de autenticação que retirem dos serviços a responsabilidade pela sua autenticação (Ex.: OAuth).
¶ Eventos
- A comunicação entre serviços através de eventos deve ser preferida quando houver necessidade de autonomia do serviço, quer seja por razões de proteger o serviço de um volume excessivo de requisições externas, quer seja por garantir sua tolerância a falhas.
- Os eventos devem usar uma linguagem e terminologia específicas de seu domínio de negócio, se desacoplando da linguagem específica da solução de sistêmica que o suporte.
- Eventos de domínio de negócio devem ser publicados através de um único meio que seja confiável e acessível através de protocolos interoperáveis (Ex.: AMQP).
- Todo evento de domínio deve ser registrado de maneira atômica junto com seu estado (transaccionalmente).
- Um serviço que publica um evento deve desconhecer os seus consumidores.
¶ Batch
- A integração por batch se aplica quando a aplicação provedora tem restrições tecnológicas e não dispõe de interfaces que permitam o consumo dos eventos e mudanças de estado assim que eles ocorrem.
- A integração por batch não deve ser pensada ponto a ponto, ou seja, deve-se imaginar que mais de uma aplicação consumidora poderá consumir a informação.
- O modelo de dados da aplicação de origem não deve ser exposto para as aplicações consumidoras para evitar o acoplamento.
- O modelo de dados exposto para consumo deve ser um modelo que abstraia a implementação da aplicação provedora e utilize uma linguagem e terminologia específicas de seu domínio de negócio.
¶ Quando usar cada estilo
-
Eventos
Quando uma aplicação precisar reagir a eventos ocorridos em outros domínios, seja para realizar uma ação na sequência, seja para armazenar uma versão adaptada para seu modelo de informação dos eventos ocorridos externamente. -
APIs
Quando for necessário um aplicação comandar ações em outra ou consultar informações de forma interativa. Também suporta interações entre front-end e back-end. -
Batch
Para quando a necessidade do negócio é baseada em processamento em lote. Ex: Lançamentos contábeis e análise de dados.