Всім привіт! У нас чудові новини, у червні OTUS знову запускає курс У зв'язку з чим ми традиційно ділимося з вами корисним матеріалом.
Якщо ви зіткнулися з усією цією історією з мікросервісами без будь-якого контексту, то вибачимо вважати її трохи дивною. Розбиття програми на фрагменти, пов'язані між собою мережею, неодмінно означає додавання складних режимів відмовостійкості в розподілену систему.
Незважаючи на те, що такий підхід включає розбиття на безліч незалежних сервісів, кінцева мета куди більше, ніж просто робота цих сервісів на різних машинах. Йдеться тут про взаємодію з навколишнім світом, який за своєю суттю теж розподілений. Не в технічному сенсі, а скоріше у сенсі екосистеми, що складається з безлічі людей, команд, програм, і кожна з цих частин так чи інакше має виконувати свою роботу.
Компанії, наприклад, являють собою набір розподілених систем, які в сукупності сприяють досягненню певної мети. Ми ігнорували цей факт протягом десятиліть, намагаючись домогтися об'єднання, передаючи файли FTP або користуючись інструментами корпоративної інтеграції, при цьому зосереджуючись на своїх особистих цілях. Але з настанням сервісів все змінилося. Сервіси допомогли нам заглянути за обрій та побачити світ взаємозалежних програм, які працюють спільно. Однак, щоб працювати успішно, необхідно усвідомити і спроектувати два принципово різні світи: зовнішній світ, де ми живемо в екосистемі безлічі інших сервісів, і наш особистий, внутрішній світ, де ми керуємо поодинці.
Такий розподілений світ відрізняється від того, в якому ми виросли та до якого звикли. Принципи побудови традиційної монолітної архітектури не витримують жодної критики. Тому правильне розуміння таких систем – це більше, ніж створення класної схеми на білій маркерній дошці чи крутий доказ концепції. Йдеться про те, щоб така система успішно працювала протягом тривалого часу. На щастя, сервіси існують вже досить давно, хоч і виглядають по-різному. все ще актуальні, навіть приправлені Docker, Kubernetes і трохи пошарпані хіпстерськими бородами.
Отже, сьогодні ми подивимося на те, як змінилися правила, чому нам потрібно переосмислити наш підхід до сервісів та даних, які вони передають один одному, і чому нам знадобиться зовсім інший інструментарій.
Інкапсуляція не завжди буде вам другом
Мікросервіси можуть працювати незалежно один від одного. Саме ця властивість надає їм найбільшої цінності. Це властивість дозволяє сервісам масштабуватися і зростати. Не стільки в сенсі масштабування до квадрильйонів користувачів або петабайт даних (хоча і тут вони можуть допомогти), скільки в сенсі масштабування з точки зору людей, оскільки команди та організації зростають безперервно.
Однак незалежність – це палиця з двома кінцями. Тобто сервіс сам по собі може крутитися легко та невимушено. Але якщо всередині сервісу реалізується функція, яка вимагає задіяти інший сервіс, то зрештою нам доводиться вносити зміни в обидва сервіси майже одночасно. У моноліті це зробити легко, ви просто вносите зміну та відправляєте у реліз, а от у разі синхронізації незалежних сервісів проблем буде більше. Координація між командами та релізними циклами руйнує гнучкість.
У рамках стандартного підходу прикрих наскрізних змін намагаються уникати, чітко розділяючи функціонал між сервісами. Сервіс єдиного входу в систему може бути хорошим прикладом. Він має чітко визначену роль, яка відрізняє його від інших сервісів. Такий чіткий поділ означає, що у світі швидко мінливих вимог до сервісів, що оточують його, сервіс єдиного входу в систему навряд чи буде змінюватися. Він існує у рамках строго обмеженого контексту.
Проблема у тому, що у світі бізнес-сервіси що неспроможні постійно зберігати однаково чисте поділ ролей. Наприклад, ті самі бізнес-сервіси більшою мірою працюють з даними, що надходять від інших таких самих сервісів. Якщо ви займаєтеся онлайн-рітейлом, обробка потоку замовлень, каталогу продукції або інформації про користувачів стане вимогою до багатьох ваших сервісів. Кожному сервісу для роботи знадобиться доступ до цих даних.
Більшість бізнес-сервісів використовують один і той же потік даних, тому їхня робота незмінно переплітається.
Таким чином, ми підійшли до важливого моменту, про який варто поговорити. У той час як сервіси добре працюють для компонентів інфраструктури, які працюють значною мірою відокремлено, більшість бізнес-сервісів виявляються переплетеними куди більш тісно.
Дихотомія даних
Підходи, орієнтовані на послуги, можливо, вже існують, однак у них все ще мало інформації про те, як обмінюватися великими обсягами даних між сервісами.
Основна проблема полягає в тому, що дані та послуги нерозлучні. З одного боку, інкапсуляція закликає нас приховувати дані, щоб сервіси можна було відокремити один від одного та полегшити їх зростання та подальші зміни. З іншого боку, нам потрібно мати можливість вільно розділяти та панувати над загальними даними, як і над будь-якими іншими. Йдеться про те, щоб мати можливість відразу ж розпочати роботу, так само вільно, як і в будь-якій іншій інформаційній системі.
Однак інформаційні системи мало спільного з інкапсуляцією. Насправді навіть навпаки. Бази даних роблять все, що можуть, щоб дати доступ до даних, що зберігаються в них. Вони поставляються з потужним декларативним інтерфейсом, який дозволяє змінити дані як вам потрібно. Такий функціонал важливий на етапі попередніх досліджень, але не для управління зростаючою складністю сервісу, що постійно розвивається.
І тут виникає проблема. Протиріччя. Дихотомія. Адже інформаційні системи – це надання даних, а послуги – про приховування.
Ці дві сили є фундаментальними. Вони лежать в основі більшості нашої роботи, постійно борючись за перевагу в системах, які ми створюємо.
У міру того, як зростають та еволюціонують системи сервісів, ми бачимо різні прояви наслідків дихотомії даних. Або інтерфейс сервісу буде зростати, надаючи все більш широкий набір функцій і почне виглядати як дуже чудова доморощена база даних, або нас спіткає розчарування, і ми реалізуємо якийсь спосіб витягувати або переміщати цілі набори даних з сервісу в сервіс.
У свою чергу створення чогось, що виглядає як чудова доморощена база даних, призведе до цілої низки проблем. Ми не будемо вдаватися до подробиць того, чим небезпечна shared database, просто скажемо, що вона являє собою значні дорогі інженерні та операційні для компанії, яка намагається її використати.
Найгірше те, що обсяги даних примножують проблеми з межами сервісів. Чим більше загальних даних лежить усередині сервісу, тим складніше стане інтерфейс і тим важче об'єднати набори даних, що надходять із різних сервісів.
Альтернативний підхід із вилученням та переміщенням цілих наборів даних теж має свої проблеми. Поширений похід до цього питання виглядає як просте вилучення та зберігання набору даних повністю, а потім зберігання його локально в кожному сервісі-споживачі.
Проблема у тому, різні сервіси по-різному інтерпретують дані, що вони споживають. Ці дані завжди під рукою. Вони змінюються та обробляються локально. Досить швидко вони перестають мати щось спільне з даними джерела.
Чим більш мутабельні копії, тим більше даних відрізнятиметься з часом.
Що ще гірше, такі дані складно виправити у ретроспективі. тут і справді може допомогти). Насправді деякі з важкорозв'язних технологічних проблем, з якими стикається бізнес, виникають через різнорідні дані, що множаться від додатка до додатку.
Щоб знайти вирішення цієї проблеми про загальні дані, потрібно думати інакше. Вони мають стати об'єктами першого класу в архітектурах, які ми будуємо. називає такі дані "зовнішніми", і це дуже важлива особливість. Нам потрібна інкапсуляція, щоб не розкривати внутрішній пристрій сервісу, але ми повинні полегшити сервісам доступ до даних, що спільно використовуються, щоб вони могли коректно виконувати свою роботу.
Проблема полягає в тому, що жоден із підходів сьогодні вже не актуальний, оскільки ні інтерфейси сервісу, ні обмін повідомленнями, ні Shared Database не пропонують хорошого рішення для роботи із зовнішніми даними. Інтерфейси сервісу погано підходять для обміну даними у будь-якому масштабі. Обмін повідомленнями переміщує дані, але не зберігає їхню історію, тому згодом дані ушкоджуються. Shared Databases надто сильно фокусуються в одній точці, що стримує розвиток прогресу. Ми неминуче застрягаємо у циклі неспроможності даних:
Цикл неспроможності даних
Потоки: децентралізований підхід до даних та сервісів
В ідеалі нам потрібно змінити підхід до того, як послуги працюють із загальними даними. На даний момент будь-який підхід стикається з вищезгаданою дихотомією, оскільки не існує ніякого чарівного пилку, яким можна було б його щедро посипати і зробити так, щоб він зник. Однак ми можемо переосмислити проблему та дійти компромісу.
Цей компроміс передбачає певний рівень централізації. Ми можемо скористатися механізмом розподілених логів, оскільки він забезпечує надійні потоки, що масштабуються. Тепер потрібно, щоб сервіси могли приєднуватись та працювати цими спільними потоками, проте ми хочемо уникнути складних централізованих God Service'ів, які виконують таку обробку. Тому найкращий варіант – це вбудувати потокову обробку у кожний сервіс-споживач. Так послуги зможуть об'єднувати набори даних із різних джерел та працювати з ними так, як їм потрібно.
Один із способів досягти такого підходу – це використання стрімінгової платформи. Існує безліч варіантів, але сьогодні ми розглянемо саме Kafka, оскільки використання її Stateful Stream Processing дозволяє ефективно вирішувати представлену проблему.
Використання механізму розподіленого логування дозволяє нам йти протоптаною стежкою, і використовувати обмін повідомленнями, щоб працювати з . Вважається, що такий підхід забезпечує краще масштабування та поділ, ніж механізм «запит-відповідь», оскільки він віддає керування потоком одержувачу, а не відправнику. Однак за все в цьому житті доводиться платити, і вам знадобиться брокер. Але для великих систем цей компроміс того вартий (чого не скажеш про ваші середньостатистичні веб-додатки).
Якщо розподілене логування відповідає брокер, а чи не традиційна система обміну повідомленнями, можна скористатися додатковими особливостями. Транспорт можна лінійно масштабувати майже так само добре, як розподілену файлову систему. Дані можуть зберігатися в логах досить довго, тому ми отримуємо не лише обмін повідомленнями, а й сховище інформації. Масштабоване сховище без страху отримати загальний стан, що змінюється.
Потім можна використовувати механізм stateful stream processing (обробка потоку із збереженням стану) для додавання декларативних інструментів бази даних до сервісів-споживачів. Це дуже важлива думка. Поки дані зберігаються у загальних потоках, яких можуть отримувати доступ всі послуги, об'єднання і обробка, яку робить сервіс, є приватними. Вони виявляються ізольованими всередині обмеженого контексту.
Позбавтеся дихотомії даних, розділивши іммутабельний потік станів. Потім додайте цю функцію до кожного сервісу за допомогою Stateful Stream Processing.
Таким чином, якщо ваш сервіс повинен працювати із замовленнями, каталогом продуктів, складом, у нього буде повний доступ: тільки ви вирішуватимете, які дані об'єднувати, де їх обробляти і як вони повинні змінюватися з часом. Незважаючи на те, що дані є спільними, робота з ними повністю децентралізована. Вона виробляється усередині кожного сервісу, у світі, де все йде за вашими правилами.
Діліться даними так, щоб не порушувалася їхня цілісність. Інкапсулюйте функцію, а не джерело, у кожному сервісі, якому він потрібний.
Так відбувається, що дані необхідно масово перемістити. Часом сервісу потрібен локальний історичний набір даних у вибраному движку бази даних. Фокус у тому, що можна гарантувати, що при потребі копію можна відновити з джерела за допомогою звернення до механізму розподіленого логування. Конектори Kafka відмінно справляються з цим завданням.
Отже, у розглянутого сьогодні підходу є кілька переваг:
- Дані використовуються у вигляді загальних потоків, які можуть довго зберігатися в логах, а сам механізм роботи із загальними даними зашитий у кожному окремому контексті, що дозволяє сервісам працювати легко та швидко. У такий спосіб можна врівноважити дихотомію даних.
- Дані, що надходять із різних сервісів, можуть легко об'єднуватися в набори. Таким чином спрощується взаємодія із загальними даними та зникає необхідність підтримки локальних наборів даних у базі даних.
- Stateful Stream Processing лише кешує дані, а джерелом істини залишаються загальні логи, тому проблема пошкодження даних із часом стоїть негаразд гостро.
- По суті, сервіси управляються даними, тобто незважаючи на постійне зростання обсягів даних, сервіси все ще можуть швидко реагувати на бізнес-події.
- Проблеми масштабованості лягають на брокера, а не на послуги. Таким чином, значно зменшується складність написання сервісів, оскільки відсутня необхідність замислюватися про масштабованість.
- Додавання нових сервісів не потребує зміни старих, тому підключення нових сервісів стає легшим.
Як бачите, це більше, ніж просто REST. Ми отримали набір інструментів, який дозволяє працювати із загальними даними децентралізовано.
У сьогоднішній статті було розкрито далеко ще не всі аспекти. Нам все ще потрібно визначитися з тим, як балансувати між парадигмою «запит-відповідь» та подієво-орієнтованою парадигмою. Але з цим ми розберемося наступного разу. Є теми, з якими потрібно познайомитися краще, наприклад, чим такий гарний Stateful Stream Processing. Про це ми поговоримо у третій статті. А ще існують інші потужні конструкції, якими ми можемо скористатися, якщо вдамося до них, наприклад, . З її допомогою змінюються правила гри для розподілених бізнес-систем, оскільки ця конструкція забезпечує транзакційні гарантії. у масштабованій формі. Про це йтиметься у четвертій статті. І нарешті, нам потрібно буде пробігтися деталями реалізації цих принципів.
Але поки що просто запам'ятайте наступне: дихотомія даних - це та сила, з якою ми стикаємося при створенні бізнес-сервісів. І ми маємо про це пам'ятати. Фокус у тому, щоб перевернути все з ніг на голову та почати вважати загальні дані об'єктами першого класу. Stateful Stream Processing надає унікальний компроміс. Він уникає централізованих “God Components”, що стримують розвиток прогресу. Більш того, він забезпечує оперативність, масштабованість і стійкість до відмови пайплайнів стрімінгу даних і додає їх в кожен сервіс. Тому ми можемо сфокусуватися на загальному потоці свідомості, до якого може підключитись будь-який сервіс та працювати з його даними. Так послуги виходять більш масштабованими, взаємозамінними та автономними. Тому вони не тільки добре виглядатимуть на маркерних дошках і під час перевірки гіпотез, але й працюватимуть і розвиватимуться десятиліттями.
Джерело: habr.com