Hola companys.
Avui us oferim per a la vostra consideració la traducció d'un article de Tugberk Ugurlu, que es va comprometre a descriure en un volum relativament petit els principis de disseny de sistemes de programari moderns. Això és el que l'autor diu sobre si mateix en resum:
Com que és absolutament impossible cobrir en un article d'habro un tema tan colossal com els patrons arquitectònics + els patrons de disseny a partir del 2019, recomanem no només el text del mateix Sr. Uruglu, sinó també els nombrosos enllaços que amablement va incloure en ell. Si us agrada, publicarem un text més especialitzat sobre el disseny de sistemes distribuïts.
Instantània de Unsplash
Si mai no heu hagut d'enfrontar-vos a reptes com el disseny d'un sistema de programari des de zero, aleshores, quan inicieu aquest treball, de vegades ni tan sols està clar per on començar. Crec que primer cal dibuixar límits per tenir una idea més o menys segura de què dissenyareu exactament, i després arremangar-vos i treballar dins d'aquests límits. Com a punt de partida, podeu agafar un producte o servei (idealment un que us agradi molt) i esbrinar com implementar-lo. Potser us sorprendrà el senzill que sembla aquest producte i la complexitat que realment conté. No oblidis: , i això està bé.
Crec que el millor consell que puc donar a qualsevol que comenci a dissenyar un sistema és aquest: no feu cap suposició! Des del principi, cal especificar els fets coneguts sobre aquest sistema i les expectatives associades a ell. Aquí teniu algunes bones preguntes per fer-vos per ajudar-vos a començar amb el vostre disseny:
- Quin és el problema que estem intentant resoldre?
- Quin és el nombre màxim d'usuaris que interactuaran amb el nostre sistema?
- Quins patrons d'escriptura i lectura de dades utilitzarem?
- Quins són els casos de fracàs esperats, com els gestionarem?
- Quines són les expectatives de coherència i disponibilitat del sistema?
- Heu de tenir en compte algun requisit relacionat amb la verificació i la regulació externa a l'hora de treballar?
- Quins tipus de dades sensibles emmagatzemarem?
Aquestes són només algunes preguntes que m'han estat útils tant a mi com als equips en què he participat al llarg dels anys d'activitat professional. Si coneixeu les respostes a aquestes preguntes (i altres que siguin rellevants per al context en què heu de treballar), podeu aprofundir gradualment en els detalls tècnics del problema.
Estableix el nivell inicial
Què vull dir aquí amb "línea de base"? De fet, en els nostres temps, la majoria dels problemes de la indústria del programari "es poden" resoldre mitjançant mètodes i tecnologies existents. En conseqüència, navegant per aquest paisatge, obteniu un cert avantatge quan us enfronteu a problemes que algú altre havia de resoldre abans que vosaltres. No oblideu que els programes estan escrits per resoldre problemes empresarials i d'usuari, per això ens esforcem per resoldre el problema de la manera més directa i senzilla (des del punt de vista de l'usuari). Per què és important recordar això? Potser al vostre sistema de coordenades us agrada buscar solucions úniques per a tots els problemes, perquè penseu, "quina mena de programador sóc si segueixo patrons a tot arreu"? De fet, l'art aquí és prendre decisions sobre on i què fer. Per descomptat, cadascú de nosaltres ha de fer front a problemes únics de tant en tant, cadascun dels quals és un autèntic repte. Tanmateix, si el nostre nivell inicial està clarament definit, aleshores sabem en què gastar la nostra energia: cercar opcions ja fetes per resoldre el problema que ens plantegem, o estudiar-lo més i obtenir una comprensió més profunda.
Crec que he pogut convèncer-vos que si un especialista entén amb confiança quin és el component arquitectònic d'alguns sistemes de programari meravellosos, aquest coneixement serà indispensable per dominar l'art d'un arquitecte i desenvolupar una base sòlida en aquest camp.
D'acord, per on començar? U Hi ha un repositori a GitHub anomenat , des del qual podeu aprendre a dissenyar sistemes a gran escala, així com preparar-vos per a entrevistes sobre aquest tema. El repositori té una secció amb exemples , on, en particular, es considera com aborden el disseny dels seus sistemes per exemple, Twitter, Uber, etc.
Tanmateix, abans de passar a aquest material, analitzem més de prop els reptes arquitectònics més importants als quals ens enfrontem a la pràctica. Això és important perquè cal concretar MOLTS aspectes d'un problema tossut i polièdric, i després resoldre'l en el marc de la normativa vigent en un sistema determinat. , un antic empleat de Facebook, va escriure , on va compartir la seva pròpia experiència de seleccionar centenars de sol·licitants. Tot i que el vídeo se centra en gran mesura en el disseny de sistemes grans i els criteris d'èxit que són importants a l'hora de buscar un candidat per a aquesta posició, encara servirà com a recurs complet sobre quines coses són més importants a l'hora de dissenyar sistemes. També suggereixo aquest vídeo.
Desenvolupar coneixements sobre l'emmagatzematge i la recuperació de dades
Normalment, la vostra decisió sobre com emmagatzemar i recuperar les vostres dades a llarg termini té un impacte crític en el rendiment del sistema. Per tant, primer heu d'entendre les característiques esperades d'escriptura i lectura del vostre sistema. Aleshores, cal poder avaluar aquests indicadors i prendre decisions en funció de les valoracions realitzades. Tanmateix, només podeu fer front a aquest treball de manera efectiva si enteneu els patrons d'emmagatzematge de dades existents. En principi, això implica coneixements sòlids relacionats amb .
Les bases de dades es poden considerar com a estructures de dades extremadament escalables i duradores. Per tant, el coneixement de les estructures de dades us hauria de ser molt útil a l'hora d'escollir una base de dades concreta. Per exemple, és un servidor d'estructura de dades que admet diversos tipus de valors. Us permet treballar amb estructures de dades com ara llistes i conjunts, i llegir dades mitjançant algorismes coneguts, per exemple, , organitzant aquest treball amb un estil durador i molt accessible.
Instantània de Unsplash
Un cop tingueu una comprensió suficient dels diferents patrons d'emmagatzematge de dades, passeu a estudiar la coherència i la disponibilitat de les dades. Primer de tot, cal entendre almenys en termes generals, i després polir aquest coneixement observant més de prop els patrons establerts и . D'aquesta manera, adquirireu més coneixements en aquesta àrea i entendreu que llegir i escriure dades són en realitat dos problemes molt diferents, cadascun amb els seus reptes únics. Armat amb uns quants patrons de coherència i disponibilitat, podeu augmentar significativament el rendiment del sistema alhora que garanteix un flux de dades fluid a les vostres aplicacions.
Finalment, per acabar la conversa sobre problemes d'emmagatzematge de dades, també hem d'esmentar la memòria cau. S'ha d'executar simultàniament al client i al servidor? Quines dades hi haurà a la memòria cau? I per què? Com organitzeu la invalidació de la memòria cau? Es farà amb regularitat, en determinats intervals? En cas afirmatiu, amb quina freqüència? Recomano començar a estudiar aquests temes amb l'esmentat manual de disseny del sistema.
Patrons de comunicació
Els sistemes consisteixen en diversos components; poden ser processos diferents que s'executen dins del mateix node físic o màquines diferents que s'executen en diferents parts de la vostra xarxa. Alguns d'aquests recursos de la vostra xarxa poden ser privats, però d'altres haurien de ser públics i oberts als consumidors que hi accedeixin des de l'exterior.
Cal garantir la comunicació d'aquests recursos entre ells, així com l'intercanvi d'informació entre tot el sistema i el món exterior. En el context del disseny de sistemes, aquí de nou ens trobem davant d'un conjunt de reptes nous i únics. A veure com poden ser útils , i què pàg.
Instantània de Unsplash
A l'hora d'organitzar la comunicació amb el món exterior, sempre és molt important , la prestació de la qual també s'ha de prendre seriosament i perseguir activament.
Distribució de la connexió
No estic segur que posar aquest tema en una secció separada sembli justificat per a tothom. No obstant això, presentaré aquest concepte amb detall aquí, i crec que el material d'aquesta secció es descriu amb més precisió amb el terme "distribució de connexió".
Els sistemes es formen connectant correctament molts components, i la seva comunicació entre ells sovint s'organitza sobre la base de protocols establerts, per exemple, TCP i UDP. Tanmateix, aquests protocols com a tals sovint són insuficients per satisfer totes les necessitats dels sistemes moderns, que sovint funcionen amb una càrrega elevada i també depenen molt de les necessitats dels usuaris. Sovint és necessari trobar maneres de distribuir les connexions per fer front a càrregues tan elevades al sistema.
Aquesta distribució es basa en el conegut (DNS). Aquest sistema permet transformacions de noms de domini com ara mètodes basats en latència i mètodes basats en latència per ajudar a distribuir la càrrega.
és fonamentalment important, i pràcticament tots els grans sistemes d'Internet amb què tractem avui es troben darrere d'un o més equilibradors de càrrega. Els equilibradors de càrrega ajuden a distribuir les sol·licituds dels clients entre diverses instàncies disponibles. Els equilibradors de càrrega vénen tant en maquinari com en programari, però, a la pràctica, més sovint heu de tractar amb els de programari, per exemple. и . conceptualment també molt semblant als equilibradors de càrrega, encara que hi ha un rang entre el primer i el segon . Aquestes diferències s'han de tenir en compte a l'hora de dissenyar un sistema en funció de les vostres necessitats.
També hauríeu de saber-ne (CDN). Un CDN és una xarxa global distribuïda de servidors intermediaris que ofereix informació des de nodes que es troben geogràficament més a prop d'un usuari específic. Els CDN són preferibles si treballeu amb fitxers estàtics escrits en JavaScript, CSS i HTML. A més, avui en dia són habituals els serveis al núvol que proporcionen gestors de trànsit, per exemple, , que us ofereix una distribució global i una latència reduïda quan treballeu amb contingut dinàmic. Tanmateix, aquests serveis solen ser útils en els casos en què heu de treballar amb serveis web sense estat.
Parlem de lògica empresarial. Estructurar la lògica de negoci, els fluxos de tasques i els components
Així doncs, vam aconseguir discutir diversos aspectes d'infraestructura del sistema. Molt probablement, l'usuari ni tan sols pensa en tots aquests elements del vostre sistema i, francament, no els importa gens. L'usuari està interessat en com és interactuar amb el vostre sistema, què es pot aconseguir fent això, i també com el sistema executa les ordres de l'usuari, què i com fa amb les dades de l'usuari.
Com suggereix el títol d'aquest article, anava a parlar sobre l'arquitectura del programari i el disseny del sistema. En conseqüència, no pensava cobrir patrons de disseny de programari que descriuen com es creen els components de programari. Tanmateix, com més hi penso, més em sembla que la línia entre els patrons de disseny de programari i els patrons arquitectònics és molt difuminada, i els dos conceptes estan estretament relacionats. Prenguem per exemple (provement d'esdeveniments). Un cop adopteu aquest patró arquitectònic, afectarà gairebé tots els aspectes del vostre sistema: emmagatzematge a llarg termini de dades, el nivell de coherència adoptat al vostre sistema, la forma dels components que hi ha, etc., etc. Per tant, vaig decidir esmentar alguns patrons arquitectònics que es relacionen directament amb la lògica empresarial. Tot i que aquest article s'haurà de limitar a una llista senzilla, us animo a que us el familiaritzeu i penseu en les idees associades a aquests patrons. Aquí estàs:
- Conceptes , en particular, ,
Enfocaments col·laboratius
És molt poc probable que us trobeu en un projecte com a participant que sigui l'únic responsable del procés de disseny del sistema. Al contrari, molt probablement hauràs d'interactuar amb companys que treballen tant dins com fora de la teva tasca. En aquest cas, és possible que hàgiu d'avaluar les solucions tecnològiques seleccionades amb els companys, identificar les necessitats empresarials i comprendre la millor manera de paral·lelitzar les tasques.
Instantània de Unsplash
El primer pas és desenvolupar una comprensió precisa i compartida de quin és l'objectiu comercial que esteu intentant assolir i amb quines parts mòbils haureu de tractar. Tècniques de modelització de grups, en particular (assalt d'esdeveniments) ajuda a accelerar significativament aquest procés i augmentar les possibilitats d'èxit. Aquest treball es pot fer abans o després de l'esquema , i després aprofundir a mesura que el producte madura. En funció del nivell de coherència que s'aconseguirà aquí, també podeu formular pel context limitat en què treballes. Quan necessiteu parlar de l'arquitectura del vostre sistema, us pot resultar útil , proposat , sobretot quan necessiteu entendre fins a quin punt haureu d'entrar en els detalls del problema, visualitzant les coses que voleu comunicar.
Probablement hi hagi una altra tecnologia madura sobre aquest tema que no és menys útil que el disseny basat en dominis. Tanmateix, tornem d'alguna manera a entendre l'àrea temàtica, per tant coneixements i experiència en el camp us hauria de ser útil.
Font: www.habr.com