Какво е Middleware? Дефиниция и примери за използване

Middleware е често използван термин в уеб разработката. Това може да означава много неща в зависимост от контекста, което прави термина малко объркващ.

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

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

Определение за Middleware

Middleware е софтуер, който действа като посредник между две приложения или услуги, за да улесни тяхната комуникация.

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

Често използвани случаи за Middleware

1) Преводач

Има много формати за обмен на данни, като JSON, XML и Protobuf. Въпреки че в днешно време използваме предимно JSON, всеки от тях има свои собствени случаи на употреба.

Например, протобуферите са известни като по-ефективни от JSON, но не са четими от хората. Така че може да използвате протобуфери за вътрешни услуги и може да използвате JSON, когато потребителят на API е браузър.

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

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

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

2) Натрупване-дублиране на данни

Архитектурата на Microservice е популярен архитектурен модел, който често се прилага в съвременните приложения.

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

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

Сега да кажем, че искаме да приложим нашето търсене по начин, който търси както потребители, така и продукти.

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

Този проблем има множество решения и ще разгледаме две от тях.

Натрупване на данни

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

След това можем да натрупаме резултатите от двата сървъра и да ги върнем на клиента. Имайте предвид, че броят на заявките се увеличава линейно, тъй като ние увеличаваме броя на сървърите (и ние също трябва да обединим тези данни).

Дублиране на данни

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

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

Имаме няколко опции: първо, можем да извикаме методите за запазване на сървъра за търсене от методите за запис на потребителския и продуктовия сървъри, за да дублираме данните. Или можем да създадем междинен софтуер за запазване, който ще направи следното:

  • Всеки път, когато пристигне заявка за запазване, обадете се на запазване на продукт / потребителски сървър и на сървър за търсене.
  • Ако първото запазване не успее, не извиквайте запазването на друго (това поддържа базата данни последователни).

Нека разгледаме дизайнерските диаграми без и със среден софтуер. Първо, ето как изглежда без:

Изглежда грозно, нали? Всъщност това е грозно и ще направи вашия код по-сложен и здраво свързан.

Ето същото решение с междинен софтуер:

В този сценарий клиентската страна просто извиква междинния софтуер, за да запази продукт или потребител, а той обработва останалото.

Няма код, свързан с дублиране на данните нито в Продукта или Потребителските сървъри, нито от страна на клиента. Middleware се грижи за тези неща.

3) API сигурност

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

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

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

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

По-рано това не беше възможно, тъй като нашият преден край комуникираше със сървъра за удостоверяване. Тъй като предният край означава компютър на клиента, не можахме да приложим IP филтър.

4) Излагане на публични API

В предишната част научихме, че средата може да се използва за ограничаване на достъпа до нашия API.

Сега нека разгледаме другата страна на уравнението: какво, ако искаме да дадем ограничен достъп до нашия API? Може би сме софтуерен инженер в банка и банката планира хакатон. Ще трябва да осигурим достъп до нашия API, нали?

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

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

Заключение

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

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

Благодаря ви, че четете. Ако статията ви е харесала, каня ви да разгледате моя блог. Можете също така да се абонирате за моя пощенски списък, за да получавате известия, когато публикувам нова публикация :)