Як вписати двигун правил в архітектуру мікросервісу, коли він вимагає великої кількості вхідних даних?

Нинішня ситуація

Ми реалізуємо (і зараз підтримуємо) веб-додаток для покупок в Інтернеті в архітектурі мікросервісів.

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

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

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

Нові вимоги

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

Продовжуючи, як є, ми зіткнемося з кількома проблемами:

• кожен (виклик механізму правил) повинен повторно виконувати отримання даних, навіть якщо вони не потрібні для себе;
• запити до двигуна правил є складними;
• продовжуючи в цьому напрямку, нам доведеться транспортувати ці дані по всій мережі для багатьох запитів (подумайте про μs A, що викликає μs B, викликає двигун правил, але A вже має деякі дані, необхідні двигуну правил);
• shopping-cart стала величезною завдяки всім отриманим даним;
• Я, мабуть, забуду багатьох ...

Що ми можемо зробити, щоб уникнути цих неприємностей?

В ідеалі ми б уникали додаткових складностей у системі двигунів. Ми також повинні переконатися, що він не стає вузьким місцем - наприклад, деякі дані доволі повільно отримують (10s або навіть більше), тому ми реалізували попереднє отримання shopping-cartтаким чином, що дані, швидше за все, будуть там, перш ніж називати правила двигуна та зберегти прийнятну роботу користувачів.

Деякі ідеї

1. Нехай механізм правил забирає необхідні йому дані. Це додало б їй ще більшої складності, порушуючи принцип єдиної відповідальності ( ще більше… );
2. Внесіть проксі-мкс перед системою правил для отримання даних;
3. Реалізуйте μs "виборці даних", який закликає двигун правил отримувати всі необхідні йому дані одразу (складений запит).

Давайте зробимо крок назад на секунду і оцінимо наше початкове місце, перш ніж виписати цю відповідь, що ймовірно, буде романом. Ти маєш:

• Великий моноліт (двигун правил)
• Велика кількість немодульованих даних, які надсилаються масово
• Важко отримати дані до та з механізму правил
• Ви не можете видалити двигун правил

Гаразд, це не так добре для мікросервісів. Безпосередньо гостра проблема - ви, здається, хлопці нерозумієте, що таке мікросервіси.

кожен (виклик механізму правил) повинен повторно виконувати отримання даних, навіть якщо вони не потрібні для себе;

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

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

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

Більшість ваших питань випливають з цього.

запити до двигуна правил є складними;

Зробіть їх менш складними.

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

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

А ще краще, ви не точно перша компанія, яка впровадила інструмент онлайн-покупок. Перейдіть на дослідження інших компаній.

Тепер що ...

Після цього ви принаймні спрацювали деякі найбільші проблеми.

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

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

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

Можна також розділити ваші двигуни правил на частини? Ви можете отримати прибутки, просто зробивши частину своїх правил, орієнтованих на правила.

Ми також повинні переконатися, що він не стає вузьким місцем - наприклад, деякі дані досить повільні для отримання (10s або навіть більше)

Якщо припустити, що ця проблема існує після вирішення вищезазначених питань, вам потрібно серйозно дослідити, чому це відбувається. У вас розгортається кошмар, але замість того, щоб розібратися, чому (10 секунд? Для надсилання даних про портали по магазинах ? Назвіть мене цинічно, але це здається трохи абсурдним), вам здається, що виправляєте симптоми, а не дивитесь на проблему, яка викликає симптоми перше місце.

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

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

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

І, нарешті, мікросервіси - це не єдине рішення. Будь ласка, заради всього, що є святим, не робіть цього лише тому, що це нова штука.

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

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

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

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

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

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

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

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

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