{"id":2760,"date":"2022-07-25T21:03:29","date_gmt":"2022-07-26T00:03:29","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=2760"},"modified":"2024-01-12T18:19:16","modified_gmt":"2024-01-12T21:19:16","slug":"projetando-sistemas-com-microsservicos","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/projetando-sistemas-com-microsservicos\/","title":{"rendered":"Cap 3.6 Projetando sistemas com microsservi\u00e7os"},"content":{"rendered":"Desde 2010, “microsservi\u00e7os” \u00e9 t\u00f3pico “quente” em arquitetura de software.<\/strong> Com a promessa de facilitar a implementa\u00e7\u00e3o de mudan\u00e7as, reduzindo\u00a0lead-times,\u00a0<\/em>melhorando a frequ\u00eancia de deploy, controlando taxas de erros e reduzindo o MTTR, o estilo arquitetural parece ter o fit\u00a0<\/em>ideal com as modernas demandas de engenharia.\n
\nH\u00e1 in\u00fameros cases\u00a0<\/em>de implementa\u00e7\u00f5es bem-sucedidas de sistemas compostos por microsservi\u00e7os, entretanto, \u00e9 importante destacar que a abordagem n\u00e3o constitui uma uma solu\u00e7\u00e3o “bala de prata”. Entretanto, tem m\u00e9ritos e dem\u00e9ritos que, se bem ponderados, tem poder de transformar organiza\u00e7\u00f5es para melhor.\n

Conceito fundamental<\/h2>\n

Microsservi\u00e7os s\u00e3o (surpresa) servi\u00e7os com interfaces p\u00fablicas enxutas e extremamente coesas.<\/strong><\/p>\n

\r\n

Defini\u00e7\u00e3o: Servi\u00e7o<\/p>\r\n

<\/p>\n

Um servi\u00e7o \u00e9 um mecanismo que permite acesso a uma ou mais\u00a0capabilities <\/em>atrav\u00e9s de uma interface p\u00fablica expl\u00edcita.<\/p>\n

<\/p>\r\n<\/div>\n

A interface p\u00fablica de um servi\u00e7o habilita a “entrada e sa\u00edda” de informa\u00e7\u00f5es, tanto de forma s\u00edncrona – em um modelo baseado em\u00a0request\/response\u00a0<\/em>– quanto ass\u00edncrona – atrav\u00e9s de troca de mensagens com comandos ou\u00a0eventos.<\/p>\n

\"\"<\/p>\n

Interfaces p\u00fablica enxutas e coesas, bem delimitadas, fazem com que microsservi\u00e7os sejam mais f\u00e1ceis de entender, tanto em sua l\u00f3gica interna quanto em demandas de integra\u00e7\u00e3o\/coopera\u00e7\u00e3o.<\/p>\n

A arquitetura de software em sistemas inteiros, empregando microsservi\u00e7os, objetiva ponderar complexidades na manuten\u00e7\u00e3o de cada componente isoladamente – ou seja, a complexidade local<\/span> -, sem ignorar as intera\u00e7\u00f5es desses componentes com o restante do sistema – ou seja, a complexidade global<\/span>.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Determinando a granularidade ideal para microsservi\u00e7os<\/p>\r\n

Manual do Arquiteto de Software - Sistemas distribu\u00eddos<\/p>\r\nInteressado em como determinar o “tamanho” de um microsservi\u00e7o? Nesse cap\u00edtulo, trato de aspectos relevantes para a modulariza\u00e7\u00e3o e, ent\u00e3o, granularidade.\r\n

Ler cap\u00edtulo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n

REST (HTTP resource API) ou gRPC<\/p>\r\n<\/p>\n

Comunica\u00e7\u00e3o intensiva entre servi\u00e7os utilizando a combina\u00e7\u00e3o HTTP\/1.1 e JSON \u00e9 um “pedido” para problemas de performance. Seja pelas limita\u00e7\u00f5es do protocolo de comunica\u00e7\u00e3o ou pela “verbosidade” do formato JSON.<\/p>\n

Recentemente, t\u00eam ganho destaque a utiliza\u00e7\u00e3o de gRPC (que opera sobre HTTP\/2) combinada protocol buffers<\/em>.<\/p>\n

<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Adote REST para comunica\u00e7\u00e3o “com o mundo exterior” e outro padr\u00e3o, mais eficiente, para comunica\u00e7\u00e3o “interna”.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n
\r\n

API Layer<\/p>\r\n<\/p>\n

A maioria das arquiteturas baseadas em microsservi\u00e7os implementa alguma forma de “camada de API”, muitas vezes implementadas por um API Gateway, conectando usu\u00e1rios externos (interfaces ou sistemas de terceiros) aos microsservi\u00e7os. Trata-se de uma abordagem opcional, mas recomendada.<\/p>\n

Essa estrat\u00e9gia permite a cria\u00e7\u00e3o facilitada de APIs externas, facilitando a ado\u00e7\u00e3o, al\u00e9m de poder implementar\u00a0shared concerns\u00a0<\/em>como autentica\u00e7\u00e3o e localiza\u00e7\u00e3o. Entretanto, \u00e9 importante destacar que n\u00e3o devem ser atribu\u00eddas a essa camada responsabilidades de orquestra\u00e7\u00e3o.<\/p>\n

<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Building Microservices<\/p>\r\nA primeira edi\u00e7\u00e3o desse livro, de Sam Newman foi, talvez,\u00a0 a primeira obra relevante sobre microsservi\u00e7os. Na segunda edi\u00e7\u00e3o, o livro foi praticamente reescrito. \r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Rela\u00e7\u00e3o com Squads<\/em><\/h2>\nN\u00e3o \u00e9 recomend\u00e1vel formar squads\u00a0<\/em>em uma organiza\u00e7\u00e3o, sem revisar a arquitetura do software que ela produz. Tampouco \u00e9 respons\u00e1vel iniciar um projeto baseado em (micros)servi\u00e7os sem, antes, fazer uma revis\u00e3o da estrutura organizacional.\n
\n

A\u00a0lei de Conway \u00e9 categ\u00f3rica<\/a>\u00a0e suas implica\u00e7\u00f5es s\u00e3o \u00f3bvias:\u00a0Uma organiza\u00e7\u00e3o monol\u00edtica n\u00e3o consegue produzir microsservi\u00e7os. Empresas que produzem softwares monol\u00edticos n\u00e3o deveriam ter \u201csquads\u201d.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Lei de Conway<\/p>\r\nQuerendo saber mais sobre a lei de Conway? Assista esse epis\u00f3dio do Tech & Biz.\r\n

Acessar epis\u00f3dio<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n

Squad<\/p>\r\n<\/p>\n

Squads\u00a0<\/em>s\u00e3o times pequenos, com grande autonomia, multi-disciplinares que operam dando \u00eanfase a agilidade no lugar metodologias e, tamb\u00e9m, princ\u00edpios no lugar pr\u00e1ticas. Eles resultam produtos, n\u00e3o projetos, por isso s\u00e3o respons\u00e1veis por todo o ciclo de vida (end-to-end<\/em>) .<\/p>\n

O termo foi lan\u00e7ado pelo Spotify e \u00e9 conceito central da celebrada cultura de engenharia da empresa.<\/p>\n

<\/div>\nSquads<\/em> s\u00e3o times multifuncionais, que conseguem desempenhar atividades organizacionais de ponta-a-ponta, com\u00a0autonomia e alinhamento<\/a>.\u00a0\u00a0Eles reduzem a burocracia da organiza\u00e7\u00e3o pois reduzem a necessidade de\u00a0documentos que nascem da falta de confian\u00e7a<\/a>.\u00a0<\/strong>Afinal, pessoas de um mesmo time costumam confiar mais umas nas outras.\n

\n

Para ter autonomia, as \u201centregas\u201d de um squad\u00a0<\/em>devem ocorrer de forma independente.\u00a0Se as entregas de um\u00a0squad\u00a0<\/em>precisarem ser feitas com as de outros, acordos s\u00e3o necess\u00e1rios e a burocracia-para-confian\u00e7a emerge.<\/p>\n

Apenas times realmente aut\u00f4nomos conseguem produzir (micros)servi\u00e7os com baixo acoplamento.\u00a0<\/strong>Microsservi\u00e7os com alto acoplamento n\u00e3o se justificam pois s\u00e3o, apenas, um pesadelo para a opera\u00e7\u00e3o.<\/p>\n

S\u00e3o necess\u00e1rios times realmente independentes para produzir (micros)servi\u00e7os que n\u00e3o compartilham banco de dados.<\/strong><\/p>\nA comunica\u00e7\u00e3o entre (micros)servi\u00e7os ser\u00e1 naturalmente ass\u00edncrona, se a comunica\u00e7\u00e3o entre os times que os produzem tamb\u00e9m for. Comunica\u00e7\u00e3o s\u00edncrona entre (micros)servi\u00e7os revela, mais que poss\u00edvel falha de design de software, falha de design organizacional.<\/strong>\n

\n

Quando um squad<\/em> desenvolve muitos microsservi\u00e7os<\/h4>\n

Por mais que se tome cuidado no processo de elabora\u00e7\u00e3o da arquitetura, muitas vezes s\u00e3o as estruturas organizacionais, formadas a partir de \u00e1reas de especialidade, que levam times a desenvolver microsservi\u00e7os que atendem apenas demandas locais.<\/p>\n

\"\"<\/a><\/p>\n

Na pr\u00e1tica, as \u201ccomunidades\u201d da organiza\u00e7\u00e3o tendem a se replicar na estrutura dos servi\u00e7os criando pontos de interface restritos com alta centralidade.<\/p>\n

\n

De qualquer forma, \u00e9 importante recordar que microsservi\u00e7os de boa qualidade implementam, de forma desacoplada,\u00a0capabilities\u00a0<\/em>das organiza\u00e7\u00f5es. Logo, deveriam ser \u00fateis muito al\u00e9m das fronteiras dos times que os desenvolveram, reduzindo a centralidade e, de maneira geral, colaborando para mitiga\u00e7\u00e3o de pontos de fragilidade.<\/p>\n

A identifica\u00e7\u00e3o de \u201ccomunidades de microsservi\u00e7os\u201d pode e deve ser facilitada pelo acompanhamento din\u00e2mico e cont\u00ednuo dos coeficientes de agrupamento local.<\/strong><\/p>\n

\r\n

Coeficiente de agrupamento local<\/p>\r\n<\/p>\n

Na\u00a0teoria dos grafos<\/a>, o\u00a0coeficiente de agrupamento<\/b>\u00a0(clustering coefficient<\/i>) mede o grau com que os n\u00f3s de um\u00a0grafo<\/a>\u00a0tendem a agrupar-se.<\/p>\n

O coeficiente de agrupamento local de um v\u00e9rtice (n\u00f3) num grafo mede o qu\u00e3o perto os seus vizinhos est\u00e3o de serem um clique (grafo completo). Por outras palavras, pode dizer-se que o coeficiente de agrupamento local mede o grau da densidade de liga\u00e7\u00f5es da vizinhan\u00e7a de um determinado n\u00f3, isto \u00e9, corresponde ao grau com que os vizinhos de um n\u00f3 se interligam.<\/p>\n

<\/div>\n

O coeficiente de agrupamento local de um microsservi\u00e7o \u00e9 calculado como sendo a propor\u00e7\u00e3o das liga\u00e7\u00f5es existentes entre os microsservi\u00e7os que este acessa em rela\u00e7\u00e3o com o total das liga\u00e7\u00f5es poss\u00edveis. Quando maior for o coeficiente, maiores s\u00e3o os ind\u00edcios de forma\u00e7\u00e3o de \u201ccomunidade\u201d.<\/p>\n<\/div>\n

\"\"<\/p>\n

\n

Quanto maiores forem os coeficientes de agrupamento local, por correla\u00e7\u00e3o, maiores s\u00e3o as chances de\u00a0changing coupling\u00a0<\/em>que podem ser verificados nos controles de vers\u00e3o. Consequentemente, mais intensos devem ser os questionamentos quanto ao \u201creagrupamento\u201d das bases de c\u00f3digo.<\/p>\n

A comprova\u00e7\u00e3o sistem\u00e1tica e recorrente de coeficientes de agrupamento elevados deve implicar em estudos mais aprofundados das causas. N\u00e3o \u00e9 incomum que a forma\u00e7\u00e3o de \u201ccomunidades de microsservi\u00e7os\u201d indique deteriora\u00e7\u00e3o no relacionamento entre os times da organiza\u00e7\u00e3o e, disto, a demanda por revis\u00f5es da estrutura organizacional. Outra possibilidade \u00e9 que o \u201colhar\u201d dos times, embora com sistemas distribu\u00eddos, permane\u00e7a \u201cviciado\u201d em uma estrutura monol\u00edtica, indicando a\u00e7\u00f5es de desenvolvimento de pessoas das equipes t\u00e9cnicas.<\/p>\n

Rela\u00e7\u00e3o com DevOps<\/h2>\nN\u00e3o \u00e9 exagero dizer que sistemas baseados em microsservi\u00e7os transferem a complexidade do desenvolvimento, reduzindo o tamanho do c\u00f3digo, para as opera\u00e7\u00f5es, pelo aumento da dimensionalidade.\n
\n

N\u00e3o percamos de vista que microsservi\u00e7os tem como objetivo central reduzir acoplamento. Estruturas organizacionais desfavor\u00e1veis, entretanto, acabam “for\u00e7ando” acoplamento emergente.<\/strong> Por exemplo, times centralizados para gerenciar bancos de dados e opera\u00e7\u00f5es “gargalam” a estrutura, “monolitizando” administra\u00e7\u00e3o dos bancos e gest\u00e3o do ambiente produtivo.<\/p>\n

\"\"<\/p>\n

O esfor\u00e7o em microsseriv\u00e7os implica na elimina\u00e7\u00e3o dessas “barreiras”. Logo, segundo Conway, o idela \u00e9 trazer opera\u00e7\u00f5es para dentro das Squads<\/em>, conciliando com atividades de desenvolvimento.<\/p>\n

\"\"<\/p>\n<\/div>\n

Implica\u00e7\u00f5es para a reutiliza\u00e7\u00e3o<\/h2>\n

Uma das “fontes inocentes” para acoplamento \u00e9 a insist\u00eancia por alternativas para reutiliza\u00e7\u00e3o.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

O trade-off negativo da reutiliza\u00e7\u00e3o \u00e9 o acoplamento. Quando um arquiteto projeta um sistema favorecendo o reuso, ele tamb\u00e9m favorece ao acoplamento para permitir esse reuso, seja por heran\u00e7a ou composi\u00e7\u00e3o.<\/em><\/p>\n

\r\n

Neil Ford<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Toda alternativa de reutiliza\u00e7\u00e3o faz emergir um componente com acoplamento aferente elevado que, mais cedo ou mais tarde, se converte em “gargalo” para o desenvolvimento.<\/p>\nSegundo Conway, componentes “gargalo” se traduzem em times gargalo, caso se d\u00ea atribui\u00e7\u00e3o de “propriedade” a algum, ou em pontos cr\u00edticos de falha devido a alta difus\u00e3o de responsabilidade.\n

\n

A emerg\u00eancia por alternativas para a gest\u00e3o de componentes deu origem a iniciativas de inner sourcing.<\/em><\/p>\n

Reutiliza\u00e7\u00e3o de recursos operacionais<\/h4>\n

A op\u00e7\u00e3o por duplica\u00e7\u00e3o frente a reutiliza\u00e7\u00e3o \u00e9 v\u00e1lida para artefatos funcionais, mas n\u00e3o para recursos operacionais (tais como\u00a0logging\u00a0<\/em>e monitoramento).\u00a0A abordagem comum \u00e9 manter recursos funcionais “dentro” dos microsservi\u00e7os, duplicados sempre que necess\u00e1rio, e recursos operacionais “fora”, em\u00a0sidecars.<\/em><\/p>\n

\"\"<\/p>\n

\r\n

Sidecar Pattern<\/em><\/p>\r\n<\/p>\n

O padr\u00e3o\u00a0sidecar\u00a0<\/em>prop\u00f5e a “entrega” de uma solu\u00e7\u00e3o (no nosso contexto, microsservi\u00e7o) composta por dois cont\u00eaineres.<\/p>\n

O primeiro cont\u00eainer contem a l\u00f3gica\u00a0core\u00a0<\/em>da aplica\u00e7\u00e3o. Sem este cont\u00eainer a solu\u00e7\u00e3o simplesmente n\u00e3o existe. O segundo cont\u00eainer \u00e9 o sidecar. <\/em>Ele amplia ou melhora os entreg\u00e1veis do cont\u00eainer de aplica\u00e7\u00e3o, muitas vezes sem o conhecimento deste.<\/p>\n

<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Padr\u00f5es e crit\u00e9rios de design para (de)composi\u00e7\u00e3o em single-node<\/p>\r\n

Manual do Arquiteto de Software - Sistemas distribu\u00eddos<\/p>\r\nInteressado em padr\u00f5es de composi\u00e7\u00e3o\/decomposi\u00e7\u00e3o? Nesse cap\u00edtulo apresento alguns padr\u00f5es importantes para sistemas distribu\u00eddos, incluindo Sidecar<\/em>\r\n

Ler cap\u00edtulo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A “padroniza\u00e7\u00e3o” de um \u00fanico sidecar\u00a0<\/em>em dois ou mais microsservi\u00e7os permite a inclus\u00e3o de componentes para administra\u00e7\u00e3o.<\/p>\n

\"\"<\/p>\n

A “predomin\u00e2ncia” de um \u00fanico sidecar <\/em>habilita a forma\u00e7\u00e3o de service meshs<\/em>.<\/p>\n

\r\n

Istio<\/p>\r\n<\/p>\n

Uma das plataformas mais utilizadas para ado\u00e7\u00e3o de Service Mesh<\/em> \u00e9 o Istio.\u00a0 Ele estende o Kubernetes para estabelecer uma rede program\u00e1vel, usando o proxy<\/em> de servi\u00e7o Envoy. Ele oferece gerenciamento de tr\u00e1fego universal, telemetria e seguran\u00e7a para implanta\u00e7\u00f5es complexas.<\/p>\n

<\/div>\n

Arquitetura naturalmente distribu\u00edda<\/h2>\n

Em produ\u00e7\u00e3o, microsservi\u00e7os operam em forma naturalmente distribu\u00edda. Afinal, cada servi\u00e7o “roda” em um processo independente, originalmente, em um computador dedicado, mas, atualmente, em m\u00e1quinas virtuais ou cont\u00eaineres.<\/p>\n

Quando muitos servi\u00e7os compartilham recursos computacionais em demasia, rodando em uma \u00fanica plataforma operacional, t\u00eam-se, inicialmente, melhor aproveitamento da largura de banda da rede, mem\u00f3ria, discos, etc. Entretanto, na medida em que as demandas de cada servi\u00e7o crescem, ocorrem restri\u00e7\u00f5es que podem levar a problemas de disponibilidade e aumentam a import\u00e2ncia de adotar t\u00e1ticas de resili\u00eancia.<\/p>\n

Sem o devido cuidado, aplica\u00e7\u00f5es baseadas em microsservi\u00e7os podem ter, devido a natureza distribu\u00edda, problemas de performance. Afinal de contas, chamadas na rede s\u00e3o muito mais custosas que chamadas a m\u00e9todos, al\u00e9m de todo o overhead\u00a0<\/em>de seguran\u00e7a e governan\u00e7a.<\/p>\n

\r\n

Oito fal\u00e1cias da computa\u00e7\u00e3o distribu\u00edda<\/p>\r\n<\/p>\n

Em 1994, Peter Deutsch, que trabalhou na Sun Microsystems, consolidou uma lista de 7 fal\u00e1cias frequentemente associadas a sistemas distribu\u00eddos. Mais tarde, em 1997, James Gosling adicionou um item a essa lista, criando a comumente conhecida rela\u00e7\u00e3o das oito fal\u00e1cias da computa\u00e7\u00e3o distribu\u00edda. S\u00e3o elas:<\/p>\n