Градивни елементи на разпределени приложения. Нулево приближение

Светът не стои на едно място. Прогресът създава нови технологични предизвикателства. В съответствие с променящите се изисквания, архитектурата на информационните системи трябва да се развива. Днес ще говорим за управлявана от събития архитектура, едновременност, паралелност, асинхронност и как можете да живеете спокойно с всичко това в Erlang.

въведение

В зависимост от размера на проектираната система и изискванията към нея, ние, разработчиците, избираме метода за обмен на информация в системата. В повечето случаи, за да се организира взаимодействието на услугите, работеща опция може да бъде схема с брокер, например, базирана на RabbitMQ или kafka. Но понякога потокът от събития, SLA и нивото на контрол върху системата са такива, че готовите съобщения не са подходящи за нас. Разбира се, можете да усложните малко системата, като поемете отговорността за транспортния слой и формирането на клъстери, например като използвате ZeroMQ или nanomsg. Но ако системата има достатъчно пропускателна способност и възможности на стандартен Erlang клъстер, тогава въпросът за въвеждането на допълнителен обект изисква подробно проучване и икономическа обосновка.

Темата за реактивните разпределени приложения е доста широка. За да се спази форматът на статията, предмет на днешната дискусия ще бъдат само хомогенни среди, изградени върху Erlang/Elixir. Екосистемата Erlang/OTP ви позволява да внедрите реактивна архитектура с най-малко усилия. Но във всеки случай ще ни трябва слой за съобщения.

Теоретична основа

Дизайнът започва с определяне на целите и ограниченията. Основната цел не е в областта на развитието в името на развитието. Трябва да получим сигурен и мащабируем инструмент, на базата на който можем да създаваме и, най-важното, да развиваме модерни приложения от различни нива: като се започне от едносървърни приложения, обслужващи малка аудитория, които по-късно могат да се развият в клъстери до 50 -60 възли, завършващи с клъстерни федерации. По този начин основната цел е да се максимизират печалбите чрез намаляване на разходите за разработка и собственост на крайната система.

Нека подчертаем 4 основни изисквания за крайната система:

• Ссъбитийно ориентиран.
  Системата винаги е готова да премине през потока от събития и да извърши необходимите действия;
• Ммащабируемост.
  Индивидуалните блокове могат да бъдат мащабирани както вертикално, така и хоризонтално. Цялата система трябва да е в състояние на безкраен хоризонтален растеж;
• Оотказоустойчивост.
  Всички нива и всички услуги трябва да могат автоматично да се възстановяват от повреди;
• Ггарантирано време за реакция.
  Времето е ценно и потребителите не трябва да чакат твърде дълго.

Помните ли старата приказка за „Малкият двигател, който можеше“? За да може проектираната система успешно да излезе от етапа на прототипа и да бъде прогресивна, нейната основа трябва да отговаря на минималните изисквания СМОГ.

Още една точка се добавя към съобщенията като инфраструктурен инструмент и основа за всички услуги: лекота на използване за програмисти.

Събитийно ориентиран

За да може едно приложение да се развие от единичен сървър до клъстер, неговата архитектура трябва да поддържа слабо свързване. Асинхронният модел отговаря на това изискване. При него подателят и получателят се грижат за информационното натоварване на съобщението и не се притесняват за предаването и маршрутизирането в рамките на системата.

Мащабируемост

Мащабируемостта и ефективността на системата са една до друга. Компонентите на приложението трябва да могат да използват всички налични ресурси. Колкото по-ефективно можем да използваме капацитета и колкото по-оптимални са нашите методи за обработка, толкова по-малко пари харчим за оборудване.

В рамките на една машина Erlang създава силно конкурентна среда. Балансът между едновременност и паралелизъм може да се настрои чрез избиране на броя на нишките на операционната система, достъпни за Erlang VM, и броя на планировчиците, които използват тези нишки.
Erlang процесите не споделят състояние и работят в неблокиращ режим. Това осигурява относително ниска латентност и по-висока производителност в сравнение с традиционните базирани на блокиране приложения. Планировчикът на Erlang гарантира справедливо разпределение на CPU и IO, а липсата на блокиране позволява на приложението да реагира дори по време на пикови натоварвания или повреди.

На клъстерно ниво проблемът с изхвърлянето също съществува. Важно е всички машини в клъстера да са равномерно натоварени и мрежата да не е претоварена. Нека си представим ситуация: потребителският трафик се приземява на входящи балансьори (haproxy, nginx и т.н.), те разпределят заявките за обработка възможно най-равномерно между набора от налични бекендове. В рамките на инфраструктурата на приложението услугата, внедряваща необходимия интерфейс, е само последната миля и ще трябва да поиска редица други услуги, за да отговори на първоначалната заявка. Вътрешните заявки също изискват маршрутизиране и балансиране.
За да управлява ефективно потоците от данни, съобщенията трябва да предоставят на разработчиците интерфейс за управление на маршрутизирането и балансирането на натоварването. Благодарение на това разработчиците ще могат, използвайки модели на микросервизи (агрегатор, прокси, верига, клон и т.н.), да решават както стандартни проблеми, така и такива, които рядко възникват.

От гледна точка на бизнеса мащабируемостта е един от инструментите за управление на риска. Основното нещо е да се задоволят исканията на клиентите чрез оптимално използване на оборудването:

• Когато мощността на оборудването се увеличава в резултат на прогреса. Няма да бездейства поради несъвършен софтуер. Erlang мащабира вертикално добре и винаги ще може да използва всички CPU ядра и налична памет;
• В облачни среди можем да управляваме количеството оборудване в зависимост от текущото или прогнозираното натоварване и да гарантираме SLA.

отказоустойчивост

Нека разгледаме две аксиоми: „Провалите са неприемливи“ и „Винаги ще има провали“. За един бизнес софтуерният срив означава загуба на пари и, което е по-лошо, загуба на репутация. Балансирайки между възможните загуби и разходите за разработване на устойчив на грешки софтуер, често може да се намери компромис.

В краткосрочен план, архитектура, която включва толерантност към грешки, спестява пари за закупуване на готови решения за клъстериране. Скъпи са и имат и бъгове.
В дългосрочен план една устойчива на грешки архитектура се изплаща многократно на всички етапи на разработка.
Съобщенията в кодовата база ви позволяват да разработите подробно взаимодействието на компонентите в системата на етапа на разработка. Това опростява задачата за реагиране и управление на повреди, тъй като всички критични компоненти се справят с повреди и получената система знае как автоматично да се върне към нормалното след повреда по проект.

Отзивчивост

Независимо от грешките, приложението трябва да отговаря на заявки и да отговаря на SLA. Реалността е, че хората не искат да чакат, така че фирмите трябва да се адаптират съответно. Все повече и повече приложения се очаква да бъдат много отзивчиви.
Отзивчивите приложения работят почти в реално време. Erlang VM работи в мек режим на реално време. За някои области, като борсова търговия, медицина и контрол на промишленото оборудване, твърдият режим в реално време е важен.
Отзивчивите системи подобряват UX и са от полза за бизнеса.

Предварително резюме

Когато планирах тази статия, исках да споделя опита си от създаването на брокер за съобщения и изграждането на сложни системи въз основа на него. Но теоретичната и мотивационната част се оказа доста обширна.
Във втората част на статията ще говоря за нюансите на внедряването на обменни точки, моделите за съобщения и тяхното приложение.
В третата част ще разгледаме общи въпроси за организиране на услуги, маршрутизиране и балансиране. Нека поговорим за практическата страна на мащабируемостта и устойчивостта на грешки на системите.

Край на първата част.

Фото @lucabravo.

Източник: www.habr.com