Короткий вступ до проксі-сервісів Azure

У цій статті ми обговоримо проксі-сервери функцій Azure. Вони забезпечують функцію "Зворотний проксі-сервер" для функцій Azure. Проксі-сервери функцій Azure досить схожі на управління API Azure.  

Ця публікація в значній мірі натхненна Метью Хендерсоном з команди функцій Microsoft Azure. У своєму дописі в блозі, загальнодоступний попередній перегляд Azure Functions Proxies, Метью пояснює причину, чому Microsoft висунула ідеологію для Azure Function Proxies.

Що таке проксі-функції Azure?

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

Ви шукаєте готовий інструмент для управління та моніторингу своїх функцій Azure? Спробуйте цей тут безкоштовно.

Причина впровадження проксі-серверів функцій Azure

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

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

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

Пояснення

Проксі-сервери функцій Azure

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

Спочатку ми створюємо функціональний додаток, вибравши параметр функції на порталі Azure. Тут, скажімо, ми створюємо тригер HTTP для C #, де функцією тригера HTTP є виклик функції із запитом HTTP.

Тепер ми створюємо дві функції: одна - це PostTag, яка представляє нашу публікацію, якщо ми хочемо створити тег. Код функції PostTag такий:

Опублікувати тег

Потім ми створюємо ще одну функцію під назвою GetTag із кодом, зазначеним наступним чином:

Отримати тег

Ми використовуємо GetTag, щоб витягнути повідомлення з черги, і останнє значення тегу повертається клієнту.

Ми можемо вибрати посилання, вказане нижче, щоб отримати URL-адресу обох функцій. Це посилання надасть нам маркер безпеки для авторизації.

Отримати URL-адресу функції

На цьому етапі ми переходимо до налаштувань програми Function і вмикаємо функціональні проксі Azure, які мають останню версію середовища виконання проксі-сервера 0.2. Отже, ми вибираємо опцію «Новий проксі» у програмі Function App Development, що дозволяє нам створити два проксі. Це проксі GetTag та проксі PostTag. Доступні параметри в проксі:

  • URL-адреса проксі-сервера
  • Шаблон маршруту
  • Домашня URL-адреса

URL-адреса, вказана в URL-адресі проксі-сервера та шаблоні маршруту, однакова щодо події GetTag та PostTag. Вихідна URL-адреса проксі GetTag буде пов’язана з подією GetTag, але для проксі PostTag вона буде пов’язана з подією PostTag.

Підсумовування

Проксі-сервери функцій Azure - це чудовий спосіб знущатись і тестувати кінцеву точку функцій Azure ще до того, як почнеться фактична внутрішня розробка. Крім того, їх навіть можна використовувати у виробництві, коли потрібно перенаправити один URI на інший.

Я хотів би зробити висновок, що проксі-сервери функцій Azure є одними з найбільш цікавих та переходять до ринкових функцій, які надала команда Azure Functions.

Цей блог був спочатку опублікований у Serverless360.