O mais recente domínio do Github, os arquitetos da Tencent produziram o manual de arquitetura de microsserviços "Ceiling Notes" de 500 páginas

prefácio

Nos últimos 5 anos, o estilo de arquitetura de microsserviços (organização de aplicativos como uma série de serviços de implantação independente, fracamente acoplados e refinados) tornou-se cada vez mais popular. Independentemente do tamanho da empresa, os microsserviços estão se tornando cada vez mais viáveis apenas para as equipes de engenharia. Hoje, os microsserviços não são mais um conceito, mas uma tendência imparável, com ricos casos práticos em grandes empresas de comércio eletrônico na Internet, e o efeito é muito bom. Mas para outros entusiastas de tecnologia que estão interessados em se transformar para a arquitetura de microsserviços, ainda há muitos pontos obscuros sobre como os microsserviços serão implementados.

Hoje, o editor compartilhará com você um livreto de estudo de arquitetura de microsserviços de mais de 500 páginas resumido pelos irmãos mais velhos da Tencent para compartilhar com você! Ao estudar este documento, os leitores entenderão como desenvolver e implantar aplicativos de microsserviços e como implementá-los por meio de microsserviços Entrega contínua eficaz e como desenvolver exemplos com Kubernetes, Docker e Google Container Engine.

Ok, sem mais delongas, vamos dar uma olhada no catálogo primeiro!

Visão geral do diretório

conteúdo principal

Este artigo tem um total de 13 capítulos, levando você a interpretar minuciosamente o combate real dos microsserviços. Como são muitos conteúdos, só posso apresentar alguns pontos de conhecimento para você. Espero que você possa entender e gostar ! !

Capítulo 1 Projeto e Operação de Microsserviços;

(1) Microsserviço não é apenas um estilo arquitetônico, mas também uma coleção de uma série de hábitos culturais. É apoiado por cinco princípios fundamentais, que são autonomia, capacidade de recuperação, transparência, automação e consistência.
(2) Os microsserviços reduzem os conflitos de desenvolvimento e alcançam autonomia, flexibilidade técnica e baixo acoplamento.
(3) O processo de design de microsserviços é muito desafiador, porque não requer apenas um rico conhecimento do domínio do negócio, mas também exige que os desenvolvedores equilibrem as prioridades entre as equipes.
(4) Serviços expõem contratos a outros serviços. Contratos bem elaborados são concisos, completos e previsíveis.
(5) Em sistemas de software de longa duração, a complexidade é inevitável, mas os desenvolvedores podem tomar algumas decisões para reduzir conflitos e riscos e continuar a agregar valor a esses sistemas.
(6) As operações de liberação automatizadas e verificáveis podem tornar o processo de implantação mais confiável e "livre de acidentes", reduzindo assim o risco de microsserviços.
(7) A tecnologia de contêineres abstrai as diferenças entre serviços no ambiente operacional e simplifica a forma de gerenciamento em larga escala de diferentes tipos de microsserviços.
(8) A falha é inevitável: Para a equipe, os microsserviços precisam ser transparentes e fáceis de observar, para que a equipe possa gerenciar ativamente, entender e realmente possuir a operação e manutenção do serviço; e vice-versa.
(9) A equipe que adota microsserviços precisa ser mais madura em operação e manutenção, e focar em todo o ciclo de vida do serviço, não apenas na fase de projeto e desenvolvimento.

Capítulo 2 Microsserviços da Empresa SimpleBank;

(1) Os microsserviços são adequados para sistemas com complexidade multidimensional, como escopo de fornecimento de um produto, implantação global e pressões regulatórias.
(2) Ao projetar microsserviços, é crucial entender o domínio de negócios do produto.
(3) A interação do serviço pode ser orquestrada ou coreografada. Este último aumentará a complexidade do sistema, mas pode reduzir o acoplamento entre os serviços do sistema.
(4) Gateway de API é um padrão comum, que encapsula e abstrai a complexidade da arquitetura de microsserviços, portanto, o front-end ou os consumidores externos não precisam considerar essa parte da complexidade.
(5) Se o desenvolvedor confiar totalmente que seu serviço pode lidar com a pressão do tráfego no ambiente de produção, pode-se dizer que o serviço está pronto para produção.
(6) Se os desenvolvedores puderem implantar e monitorar um serviço de forma confiável, eles poderão ter mais confiança no serviço.
(7) O monitoramento do serviço deve incluir agregação de logs e verificações de integridade no nível do serviço.
(8) Os microsserviços falharão por motivos como hardware, comunicação e dependências, e não apenas defeitos no código causarão falhas.
(9) A coleta de indicadores de negócios, logs e registros de rastreamento de link entre serviços é crucial para entender o desempenho atual e passado de aplicativos de microsserviço.
(10) À medida que o número de microsserviços e equipes de suporte continua a aumentar, as diferenças técnicas e o isolamento se tornarão cada vez mais desafios para as equipes técnicas.
(11) Evitar divergências e isolamentos técnicos requer a adoção de padrões e melhores práticas semelhantes entre diferentes equipes, independentemente da base técnica utilizada.

Capítulo 3 Arquitetura de Aplicação de Microsserviços;

(1) Separadamente, os componentes internos dos microsserviços são semelhantes aos aplicativos monolíticos.
(2) Um aplicativo de microsserviço é como um bloco: sua aparência final não é especificada, mas é guiada por uma série de diretrizes e um modelo de estrutura de tópicos de alto nível.
(3) Os princípios que orientam a arquitetura de microsserviços refletirão os objetivos da organização e terão impacto na prática da equipe.
(4) O planejamento da arquitetura deve promover um desenvolvimento saudável, em vez de especificar todo o programa aplicativo.
(5) A aplicação de microsserviço é composta por quatro camadas: camada de plataforma, camada de serviço, camada de limite e camada de cliente.
(6) A camada de plataforma fornece uma série de ferramentas e infraestrutura para apoiar o desenvolvimento de serviços orientados à produção.
(7) Em aplicativos de microsserviços, a comunicação síncrona geralmente é a primeira escolha e é muito adequada para interação do tipo comando, mas também há desvantagens - aumentará o acoplamento e a instabilidade.
(8) A comunicação assíncrona é mais flexível e pode se adaptar à rápida evolução do sistema, ao custo de maior complexidade.
(9) Padrões comuns de comunicação assíncrona incluem filas e publicação-assinatura.
(10) A camada limite é uma fachada de aplicações de microsserviços, que é muito adequada para consumidores externos.
(11) Os padrões comuns da camada limite incluem gateways de API e gateways orientados ao consumidor (como GraphQL).
(12) Aplicativos cliente, como sites e aplicativos móveis, interagem com o back-end móvel por meio da camada limite.
(13) O cliente corre o risco de ficar cada vez mais inchado, mas agora também começam a aparecer algumas tecnologias que aplicam princípios de microsserviços a aplicações front-end.

Capítulo 4 Projeto de Nova Função;

(1) Entenda os problemas de negócios - identifique entidades e casos de uso - divida as responsabilidades do serviço, podemos usar esse processo para delinear o escopo dos serviços.
(2) Os serviços podem ser divididos de diferentes maneiras: por função de negócio, por caso de uso e por variabilidade. Os leitores podem usar esses métodos em combinação.
(3) Uma boa decisão de divisão pode fazer com que o serviço atenda às três principais características dos microsserviços: responsável apenas por responsabilidade única, substituível e implantável de forma independente.
(4) O contexto limitado geralmente corresponde ao limite do serviço, que é um método muito eficaz ao pensar no desenvolvimento futuro do serviço.
(5) Por meio do pensamento aprofundado em campos variáveis, os desenvolvedores podem encapsular os campos que mudarão juntos, de modo a melhorar a adaptabilidade a mudanças futuras.
(6) Se a divisão de serviços não for boa, o custo da revisão tardia será particularmente alto, porque, nesse momento, os desenvolvedores precisarão refatorar várias bases de código e a carga de trabalho resultante se tornará particularmente grande.
(7) Também podemos encapsular funções técnicas em um serviço, que pode não apenas simplificar os recursos de negócios, mas também fornecer suporte para funções de negócios e maximizar a disponibilidade de serviços.
(8) Se o limite de serviço não for claro o suficiente, preferimos escolher um serviço de baixa granularidade, mas adotar ativamente uma solução modular dentro do serviço para nos prepararmos para futuras divisões.
(9) O serviço off-line é um trabalho particularmente desafiador, mas com o desenvolvimento contínuo de aplicativos de microsserviços, precisaremos fazer isso um dia no futuro.
(10) Em grandes organizações, é necessário dividir a propriedade entre várias equipes, mas isso introduz novos problemas: controle enfraquecido, design limitado, velocidade de desenvolvimento inconsistente.
(11) Código aberto, interfaces claras, comunicação contínua e requisitos relaxados para o princípio DRY podem aliviar a tensão entre as equipes.

Capítulo 5 Transações e Consultas de Microsserviços;

(1) É difícil obter características ACID em interações entre serviços, e os microsserviços precisam adotar métodos diferentes para obter consistência.
(2) Os esquemas de coordenação, como o commit de duas fases, introduzem operações de bloqueio e a escalabilidade não é boa.
(3) A arquitetura baseada em eventos pode desacoplar os componentes independentes e estabelecer as bases para a escalabilidade da lógica de negócios e consulta de aplicativos de microsserviço.
(4) Tende a ser altamente disponível em vez de consistente, o que tornará a arquitetura mais escalável.
(5) Saga é uma operação global composta por transações locais independentes conduzidas por mensagens de grupo. Eles revertem estados errados por meio de operações de compensação para obter consistência.
(6) Ao construir microsserviços que refletem ambientes do mundo real, antecipar e preparar cenários de falha é uma parte muito importante do conteúdo, e o isolamento de operações não é tão crítico.
(7) Geralmente realizamos a função de consulta em vários microsserviços combinando os resultados de várias APIs.
(8) Consultas compostas eficientes devem usar o modo CQRS para implementar um conjunto de modelos de dados de leitura independentes, especialmente quando esses modos de consulta precisam usar outro sistema de armazenamento de dados.

Capítulo 6 Projetando Serviços Altamente Confiáveis;

(1) As falhas são inevitáveis em sistemas distribuídos complexos - os desenvolvedores devem considerar a tolerância a falhas ao projetar esses sistemas.
(2) A disponibilidade de cada serviço terá impacto na disponibilidade de toda a aplicação.
(3) O desenvolvimento de estratégias apropriadas para cada aplicação para mitigar o risco de falha requer consideração cuidadosa da frequência, impacto e custo de redução desses raros eventos de falha.
(4) A maioria das falhas ocorre em 4 áreas: hardware, comunicação, dependências e internas.
(5) Falhas em cascata causadas por feedback positivo são uma forma muito comum de falha em aplicativos de microsserviço. Normalmente, a maioria das falhas em cascata são causadas por serviços sobrecarregados.
(6) Estratégias de repetição e tempo limite podem ser usadas para mitigar o impacto de falhas nas interações de serviço. Os desenvolvedores devem ter cuidado redobrado ao adotar o método de repetição, para não agravar a falha de outros serviços.
(7) Esquemas de backup (fllback), como cache, serviços candidatos e valores padrão, podem ser usados para retornar resultados bem-sucedidos, mesmo se as dependências do serviço estiverem indisponíveis.
(8) O período de tempo limite deve ser propagado para serviços de downstream durante a interação do serviço, de modo a não apenas garantir que o período de tempo limite seja consistente em todo o sistema, mas também reduzir o trabalho inútil.
(9) Os disjuntores entre serviços evitam falhas em cascata falhando rapidamente quando a quantidade de erros atinge um determinado limite.
(10) Um serviço pode usar uma estratégia de limitação de tráfego para protegê-lo de solicitações repentinas de pico de carga que excedam a capacidade do serviço.
(11) Cada serviço deve abrir uma interface de verificação de integridade para uso do balanceador de carga e do sistema de monitoramento.
(12) A capacidade de recuperação do sistema pode ser verificada de forma eficaz por meio de testes de estresse e testes de caos.
(13) Padrões podem ser adotados - seja por meio de estruturas ou proxies - para ajudar os engenheiros rapidamente ("cair no poço do acesso""") a desenvolver serviços tolerantes a falhas por padrão.

O Capítulo 7 constrói uma estrutura de microsserviço reutilizável;

(1) A base de microsserviços pode acelerar a inicialização de novos serviços, expandir o campo de experimentação e reduzir riscos.
(2) O uso da base de serviços permite que os desenvolvedores extraiam implementações de código relacionadas a determinadas infraestruturas.
(3) Descoberta de serviço, observabilidade e diferentes protocolos de comunicação são preocupações da base de serviço, e a base de serviço precisa fornecer essas funções.
(4) Se existirem ferramentas adequadas, podemos desenvolver rapidamente protótipos para funções complexas, como fazer pedidos para vender estoques.
(5) Embora a arquitetura de microsserviços seja frequentemente associada à possibilidade de desenvolver sistemas em qualquer linguagem, em um ambiente de produção, esses sistemas precisam garantir e fornecer mecanismos para tornar a operação e a manutenção gerenciáveis.
(6) A base de microsserviço pode realizar as garantias acima e, ao mesmo tempo, pode permitir que os desenvolvedores iniciem e desenvolvam rapidamente para verificar a exatidão da ideia. Se a verificação for aprovada, ela poderá ser implantada no ambiente de produção.

Capítulo 8 Implantação de microsserviço;

(1) A implantação de novos aplicativos e alterações deve ser padronizada e direta para evitar atritos durante o desenvolvimento de microsserviços.
(2) Os microsserviços podem ser executados em qualquer lugar, mas uma plataforma de implantação ideal precisa oferecer suporte a uma variedade de funções, incluindo segurança, gerenciamento de configuração, descoberta de serviço e redundância.
(3) O desenvolvedor implanta um serviço típico como um grupo de instâncias idênticas e o conecta a um balanceador de carga.
(4) Grupos de instâncias, balanceadores de carga e verificações de integridade podem permitir que os serviços implantados alcancem autocorreção e expansão automática.
(5) Os artefatos de serviço devem ser imutáveis e previsíveis para minimizar os riscos, reduzir a dificuldade cognitiva e simplificar a abstração da implantação.
(6) Os desenvolvedores podem empacotar serviços como pacotes específicos de linguagem, pacotes de sistema operacional, modelos de máquina virtual ou imagens de contêiner.
(7) Adicionar/excluir uma única instância de um microsserviço é uma operação primária básica que pode ser combinada por desenvolvedores em implantações de nível superior.
(8) Os desenvolvedores podem usar implantação canário ou implantação azul-verde para reduzir o impacto de defeitos inesperados na disponibilidade.

Capítulo 9 Implantação baseada em contêiner e agendador;

(1) O empacotamento de microsserviços como artefatos imutáveis e executáveis permite que os desenvolvedores orquestrem o processo de implantação por meio de operações básicas (adicionar ou remover contêineres).
(2) A fim de facilitar o desenvolvimento e a implantação do serviço, o agendador e o contêiner extrairão o conceito de gerenciamento de máquina subjacente.
(3) O trabalho do agendador é tentar combinar os requisitos de recursos do aplicativo com o uso de recursos das máquinas do cluster e executar verificações de integridade nos serviços em execução para garantir que estejam sendo executados corretamente.
(4) O Kubernetes tem as características ideais de uma plataforma de implantação de microsserviços, incluindo gerenciamento de credenciais de senha, descoberta de serviço e expansão horizontal.
(5) Os usuários do Kubernetes definem o estado desejado do serviço de cluster (ou especificação), e o Kubermetes executará continuamente a operação de loop de "execução de comparação de observação" para calcular como atingir o estado desejado.
(6) A unidade de aplicação lógica do Kubernetes é pod: um contêiner ou vários contêineres executados juntos.
(7) O conjunto de réplicas gerencia o ciclo de vida do grupo de pods. Se um pod existente falhar, o conjunto de réplicas iniciará um novo pod.
(8) Os objetos de implantação no Kubernetes são projetados para manter a disponibilidade do serviço executando atualizações contínuas para pods em um conjunto de réplicas.
(9) Os desenvolvedores podem usar objetos de serviço para agrupar pods subjacentes para acesso por outros aplicativos dentro e fora do cluster.

O Capítulo 10 constrói um pipeline de entrega de microsserviços;

(1) O processo de implantação do microsserviço deve atender a dois objetivos: segurança do ritmo e consistência.
(2) O tempo que leva para implantar novos serviços geralmente é um grande obstáculo em aplicativos de microsserviço.
(3) Para microsserviços, a entrega contínua é uma prática de implantação ideal, que reduz o risco ao entregar rapidamente pequenas versões de conjuntos de alterações verificados.
(4) Um bom pipeline de entrega contínua pode garantir a visibilidade do processo de implantação, a exatidão dos resultados da implantação e pode fornecer informações valiosas à equipe de engenharia.
(5) Jenkins é uma ferramenta de construção automatizada muito popular, que usa uma linguagem de script para vincular diferentes ferramentas e combiná-las em um pipeline de entrega.
(6) O ambiente de pré-lançamento é muito valioso, mas quando se depara com um grande número de mudanças independentes, manter um bom ambiente de pré-lançamento também enfrenta grandes desafios.
(7) Os leitores podem reutilizar as etapas declarativas do pipeline nos serviços; a promoção ativa da padronização pode melhorar a previsibilidade do processo de implantação em diferentes equipes.
(8) Para fornecer controle refinado sobre lançamentos e reversões, o leitor deve gerenciar a atividade técnica de implantação separadamente da atividade comercial de lançamentos de recursos.

O Capítulo 11 constrói um sistema de monitoramento;

(1) Um sistema confiável de monitoramento de microsserviços inclui métricas, rastreamento de links e logs.
(2) A coleta de dados ricos de microsserviços ajuda os desenvolvedores a encontrar falhas, investigar problemas e entender o desempenho de todo o aplicativo.
(3) Ao coletar métricas, os desenvolvedores devem se concentrar nos quatro sinais de ouro: latência, volume de erros, tráfego (taxa de transferência) e saturação.
(4) Prometheus e StatsD são duas ferramentas comuns e independentes de linguagem para coletar métricas de microsserviços.
(5) Os desenvolvedores podem usar o Grafana para exibir dados de métricas na forma de gráficos, criar painéis legíveis por humanos e acionar alertas.
(6) Se os alarmes baseados em métricas refletem os sintomas de anormalidades do sistema em vez dos motivos, esses alarmes são mais duráveis e fáceis de manter.
(7) Um alarme bem definido deve ter uma prioridade clara, poder ser escalado para o pessoal correspondente camada por camada, ser operável e conter informações concisas e valiosas.
(8) Os dados coletados e agregados de vários serviços permitem que os desenvolvedores correlacionem e comparem métricas diferentes para obter uma compreensão mais abrangente do sistema.

O Capítulo 12 usa registro e rastreamento de link para entender o comportamento do sistema;

(1) Os leitores podem usar Elasticsearch, Kibana e Fluentd para construir uma infraestrutura de log juntos e usar Jaeger para construir um sistema de rastreamento de link distribuído.
(2) A infraestrutura de log pode gerar, encaminhar e armazenar dados de log indexados para facilitar a recuperação e correlação de diferentes solicitações.
(3) O rastreamento de link distribuído permite que os desenvolvedores rastreiem o processo de execução de solicitações entre diferentes microsserviços.
(4) Além da coleta de métricas, o rastreamento de links pode permitir que os desenvolvedores entendam melhor como o sistema opera, descubram possíveis problemas e revisem o sistema a qualquer momento.

Capítulo 13 Construção de equipes de microsserviços;

(1) Construir um software excelente não está relacionado apenas à escolha da solução, mas também à comunicação, coordenação e colaboração eficazes.
(2) A arquitetura do aplicativo e a estrutura da equipe têm uma relação simbiótica. O último pode ser usado para alterar o primeiro.
(3) Se você deseja que as equipes sejam eficientes, elas devem ser organizadas para maximizar a autonomia, propriedade e responsabilidades de ponta a ponta.
(4) Em termos de entrega de microsserviços, as equipes multifuncionais são mais rápidas e eficientes do que as equipes funcionais tradicionais.
(5) Organizações de engenharia maiores devem estabelecer um modelo em camadas com equipes de infraestrutura, plataforma e produto. As equipes de nível inferior fornecem serviços às equipes de nível superior para permitir que trabalhem com mais eficiência.
(6) Práticas comunitárias (como associações e capítulos), onde o conhecimento funcional pode ser compartilhado.
(7) Aplicações de microsserviços são difíceis de caber no cérebro humano, o que traz desafios para a tomada de decisões globais e engenheiros de plantão.
(8) O arquiteto deve orientar e influenciar a evolução da aplicação, ao invés de ditar a direção e os resultados da aplicação.
(9) O modelo interno de código aberto pode melhorar a colaboração entre equipes, enfraquecer a possessividade e reduzir o risco do fator barramento.
(10) As revisões de design podem melhorar a qualidade, a acessibilidade e a consistência dos microsserviços.
(11) A documentação do microsserviço deve incluir visão geral, manual de operação, metadados e contrato de serviço.

Este documento [Microservice Actual Combat] tem um total de 551 páginas. Se você estiver interessado, envie-me uma mensagem privada