Давайте поговоримо про позитиви та негативи мікросервісного підходу.
Перші негативи. Коли ви створюєте мікросервіси, ви додаєте властиву складності коду. Ви додаєте накладні витрати. Ви ускладнюєте копіювати середовище (наприклад, для розробників). Ви ускладнюєте налагодження переривчастих проблем.
Дозвольте проілюструвати справжній мінус. Розглянемо гіпотетично випадок, коли у вас створюється 100 мікросервісів під час створення сторінки, кожна з яких робить правильно 99,9% часу. Але 0,05% часу вони дають неправильні результати. І 0,05% часу виникає запит на повільне підключення, коли, скажімо, потрібен час очікування TCP / IP для підключення, і це займає 5 секунд. Близько 90,5% часу ваш запит працює бездоганно. Але приблизно в 5% часу ви маєте неправильні результати і приблизно 5% часу ваша сторінка повільна. І кожен невідтворюваний збій має різну причину.
Якщо ви не будете багато думати навколо інструментів для моніторингу, відтворення тощо, це перетвориться на безлад. Особливо, коли одна мікрослужба викликає іншу, яка викликає іншу на кілька шарів углиб. І як тільки у вас виникнуть проблеми, вони з часом тільки погіршаться.
Гаразд, це звучить як кошмар (і більше однієї компанії створили для себе величезні проблеми, йдучи цим шляхом). Успіх можливий лише тоді, коли ви чітко знаєте потенційний недолік і послідовно працюєте над його вирішенням.
То як щодо того монолітного підходу?
Виявляється, монолітний додаток так само легко модулювати, як мікросервіси. А виклик функції на практиці є і дешевшим, і надійнішим, ніж дзвінок RPC. Таким чином, ви можете розробити те саме, за винятком того, що воно надійніше, працює швидше і містить менше коду.
Добре, тоді чому компанії йдуть на підхід до мікросервісів?
Відповідь полягає в тому, що в міру масштабування існує обмеження в тому, що ви можете зробити з монолітним додатком. Після стільки користувачів, стільки запитів тощо, ви досягаєте точки, коли бази даних не масштабуються, веб-сервери не можуть зберігати ваш код у пам’яті тощо. Крім того, підходи до мікросервісу дозволяють незалежно та поступово оновити вашу програму. Тому архітектура мікросервісу - це рішення масштабування вашої програми.
Моє особисте правило полягає в тому, що перехід від коду на мові сценаріїв (наприклад, Python) до оптимізованого C ++, як правило, може поліпшити 1-2 порядки як на продуктивність, так і на використання пам'яті. Інший шлях до розподіленої архітектури додає величини вимогам до ресурсів, але дозволяє масштабувати нескінченно. Можна зробити розподілену архітектурну роботу, але зробити це складніше.
Тому я б сказав, що якщо ви починаєте особистий проект, будьте монолітними. Дізнайтеся, як це зробити добре. Не розповсюджуйтесь, тому що (Google | eBay | Amazon | тощо) є. Якщо ви приземляєтесь у великій компанії, яка розповсюджується, зверніть пильну увагу на те, як вони змушують її працювати, а не збивайтеся з цього. А якщо вам доведеться робити перехід, будьте дуже, дуже обережними, оскільки ви робите щось важке, що легко зрозуміти дуже, дуже неправильно.
Розкриття, я маю майже 20-річний досвід роботи в компаніях усіх розмірів. І так, я бачив як монолітну, так і розподілену архітектури близько і особисто. Виходячи з цього досвіду, я кажу вам, що розподілена архітектура мікросервісів справді - це те, що ви робите тому, що вам потрібно, а не тому, що це якось чистіше і краще.
