През последните няколко десетилетия една от най-важните цели в програмирането за системи може би е отделянето на зависимостите.

Следователно има интерфейси, абстракции, библиотеки и т.н. и т.н.

И открихме, че поканата на опашката от съобщения в система е истинската сделка за разбиване на компонентите и зависимостите.

Какво представлява опашката за съобщения?

Не давам урок за толкова страхотна технология, тъй като не сме истински експерти в тази област, нито тази статия всъщност за това.

Парадигмата на опашката на съобщенията е брат или сестра на модела „издател/абонат“ …… Те използват „опашка“ за „съобщения“ — предаване на контрол или на съдържание. — https://en.wikipedia.org/wiki/Message_queue

С по-прости думи, позволяваме на 2 отделни, изолирани компонента да комуникират чрез някои съобщения, чрез опашка. Всеки от които не би могъл да знае нищо за другия, например компонент А ще се опита да изпрати регистрационно съобщение в опашката със съобщения, докато компонент А няма представа как се обработва регистрационният файл или дори дали някой компонент Б служи за неговия дневник. Обратно на компонент B.

Компонент B ще наблюдава на опашка, точно както всички ние чакаме за някои задачи, и ще обработва задачата по съответния начин, без никаква представа за възложителя. Повече късмет от мен, компонент Б можеше да избере да изостави полученото и да се откаже от задачата по решение.

Любимият ми пример

Когато за първи път представих опашката за съобщения на нашия екип, използвах една от системите на нашите клиенти, която е толкова наследена, голяма и лоша, проектирана да приема всякакви промени или надстройки.

В моята демонстрация първо замених логиката за изпращане на разписка по имейл (дяволски много код!) с изпращане на прост сигнал до опашката със съобщения и казах: „да, внедряването е готово за работа“. Спомням си всички лица в стаята.

Разбира се, внедряването не е наистина готово, обясних допълнително как съобщението се „съхранява“ в опашката, всяко приложение, което слуша тази опашка, може да помогне за изпращане на имейл разписката (или друг електронен път).

Едно от готините неща е, че след като съобщението продължава да стои в тази опашка, нямаме нужда от никакво приложение, за да обслужим това съобщение веднага. Лесното мащабиране нагоре/надолу ще бъде другото готино нещо, можем да решим колко екземпляра на услугата ни трябват, за да обслужваме 1 опашка според натоварванията.

Нашият нов поток за внедряване

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

НЕЕЕЕ!!! Моят дизайн беше ПЕРФЕКТЕН!!! — Архитектът Coding Cat

Разрешихме зависимостите по дяволите и избегнахме да направим системата твърде стабилна, за да приема промени, просто като въведохме опашката.

Накратко, сега разработваме компонентите като някои уеб базирани услуги. Първо дефинираме какво е входът и изходът за „крайната точка“, преглеждаме дали има някакъв шанс да я направим генерична услуга (ляв бутон е :P) (а… не наистина), след което присвояваме всеки разработчик към нея.

Изчакайте... Как това е различно от подхода на сглобяване?

На първо място, когато си играете в .NET, всички зависимости от вашите сборки също ще бъдат включени във вашия проект (всеки, който трябва да разреши обвързването на версията на пакетите NuGet, ще знае). Но това няма да се случи с опашката със съобщения, когато компонент А дори не знае дали има компонент Б, както беше споменато.

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

Освен това понякога зависимостите на сборките са в конфликт, веднъж се сблъскахме с голямо главоболие, че 2 различни сборки зависят от една и съща библиотека, но 2 конфликтни версии. Разделянето на операциите в 2 приложения разреши този проблем като шампион, познайте как биха могли да комуникират помежду си? — Опашката от съобщения.

Обобщаване

Не казвам, че опашката със съобщения (или SoA) ще реши всички проблеми с програмирането/системата, вярвам, че няма сребърен куршум в света. Това, което се опитвам да изразя, е въвеждането на опашката от съобщения в нашите системи наистина помогна за определяне на границите на компонентите и позволява по-лесно разделяне на загрижеността на компонентите.

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

Ние сме нови в Medium и бихме искали да споделим някои мисли със света. Ще бъде страхотно, ако можете също да покажете подкрепата си, като оставите коментар или ни ръкопляскате :)