Використання проекту Microsoft YARP для проксі-сервера веб-мікросервісів

Але що відбувається зі зрілим проектом із внутрішнього джерела, який може бути корисним за межами організації, яка його створила? Деякі залишаються за закритими дверима, інші занурюються у відкрите джерело. Такий випадок із YARP від ​​Microsoft, проектом, який розпочався з метою консолідації кількох проектів зворотного проксі в компанії. Його назва є акронімом від Yet Another Reverse Proxy, оскільки багато команд уже створювали та використовували різні проксі або шукали API та бібліотеки, які могли б їх використовувати.

Він на шляху до того, щоб стати важливою частиною мережевого стека .NET, застосовуючи API клієнта і сервера, забезпечуючи проксі, який може працювати з протоколами наступного покоління, такими як HTTP / 2 (і в майбутньому QUIC).

Використовуйте зворотні проксі

Зворотні проксі є важливим мережевим інструментом і інструментом безпеки, який забезпечує ізоляцію між вашою інфраструктурою веб-додатків або API та загальнодоступним Інтернетом. Він пересилає запити на кінцеві точки, не розкриваючи деталей мережі за проксі-сервером, гарантуючи відсутність прямого зв’язку між внутрішньою та зовнішньою мережами. Він відрізняється від традиційного проксі-сервера тим, що зворотний проксі-сервер обробляє з’єднання, ініційовані ззовні вашої мережі.

Ви можете використовувати зворотний проксі для різних цілей залежно від програми, для якої він використовує. У деяких випадках він забезпечує балансування навантаження або кешування, переміщує запити через пул серверів (локальних або глобальних), зберігає та пересилає статичний або незалежний від часу вміст. Потім проксі-сервер може фільтрувати розподілені атаки відмови в обслуговуванні та захищати внутрішню мережу. Нарешті, його можна використовувати як прискорювач, виконуючи інтенсивні обчислювальні задачі, наприклад, розшифровуючи зашифрований трафік перед пересиланням його на внутрішній сервер, тим самим зменшуючи навантаження на сервери додатків.

Оскільки розробникам Microsoft потрібні зворотні проксі для всіх цих сценаріїв, вони створили багато різних інструментів. Об’єднання команд дозволило розгорнути стандартний проксі-сервер, який можна було б налаштувати для керування різними сценаріями, додавши проміжне програмне забезпечення для функціональних можливостей програми та миттєво керуючи звичайними випадками використання зворотного проксі.

Надання відкритого зворотного проксі на основі .NET

Результатом є інструмент .NET, який працює як для .NET, так і для ASP.NET, з метою доставки бібліотек із шаблонами, які допоможуть вам налаштувати інструмент. Ця настройка є ключовою відмінністю та дозволяє вам керувати або за допомогою файлів конфігурації, або шляхом інтеграції з інструментами керування додатками. Якщо вам потрібно внести зміни до проксі-сервера YARP, вам не доведеться створювати його з нуля. API конфігурації дозволяє вносити зміни на льоту.

Наразі доступний у вигляді вихідного коду-кандидата, YARP незабаром має досягти версії 1.0. Остання версія базується на всіх підтримуваних на даний момент випусках .NET Core: 3.1, 5.0 і майбутніх 6.0. Ви можете завантажити архіви вихідного коду зі сторінки версії проекту GitHub або, бажано, клонувати репозиторій локально, а потім використовувати сценарії збірки для автоматичного завантаження .NET SDK та створення інструменту. Microsoft надає інструкції щодо використання Visual Studio 2022 зі сценарієм запуску, який завантажує відповідну версію .NET SDK.

Ймовірно, ви віддаєте перевагу .NET 5 або новішої, оскільки версія .NET Core 3.1 не підтримує певні ключові функції, зокрема обмеження телеметрії, необхідне для повного моніторингу проксі-сервера. Вам все одно потрібен пакет SDK .NET 5 для побудови на .NET Core 3.1, оскільки потрібні деякі функції C #, які не підтримуватимуться до наступних версій. Інші вдосконалення, зроблені з новими версіями .NET, включають кращу підтримку HTTP / 2, яка потрібна для використання з gRPC.

Після створення ви можете використовувати файли конфігурації для керування зворотним проксі YARP. Вони використовують стандартні постачальники конфігурації .NET, і ви можете вибрати свою технологію як частину створення YARP. Такий підхід дозволяє вибирати власні інструменти для розгортання конфігурацій, наприклад, як частину інструменту «Інфраструктура як код». Типовим є JSON з іменованими розділами у файлі конфігурації, які використовуються для визначення маршрутизації та кластерів серверів призначення.

Налаштуйте та використовуйте YARP у своїх програмах

Конфігурація маршруту спрямована на поєднання масивів або шляхів із визначеними кластерами, де кластери є пунктами призначення та адресами, які можуть відповідати на запити певного маршруту. У конфігурацію можна навіть включити політики на основі маршрутів, напр. Наприклад, додавання правил авторизації до маршруту або забезпечення того, що політики між джерелами застосовуються до спільного використання ресурсів. Результатом є відносно простий набір конфігурацій, які дозволяють сучасну маршрутизацію на основі політик.

Ті самі об’єкти конфігурації та колекції, які описані у ваших файлах конфігурації JSON, можна використовувати як структури даних для налаштувань, керованих програмою. Під час роботи можна динамічно перезавантажувати налаштування без перезапуску проксі. Тож якщо ви автоматично масштабуєте програму на сервері Kubernetes або в Azure Service Fabric, ви можете оновлюватись у міру додавання нових кінцевих точок або видалення старих.

Цікавою опцією в YARP є можливість додавати власне проміжне програмне забезпечення до проксі за допомогою підходу конвеєра ASP.NET для додавання нових функцій. Наприклад, у вас можуть бути інструменти, які автоматично відхиляють запити на основі правил і надсилають спеціальну відповідь від проксі-сервера, не передаючи жодних даних у кластер проксі-сервера. Найкраще використовувати проміжне програмне забезпечення лише для заголовків запитів; Змінювати текст запиту чи відповіді – не найкраща ідея.

Існують вбудовані перетворення, які змінюють вимоги та відповіді, наприклад: Наприклад, якщо ви використовуєте проксі-сервер YARP як прискорювач рівня Secure Sockets Layer, змінюючи заголовки та відповіді, щоб додати або видалити шифрування за потреби. Інші параметри додають або видаляють параметри з рядків запиту, щоб ви могли обмежити запити, надіслані через проксі-сервер, і забезпечити доставку на сервери лише обмеженого набору параметрів. Контролюючи запити через проксі, ви можете зменшити поверхню атаки та посилити свою програму. Ви можете зробити те ж саме для значень запиту, щоб уникнути зловмисно помилкових запитів.

За межами веб-проксі

YARP може бути частиною самомоніторингу ваших програм і пропонує можливість регулярно перевіряти стан кінцевих точок. Запити можна надсилати на певні кінцеві точки, а кластери можна позначати як справні або погані залежно від відповідей. Несправні кластери автоматично блокуються, щоб ви могли виконувати технічне обслуговування, поки ваша програма продовжує працювати.

Завдяки підтримці HTTP / 2, gRPC і Service Fabric, YARP є важливим інструментом для тих, хто створює великомасштабні програми ASP.NET і підтримує мікросервіси на основі .NET. Варто витратити час на створення та налаштування власних екземплярів і скористатися перевагами архітектури конвеєра та програмованих конфігурацій.

Спочатку розробивши інструмент для підтримки багатьох різних внутрішніх проектів, Microsoft надала універсальний зворотний проксі, який набагато більше ніж найменший спільний знаменник. Перехід від внутрішнього джерела до відкритого коду не є великим, але він приносить користь усім, а не лише внутрішнім командам Microsoft із продуктів.