Consul.io Частина 1

При розробці додатків необхідно приділяти особливу увагу архітектурі. Якщо цього не зробити, проблеми масштабування можуть з'явитися раптово (а іноді можуть не мати розв'язку). Масштабування програми та ефективне використання ресурсів на початковому етапі — це зекономлені місяці роботи в подальшому.
Для запобігання подібних проблем часто використовують розподілену архітектуру, тобто архітектуру з можливістю горизонтального масштабування всіх компонентів. Але на жаль, при реалізації SOA виникають нові проблеми, а саме: зв'язність і складність конфігурації сервісів.



У даній статті ми розповімо про один з discovery-сервісів під назвою Consul, за допомогою якого можна вирішити вищевикладені проблеми і зробити архітектуру більш прозорою і зрозумілою.

Розподілені архітектури(SOA) і проблеми їх побудови

Проектуючи додаток як набір слабо пов'язаних компонентів, ми отримуємо можливість масштабування будь-якого компонента.
SOA (Service Oriented Architecture — це архітектурний патерн, що описує архітектуру програми у вигляді автономних компонентів зі слабкою зв'язаністю, що спілкуються між собою за стандартними протоколами (наприклад REST). Логічним продовженням (або підмножиною) SOA є микросервисная архітектура. Вона базується на збільшенні кількості сервісів замість збільшення функціональності конкретного сервісу (відображення принципу Single Responsibility в архітектурі) і глибокої інтеграції з continuous-процесами.
Якщо займатися реалізацією микросервисной архітектури, то, безсумнівно, відповідальність за взаємодію наших сервісів переходить в бік інфраструктурного рішення нашої програми. Сервіси, які відповідають принципу Single Responsibility, вміють тільки брати запит і повертати відповідь. При цьому потрібно балансувати трафік між вузлами системи, потрібно зв'язати, нехай і слабо, але все одно залежні один від одного сервіси між собою. І звичайно ж нам потрібно реагувати на зміни конфігурації системи:
  • Сервіси постійно додаються.
  • Деякі сервіси перестають реагувати на healthcheck.
  • Нові компоненти з'являються в системі і потрібно максимально ефективно поширити інформацію про них.
  • Оновлюються версії окремих компонентів — ламається зворотна сумісність.
У будь-якій системі це безперервний і складний процес, але за допомогою сервісу discovery ми зможемо його контролювати і зробити його прозорішим.

Що таке discovery?

Discovery — це інструмент (або набір інструментів) для забезпечення зв'язку між компонентами архітектури. Використовуючи discovery ми забезпечуємо зв'язність між компонентами програми, але не зв'язаність. Discovery можна розглядати як якийсь реєстр метаінформації про розподіленої архітектурі, в якому зберігаються всі дані про компоненти. Це дозволяє реалізувати взаємодію компонентів з мінімальним ручним втручанням (тобто у відповідності з принципом ZeroConf).

Роль discovery в процесі побудови розподіленої архітектури

Discovery-сервіс забезпечує три основні функції, на яких базується зв'язність в рамках розподіленої архітектури:
  • Консистентним метаінформації про сервіси в рамках кластера.
  • Механізм для реєстрації і моніторингу доступності компонентів.
  • Механізм для виявлення компонентів.
Розкриємо значення кожного пункту докладно:

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

Реєстрація та моніторинг
Знову додаються сервіси повинні повідомити про себе, а вже запущені зобов'язані проходити постійну перевірку на доступність. Це є необхідною умовою для автоматичної конфігурації кластера. Балансеры трафіку і залежні ноди обов'язково повинні мати інформацію про поточної конфігурації кластера для ефективного використання ресурсів.

Пошук
Під прибутком мається на увазі механізм пошуку сервісів, наприклад, за ролями які вони виконують. Ми можемо запросити розташування для всіх сервісів певної ролі, не знаючи їх точної кількості і конкретних адрес, а знаючи лише адресу discovery-сервісу.

Consul.io як реалізація discovery

У даній статті розглядається реалізація discovery на базі Consul.
Consul — це децентралізований відмовостійкий discovery-сервіс від компанії HashiCorp (яка розробляє такі продукти як Vagrant, TerraForm, Otto, Atlas та інші).

Consul є децентралізованим сервісом, тобто Consul agent встановлюється на кожен хост і є повноправним учасником кластера. Таким чином, сервісів не потрібно знати адресу discovery в нашій мережі, всі запити до discovery виконуються на локальний адресу 127.0.0.1.

Що ще необхідно знати про Consul:
Для поширення інформації використовує алгоритми, які базуються на моделі eventual consistency.
Агенти для поширення інформації використовують протокол gossip.
Сервери для вибору лідера використовують алгоритм Raft.
Лідер — це сервер, який приймає всі запити на зміну інформації. Якщо провести аналогію з БД, то це master в контексті master/slave — реплікації. Всі інші сервери реплікують дані з лідера. Ключова відмінність від БД-реплікації в тому, що в разі виходу з ладу лідера всі інші сервери запускають механізм виборів нового лідера і після виборів автоматично починають правильно з нього. Механізм перемикання повністю автоматичний і не вимагає втручання адміністратора.
Кожен інстанси може працювати в двох режимах: агент і сервер. Різниця в тому, що агент є точкою поширення інформації, а сервер — точкою реєстрації. Тобто агенти приймають запити на читання, а сервер може виконувати зміни вже наявної інформації (реєстрація та видалення сервісів). Фактично ми, в будь-якому випадку, виконуємо запит до локальної адреси, різниця лише в тому, що запит на читання буде оброблений агентом на локальному хості, а запит на зміну даних буде переадресовано лідеру, який збереже і поширить дані по всьому кластеру. Якщо наш локальний агент не є лідером в даний момент, то наш запит буде повністю оброблений локально і поширений по кластеру.

Використання Consul в кластері

Consul кластер являє собою мережу пов'язаних вузлів, на яких запущені сервіси, зареєстровані в discovery. Consul гарантує, що інформація про кластер буде поширена по всіх учасників кластера та доступна за запитом. Також реалізована підтримка не тільки одноранговій мережі, але і многорангового, розділеного по зонах, кластери, які в термінології Consul називаються датацентрами. За допомогою Consul можна працювати як з конкретним датацентром, так і виконувати дії над будь-яким іншим. Датацентри не ізольовані один від одного в рамках discovery. Агент в одному ДЦ може отримати інформацію з іншого ДЦ, що може допомогти в побудові ефективного рішення для розподіленої системи.



Агенти Consul, запущені в режимі server, крім своєї основної ролі, отримують ще й роль потенційного лідера кластера. Рекомендується використовувати в кластері не менше трьох агентів в режимі server для забезпечення відмовостійкості. Використання режиму server не накладає ніяких обмежень на основну функціональність агента.
При введенні нового вузла в кластер, нам необхідно знати адреса будь-якого вузла у кластері. Виконавши команду:
consul join node_ip_address

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

Типи вузлів: internal, external

У Consul ми можемо зареєструвати наш сервіс двома способами:
  • HTTP API або конфігураційний файл агента, але тільки в тому випадку, якщо ваш сервіс може спілкуватися з Consul самостійно.
  • Зареєструвати сервіс як 3d-party компонент, в разі якщо сервіс не може спілкуватися з Consul.
Розглянемо обидва випадки трохи докладніше.
За допомогою HTTP API, що надається Consul, є можливість зробити коректну реєстрацію компонента і видалення сервісу в discovery. Крім цих двох станів, можна використовувати стан
maintenance
. У цьому режимі сервіс позначається як недоступний і перестає відображатися в DNS і API-запитах.

Розглянемо приклад запиту реєстрації компонента (JSON повинен бути переданий в PUT-запиті):
http://localhost:8500/v1/agent/service/register

{
"ID": "redis1",
"Name": "redis",
"Tags": [
"master",
"v1"
],
"Address": "127.0.0.1",
"Порту": 8000,
"Check": {
"Script": "/usr/local/bin/check_redis.py",
"HTTP": "http://localhost:5000/health",
"Interval": "10s",
"TTL": "15s"
}
}

Приклад запиту на видалення компонента з каталогу:
http://localhost:8500/v1/agent/service/deregister/[ServiceID]
 

Приклад запиту на переказ сервісу в режим maintenance:
http://localhost:8500/v1/agent/service/maintenanse/[ServiceID]?enable=true|false
 

За допомогою прапора enable ми можемо змінювати стан і додати необов'язковий параметр reason, який містить текстовий опис причини переведення компонента в режим обслуговування.

Якщо нам необхідно зареєструвати який-небудь зовнішній сервіс і у нас немає можливості «навчити» його реєструватися Consul самостійно, то ми можемо зареєструвати його не як сервіс-провайдер, а саме як зовнішній сервіс (external service). Після реєстрації ми зможемо отримати дані про зовнішнє сервісі через DNS:
$ curl -X PUT -d '{"Datacenter": "dc1", "Node": "google",
"Address": "www.google.com",
"Service": {"Service": "search", "Порту": 80}}'
http://127.0.0.1:8500/v1/catalog/register

Крім HTTP API ви можете використовувати конфігураційні файли агента з описом сервісів.

У другій частині ми завершимо розповідь про сервіс Consul, а саме розповімо про його наступних функціях:
  • Інтерфейс DNS.
  • HTTP API.
  • Health Checks.
  • K/V storage.
І звичайно ж підведемо підсумки роботи з Consul.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.