Мікросервіси та зберігаються процедури

Чи вважаються збережені процедури поганою практикою в архітектурі мікросервісу?

Ось мої думки:

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

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

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

Будь-які думки з цього приводу?

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

Відмова: Мені не подобаються збережені процедури з POV розробника, але це ніяк не пов'язане з мікросервісами.

Збережені процедури зазвичай працюють на монолітній базі даних.

Я думаю, ти піддаєшся логічній помилковості.

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

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

Більшість книг про мікросервіси рекомендують по одній базі даних на мікросервіс.

Немає жодних технічних причин, чому ці менші бази даних не можуть зберігати процедури.

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

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

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

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

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

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

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

Для написання програмного забезпечення потрібно чітко поєднатися з технологією.

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

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

• Мережевий сервісний сервіс для забезпечення реалізації протоколів HTTP / SSL / SOAP високого рівня
• Репозиторій / ORM / DAO Framework для забезпечення стійкості.
• Структури маніпуляції даними для забезпечення інструментів для роботи з даними.
• Process / Threading / OS Framework для забезпечення доступу до ресурсів ОС, таких як багатозадачність, файлова система, пам'ять, обчислення GPU, карти розширення тощо ...

А це - зробити мікропослугу з голими кістками.

Збережені процедури

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

Що це все-таки:

• Ще одна технологія. Кожна технологія, яка присутня у додатку, зменшує ймовірність використання будь-якого програміста, який може читати, розуміти та робити мудрий вибір дизайну для цієї технології.
• Мова, що використовує іншу парадигму програмування. Неекспертам занадто просто намагатися спробувати застосувати свою власну імперативність, функціональність, ОО та ін ... перспективу, що часто призводить до менш зоряних результатів.
• API. Який повинен підтримуватися як і будь-який інший клас у кодовій базі. Це також означає, що база даних забезпечує негенеричний інтерфейс. Це ускладнює як заміну самого двигуна бази даних, так і прозоре застосування загальної поведінки, наприклад у кешування пам'яті.
• Артефакт. Які повинні бути переосмислені, протестовані та розгорнуті. Це можна зробити, але бази даних - це живі артефакти, що вимагають іншого підходу. Зазвичай ви не можете просто видалити оригінал та замінити його. Часто потрібна ретельна оркестровка змін із часом, щоб перевести систему в потрібний стан.

Кожне з них - реальна вартість. У деяких випадках вартість є виправданою, в інших - ні.

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

Бізнес-логіка

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

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

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

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

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

Простий акт визначення схеми таблиці - це переміщення бізнес-логіки в базу даних.

Архітектура

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

Це непросто.

Але давайте подумаємо немислиме, як би ви підтримували ділову логіку, розподілену на декілька мов?

• Каталог ... так що кожне впровадження правил для бізнесу можна відслідковувати та підтримувати.
• Тести ... які можуть бути використані проти кожного бізнес-правила, незалежно від того, де та як воно було здійснено.
• Довідкова реалізація .. так що, коли будуть виявлені розбіжності, існує джерело істини (або принаймні джерело дебатів).

Але це теж має витрати.

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

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

Отже, коротка відповідь - ні, збережені процедури не є по суті поганими в архітектурі мікросервісу. Але вам потрібно зрозуміти:

1. Ви додаєте перешкоди для заміни двигунів зберігання даних. Якщо деякі експлуатаційні або експлуатаційні характеристики або обмеження функцій вимагають від вас перемикання двигунів зберігання даних, вартість буде більшою, оскільки ви будете писати та протестувати багато нового коду. Запуск декількох механізмів зберігання даних (або під час фази міграції, або для виділення діяльності на основі потреб у продуктивності) може створити проблеми з узгодженістю, якщо ви не використовуєте двофазну комісію (2PC), яка сама по собі має проблеми з продуктивністю.
2. У вас є ще один API для підтримки, що означає, що ваші залежності можуть зламатися. Додавання, видалення або зміна типів параметрів у процедурах може порушити існуючий код. Те саме відбувається з таблицями та запитами, але ваші інструменти можуть бути менш корисними для відстеження, де все може піти не так. Проблеми із збереженими процедурами, як правило, зустрічаються під час виконання, дуже пізно в процесі розробки / розгортання.
3. Ваші дозволи бази даних просто ускладнилися. Чи працює процедура як зареєстрований користувач або як якась інша роль? Вам потрібно подумати над цим і керувати цим (сподіваюся, в автоматизованому вигляді).
4. Вам потрібно буде безпечно переходити до нових версій. Часто процедуру необхідно скасувати та створити заново. Ще раз, дозволи можуть спричинити деякі проблеми для вас.
5. Відкат невдалої міграції може означати додаткові зусилля. Коли виробниче середовище відокремлюється від розробників, речі стають ще складнішими.

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

1. Забезпечення історії редагування (журнали аудиту). Для цього зазвичай використовують тригери, а тригери - це збережені процедури. У деяких базах даних також можна заборонити вставки та оновлення повністю для ролі програми: клієнти виконують процедури, які виконуються як інша роль з відповідними дозволами, і які застосовують всі необхідні дії.
2. Подовження обмежень перевірки. Це може зайняти вас територією ділової логіки, але є випадки, коли вбудованих засобів обмеження баз даних може бути недостатньо для того, що вам потрібно. Найчастіше найкращий спосіб висловити чеки - це імперативний код, і ви ризикуєте пустити недостовірні дані, якщо ви залежите від вашої програми, щоб зробити це за вас.
3. Інкапсулювання складних запитів, коли перегляд недоцільний або занадто складний. Я бачив декілька випадків, коли для правильного перегляду потрібен надзвичайно складний SQL, який може бути виражений набагато зрозуміліше у збереженій процедурі. Це, мабуть, рідко, але воно трапляється.

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

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

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

Більшість книг про мікросервіси рекомендують по одній базі даних на мікросервіс.

Гаразд, щоб ми могли кодувати збережені процедури у цих базах даних.

знову ж таки більшість книг з архітектури мікросервісу стверджують, що вони повинні бути автономними і нещільно пов'язаними

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

Зауважте, що "розщеплення" вже діє як агент для роз'єднання. Скажімо, у нас є дві служби, A підтримується Oracle, а B - MongoDB. Якщо ми не порушимо золотого правила роз’єднання, слід мати можливість скинути A + Oracle з незначними побічними ефектами на B.

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

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

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

Більшість книг MSA (які я прочитав) рекомендують мікросервіси орієнтуватися на бізнес (розроблені за допомогою DDD).

Це має бути орієнтоване на бізнес, і тут річ. Не весь бізнес користується перевагою DDD. DDD та мікросервіси перетинаються в багатьох точках, але вони не є причиною. Ми могли б отримати екосистему мікросервісів, що складається з анемічних служб. Або складається з поєднання обох: служб, що реалізують складний домен, і тупої анемічної послуги, що надає POJO безпосередньо з БД. У цьому немає нічого поганого.

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

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

Це насправді не має нічого спільного з мікросервісами.

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

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

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

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