Софтверска архитектура и дизајн на системи: Водич за голема слика и ресурси

Здраво колеги.

Денес ви нудиме превод на статија од Тугберк Угурлу, кој се обврза да ги претстави во релативно мал обем принципите на дизајнирање современи софтверски системи. Еве што накратко кажува авторот за себе:

Бидејќи е апсолутно невозможно во хабро статија да се опфати таква колосална тема како архитектонски обрасци + модели на дизајн од 2019 година, го препорачуваме не само текстот на самиот г-дин Уруглу, туку и бројните врски што тој љубезно ги вклучи во него. Ако ви се допаѓа, ќе објавиме повисоко специјализиран текст за дизајнот на дистрибуирани системи.

Снимка Исак Смит од Unsplash

Ако никогаш не сте морале да се соочите со такви предизвици како дизајнирање софтверски систем од нула, тогаш кога започнувате таква работа, понекогаш дури и не е јасно од каде да започнете. Верувам дека прво треба да повлечете граници за да имате повеќе или помалку сигурна идеја за тоа што точно ќе дизајнирате, а потоа да ги засукате ракавите и да работите во тие граници. Како почетна точка, можете да земете производ или услуга (идеално оној што навистина ви се допаѓа) и да сфатите како да го имплементирате. Можеби ќе бидете изненадени од тоа колку едноставно изгледа овој производ и колку сложеност всушност содржи. Не заборавај: едноставно - обично сложено, и тоа е во ред.

Мислам дека најдобриот совет што можам да му го дадам на секој што почнува да дизајнира систем е овој: не правете никакви претпоставки! Од самиот почеток, треба да ги наведете фактите познати за овој систем и очекувањата поврзани со него. Еве неколку добри прашања што треба да ги поставите за да ви помогнат да започнете со вашиот дизајн:

• Кој е проблемот што се обидуваме да го решиме?
• Колкав е максималниот број на корисници што ќе комуницираат со нашиот систем?
• Кои модели на пишување и читање податоци ќе ги користиме?
• Кои се очекуваните случаи на неуспех, како ќе се справиме со нив?
• Кои се очекувањата за конзистентноста и достапноста на системот?
• Дали треба да ги земете предвид сите барања поврзани со надворешната верификација и регулатива кога работите?
• Какви видови чувствителни податоци ќе складираме?

Ова се само неколку прашања кои ми беа корисни и за мене и за тимовите во кои сум учествувал низ годините на професионална дејност. Ако ги знаете одговорите на овие прашања (и сите други кои се релевантни за контекстот во кој треба да работите), тогаш можете постепено да истражувате во техничките детали на проблемот.

Поставете го почетното ниво

Што мислам со „основна линија“ овде? Всушност, во наше време, повеќето проблеми во софтверската индустрија „може“ да се решат со користење на постоечки методи и технологии. Според тоа, со навигација по овој пејзаж, добивате одреден почеток кога ќе се соочите со проблеми што некој друг морал да ги реши пред вас. Не заборавајте дека програмите се напишани за да ги решаваат деловните и корисничките проблеми, затоа се стремиме да го решиме проблемот на најдиректен и наједноставен (од гледна точка на корисникот) начин. Зошто е ова важно да се запамети? Можеби во вашиот координатен систем сакате да барате уникатни решенија за сите проблеми, затоа што мислите, „каков програмер сум јас ако следам шеми насекаде“? Всушност, уметноста овде е донесување одлуки за тоа каде и што да се прави. Се разбира, секој од нас треба одвреме-навреме да се справува со уникатни проблеми, од кои секој е вистински предизвик. Меѓутоа, ако нашето почетно ниво е јасно дефинирано, тогаш знаеме на што да ја трошиме нашата енергија: барање готови опции за решавање на проблемот што ни е поставен или дополнително проучување и стекнување подлабоко разбирање.

Мислам дека успеав да ве убедам дека ако специјалист самоуверено разбере која е архитектонската компонента на некои прекрасни софтверски системи, тогаш ова знаење ќе биде неопходно за совладување на уметноста на архитект и развивање солидна основа во оваа област.

Добро, па од каде да почнам? У Дона Мартина Постои складиште на GitHub наречено систем-дизајн-прајмер, од кои можете да научите како да дизајнирате системи од големи размери, како и да се подготвите за интервјуа на оваа тема. Во складиштето има дел со примери вистински архитектури, каде што, особено, се разгледува како тие пристапуваат кон дизајнот на нивните системи некои познати компаниина пр. Twitter, Uber итн.

Сепак, пред да преминеме на овој материјал, да ги погледнеме подетално најважните архитектонски предизвици со кои се соочуваме во пракса. Ова е важно затоа што треба да наведете МНОГУ аспекти на тврдоглав и повеќеслоен проблем, а потоа да го решите во рамките на важечките прописи во даден систем. Џексон Габард, напиша поранешен вработен во Фејсбук 50-минутно видео за интервјуа за дизајн на системи, каде што го сподели сопственото искуство за проверка на стотици апликанти. Иако видеото многу се фокусира на дизајнот на големиот систем и критериумите за успех кои се важни кога барате кандидат за таква позиција, сепак ќе служи како сеопфатен ресурс за тоа кои работи се најважни при дизајнирање системи. Предлагам и јас резиме ова видео.

Изградете знаење за складирање и преземање податоци

Вообичаено, вашата одлука за тоа како ги складирате и враќате вашите податоци на долг рок има критично влијание врз перформансите на системот. Затоа, прво мора да ги разберете очекуваните карактеристики за пишување и читање на вашиот систем. Потоа треба да бидете во можност да ги оцените овие индикатори и да направите избор врз основа на направените проценки. Сепак, можете ефикасно да се справите со оваа работа само ако ги разбирате постоечките обрасци за складирање податоци. Во принцип, ова подразбира солидно знаење поврзано со избор на база на податоци.

Базите на податоци може да се сметаат како структури на податоци кои се исклучително скалабилни и издржливи. Затоа, знаењето за структурите на податоци треба да ви биде многу корисно при изборот на одредена база на податоци. На пример, Redis е сервер за структура на податоци кој поддржува различни типови на вредности. Ви овозможува да работите со структури на податоци како што се списоци и множества и да читате податоци користејќи добро познати алгоритми, на пример, ЛРУ, организирање на таква работа во издржлив и многу достапен стил.

Снимка Семјуел Зелер од Unsplash

Откако ќе имате доволно разбирање за различните обрасци за складирање податоци, преминете на проучување на конзистентноста и достапноста на податоците. Пред сè, треба да разберете CAP теорема барем во општа смисла, а потоа да го полираме ова знаење со внимателно разгледување на воспоставените обрасци конзистентност и пристапност. На овој начин, ќе развиете разбирање за областа и ќе разберете дека читањето и пишувањето податоци се всушност два многу различни проблеми, секој со свои уникатни предизвици. Вооружени со неколку модели на конзистентност и достапност, можете значително да ги зголемите перформансите на системот, истовремено обезбедувајќи непречен проток на податоци до вашите апликации.

Конечно, завршувајќи го разговорот за прашањата за складирање податоци, треба да го споменеме и кеширањето. Дали треба да работи истовремено на клиентот и серверот? Кои податоци ќе бидат во вашиот кеш? И зошто? Како да организирате неважење на кешот? Дали тоа ќе се прави редовно, во одредени интервали? Ако да, колку често? Препорачувам да започнете да ги проучувате овие теми со следниот дел гореспоменатиот прајмер за дизајн на системот.

Модели за комуникација

Системите се состојат од различни компоненти; тоа може да бидат различни процеси кои работат во ист физички јазол или различни машини кои работат на различни делови од вашата мрежа. Некои од овие ресурси во вашата мрежа можеби се приватни, но други треба да бидат јавни и отворени за потрошувачите кои им пристапуваат однадвор.

Неопходно е да се обезбеди комуникација на овие ресурси меѓу себе, како и размена на информации помеѓу целиот систем и надворешниот свет. Во контекст на дизајнот на системи, овде повторно се соочуваме со сет на нови и уникатни предизвици. Ајде да видиме како тие можат да бидат корисни асинхрони текови на задачи, и што стрДостапни се различни обрасци за комуникација.

Снимка Тони Стодард од Unsplash

Кога се организира комуникација со надворешниот свет, секогаш е многу важно безбедност, чие обезбедување исто така треба сериозно и активно да се продолжи.

Дистрибуција на поврзување

Не сум сигурен дека ставањето на оваа тема во посебен дел ќе изгледа оправдано за сите. Сепак, овде детално ќе го претставам овој концепт и верувам дека материјалот во овој дел е најпрецизно опишан со терминот „дистрибуција на поврзување“.

Системите се формираат со правилно поврзување на многу компоненти, а нивната комуникација меѓу себе често се организира врз основа на воспоставени протоколи, на пример, TCP и UDP. Меѓутоа, овие протоколи како такви често се недоволни за да ги задоволат сите потреби на современите системи, кои често работат под големо оптоварување и исто така се многу зависни од потребите на корисниците. Често е неопходно да се најдат начини за дистрибуција на врски за да се справат со толку високи оптоварувања на системот.

Оваа дистрибуција се заснова на добро познатото систем за име на домен (DNS). Таквиот систем дозволува трансформации на имиња на домени, како што се методите засновани на пондерирање и латентност за да помогнат во дистрибуцијата на оптоварувањето.

Балансирање на товарот е фундаментално важен, и практично секој голем интернет систем со кој се занимаваме денес се наоѓа зад еден или повеќе балансери на оптоварување. Балансите на оптоварување помагаат да се дистрибуираат барањата на клиентите низ повеќе достапни примероци. Балансите на оптоварување доаѓаат и во хардвер и во софтвер, меѓутоа, во пракса, почесто треба да се занимавате со софтверски, на пример HAProxy и ELB. Обратна прокси Концептуално, исто така, многу слични на балансерите на оптоварување, иако постои опсег помеѓу првиот и вториот различни разлики. Овие разлики мора да се земат предвид при дизајнирање на систем заснован на вашите потреби.

Треба да знаете и за мрежи за испорака на содржина (CDN). CDN е глобална дистрибуирана мрежа на прокси-сервери што доставува информации од оние јазли кои географски се наоѓаат поблиску до одреден корисник. ЦДН се претпочитаат да се користат ако работите со статични датотеки напишани во JavaScript, CSS и HTML. Покрај тоа, облак услугите кои обезбедуваат менаџери за сообраќај се вообичаени денес, на пример, Менаџер за сообраќај Azure, давајќи ви глобална дистрибуција и намалена латентност при работа со динамична содржина. Сепак, таквите услуги обично се корисни во случаи кога треба да работите со веб-услуги без државјанство.

Ајде да зборуваме за деловната логика. Структурирање на деловната логика, текови на задачи и компоненти

Така, успеавме да разговараме за различни инфраструктурни аспекти на системот. Најверојатно, корисникот дури и не размислува за сите овие елементи на вашиот систем и, искрено, воопшто не се грижи за нив. Корисникот го интересира како е да комуницирате со вашиот систем, што може да се постигне со тоа, а исто така и како системот ги извршува корисничките команди, што и како прави со корисничките податоци.

Како што сугерира насловот на оваа статија, требаше да зборувам за софтверска архитектура и дизајн на системот. Според тоа, не планирав да покривам обрасци за дизајн на софтвер кои опишуваат како се креираат софтверските компоненти. Меѓутоа, колку повеќе размислувам за тоа, толку повеќе ми се чини дека линијата помеѓу обрасците за дизајн на софтвер и архитектонските обрасци е многу нејасна, а двата концепта се тесно поврзани. Да земеме на пример регистрација на настанот (извори за настан). Откако ќе го усвоите овој архитектонски модел, тој ќе влијае на речиси секој аспект од вашиот систем: долгорочно складирање на податоци, нивото на конзистентност усвоено во вашиот систем, обликот на компонентите во него, итн., итн. Затоа, решив да споменам некои архитектонски обрасци кои директно се однесуваат на деловната логика. Иако оваа статија ќе мора да се ограничи на едноставна листа, ве охрабрувам да се запознаете со неа и да размислите за идеите поврзани со овие модели. Тука си:

• Цврсти принципи
• Концепти Дизајн управуван од домен, особено, агрегати, тимови и настани
• Шестоаголна архитектура
• Поделба на одговорностите во команди и барања (CQRS)
• Регистрација на настанот
• Актер модел
• Шаблони за дизајнирање MVC, MVVM и MVP

Колаборативни пристапи

Исклучително е малку веројатно дека ќе се најдете на проект како учесник кој е единствено одговорен за процесот на дизајнирање на системот. Напротив, најверојатно ќе мора да комуницирате со колегите кои работат и во и надвор од вашата задача. Во овој случај, можеби ќе треба да ги оцените избраните технолошки решенија со колегите, да ги идентификувате деловните потреби и да разберете како најдобро да ги паралелизирате задачите.

Снимка Калеидико од Unsplash

Првиот чекор е да развиете точно и заедничко разбирање за тоа која е деловната цел што се обидувате да ја постигнете и со кои подвижни делови ќе треба да се справите. Техники за групно моделирање, особено бурни настани (бура на настани) помагаат значително да се забрза овој процес и да се зголемат вашите шанси за успех. Оваа работа може да се направи пред или откако ќе го нацртате границите на вашите услуги, а потоа продлабочете го додека производот созрева. Врз основа на нивото на конзистентност што ќе се постигне овде, можете исто така да формулирате заеднички јазик за ограничениот контекст во кој работите. Кога треба да зборувате за архитектурата на вашиот систем, можеби ќе ви биде корисно модел C4, предложен Сајмон Браун, особено кога станува збор за разбирање колку ќе треба да навлегувате во детали за проблемот, визуелизирајќи ги работите што сакате да ги комуницирате.

Веројатно постои уште една зрела технологија на оваа тема која не е помалку корисна од Дизајн управуван од домен. Сепак, некако се враќаме на разбирање на предметната област, значи знаење и искуство во областа Дизајн управуван од домен треба да ви биде корисно.

Извор: www.habr.com