Olá colegas.
Hoje oferecemos para sua consideração a tradução de um artigo de Tugberk Ugurlu, que se comprometeu a delinear em um volume relativamente pequeno os princípios de projeto de sistemas de software modernos. Aqui está o que o autor diz sobre si mesmo em resumo:
Como é absolutamente impossível cobrir em um artigo habro um tópico tão colossal como padrões arquitetônicos + padrões de design a partir de 2019, recomendamos não apenas o texto do próprio Sr. Uruglu, mas também os numerosos links que ele gentilmente incluiu nele. Se gostar, publicaremos um texto mais especializado sobre projeto de sistemas distribuídos.
Foto do Unsplash
Se você nunca teve que enfrentar desafios como projetar um sistema de software do zero, então, ao iniciar esse trabalho, às vezes nem fica claro por onde começar. Acredito que primeiro você precisa traçar limites para ter uma ideia mais ou menos segura do que exatamente vai projetar e, então, arregaçar as mangas e trabalhar dentro desses limites. Como ponto de partida, você pode pegar um produto ou serviço (de preferência um que você realmente goste) e descobrir como implementá-lo. Você pode se surpreender com a aparência simples deste produto e com a complexidade que ele realmente contém. Não esqueça: , e tudo bem.
Acho que o melhor conselho que posso dar a quem está começando a projetar um sistema é este: não faça suposições! Desde o início, você precisa especificar os fatos conhecidos sobre este sistema e as expectativas associadas a ele. Aqui estão algumas boas perguntas a serem feitas para ajudá-lo a começar seu design:
- Qual é o problema que estamos tentando resolver?
- Qual é o número máximo de usuários que irão interagir com nosso sistema?
- Que padrões de escrita e leitura de dados usaremos?
- Quais são os casos de falha esperados e como vamos lidar com eles?
- Quais são as expectativas para consistência e disponibilidade do sistema?
- Você deve levar em consideração algum requisito relacionado à verificação e regulamentação externa ao trabalhar?
- Que tipos de dados confidenciais iremos armazenar?
Estas são apenas algumas questões que têm sido úteis tanto para mim como para as equipas em que tenho participado ao longo dos anos de atividade profissional. Se você souber as respostas para essas perguntas (e quaisquer outras que sejam relevantes para o contexto em que você deve trabalhar), poderá gradualmente se aprofundar nos detalhes técnicos do problema.
Defina o nível inicial
O que quero dizer com “linha de base” aqui? Na verdade, nos nossos tempos, a maioria dos problemas na indústria de software “pode” ser resolvida usando métodos e tecnologias existentes. Assim, ao navegar nesse cenário, você obtém uma certa vantagem ao se deparar com problemas que outra pessoa teve que resolver antes de você. Não se esqueça de que os programas são escritos para resolver problemas de negócios e de usuários, por isso nos esforçamos para resolver o problema da maneira mais direta e simples (do ponto de vista do usuário). Por que é importante lembrar isso? Talvez no seu sistema de coordenadas você goste de procurar soluções únicas para todos os problemas, porque pensa: “que tipo de programador eu sou se sigo padrões em todos os lugares”? Na verdade, a arte aqui é tomar decisões sobre onde e o que fazer. É claro que cada um de nós tem que lidar com problemas únicos de tempos em tempos, cada um dos quais é um verdadeiro desafio. No entanto, se o nosso nível inicial estiver claramente definido, então sabemos em que gastar a nossa energia: na procura de opções prontas para resolver o problema que temos diante de nós, ou no seu estudo mais aprofundado e na obtenção de uma compreensão mais profunda.
Acho que consegui convencê-lo de que se um especialista compreender com segurança qual é o componente arquitetônico de alguns sistemas de software maravilhosos, então esse conhecimento será indispensável para dominar a arte de um arquiteto e desenvolver uma base sólida nesta área.
Ok, então por onde começar? você Existe um repositório no GitHub chamado , onde você aprenderá como projetar sistemas de grande escala, bem como se preparar para entrevistas sobre o assunto. O repositório possui uma seção com exemplos , onde, em particular, é considerado como eles abordam o design de seus sistemas por exemplo, Twitter, Uber, etc.
No entanto, antes de passarmos a este material, vamos dar uma olhada nos desafios arquitetônicos mais importantes que enfrentamos na prática. Isto é importante porque é necessário especificar MUITOS aspectos de um problema persistente e multifacetado e depois resolvê-lo no âmbito dos regulamentos em vigor num determinado sistema. , um ex-funcionário do Facebook, escreveu , onde compartilhou sua própria experiência na triagem de centenas de candidatos. Embora o vídeo se concentre fortemente no projeto de grandes sistemas e nos critérios de sucesso que são importantes ao procurar um candidato para tal posição, ele ainda servirá como um recurso abrangente sobre o que é mais importante ao projetar sistemas. Eu também sugiro esse vídeo.
Construir conhecimento sobre armazenamento e recuperação de dados
Normalmente, a sua decisão sobre como armazenar e recuperar os seus dados a longo prazo tem um impacto crítico no desempenho do sistema. Portanto, você deve primeiro compreender as características esperadas de gravação e leitura do seu sistema. Então você precisa ser capaz de avaliar esses indicadores e fazer escolhas com base nas avaliações feitas. No entanto, você só poderá lidar com esse trabalho de maneira eficaz se compreender os padrões existentes de armazenamento de dados. Em princípio, isto implica conhecimentos sólidos relacionados com .
Os bancos de dados podem ser considerados estruturas de dados extremamente escaláveis e duráveis. Portanto, o conhecimento de estruturas de dados deve ser muito útil na escolha de um banco de dados específico. Por exemplo, é um servidor de estrutura de dados que suporta vários tipos de valores. Ele permite trabalhar com estruturas de dados como listas e conjuntos, e ler dados usando algoritmos bem conhecidos, por exemplo, , organizando esse trabalho em um estilo durável e altamente acessível.
Foto do Unsplash
Depois de ter uma compreensão suficiente dos vários padrões de armazenamento de dados, prossiga para o estudo da consistência e disponibilidade dos dados. Primeiro de tudo, você precisa entender pelo menos em termos gerais, e depois aprimorar esse conhecimento examinando mais de perto os padrões estabelecidos и . Dessa forma, você desenvolverá uma compreensão da área e compreenderá que ler e escrever dados são, na verdade, dois problemas muito diferentes, cada um com seus desafios únicos. Munido de alguns padrões de consistência e disponibilidade, você pode aumentar significativamente o desempenho do sistema e, ao mesmo tempo, garantir um fluxo de dados suave para seus aplicativos.
Finalmente, concluindo a conversa sobre questões de armazenamento de dados, devemos mencionar também o cache. Deve ser executado simultaneamente no cliente e no servidor? Quais dados estarão em seu cache? E porque? Como você organiza a invalidação do cache? Será feito regularmente, em determinados intervalos? Se sim, com que frequência? Eu recomendo começar a estudar esses tópicos com a cartilha de design de sistema acima mencionada.
Padrões de comunicação
Os sistemas consistem em vários componentes; podem ser processos diferentes executados no mesmo nó físico ou máquinas diferentes executadas em partes diferentes da rede. Alguns desses recursos dentro da sua rede podem ser privados, mas outros devem ser públicos e abertos aos consumidores que os acessam de fora.
É necessário garantir a comunicação destes recursos entre si, bem como a troca de informações entre todo o sistema e o mundo exterior. No contexto do design de sistemas, aqui novamente nos deparamos com um conjunto de desafios novos e únicos. Vamos ver como eles podem ser úteis , e o que p.
Foto do Unsplash
Ao organizar a comunicação com o mundo exterior, é sempre muito importante , cuja disponibilização também deve ser levada a sério e prosseguida ativamente.
Distribuição de conexão
Não tenho certeza se colocar este tópico em uma seção separada parecerá justificado para todos. No entanto, apresentarei este conceito em detalhes aqui e acredito que o material desta seção é descrito com mais precisão pelo termo “distribuição de conexão”.
Os sistemas são formados pela conexão adequada de muitos componentes, e sua comunicação entre si é frequentemente organizada com base em protocolos estabelecidos, por exemplo, TCP e UDP. No entanto, estes protocolos como tais são muitas vezes insuficientes para satisfazer todas as necessidades dos sistemas modernos, que são frequentemente operados sob elevada carga e também são altamente dependentes das necessidades do utilizador. Muitas vezes é necessário encontrar maneiras de distribuir conexões para lidar com cargas tão elevadas no sistema.
Esta distribuição é baseada no conhecido (DNS). Esse sistema permite transformações de nomes de domínio, como round robin ponderado e métodos baseados em latência, para ajudar a distribuir a carga.
é fundamentalmente importante, e praticamente todos os grandes sistemas de Internet com os quais lidamos hoje estão localizados atrás de um ou mais balanceadores de carga. Os balanceadores de carga ajudam a distribuir solicitações de clientes em várias instâncias disponíveis. Os balanceadores de carga vêm em hardware e software, porém, na prática, mais frequentemente você tem que lidar com software, por exemplo и . conceitualmente também muito semelhante aos balanceadores de carga, embora haja uma faixa entre o primeiro e o segundo . Essas diferenças devem ser levadas em consideração ao projetar um sistema baseado em suas necessidades.
Você também deve saber sobre (CDN). Uma CDN é uma rede global distribuída de servidores proxy que fornece informações de nós localizados geograficamente mais próximos de um usuário específico. É preferível usar CDNs se você trabalha com arquivos estáticos escritos em JavaScript, CSS e HTML. Além disso, hoje são comuns os serviços em nuvem que fornecem gerenciadores de tráfego, por exemplo, , proporcionando distribuição global e latência reduzida ao trabalhar com conteúdo dinâmico. No entanto, esses serviços geralmente são úteis nos casos em que você precisa trabalhar com serviços da Web sem estado.
Vamos falar sobre lógica de negócios. Estruturação de lógica de negócios, fluxos de tarefas e componentes
Assim, conseguimos discutir vários aspectos infraestruturais do sistema. Muito provavelmente, o usuário nem pensa em todos esses elementos do seu sistema e, francamente, nem se importa com eles. O usuário está interessado em saber como é interagir com seu sistema, o que pode ser alcançado fazendo isso e também como o sistema executa comandos do usuário, o que e como ele faz com os dados do usuário.
Como sugere o título deste artigo, eu falaria sobre arquitetura de software e design de sistema. Conseqüentemente, não planejei cobrir padrões de projeto de software que descrevem como os componentes de software são criados. No entanto, quanto mais penso nisso, mais me parece que a linha entre os padrões de design de software e os padrões de arquitetura é muito confusa e os dois conceitos estão intimamente relacionados. Tomemos por exemplo (fonte de evento). Depois de adotar esse padrão de arquitetura, ele afetará quase todos os aspectos do seu sistema: armazenamento de dados a longo prazo, o nível de consistência adotado no seu sistema, a forma dos componentes nele, etc., etc. Por isso, resolvi citar alguns padrões de arquitetura que se relacionam diretamente com a lógica de negócios. Embora este artigo tenha que se limitar a uma lista simples, encorajo você a se familiarizar com ele e a pensar nas ideias associadas a esses padrões. Olha Você aqui:
- Do conceito em particular ,
Abordagens colaborativas
É extremamente improvável que você se encontre em um projeto como o único participante responsável pelo processo de design do sistema. Pelo contrário, você provavelmente terá que interagir com colegas que trabalham dentro e fora da sua tarefa. Neste caso, poderá ser necessário avaliar as soluções tecnológicas selecionadas com colegas, identificar necessidades de negócio e compreender a melhor forma de paralelizar tarefas.
Foto do Unsplash
A primeira etapa é desenvolver uma compreensão precisa e compartilhada de qual é a meta de negócios que você está tentando alcançar e com quais partes móveis você terá que lidar. Técnicas de modelagem de grupo, em particular (event storming) ajudam a acelerar significativamente esse processo e aumentar suas chances de sucesso. Este trabalho pode ser feito antes ou depois de você delinear e aprofunde-o à medida que o produto amadurece. Com base no nível de consistência que será alcançado aqui, você também pode formular para o contexto limitado em que você trabalha. Quando você precisar falar sobre a arquitetura do seu sistema, poderá achar útil , proposto , principalmente quando você precisa entender o quanto terá que entrar nos detalhes do problema, visualizando o que deseja comunicar.
Provavelmente existe outra tecnologia madura neste tópico que não é menos útil do que o Domain Driven Design. Porém, de alguma forma voltamos a compreender a área temática, portanto o conhecimento e a experiência na área deve ser útil para você.
Fonte: habr.com