Найкраща архітектура з Докером та Кубернетами - міф чи реальність?

Як змінився світ розробки програмного забезпечення в епоху Докера та Кубернета? Чи можливо побудувати архітектуру раз і назавжди, використовуючи ці технології? Чи можливо уніфікувати процеси розвитку та інтеграції, коли все "запаковано" в контейнери? Які вимоги до таких рішень? Які обмеження вони вводять у гру? Чи полегшать вони життя розробникам або замість цього додадуть зайвих ускладнень?

Настав час пролити світло на ці (та деякі інші) питання! (У тексті та оригінальних ілюстраціях.)

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

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

Від реального життя до робочих процесів розвитку

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

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

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

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

Решта 20% явно нікуди не пішли. Але саме там ви можете зосередити свій внутрішній творчий геній на цікавій роботі, а не займатися повторюваними рутинними завданнями. Піклування про «архітектурну основу» лише один раз дозволить вам забути про 80% вирішених проблем.

Що все це означає і як саме Докер вирішує проблеми робочого процесу в галузі розробки? Давайте розглянемо простий процес, який також є достатнім для більшості робочих середовищ:

При належному підході ви можете автоматизувати та уніфікувати все з наступної послідовності та забути про це на наступні місяці.

Створення середовища розвитку

Проект повинен містити файл docker-compose.yml, який може позбавити вас від думки про те, що і як потрібно зробити для запуску програми / послуги на локальній машині. Проста команда складання докерів повинна запустити вашу програму з усіма її залежностями, заповнити базу даних за допомогою світильників, завантажити локальний код всередині контейнера, включити відстеження коду для компіляції на льоту та врешті-решт почати реагувати на очікуваному порті. Навіть налаштовуючи новий сервіс, вам не потрібно хвилюватися про те, як запустити, де вносити зміни або які рамки використовувати. Все це слід заздалегідь описати в стандартних інструкціях та продиктувати шаблони сервісу для різних налаштувань: frontend, backkend та работники.

Автоматизоване тестування

Все, що ви хочете знати про "чорну скриньку" (детальніше про те, чому я називаю контейнер, про це піде далі в тексті), - це все в ньому все в порядку. Так або ні. 1 або 0. Маючи обмежену кількість команд, які можна виконати всередині контейнера, і docker-compose.yml, що описують усі його залежності, ви можете легко автоматизувати та уніфікувати тестування, не зосереджуючись занадто багато на деталях реалізації.

Наприклад, ось так!

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

Система доставки

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

Ось алгоритм, який мені здається досить ефективним у вирішенні цієї проблеми:

  1. Збирайте зображення з усіх своїх Dockerfiles (наприклад, подібних)
  2. Використовуючи мета-проект, доставляйте ці зображення Kubernetes за допомогою API Kube. Ініціювання доставки зазвичай вимагає декількох вхідних параметрів:
  • Кінцева точка API Kube
  • "секретний" об'єкт, який змінюється в різних контекстах (локальний / демонстраційний зал / постановка / виробництво)
  • назви систем для відображення та теги зображень Докера для цих систем (отримані на попередньому кроці)
Як приклад метапроекту, який охоплює всі системи та сервіси (іншими словами, проект, який описує, як організована екосистема та як до неї надходять оновлення), я вважаю за краще використовувати ігрові книжки Ansible з цим модулем для інтеграції з Kube API. Однак, складні автомати можуть звернутися до інших варіантів, і я зупинюсь на своєму власному виборі пізніше. Однак ви повинні думати про централізований / уніфікований спосіб управління архітектурою. Наявність одного дозволить вам зручно та рівномірно керувати всіма службами / системами та нейтралізувати будь-які ускладнення, які майбутні джунглі технологій та систем, що виконують подібні функції, можуть на вас накинути.

Зазвичай установка середовища потрібна в:

  • "ShowRoom" - для деяких ручних перевірок або налагодження системи
  • "Постановка" - для середовищ, що живуть поблизу, та інтеграцій із зовнішніми системами (як правило, розташовані в DMZ на відміну від ShowRoom)
  • «Виробництво» - фактичне середовище для кінцевого споживача

Безперервність в інтеграції та постачанні

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

Мабуть, єдиний вимикач угод тут - послідовність інтеграції та доставки. Якщо випусків немає, як ви запобігаєте «стану гонки» в одній системі з набором паралельних гілок функцій?

Тому цей процес слід починати лише тоді, коли немає змагань, інакше "стан гонки" буде переслідувати ваш розум:

  1. Спробуйте оновити гілку функцій до висхідної частини (git rebase / merge)
  2. Створіть зображення з Dockerfiles
  3. Перевірте всі вбудовані зображення
  4. Запустіть і почекайте, поки будуть доставлені системи із зображеннями з кроку 2
  5. Якщо попередній крок не вдався, поверніть екосистему до попереднього стану
  6. Об’єднайте функцію-гілку в потоці та відправте її у сховище

Будь-який збій на будь-якому кроці повинен припинити процес доставки та повернути розробнику завдання виправити помилку, будь то невдалий тест чи конфлікт злиття.

Ви можете використовувати цей процес для роботи з більш ніж одним сховищем. Просто виконайте кожен крок для всіх сховищ одразу (крок 1 для репостів A і B, крок 2 для репозицій A і B тощо), а не робити весь процес повторно для кожного окремого сховища (кроки 1–6 для repo A , кроки 1–6 для репо B і так далі).

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

Відкатні системи

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

  • Служба повинна мати можливість налаштувати своє оточення, а також зміни відката. Наприклад, міграція баз даних, схема RabbitMQ тощо.
  • Якщо неможливо відкинути середовище, сервіс повинен бути поліморфним і підтримувати як стару, так і нову версії коду. Наприклад: міграція бази даних не повинна порушувати старі версії служби (як правило, 2 або 3 минулі версії)
  • Зворотна сумісність будь-якого оновлення сервісу. Зазвичай це сумісність API, формати повідомлень тощо.
Досить просто перевертати стани в кластері Kubernetes (запустити kubectl rollout скасувати розгортання / деяку розгортання та Kubernetes відновить попередній "знімок"), але для цього, ваш мета-проект повинен містити інформацію про цей знімок. Більш складні алгоритми відкази доставки сильно не рекомендують, хоча вони іноді необхідні.

Ось що може запустити механізм відкату:

  • Високий відсоток помилок програми після випуску
  • Сигнали від ключових точок моніторингу
  • Невдалі випробування на дим
  • Ручний режим - людський фактор

Забезпечення інформаційної безпеки та аудиту

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

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

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

Від робочих процесів розвитку до архітектури

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

Мікросервісна архітектура

Немає необхідності деталізувати переваги сервісно-орієнтованої архітектури - SOA, включаючи, чому послуги повинні бути “мікро”. Я лише скажу, що якщо ви вирішили використовувати Докер та Кубернетес, то, швидше за все, ви зрозумієте (і погоджуєтесь), що мати монолітну архітектуру важко і навіть ідеологічно неправильно. Створений для запуску єдиного процесу та роботи з наполегливістю, Docker змушує нас мислити в рамках DDD (Домен, керований доменом). У Docker упакований код розглядається як чорна скринька з деякими відкритими портами.

Критичні компоненти та рішення екосистеми

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

Якщо ви (як я) прийшли до висновку, що було б чудово керувати кожним із цих компонентів як звичайний сервіс Kubernetes, то я рекомендую вам запустити їх в окремий кластер, окрім «виробництва». Наприклад, кластеризовані «постановочні», тому що це може врятувати ваше життя, коли виробниче середовище нестабільне і вам відчайдушно потрібно джерело його зображення, коду чи інструментів моніторингу. Це вирішує проблему з куркою і яйцями, так би мовити.

Служба посвідчення особи

Як завжди, все починається з доступу - до серверів, віртуальних машин, додатків, офісної пошти тощо. Якщо ви або хочете бути клієнтом однієї з найбільших корпоративних платформ (IBM, Google, Microsoft), проблемою доступу буде займатися одна з служб постачальника. Однак якщо ви хочете мати власне рішення, яким керуєте лише ви та в межах свого бюджету?

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

Автоматизоване надання послуг

Хоча Kubernetes вимагає наявності лише декількох компонентів на фізичних машинах / хмарних віртуальних машинах (кластер docker, kubelet, kube proxy тощо), вам все одно потрібно автоматизувати додавання нових машин та управління кластерами. Ось кілька простих способів зробити це:

  • KOPS - цей інструмент дозволяє встановити кластер на одному з двох хмарних провайдерів - AWS або GCE
  • Teraform - це дозволяє керувати інфраструктурою для будь-якого середовища та слідкувати за ідеологією IAC (Infrastructure as Code)
  • Ansible - універсальний інструмент для автоматизації будь-якого типу
Особисто я віддаю перевагу третьому варіанту (з невеликим модулем інтеграції Kubernetes), оскільки він дозволяє мені працювати як із серверами, так і з об'єктами k8s та здійснювати будь-яку автоматизацію. Однак ніщо не заважає вам скористатися Teraform та його модулем Kubernetes. KOPS не працює добре з «голим металом», але це все ще чудовий інструмент для використання з AWS / GCE!

Репозиторій Git і трекер завдань

Зайве говорити, що для забезпечення повноцінної роботи розробників та інших пов’язаних ролей потрібно мати місце для обговорення роботи в команді та зберігання коду. Мені важко буде визначити, яка послуга найкраща для цього, але мій особистий золотой стандарт для відстеження завдань - Redmine (безкоштовно) або Jira (платний), а для сховища коду - "old school" [gerrit] ( https://www.gerritcodereview.com/) (безкоштовно) або бітбукет (оплачується).

Варто звернути увагу на два найбільш послідовних (хоча комерційні) набори для спільної роботи у корпоративному середовищі: Atlassian та Jetbrains. Ви можете використовувати будь-який з них як окремий розчин, так і комбінувати різні компоненти обох.

Щоб максимально використати комбінацію трекера та сховища, продумайте їхню інтеграційну стратегію. Наприклад, кілька порад щодо забезпечення цілісності коду та пов'язаних із ним завдань (звичайно, ви можете обрати власний підхід):

  • Можливість "проштовхуватися" у віддалений сховище має бути увімкнена лише у тому випадку, якщо гілка, до якої намагається натиснути, має відповідний номер завдання (TASK-1 / особливість-34)
  • Будь-яка гілка повинна бути доступною для злиття лише після певної кількості ітерацій перегляду позитивного коду
  • Будь-яка гілка повинна бути заблокована та вимкнена для майбутніх оновлень, якщо відповідне завдання не є "Незавершеним" чи подібним статусом
  • Будь-які кроки, призначені для автоматизації, не повинні бути безпосередньо доступні розробникам
  • Тільки авторизовані розробники повинні мати можливість безпосередньо змінювати головну гілку - все інше, кероване роботом автоматизації
  • Гілка не повинна бути доступною для об'єднання, якщо відповідне завдання знаходиться в будь-якому статусі, відмінному від "Для доставки" або подібному

Докерський реєстр

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

Ви можете використовувати хмарне рішення (наприклад, hub.docker.com) або приватну службу, яку навіть можна встановити в самому кластері Kubernetes. Vmware Harbor, позиціонований як корпоративне рішення для Docker Registry, є хорошим прикладом останнього. Найгірший випадок, ви навіть можете використовувати старий добрий реєстр Docker, якщо ви просто хочете зберігати зображення і не потребуєте в складній системі.

CI / CD та система надання послуг

Жоден з компонентів, про які ми говорили раніше (git repo, трекер завдань, метапроект з Ansible Playbooks, зовнішні залежності) не може функціонувати один від одного, як ніби вивішений у вакуумі. Що їх пов’язує, - це безперервна інтеграція та служба доставки.

CI - CD безперервної інтеграції - безперервна доставка

Послуга повинна бути досить простою і позбавлена ​​будь-якої логіки, пов'язаної з доставкою або конфігурацією систем. Все, що має зробити служба CI / CD, - це реагувати на події із зовнішнього світу (зміни в сховищі git, переміщення завдань навколо трекера завдань) та запускати дії, описані в мета-проекті. Крім того, сервісвизначає пункт контролю над усіма сховищами та інструмент для управління ними (об'єднання гілок, оновлення з upstream / master).

Я історично використовував досить потужний, але дуже простий інструмент від Jetbrains - TeamCity, але я не бачу жодних проблем, якщо ви вирішите спробувати щось інше, наприклад, безкоштовний Дженкінс.

У схемі, яку ми описали вище, служба інтеграції по суті відповідає за запуск чотирьох основних процесів та допоміжного, які є наступними:

  • Автоматичне тестування послуг - як правило, для одного сховища, коли стан філії змінився або коли стан було змінено на "Очікування автотестів" (або подібне)
  • Постачання послуг - як правило, з метапроекту та для ряду послуг (кількість репозиторіїв відповідно), коли статус змінився на "Очікування шоуруму" або "Очікування доставки" для QA та виробничого середовища відповідно
  • Відкат - як правило, з метапроекту та для певної частини однієї послуги або всієї послуги, викликаної зовнішньою подією або у разі невдалої доставки
  • Видалення послуги - це потрібно для повного видалення всієї екосистеми з єдиного тестового середовища (салону), коли статус In QA закінчився або довкілля більше не потрібне
  • Конструктор зображень (допоміжний процес) - може бути інтегрований у процесі надання послуг або використовуватись самостійно для складання зображень Докера та відправлення їх до Реєстру Докера. Часто обробляє широко використовувані зображення (БД, загальні послуги чи послуги, які не потребують частих змін)

Система збору та аналізу журналів

Єдиний спосіб будь-якого контейнера Docker зробити його журнали доступними - це записати їх у STDOUT або STDERR кореневого процесу, що працює в контейнері. Розробнику послуг зовсім не байдуже, що буде далі з даними журналів, головне, щоб вони були доступні, коли це необхідно, і бажано містити записи до певного моменту минулого. Вся відповідальність за виконання цих очікувань покладається на Kubernetes та інженерів, які підтримують екосистему.

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

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

Elasticsearch - це ресурсомістке рішення, але воно добре масштабує і має готові зображення Docker для запуску як окремого вузла, так і кластера потрібного розміру.

Система відстеження

Настільки ж досконалий, як може бути ваш код, трапляються збої, і тоді ви хочете вивчити їх за допомогою тонкозубного гребінця на виробництві і спробувати зрозуміти, "що за чорт пішло не так, якщо все працювало нормально на моїй локальній машині?". Повільні запити до бази даних, неправильне кешування, повільні диски або зв’язок із зовнішнім ресурсом, транзакції в екосистемі, вузькі місця та недостатні масштаби обчислювальних служб - одні з причин, через які вас змусять відстежувати та оцінювати витрачений час на виконання коду під реальне навантаження.

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

Складності, що виникають при інструментації коду та пересиланні “Trace Id” через усі сервіси, черги повідомлень, бази даних тощо, вирішуються вищезазначеними стандартами розробки та шаблонами обслуговування. Останні також дбають про рівномірність підходу.

Моніторинг та оповіщення

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

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

Весь діапазон моніторингу розділений на три повністю логічно ізольованих рівні. Ось, на мій погляд, найважливіші приклади відстеження точок на кожному рівні:

  • Фізичний рівень: - Мережеві ресурси та їх доступність - Диски (введення / виведення, доступний простір) - Основні ресурси окремих вузлів (ЦП, ОЗУ, ЛА)
  • Рівень кластерів: - Наявність основних систем кластерів на кожному вузлі (кубелет, kubeAPI, DNS тощо тощо) - Кількість вільних ресурсів та їх рівномірний розподіл - Моніторинг дозволеного та фактичного споживання ресурсів службами - Перезавантаження стручки
  • Рівень обслуговування: - Будь-який вид моніторингу програм - від вмісту бази даних до частоти дзвінків API - Кількість помилок HTTP на шлюзі API - Розмір черг та використання працівників - Кілька показників для бази даних (відставання реплікації, час та кількість транзакцій, повільні запити та інше) - Аналіз помилок для процесів, що не належать до HTTP - Моніторинг запитів, що надсилаються до системи журналів (ви можете перетворити будь-які запити в показники)

Що стосується сповіщень про сповіщення на кожному рівні, я хотів би рекомендувати використовувати один із незліченних зовнішніх служб, які можуть надсилати сповіщення електронною поштою, SMS або телефонувати на мобільний номер. Я також згадаю про іншу систему - OpsGenie - яка тісно інтегрується з менеджером сповіщень Прометея.

OpsGenie - це гнучкий інструмент для оповіщення, який допомагає боротися з ескалаціями, цілодобовим режимом, вибором каналу сповіщення та багато іншого. Також легко поширювати сповіщення між командами. Наприклад, різні рівні моніторингу повинні надсилати сповіщення різним командам / відділам: фізичні - Infra + Devops, кластерні - Devops, програми - кожен до відповідної команди.

Шлюз API та єдиний вхід

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

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

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

Ось деякі проблеми, які вирішує шлюз API:

  • Доступ до послуг екосистеми ззовні та зсередини (служби не спілкуються безпосередньо між собою)
  • Інтеграція з службою єдиного входу: - Перетворення маркерів та додавання HTTPS-запитів із заголовками, що містять ідентифікаційні дані користувача (ідентифікатор, ролі, інші деталі) для запитуваної послуги, - включення / відключення контролю доступу до запитуваної служби на основі ролей отриманий від послуги єдиного входу
  • Єдина точка моніторингу HTTP-трафіку
  • Поєднання документації API різних служб (наприклад, комбінування файлів json / yml Swagger's
  • Можливість управління маршрутизацією для всієї екосистеми на основі доменів та запитуваних URI
  • Єдина точка доступу для зовнішнього трафіку та інтеграція з постачальником доступу

Шина подій та інтеграція підприємств / Шина обслуговування

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

В якості шини подій ви можете використовувати будь-яку систему, яка може управляти так званим брокером: RabbitMQ, Kafka, ActiveMQ та ін. Загалом, висока мікродоступність та узгодженість даних є критично важливими для мікропослуг, але вам доведеться щось пожертвувати, щоб досягти правильного розподілу та кластеризації шини, завдяки теоремі CAP.

Звичайно, автобус подій повинен мати можливість вирішувати всілякі проблеми міжобслугового спілкування, але оскільки кількість послуг зростає від сотень до тисяч до десятків тисяч, навіть найкраща архітектура на основі автобусних подій вийде з ладу, і ви потрібно шукати інше рішення. Хорошим прикладом може бути підхід до інтеграційної шини, який може розширити можливості описаної вище тактики «Тупа труба - розумний споживач».

Існує десятки причин використання підходу «Інтеграція підприємства / шина обслуговування», який спрямований на зменшення складності сервісно-орієнтованої архітектури. Ось лише кілька таких причин:

  • Агрегація декількох повідомлень
  • Розщеплення однієї події на кілька подій
  • Синхронний / транзакційний аналіз реакції системи на подію
  • Координація інтерфейсів, що особливо важливо для інтеграції із зовнішніми системами
  • Розширена логіка маршрутизації подій
  • Багаторазова інтеграція з тими ж послугами (ззовні та зсередини)
  • Не масштабована централізація шини даних
Як програмне забезпечення з відкритим кодом для шини інтеграції підприємства, ви можете розглянути Apache ServiceMix, що включає кілька компонентів, необхідних для розробки та розробки такого типу SOA.

Бази даних та інші державні послуги

Як і Kubernetes, Docker змінив правила гри раз і назавжди для сервісів, які вимагають збереження даних і тісно співпрацюють з диском. Деякі кажуть, що служби повинні "жити" по-старому на фізичних серверах або віртуальних машинах. Я поважаю цю думку і не буду вступати в суперечки щодо її плюсів і мінусів, але я цілком впевнений, що такі заяви існують лише через тимчасову нестачу знань, рішень та досвіду управління державними послугами в середовищі Докера.

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

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

  • Системи управління базами даних - PostDock - це просте і надійне рішення для PostgreSQL всередині будь-якого середовища Docker
  • Брокери черги / повідомлення - RabbitMQ - це класичне програмне забезпечення для побудови системи черги повідомлень та маршрутизації повідомлень. Параметр cluster_formation в конфігурації RabbitMQ незамінний для налаштування кластера
  • Послуги кешування - Redis вважається одним з найнадійніших і гнучких кеш-даних
  • Повний текст - стек Elasticsearch, про який я вже згадував вище, спочатку використовувався для повнотекстового пошуку, але так само хороший для зберігання журналів та для будь-якої роботи з великою кількістю текстових даних
  • Послуги зберігання файлів - узагальнююча група послуг для зберігання та доставки будь-якого типу файлів (ftp, sftp тощо)

Дзеркала залежності

Якщо ви ще не стикалися з ситуацією, коли потрібні вам пакети чи залежності були вилучені або тимчасово недоступні з загальнодоступного сервера, не думайте, що це ніколи не відбудеться. Щоб уникнути небажаної недоступності та забезпечити безпеку внутрішніх систем, переконайтеся, що ні побудова, ні доставка ваших послуг не потребують підключення до Інтернету. Налаштуйте дзеркальне відображення та копіювання всіх залежностей у внутрішню мережу: зображення Docker, rpm-пакети, джерельні сховища, модулі python / go / js / php.

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

Від архітектури до реального життя

Подобається це чи ні, рано чи пізно вся ваша архітектура буде приречена на провал. Це завжди буває: технології швидко застарівають (1–5 років), методи та підходи - трохи повільніше (5–10 років), принципи проектування та основи - періодично (10–20 років), але неминуче.

Пам’ятаючи про застарілість технології, завжди намагайтеся підтримувати свою екосистему на піку технологічних інновацій, плануйте та впроваджуйте нові сервіси для задоволення потреб розробників, бізнесу та кінцевих користувачів, пропонуйте нові комунальні послуги своїм зацікавленим сторонам, надайте знання для переміщення своїх команда та компанія вперед.

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

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

Повертаючись до запитання з назви: "чи можна побудувати кращу архітектуру?" Ні, не "раз і назавжди", але обов'язково прагніть до цього і в якийсь момент, "ненадовго", ви неодмінно вдасться!

PS:

Оригінальна стаття була написана російською мовою, тому дякую моєму колезі по Lazada Сергію Родіну за чудову допомогу в її перекладі!