Здравейте колеги.
Днес предлагаме на вашето внимание превод на статия от Тугберк Угурлу, който се зае да очертае в сравнително малък обем принципите на проектиране на съвременни софтуерни системи. Ето какво в обобщение казва авторът за себе си:
Тъй като е абсолютно невъзможно да се обхване в habro статия такава колосална тема като архитектурни шаблони + дизайнерски модели от 2019 г., препоръчваме не само самия текст на г-н Уруглу, но и многобройните връзки, които той любезно включи в него. Ако ви харесва, ще публикуваме по-тясно специализиран текст за дизайна на разпределени системи.
Моментална снимка от Unsplash
Ако никога не сте се сблъсквали с такива предизвикателства като проектиране на софтуерна система от нулата, тогава когато започнете такава работа, понякога дори не е ясно откъде да започнете. Вярвам, че първо трябва да очертаете граници, така че да имате повече или по-малко уверена представа какво точно ще проектирате, а след това да запретнете ръкави и да работите в тези граници. Като отправна точка можете да вземете продукт или услуга (в идеалния случай такъв, който наистина харесвате) и да разберете как да го приложите. Може да се изненадате колко прост изглежда този продукт и колко сложност всъщност съдържа. Не забравяй: , и това е добре.
Мисля, че най-добрият съвет, който мога да дам на всеки, който започва да проектира система, е следният: не правете никакви предположения! От самото начало трябва да посочите известните факти за тази система и очакванията, свързани с нея. Ето няколко добри въпроса, които да зададете, за да ви помогнем да започнете с вашия дизайн:
- Какъв е проблемът, който се опитваме да разрешим?
- Какъв е пиковият брой потребители, които ще взаимодействат с нашата система?
- Какви модели на писане и четене на данни ще използваме?
- Какви са очакваните случаи на провал, как ще се справим с тях?
- Какви са очакванията за последователност и достъпност на системата?
- Трябва ли да вземете предвид някакви изисквания, свързани с външна проверка и регулиране, когато работите?
- Какви типове чувствителни данни ще съхраняваме?
Това са само няколко въпроса, които бяха полезни както на мен, така и на екипите, в които съм участвал през годините на професионална дейност. Ако знаете отговорите на тези въпроси (и всички други, които са от значение за контекста, в който трябва да работите), тогава можете постепенно да се задълбочите в техническите подробности на проблема.
Задайте първоначалното ниво
Какво имам предвид под „базова линия“ тук? Всъщност в наше време повечето проблеми в софтуерната индустрия „могат“ да бъдат решени с помощта на съществуващите методи и технологии. Съответно, като се ориентирате в този пейзаж, получавате известна преднина, когато се сблъскате с проблеми, които някой друг е трябвало да реши преди вас. Не забравяйте, че програмите са написани за решаване на бизнес и потребителски проблеми, така че ние се стремим да разрешим проблема по най-ясния и прост (от гледна точка на потребителя) начин. Защо е важно да запомните това? Може би във вашата координатна система обичате да търсите уникални решения за всички проблеми, защото си мислите „какъв програмист съм, ако следвам модели навсякъде“? Всъщност, изкуството тук е да вземаш решения къде и какво да правиш. Разбира се, всеки от нас от време на време трябва да се справя с уникални проблеми, всеки от които е истинско предизвикателство. Но ако първоначалното ни ниво е ясно дефинирано, тогава знаем за какво да изразходваме енергията си: да търсим готови варианти за решаване на поставения пред нас проблем или да го изучаваме по-нататък и да придобием по-дълбоко разбиране.
Мисля, че успях да ви убедя, че ако един специалист уверено разбира какъв е архитектурният компонент на някои прекрасни софтуерни системи, тогава това знание ще бъде незаменимо за овладяване на изкуството на архитект и за разработване на солидна основа в тази област.
Добре, откъде да започна? U В GitHub има хранилище, наречено , от който можете да научите как да проектирате мащабни системи, както и да се подготвите за интервюта по тази тема. В хранилището има раздел с примери , където по-специално се разглежда как те подхождат към дизайна на своите системи например Twitter, Uber и др.
Въпреки това, преди да преминем към този материал, нека разгледаме по-подробно най-важните архитектурни предизвикателства, с които се сблъскваме на практика. Това е важно, защото трябва да посочите МНОГО аспекти на упорит и многостранен проблем и след това да го разрешите в рамките на действащите разпоредби в дадена система. , бивш служител на Facebook, пише , където сподели собствен опит от проверка на стотици кандидати. Докато видеото се фокусира силно върху проектирането на голяма система и критериите за успех, които са важни при търсенето на кандидат за такава позиция, то все пак ще служи като изчерпателен ресурс за това кои неща са най-важни при проектирането на системи. Аз също предлагам това видео.
Изградете знания за съхраняване и извличане на данни
Обикновено вашето решение за това как съхранявате и извличате данните си в дългосрочен план има критично въздействие върху производителността на системата. Следователно, първо трябва да разберете очакваните характеристики за запис и четене на вашата система. След това трябва да можете да оцените тези показатели и да направите избор въз основа на направените оценки. Можете обаче да се справите ефективно с тази работа само ако разбирате съществуващите модели за съхранение на данни. По принцип това предполага солидни познания, свързани с .
Базите данни могат да се разглеждат като структури от данни, които са изключително мащабируеми и издръжливи. Следователно познаването на структурите от данни трябва да ви бъде много полезно при избора на конкретна база данни. Например, е сървър за структура на данни, който поддържа различни типове стойности. Позволява ви да работите със структури от данни като списъци и набори и да четете данни с помощта на добре познати алгоритми, например , организирайки такава работа в траен и изключително достъпен стил.
Моментална снимка от Unsplash
След като имате достатъчно разбиране за различните модели за съхранение на данни, преминете към изучаване на последователността и наличността на данните. На първо място, трябва да разберете поне в общи линии и след това да изгладите това знание, като разгледате по-отблизо установените модели и . По този начин ще развиете разбиране за областта и ще разберете, че четенето и записването на данни всъщност са два много различни проблема, всеки със своите уникални предизвикателства. Въоръжени с няколко модела за последователност и наличност, можете значително да увеличите производителността на системата, като същевременно гарантирате плавен поток от данни към вашите приложения.
И накрая, завършвайки разговора за проблемите със съхранението на данни, трябва да споменем и кеширането. Трябва ли да работи едновременно на клиента и сървъра? Какви данни ще има в кеша ви? И защо? Как организирате анулирането на кеша? Дали ще се прави редовно, на определени интервали? Ако да, колко често? Препоръчвам да започнете да изучавате тези теми с гореспоменатия грунд за проектиране на системата.
Комуникационни модели
Системите се състоят от различни компоненти; това може да са различни процеси, изпълнявани в рамките на един и същ физически възел, или различни машини, работещи в различни части на вашата мрежа. Някои от тези ресурси във вашата мрежа може да са частни, но други трябва да са публични и отворени за потребители, които имат достъп до тях отвън.
Необходимо е да се осигури комуникация на тези ресурси един с друг, както и обмен на информация между цялата система и външния свят. В контекста на системния дизайн тук отново сме изправени пред набор от нови и уникални предизвикателства. Нека да видим как могат да бъдат полезни , и какво p.
Моментална снимка от Unsplash
Когато организирате комуникацията с външния свят, тя винаги е много важна , чието предоставяне също трябва да се приеме сериозно и да се работи активно.
Разпределение на връзката
Не съм сигурен, че поставянето на тази тема в отделен раздел ще изглежда оправдано за всички. Въпреки това ще представя тази концепция подробно тук и смятам, че материалът в този раздел е най-точно описан с термина „разпределение на връзката“.
Системите се формират чрез правилно свързване на много компоненти и тяхната комуникация помежду си често се организира въз основа на установени протоколи, например TCP и UDP. Въпреки това, тези протоколи като такива често са недостатъчни, за да отговорят на всички нужди на съвременните системи, които често работят под голямо натоварване и също така са силно зависими от нуждите на потребителите. Често е необходимо да се намерят начини за разпределяне на връзките, за да се справят с толкова големи натоварвания на системата.
Това разпределение се основава на добре познатите (DNS). Такава система позволява трансформации на имена на домейни, като претеглени кръгови и базирани на латентност методи, за да се разпредели натоварването.
е фундаментално важен и почти всяка голяма интернет система, с която имаме работа днес, се намира зад един или повече балансиращи устройства. Балансиращите натоварване помагат за разпределянето на клиентските заявки в множество налични инстанции. Балансиращите натоварване се предлагат както в хардуер, така и в софтуер, но на практика по-често трябва да се справяте със софтуерни, например и . концептуално също много подобни на load balancers, въпреки че има диапазон между първия и втория . Тези разлики трябва да се вземат предвид при проектирането на система, базирана на вашите нужди.
Трябва също да знаете за (CDN). CDN е глобална разпределена мрежа от прокси сървъри, която доставя информация от възли, които са географски разположени по-близо до конкретен потребител. CDN е за предпочитане да използвате, ако работите със статични файлове, написани на JavaScript, CSS и HTML. Освен това облачните услуги, които предоставят мениджъри на трафик, са често срещани днес, напр. , което ви дава глобално разпространение и намалено забавяне при работа с динамично съдържание. Такива услуги обаче обикновено са полезни в случаите, когато трябва да работите с уеб услуги без състояние.
Нека поговорим за бизнес логиката. Структуриране на бизнес логика, потоци от задачи и компоненти
И така, успяхме да обсъдим различни инфраструктурни аспекти на системата. Най-вероятно потребителят дори не мисли за всички тези елементи на вашата система и, честно казано, изобщо не се интересува от тях. Потребителят се интересува какво е да взаимодействаш с вашата система, какво може да се постигне по този начин, както и как системата изпълнява потребителски команди, какво и как прави с потребителските данни.
Както подсказва заглавието на тази статия, щях да говоря за софтуерна архитектура и системен дизайн. Съответно, не планирах да обхващам шаблони за проектиране на софтуер, които описват как се създават софтуерните компоненти. Въпреки това, колкото повече мисля за това, толкова повече ми се струва, че границата между моделите на софтуерен дизайн и архитектурните модели е много размита и двете понятия са тясно свързани. Да вземем за пример (събитие източник). След като приемете този архитектурен модел, той ще засегне почти всеки аспект на вашата система: дългосрочно съхранение на данни, нивото на съгласуваност, прието във вашата система, формата на компонентите в нея и т.н., и т.н. Затова реших да спомена някои архитектурни модели, които са пряко свързани с бизнес логиката. Въпреки че тази статия ще трябва да се ограничи до прост списък, насърчавам ви да се запознаете с нея и да помислите върху идеите, свързани с тези модели. Заповядайте:
- понятие , в частност, ,
Подходи за сътрудничество
Изключително малко вероятно е да се окажете в даден проект като участник, който е единствено отговорен за процеса на проектиране на системата. Напротив, най-вероятно ще трябва да общувате с колеги, работещи както в рамките на вашата задача, така и извън нея. В този случай може да се наложи да оцените избраните технологични решения с колеги, да идентифицирате бизнес нуждите и да разберете как най-добре да паралелизирате задачите.
Моментална снимка от Unsplash
Първата стъпка е да развиете точно и споделено разбиране за това каква е бизнес целта, която се опитвате да постигнете, и с какви движещи се части ще трябва да се справите. По-специално техники за групово моделиране (event storming) помагат значително да ускорят този процес и да увеличат шансовете ви за успех. Тази работа може да се извърши преди или след очертаването , и след това го задълбочете, докато продуктът узрее. Въз основа на нивото на последователност, което ще бъде постигнато тук, можете също да формулирате за ограничения контекст, в който работите. Когато трябва да говорите за архитектурата на вашата система, може да го намерите за полезно , предложено , особено когато трябва да разберете колко ще трябва да навлизате в детайлите на проблема, визуализирайки нещата, които искате да комуникирате.
Вероятно има друга зряла технология по тази тема, която е не по-малко полезна от Domain Driven Design. Въпреки това някак се връщаме към разбирането на предметната област, така че знанията и опита в областта трябва да ви е полезно.
Източник: www.habr.com