Моноліти масштабування проти масштабування мікросервісів


15

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

Скажімо, у нас був додаток, що складається з 10 мікросервісів, 9 з яких мали по два екземпляри (для надмірності) і один з них з 4 примірниками для обробки навантаження (масштабованість). Аргумент pro-мікросервісу полягає в тому, що ви можете самостійно масштабувати цю miroservice з інших служб.

Однак скажемо, що всі 10 мікросервісів були модулями в одному моноліті, і було розгорнуто кілька (наприклад, 22 як сума зверху) екземплярів цього моноліту. Система повинна мати можливість обробляти навантаження для однієї критичної частини, оскільки для цього достатньо примірників. Якщо екземпляри містять програмну логіку, яка не потрібна, єдиним недоліком буде те, що двійкові та об'єм необхідної оперативної пам'яті будуть трохи більшими. Але знову ж таки, різниця не повинна бути надто великою у більшості випадків - принаймні, не порівняно з рештою стека (подумайте про Spring Boot). Перевернутий масштабний монліт був би простішою системою без (більшості) помилок розподіленої системи.

Я щось пропускаю?


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

Я не порахував рядки коду, але моноліт мав би кілька тисяч рядків коду (не гігантська система). Початковим моментом мого розгляду було те, що розмір фактичного коду програми є невеликим порівняно з великими рамками, такими як Spring та Hibernate. Кількість розгортань насправді може бути меншою, ніж у мікросервісів, тому що якби у вас було 2 екземпляри, ви б мали вже базове надмірність, а більше екземплярів було б для масштабування.
Діамон

@deamon Будьте в курсі, що при монолітному підході немає частин коду, який є абсолютно мертвим у кожному випадку, просто рідко використовується код. Тепер сам код може зайняти лише невеликий об'єм пам'яті, але якщо він використовує багато об'єктів, що є в пам'яті, цей об'єм може значно зрости.
Френк Хопкінс

Зауважте, що накладні витрати базового "отримання його запуску коду" не обов'язково є настільки великими, як ви можете це знати з ваших програм Java, де часто весь jvm є частиною зображення зображення.
Френк Хопкінс

Відповіді:


21

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

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

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


2
Домовились. Причина переходу до архітектури мікросервісу здебільшого є політичною. Розподілене навантаження, роз'єднання - це наслідки, а не причини. Справжня користь мікросервісів полягає в SDLC та Управлінні. Крім цього, архітектура - це логічна відповідь на потребу, яка в більшості випадків походить від ринкової стратегії компанії. Час виходу на ринок коротший, ніж монолітні архітектури, тому компанії дозволено приймати нові стратегії, переходити від однієї до іншої плавно і швидко
Laiv

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

"Ми робимо це тому, що нам доводиться через те, що складність покращила нас, і ми робимо найкраще в умовах неоптимальної ситуації." Так. Для мене це нігті!
Thomas Junk

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

1
@ewan Ви також можете використовувати декілька комп'ютерів з монолітами.
Діамон

3

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

Однак. як тільки у вас виникне дисбаланс, скажімо, сервіс 5 займає 100% процесора за 2 хвилини, ви хочете перенести цю службу на власну коробку, щоб вона не блокувала всі інші служби, якщо вона працює.

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

Тепер ви могли б зробити те ж саме і з добре модульованим монолітом. Встановіть усі сервіси, але лише маршрутне обслуговування 5 трафіку до одного з них. Хоча не маршрутизує сервіс 5 трафіку до інших вікон.

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


1

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


Я частково згоден. Моя думка стосувалася не аргументів для мікросервісів загалом, а про масштабованості. У моєму конкретному випадку, наприклад, мікросервіси написані в одній технології. Тож як можна було б використовувати різні технології для кожного, тут просто не так. Я хотів переконатися, що я не пропускаю важливого моменту щодо масштабованості.
Діамон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.