Мікросервіси: MonolithFirst?

Я досліджував архітектури мікросервісів, намагаючись отримати огляд на високому рівні щодо всіх плюсів і мінусів, про те, хто і чому, і т.д. al).

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

Зокрема, це одне:

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

• Майже всі успішні історії мікросервісу почалися з моноліту, який став занадто великим і розпався
• Майже всі випадки, коли я чув про систему, яка була побудована як мікросервісна система з нуля, вона закінчилася серйозними неприємностями.

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

(посилання: https://martinfowler.com/bliki/MonolithFirst.html - акцент їх)

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

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

Схоже, на розумний загальний підхід, але цікавий думок громади.

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

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

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

В загальному:

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

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

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

Найбільш негайно цінні переваги мікросервісів можна досягти простою модуляцією коду. Ви можете виділити групи функцій у модулі, використовуючи будь-яку модульну систему у вас (maven, npm, nuget, тощо). Кожен модуль може служити одній цілі, сидіти у власній системі репо, використовувати власну схему БД, керувати власною конфігурацією, мати власні відсталі функції та графік випуску. Вони все ще можуть бути розгорнуті разом на моноліт. Це дуже керована сума накладних витрат і дає хороші переваги. Більш великі накладні витрати виникають через розділення розгортань, що є справді цінним лише після того, як у вас буде достатньо масштабу для необхідності. Якщо ваш код уже модульний, тоді це буде легшою міграцією, коли настане час.

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

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

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

Я майже впевнений, що в цій точній статті MF виникло кілька запитань.

Я беру на себе це:

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

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

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

Також ми повинні пам’ятати, що MF пише з великої точки зору OOP. Він, природно, скептично ставиться до більш сучасного розподіленого підходу.

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

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

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