Ola compañeiros.
Hoxe ofrecemos para a súa consideración a tradución dun artigo de Tugberk Ugurlu, que se comprometeu a esbozar nun volume relativamente pequeno os principios do deseño de sistemas de software modernos. Isto é o que o autor di sobre si mesmo en resumo:
Dado que é absolutamente imposible cubrir nun artigo de habro un tema tan colosal como patróns arquitectónicos + patróns de deseño a partir de 2019, recomendamos non só o texto do propio Sr. Uruglu, senón tamén as numerosas ligazóns que amablemente incluíu nel. Se che gusta, publicaremos un texto máis especializado sobre o deseño de sistemas distribuídos.
Instantánea de Unsplash
Se nunca tivo que enfrontarse a retos como deseñar un sistema de software desde cero, entón ao comezar ese traballo, ás veces nin sequera está claro por onde comezar. Creo que primeiro cómpre debuxar límites para ter unha idea máis ou menos segura do que vai deseñar exactamente, e despois arremangarse e traballar dentro deses límites. Como punto de partida, podes tomar un produto ou servizo (idealmente un que che guste moito) e descubrir como implementalo. Podes sorprenderte do sinxelo que parece este produto e da complexidade que realmente contén. Non esquezas: , e iso está ben.
Creo que o mellor consello que podo dar a quen empece a deseñar un sistema é o seguinte: non fagas ningunha suposición! Desde o principio, cómpre especificar os feitos coñecidos sobre este sistema e as expectativas asociadas a el. Aquí tes algunhas boas preguntas para axudarche a comezar co teu deseño:
- Cal é o problema que intentamos resolver?
- Cal é o número máximo de usuarios que interactuarán co noso sistema?
- Que patróns de escritura e lectura de datos usaremos?
- Cales son os casos de fallo esperados, como imos tratalos?
- Cales son as expectativas de coherencia e dispoñibilidade do sistema?
- Tes que ter en conta algún requisito relacionado coa verificación externa e a regulación cando traballas?
- Que tipos de datos sensibles imos almacenar?
Son só algunhas preguntas que me resultaron útiles tanto para min como para os equipos nos que participei ao longo dos anos de actividade profesional. Se coñeces as respostas a estas preguntas (e a outras que sexan relevantes para o contexto no que tes que traballar), podes profundizar aos poucos nos detalles técnicos do problema.
Establece o nivel inicial
Que quero dicir aquí con "línea de base"? En realidade, nos nosos tempos, a maioría dos problemas da industria do software "poden" resolverse utilizando métodos e tecnoloxías existentes. En consecuencia, ao navegar por esta paisaxe, obtén unha certa vantaxe cando te enfrontas a problemas que outra persoa tivo que resolver antes que ti. Non esquezas que os programas están escritos para resolver problemas empresariais e dos usuarios, polo que nos esforzamos por resolver o problema da forma máis sinxela e sinxela (desde o punto de vista do usuario). Por que é importante lembralo? Quizais no teu sistema de coordenadas che guste buscar solucións únicas para todos os problemas, porque pensas, "que clase de programador son eu se sigo patróns en todas partes"? De feito, a arte aquí é tomar decisións sobre onde e que facer. Por suposto, cada un de nós ten que enfrontarse a problemas únicos de cando en vez, cada un dos cales é un verdadeiro desafío. Non obstante, se o noso nivel inicial está claramente definido, entón sabemos en que gastar a nosa enerxía: buscar opcións preparadas para resolver o problema que nos plantexamos, ou estudalo máis e obter unha comprensión máis profunda.
Creo que puiden convencelo de que se un especialista entende con confianza cal é o compoñente arquitectónico dalgúns sistemas de software marabillosos, entón este coñecemento será indispensable para dominar a arte dun arquitecto e desenvolver unha base sólida neste campo.
Vale, entón por onde comezar? U Hai un repositorio en GitHub chamado , do que podes aprender a deseñar sistemas a gran escala, así como prepararte para entrevistas sobre este tema. O repositorio ten unha sección con exemplos , onde, en particular, se considera como abordan o deseño dos seus sistemas por exemplo, Twitter, Uber, etc.
Non obstante, antes de pasar a este material, vexamos máis de cerca os retos arquitectónicos máis importantes aos que nos enfrontamos na práctica. Isto é importante porque hai que concretar MOITOS aspectos dun problema teimudo e polifacético, e despois resolvelo no marco da normativa vixente nun determinado sistema. , un antigo empregado de Facebook, escribiu , onde compartiu a súa propia experiencia na selección de centos de candidatos. Aínda que o vídeo se centra en gran medida no deseño de sistemas grandes e nos criterios de éxito que son importantes á hora de buscar un candidato para tal posto, aínda servirá como un recurso completo sobre cales son as cousas máis importantes á hora de deseñar sistemas. Tamén suxiro este vídeo.
Adquirir coñecementos sobre o almacenamento e a recuperación de datos
Normalmente, a súa decisión sobre como almacenar e recuperar os seus datos a longo prazo ten un impacto crítico no rendemento do sistema. Polo tanto, primeiro debes comprender as características de lectura e escritura esperadas do teu sistema. Entón cómpre ser capaz de avaliar estes indicadores e facer eleccións en función das valoracións realizadas. Non obstante, só pode facer fronte a este traballo de forma eficaz se comprende os patróns de almacenamento de datos existentes. En principio, isto implica coñecementos sólidos relacionados co .
As bases de datos pódense considerar como estruturas de datos extremadamente escalables e duradeiros. Polo tanto, o coñecemento das estruturas de datos debería serlle moi útil á hora de escoller unha base de datos en particular. Por exemplo, é un servidor de estrutura de datos que admite varios tipos de valores. Permítelle traballar con estruturas de datos como listas e conxuntos, e ler datos utilizando algoritmos coñecidos, por exemplo, , organizando ese traballo nun estilo duradeiro e moi accesible.
Instantánea de Unsplash
Unha vez que teña unha comprensión suficiente dos distintos patróns de almacenamento de datos, pase a estudar a coherencia e dispoñibilidade dos datos. Primeiro de todo, cómpre entender polo menos en termos xerais, e despois pulir estes coñecementos poñendo unha ollada máis atenta aos patróns establecidos и . Deste xeito, desenvolverás unha comprensión do campo e entenderás que ler e escribir datos son en realidade dous problemas moi diferentes, cada un cos seus propios desafíos únicos. Armado con algúns patróns de coherencia e dispoñibilidade, pode aumentar significativamente o rendemento do sistema ao tempo que garante un fluxo de datos fluido ás súas aplicacións.
Finalmente, rematando a conversación sobre os problemas de almacenamento de datos, tamén debemos mencionar o caché. Debería executarse simultaneamente no cliente e no servidor? Que datos haberá na túa caché? E por que? Como organizas a invalidación da caché? Farase regularmente, a determinados intervalos? Se si, cantas veces? Recomendo comezar a estudar estes temas con o citado manual de deseño do sistema.
Patróns de comunicación
Os sistemas consisten en varios compoñentes; estes poden ser procesos diferentes que se executan no mesmo nodo físico ou máquinas diferentes que se executan en diferentes partes da súa rede. Algúns destes recursos da túa rede poden ser privados, pero outros deberían ser públicos e abertos aos consumidores que accedan a eles desde fóra.
É necesario garantir a comunicación destes recursos entre si, así como o intercambio de información entre todo o sistema e o mundo exterior. No contexto do deseño de sistemas, aquí de novo estamos ante un conxunto de desafíos novos e únicos. A ver como poden ser útiles , e que páx.
Instantánea de Unsplash
Á hora de organizar a comunicación co mundo exterior, sempre é moi importante , cuxa prestación tamén debe ser tomada en serio e perseguida activamente.
Distribución de conexións
Non estou seguro de que poñer este tema nunha sección separada pareza xustificado para todos. Non obstante, presentarei este concepto en detalle aquí e creo que o material desta sección descríbese con máis precisión co termo "distribución de conexións".
Os sistemas fórmanse conectando correctamente moitos compoñentes, e a súa comunicación entre si organízase a miúdo en base a protocolos establecidos, por exemplo, TCP e UDP. Non obstante, estes protocolos como tales adoitan ser insuficientes para satisfacer todas as necesidades dos sistemas modernos, que adoitan funcionar baixo carga elevada e tamén dependen moito das necesidades dos usuarios. Moitas veces é necesario atopar formas de distribuír conexións para facer fronte a cargas tan elevadas no sistema.
Esta distribución baséase no coñecido (DNS). Este sistema permite transformacións de nomes de dominio como métodos baseados en latencia e round robin ponderados para axudar a distribuír a carga.
é fundamentalmente importante, e practicamente todos os grandes sistemas de Internet cos que tratamos hoxe están situados detrás dun ou máis equilibradores de carga. Os equilibradores de carga axudan a distribuír as solicitudes dos clientes en varias instancias dispoñibles. Os equilibradores de carga veñen tanto en hardware como en software, non obstante, na práctica, con máis frecuencia ten que tratar con software, por exemplo и . conceptualmente tamén moi semellante aos equilibradores de carga, aínda que hai un intervalo entre o primeiro e o segundo . Estas diferenzas deben terse en conta á hora de deseñar un sistema en función das súas necesidades.
Tamén debes saber (CDN). Un CDN é unha rede distribuída global de servidores proxy que ofrece información desde nodos que están xeograficamente situados máis preto dun usuario específico. Os CDN son preferibles se traballas con ficheiros estáticos escritos en JavaScript, CSS e HTML. Ademais, os servizos na nube que proporcionan xestores de tráfico son comúns hoxe en día, por exemplo, , ofrecéndoche unha distribución global e unha latencia reducida ao traballar con contido dinámico. Non obstante, estes servizos adoitan ser útiles nos casos nos que tes que traballar con servizos web sen estado.
Falemos de lóxica empresarial. Estruturar a lóxica de negocio, os fluxos de tarefas e os compoñentes
Así, conseguimos discutir varios aspectos infraestruturais do sistema. O máis probable é que o usuario nin sequera pense en todos estes elementos do seu sistema e, francamente, non lle importa nada. O usuario está interesado en como é interactuar co seu sistema, o que se pode conseguir facendo isto e tamén como o sistema executa os comandos do usuario, que e como fai cos datos do usuario.
Como suxire o título deste artigo, ía falar sobre a arquitectura de software e o deseño de sistemas. En consecuencia, non pensaba cubrir patróns de deseño de software que describen como se crean os compoñentes de software. Porén, canto máis o penso, máis me parece que a liña entre os patróns de deseño de software e os patróns arquitectónicos está moi difuminada, e os dous conceptos están moi relacionados. Poñamos por exemplo (proveemento de eventos). Unha vez que adopte este patrón arquitectónico, afectará a case todos os aspectos do seu sistema: almacenamento a longo prazo de datos, o nivel de coherencia adoptado no seu sistema, a forma dos compoñentes, etc., etc. Por iso, decidín mencionar algúns patróns arquitectónicos que se relacionan directamente coa lóxica empresarial. Aínda que este artigo terá que limitarse a unha lista sinxela, anímoche a que te familiarices con el e penses nas ideas asociadas a estes patróns. Aquí estás:
- Conceptos , en particular, ,
Enfoques colaborativos
É moi improbable que te atopes nun proxecto como o participante que é o único responsable do proceso de deseño do sistema. Pola contra, o máis probable é que teñas que interactuar con compañeiros que traballan tanto dentro como fóra da túa tarefa. Neste caso, pode ter que avaliar as solucións tecnolóxicas seleccionadas cos seus compañeiros, identificar as necesidades empresariais e comprender a mellor forma de paralelizar as tarefas.
Instantánea de Unsplash
O primeiro paso é desenvolver unha comprensión precisa e compartida de cal é o obxectivo empresarial que estás a conseguir e con que partes móbiles terás que tratar. Técnicas de modelado de grupos, en particular (asalto de eventos) axudan a acelerar significativamente este proceso e aumentan as súas posibilidades de éxito. Este traballo pódese facer antes ou despois de esbozar , e despois profundiza a medida que o produto madura. En función do nivel de coherencia que se acadará aquí, tamén se pode formular polo limitado contexto no que traballas. Cando necesites falar sobre a arquitectura do teu sistema, pode resultarlle útil , proposto , sobre todo cando necesitas entender canto terás que entrar nos detalles do problema, visualizando as cousas que queres comunicar.
Probablemente haxa outra tecnoloxía madura sobre este tema que non sexa menos útil que o Domain Driven Design. Porén, volvemos dalgún xeito a comprender a área temática, polo tanto coñecementos e experiencia na materia debería ser útil para ti.
Fonte: www.habr.com