Habilidades avançadas em design de arquitetura de sistema · Teoria e prática de design de arquitetura orientada a serviços

Clique para entrar no diretório de séries de artigos

1. Conceitos relacionados de SOA

1.1Definição de SOA

A partir da definição dos princípios básicos de software, pode-se considerar que SOA é um modelo de componentes que conecta diferentes unidades funcionais de uma aplicação (chamadas de serviços) através de interfaces e contratos bem definidos entre esses serviços. A interface é definida de forma neutra e deve ser independente da plataforma de hardware, sistema operacional e linguagem de programação na qual o serviço está implementado. Isso permite que os serviços integrados em uma variedade de sistemas interajam de maneira unificada e comum.

1.2 Processo de negócios e linguagem de execução de processos de negócios

Linguagem de processos de negócios e execução de processos de negócios (Business Process Execution Language, BPEL) . Processo de negócios refere-se a um processo ou uma série de ações executadas para atingir um determinado propósito de negócios. Usando BPEL, os usuários podem implementar uma arquitetura orientada a serviços de cima a baixo, compondo, orquestrando e coordenando serviços da Web. O BPEL é atualmente usado para integrar serviços Web existentes e organizar os serviços Web existentes em um novo serviço Web de acordo com os processos de negócios necessários. Com base nisso, é formado um serviço que é igual a um único serviço do mundo exterior.

2. História do Desenvolvimento de SOA

(1) Estágio embrionário : Este uso generalizado de XML permite que as organizações definam os metadados de documentos, permitam a troca eletrônica de dados dentro e entre empresas e especifiquem o formato e a estrutura da troca de dados entre serviços e dentro dos serviços.

(2) Etapa de padronização : Padrões e especificações internacionais - Simple Object Access Protocol (SOAP), Web Service Description Language (Web Service Description, UDDI).

(3) Estágio maduro : 3 especificações pesadas - SCA, SDO, WS-Policy. SCA e SDO formam a base do modelo de programação SOA, e WS-Policy estabelece as especificações para interações seguras entre componentes SOA.

3. A diferença entre SOA e microsserviços

(1) Os microsserviços são mais sofisticados que a SOA. Os microsserviços existem mais como processos independentes e não têm influência uns sobre os outros.

(2) O método de interface fornecido pelos microsserviços é mais universal, como o método HTTP RESTful, que pode ser chamado por vários terminais, independentemente das restrições de idioma e plataforma.

(3) Os microsserviços estão mais inclinados a um método de implantação distribuído e descentralizado, que é mais adequado em cenários de negócios na Internet.

A seguir, um gráfico de comparação entre a arquitetura SOA e a arquitetura de microsserviços:

3. Arquitetura de referência SOA

A arquitetura de referência de integração de negócios Websphere da IBM é uma típica arquitetura de integração empresarial centrada em serviços, que pode ser dividida em seis categorias :

(1) Serviço de lógica de negócios.
(2) Serviço de Controle.
(3) Serviço de Conectividade.
(4) Serviço de Inovação e Otimização Empresarial.
(5) Serviço de Desenvolvimento.
(6) Gestão de Serviços de TI.

4. Principais especificações do protocolo SOA

Como segue, com base no protocolo de serviço da Web:

(1) Protocolo UDDI : protocolo unificado de descrição, descoberta e integração. Contém uma especificação padrão para descrição e descoberta de serviços, que permite que entidades comerciais descubram umas às outras; define como elas interagem na Internet e compartilham informações em uma arquitetura de registro global.

(2) Linguagem de descrição de serviços da Web (WSDL) : WSDL é uma linguagem XML usada para descrever serviços da Web e explicar como se comunicar com os serviços da Web. Descreve três atributos básicos de serviços da Web:

• O que o serviço faz – as operações (métodos) fornecidas pelo serviço.
• Como acessar o serviço - formato dos dados e protocolos necessários para interagir com o serviço.
• Onde o serviço está localizado – um endereço relacionado ao protocolo, como uma URL.
  A seguir está a estrutura estrutural básica do documento:
  

(3) Protocolo SOAP : SOAP é um protocolo simples para troca de informações em um ambiente descentralizado ou distribuído. É um protocolo baseado em XML.
(4) Especificação REST : Para permitir que diferentes softwares ou aplicativos transfiram informações entre si em qualquer ambiente de rede. Os microsserviços são expostos aos chamadores na forma de API REST. RESTful é a forma de REST. É um termo geral para um tipo de projeto arquitetônico ou aplicativo que segue as ideias de design REST enquanto satisfaz as restrições de design. Esse tipo pode ser chamado de RESTful, que pode ser entendido como transferência de estado expressivo de recursos:

• Recursos : Todas as transações expostas aos clientes na Internet podem ser consideradas um recurso.
• Representação : A representação é usada em REST para descrever o status dos recursos em um determinado momento na Web.
• Transferência de estado : dividido em dois tipos,
  estado do aplicativo - um instantâneo das informações relacionadas à sessão de solicitação do usuário dentro de um determinado período de tempo, salvo no cliente.
  Status do recurso - salvo no servidor, é um instantâneo da representação da solicitação de recurso em um determinado momento.
• Hiperlinks : Faça conexões com outros recursos incorporando links em suas páginas.

5. Requisitos padrão de design SOA

(1) Padronização de documentos .
Os serviços SOA possuem documentos XML autodescritivos independentes de plataforma. A linguagem de descrição de serviços da Web é uma linguagem padrão para descrever serviços.

(2) Padrões de protocolo de comunicação .
Os serviços SOA se comunicam por meio de mensagens, que normalmente são definidas usando o Esquema XML (também conhecido como Definição de Esquema XML, XSD).
(3) Cadastro unificado e integração de aplicativos .
Dentro de uma empresa, os serviços SOA são mantidos através de um registro que desempenha a função de Director Listing. A aplicação procura e chama um serviço no Registro. Descrição, definição e integração unificadas são os padrões para registro de serviços.
(4) Qualidade de serviço (QoS) . incluem principalmente:

• Confiabilidade : características de transmissão ao transmitir documentos entre consumidores de serviços e prestadores de serviços (e transmitir apenas uma vez, transmitir no máximo uma vez, repetir filtragem de mensagens, entrega garantida de mensagens)
• Segurança : As especificações de segurança do serviço da Web são usadas para garantir a segurança das mensagens.
• Políticas : os provedores de serviços às vezes exigem que os consumidores de serviços se comuniquem com uma determinada política. Por exemplo, um provedor de serviços pode exigir que os consumidores forneçam um token de segurança Kerberos para obter um determinado serviço.
• Controle : Em SOA, os processos são criados usando um conjunto discreto de serviços. BPEL4WS ou WSBPEL (Web Service Business Process Execution Language) é a linguagem usada para controlar esses serviços.
• Gerenciamento : Deve haver um sistema de gerenciamento unificado para todos os serviços executados em vários ambientes, para que os administradores do sistema possam gerenciá-los de forma eficaz. Qualquer serviço implementado com base em WSDM pode ser gerenciado por uma solução de gerenciamento da empresa WSDM.

6. O papel e os princípios de design da SOA

(1) A principal função da SOA: quebrar ilhas de informação e converter aplicações e recursos em serviços. E transforme esses serviços em serviços padrão para formar o compartilhamento de recursos.
(2) Os princípios de design da SOA incluem principalmente:

• Apátrida .
  Para evitar que o solicitante do serviço fique dependente do estado do provedor de serviços.
• Instância única .
  Use um método de implementação altamente coeso para evitar redundância funcional.
• Interface bem definida .
  A interface de um serviço é definida por WSDL, que é usado para indicar a fronteira entre a interface pública do serviço e sua implementação privada interna.
• Autônomo e modular .
  Os serviços encapsulam as atividades e componentes que são estáveis ​​e recorrentes nos negócios. As entidades funcionais que implementam os serviços são completamente independentes e podem ser implantadas, versionadas, autogerenciadas e restauradas de forma independente.
• Grão grosso .
  O número de serviços não deve ser muito grande e depende da interação de mensagens em vez de Chamada de Procedimento Remoto (RPC).Geralmente o volume de mensagens é grande, mas a frequência de interação entre os serviços é baixa.
• Acoplamento frouxo entre serviços .
  O que os usuários do serviço veem é a interface do serviço. Sua localização, tecnologia de implementação e status atual não são visíveis para os usuários. Os dados privados do serviço não são visíveis para os usuários do serviço.
• Interoperabilidade, compatibilidade e declarações de política .
  Para garantir que a especificação do serviço seja abrangente e clara, são utilizadas políticas para definir semânticas de interoperabilidade configuráveis ​​para descrever as expectativas de serviços específicos e controlar o seu comportamento. Aproveite as declarações de política para garantir integridade e clareza em relação às expectativas de serviço e compatibilidade semântica.

7. Padrões de projeto SOA

7.1 Modo de registro de serviço

O registro de serviço oferece suporte ao desenvolvimento, publicação e gerenciamento de contratos de serviço, políticas e metadados que orientam a governança SOA.
(1) Registro de serviço : Os desenvolvedores de aplicativos, também chamados de provedores de serviços, publicam suas funções no registro.
(2) Localização do serviço : Ou seja, os desenvolvedores de aplicativos de serviço os ajudam a consultar serviços de registro e encontrar serviços que atendam aos seus próprios requisitos.
(3) Ligação de serviço : O consumidor do serviço usa o contrato de serviço recuperado para desenvolver o código. O código desenvolvido está vinculado ao serviço registrado, chama o serviço registrado e interage com ele.

7.2 Modelo de Barramento de Serviço Corporativo (EBS)

O modelo de barramento de serviço corporativo fornece uma arquitetura subjacente de software padrão. Vários componentes do programa podem ser "inseridos" na plataforma como unidades de serviço e podem interagir uns com os outros em um método padrão de comunicação de mensagens . Suas funções principais são as seguintes:

(1) Serviços de roteamento e endereçamento de mensagens que fornecem transparência de localização. Os componentes do programa não precisam prestar atenção ao roteamento e endereçamento uns dos outros.
(2) Fornecer funções de gerenciamento para registro e nomenclatura de serviços.
(3) Suporta múltiplas especificações de mensagens (como solicitação/resposta, publicação e assinatura).
(4) Suporta uma variedade de protocolos de transmissão amplamente utilizados.
(5) Suporta vários formatos de dados e sua conversão mútua.
(6) Fornece funções de registro e monitoramento.

Conforme mostrado abaixo, diagrama EBS :

7.3 Modelo de microsserviço

Arquitetura de microsserviços Dividir um único aplicativo ou serviço grande em vários microsserviços permite dimensionar componentes individuais em vez de toda a pilha de aplicativos para atender aos acordos de nível de serviço. A arquitetura de microsserviços divide os serviços em áreas de negócios. Cada serviço pode ser desenvolvido, gerenciado e iterado de forma independente. Eles se comunicam entre si usando uma interface unificada, realizando funções de implantação, gerenciamento e serviço em componentes dispersos, facilitando a entrega do produto. Torna-se mais simples dividir efetivamente os aplicativos e obter desenvolvimento e implantação ágeis. As características do modelo de microsserviço são as seguintes:
(1) Desacoplamento de aplicativos complexos : A arquitetura de microsserviço decompõe um aplicativo de módulo único em vários microsserviços, mantendo a funcionalidade geral inalterada.
(2) Independente : os microsserviços são desenvolvidos, testados e implantados de forma independente no ciclo de vida do software do sistema.
(3) Seleção flexível de tecnologia : A seleção de tecnologia de aplicativos de sistema sob a arquitetura de microsserviços é descentralizada, cada equipe de desenvolvimento pode escolher a arquitetura e a tecnologia de sistema apropriadas com base nas necessidades de negócios de seu próprio aplicativo.
(4) Tolerância a falhas : Cada microsserviço é independente um do outro, as falhas serão isoladas em um único serviço e outros microsserviços no sistema podem alcançar tolerância a falhas na camada de aplicação por meio de mecanismos como nova tentativa e degradação suave, melhorando assim a tolerância a falhas de aplicações do sistema.
(5) Acoplamento fraco e expansão fácil : Cada serviço na arquitetura de microsserviços é fracamente acoplado e pode ser expandido de forma independente de acordo com as necessidades reais, refletindo a flexibilidade da arquitetura de microsserviços. O diagrama esquemático da arquitetura de aplicativo monolítico e da arquitetura de microsserviços é o seguinte:

7.4 Solução de modelo de arquitetura de microsserviços

A solução do modelo de arquitetura de microsserviços inclui principalmente:
(1) Microsserviço agregador : O agregador atua como um comandante de processo e chama vários microsserviços para implementar as funções exigidas pelos aplicativos do sistema.
(2) Microsserviços encadeados : Depois que o cliente ou servidor recebe uma solicitação, ocorrerão chamadas recursivas aninhadas entre vários serviços e uma resposta processada será retornada.
(3) Microsserviços de compartilhamento de dados : Este modelo é adequado para o estágio de transição da arquitetura monolítica para a arquitetura de microsserviços.Fortes relações de acoplamento são permitidas entre serviços, como vários microsserviços compartilhando cache e armazenamento de banco de dados.
(4) Microsserviços de mensagens assíncronas : para algumas lógicas de negócios que não precisam ser executadas de maneira síncrona, filas de mensagens podem ser usadas em vez de REST para implementar solicitações e respostas para acelerar a velocidade de resposta das chamadas de serviço.

A seguir, arquitetura monolítica e arquitetura de microsserviços:

7.5 Problemas e desafios enfrentados pela arquitetura de microsserviços

(1) A descoberta de serviços e o rastreamento da cadeia de chamadas de serviço tornam-se difíceis.
(2) É difícil conseguir uma consistência forte nas bases de dados tradicionais e, em vez disso, procura uma consistência eventual.

8. Questões que devem ser observadas ao construir uma arquitetura SOA

(1) Os requisitos de integração na arquitetura original do sistema incluem: requisitos de integração de aplicativos, requisitos de integração de interface de usuário de terminal, requisitos de integração de processos e requisitos de integração de informações de sistema existentes.

(2) O controlo da granularidade do serviço e a concepção de serviços sem estado são expressos da seguinte forma:

• Controle de granularidade de serviço : Recomenda-se o uso de interfaces de granularidade grossa para serviços que serão expostos fora de todo o sistema, enquanto interfaces de serviço relativamente granulares são geralmente usadas na arquitetura do sistema corporativo.
• Projeto de serviços sem estado : Serviços específicos na arquitetura do sistema SOA devem ser solicitações independentes e independentes. Ao implementar esses serviços, o estado da solicitação anterior não é necessário, o que significa que os serviços não devem depender do contexto de outros serviços E estado, isto é, os serviços na arquitetura SOA devem ser serviços sem estado.

9. Processo de implementação SOA

(1) Selecione soluções SOA principalmente a partir dos três aspectos a seguir:

• Tente escolher um plano que permita um planejamento geral.
• Na hora de escolher leve em consideração as necessidades da própria empresa.
• Realizar inspeções desde aspectos técnicos como plataforma e implementação.

(2) A análise de processos de negócios concentra-se principalmente em:

• Estabelecer modelo de serviço :
  método de decomposição de cima para baixo, método de análise de metas de negócios, método de análise de baixo para cima.
• Estabeleça processos de negócios :
  estabeleça objetos de negócios (objetos de negócios como entidades, processos, eventos, etc.), estabeleça interfaces de serviço e estabeleça processos de serviço.

Clique para entrar no diretório de séries de artigos