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

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

Въведение

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

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

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

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

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

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

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

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

Ориентираност към събития.

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

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

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

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

На ниво клъстери проблемът с използването също съществува. Важно е всички машини в клъстера да бъдат равномерно натоварени и мрежата да не е пренатоварена. Да си представим ситуация: потребителският трафик приземява на входните балансировачи (haproxy, nginx и др.), които максимално равномерно разпределят заявките за обработка между наличните бекенди. В рамките на инфраструктурата на приложението, услугата, реализираща необходимия интерфейс, е само последната миля и трябва да поиска редица други услуги, за да отговори на първоначалната заявка. Вътрешните заявки също изискват маршрутизиране и балансиране.
За да управляваме ефективно потоковете от данни, messaging трябва да предоставя на разработчиците интерфейс за управление на маршрутизацията и разпределението на натоварването. По този начин разработчиците ще могат, използвайки микросервисни шаблони (aggregator, proxy, chain, branch и др.), да решават както стандартни задачи, така и рядко срещани.

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

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

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

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

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

Отзивчивост

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

Предварителен резултат

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

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

Снимка @lucabravo.

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