Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?
Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
Здравствуйте, Shmj, Вы писали:
S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
да, в большинстве случаев так лучше и не стоит связываться с микросервисами.
S>Зачем все это? Ради чего?
микросервис имеет смысл если есть следующее (то чем мы руководствувоемся у себя):
— когда функционал микрососервиса может быть довольно хорошо изолирован/выделен и имеет ограниченное взаимодействие с данными основного, желательно чтоб его действия не были частью другой более высокоуровневой транзакции (иначе надо решать доп. сложности как откатить его действия при отмене внешней транзакции).
— когда его пилит другая команда/компания и есть причины чтоб не делать это в исходниках одного проекта.
— когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.
S>В чем смысл микросервисов?
Сам не пользую, но периодически слушаю подкасты с обсуждением.
Основноая идея — что это позволяет гибко балансировать нагрузку и на лету подключать/отключать.
Допустим, у вас сайтик, который умеет детектировать котиков на фото, или ведет рейтинг барбершопов, или что в таком духе.
И если к вам набегут хипстеры, то сайт не ляжет, и вы сможете рекламой заработать на смузи или даже новый айфон.
Какие такие транзакции?, это же вам не банк.
Средний такой pet-project(англ. проект собачьей будки) содержит около ~20 микросервисов, в каждом сервисе обычно от 3 до 50 строк кода.
Здравствуйте, Shmj, Вы писали:
S>Зачем все это? Ради чего?
1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро. Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.
Естественно есть и недостатки у такой архитектуры. Ибо увеличение сложности на ровном месте, затраты на коммуникации, нужна облачная инфраструктура. Потому вообще все проекты фигачить как микросервисы — это полный идиотизм. Если есть возможность сделать проект как монолит — лучше проект сделать как монолит, а не плодить сущностей. Но не всегда можно обойтись монолитом.
А вообще, для многих задач хорошо в свое время подходила просто сервисная архитектура. Если имеем распределенные системы, эта SOA уже в мейнстриме лет 15 минимум. Но когда эта SOA стала приобретать популярность, необходимым аттрибутом этой SOA стали тяжеленные сервера приложений. В результате рестарт приложения занимал иногда часы. Микросервисная архитектура — это тоже SOA, но на более легких решениях. Не нужна тяжеленная дорогущая промышленная шина, можно использовать легкую опенсорсную бесплатную библиотеку, и самому разобраться в нормальной документации, а не платить бешенные деньги за техподдержку какого то монстра, который к тому же глючит и тормозит. Простейшие микросервисы поднимаются вообще мгновенно. Тяжелые сервисы тоже никуда не делись, от них никуда. Но так как теперь сервисы стало писать и обслуживать гораздо легче, стало легче дробить функционал на сервисы. Некоторые сервисы по прежнему довольно тяжелые, и поднимаются довольно долго. Но у них строго один функционал, и время подъема зачастую там из за того, что идет пересчет каких то показателей, выполнение различных расчетов, поднятие и построение первичного кеша и т.д. Сами коммуникации то поднимаются мгновенно.
Ну а вообще, эта микросервисность появилась как ответ на решение проблем производительности всяких фейсбуков, твиттеров, гуглов и т.д. Где миллиарды пользователей и относительно простой функционал. И весь современный хайп идет оттуда.
Здравствуйте, Shmj, Вы писали:
S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
S>Зачем все это? Ради чего?
Ради того, чтобы развязать жизненные циклы компонент. То есть чтобы они могли разрабатываться и деплоиться независимо друг от друга. Это позволяет более эффективно масштабировать процесс разработки.
Полной независимости, конечно, достичь не получится, и придется иногда по необходимости вводить точки синхронизации при изменениях, ломающих совместимость. Но это стараются делать пореже.
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов?
S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?
S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
S>Зачем все это? Ради чего?
— Повторное использование. микросервисы проще использовать повторно, чем библиотеки, т.к. библиотеке нужна конфигурация, конкретные зависимости, иногда конкретная платформа или ОС.
— Версионирование. Можно развернуть несколько версий микросервиса и использовать их совместно из множества приложений. С библиотекой это сложнее.
— Изоляция по данным. Это очень важно, т.к. маленькую БД намного легче поддерживать, оптимизировать и кешировать.
— Изоляция по коду. При рефакторинге можно не затрагивать другие микросервисы по принципу "работает — не трогай". При наличии хорошей документации можно использовать микросервис без необходимости смотреть исходный код.
Еще побочные плюсы, вытекающие из микросервисной архитектуры:
— Масштабирование. В целом, монолитные приложения масштабируются хорошо, в отличие от огромной БД монолитного приложения. И наличия внутреннего состояния, которым грешат монолиты.
— Жесткие границы отдельных микросервисов, препятствующие превращению системы в лапшу.
— Устойчивость к отказам. Отказ от транзакций и необходимость тщательной обработки ошибки позволяет строить системы, адекватно реагирующие на перегрузку и отказ отдельных компонентов.
И минусы:
— Сложность. Микросервисная архитектура требует огромных вложений в единую архитектуру системы, девопс, мониторинг, логгирование и аналитику.
— Еще раз сложность. Правильно разбить еще не написанное приложение на микросервисы — задача нетривиальная и при ошибке реализация каждой фичи затрагивает множество микросервисов, что серьезно стопорит разработку
— И еще раз сложность. Отказ от распределенных транзакций и сетевое взаимодействие требуют очень вдумчивого подхода к обработке ошибок.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Shmj, Вы писали:
S>>Зачем все это? Ради чего? E>1) Ради масштабирования
Я думаю, сэр, вы гоните дичь. Причём тут масштабирование, если это МИКРОсервисы? Каждый ест по чуть-чуть. Можно, конечно, отловить самый прожорливый микросервис, но боюсь, узкое горлышко будет совсем в другом месте.
E>...Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев
И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
E>2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.
Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет. Как только в проект вносят ещё один язык, на проект сразу взваливают ещё одну ненужную проблему — поддержку этого языка, т.е. людей. Люди — это ВСЕГДА ПРОБЛЕМА. При тысячах резюме, подходят по уровню лишь десятки. И только паре из них можно навешать второстепенную задачу "вы тут микросервисом позанимайтесь". Причём отдавать этот сервис студоте вы явно не захотите. Ну а кто мнит себя даже "просто разрабом", хочет за свои услуги будто он всю систему писал! И даже согласные могут заболеть, найти лучшую вакансию и т.п. В команде 10 джавистов вы всегда найдёте, кому перекинуть сервис. В команде 10 джавистов и два Перловика ваш "перлосервис" будет дамокловым мечом — заслуженным наказанием за свою бестолковость "язык под задачу". По этой фразе можно сразу увольнять с работы, моё мнение.
E>Ну а вообще, эта микросервисность появилась как ответ на решение проблем производительности всяких фейсбуков, твиттеров, гуглов и т.д. Где миллиарды пользователей и относительно простой функционал. И весь современный хайп идет оттуда.
Микросервисы там вообще не причём. Их главная задача — масштабирование и решается она куда проще.
K>Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет.
Кстати, хотел тебя спросить про c# -- оно еще не сдохло?
К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).
Часто бывает такая ситуация: в начале проектирования системы видно, что функцию A надо делать вот так, функцию B надо делать примерно вот так, функцию C надо делать пока что хрен знает как, но она должна быть; вместо функции D надо пока сделать заглушку, а функция E, возможно, появится в будущем. И нагрузка на эту функциональность будет пока что непонятно какая.
Если заложиться, что система будет построена на микросервисах — как минимум, можно начать варганить эту систему и потом относительно безболезненно пристегивать к ней новую функциональность по мере развития. (это , конечно, не единственный способ решения проблемы, но один из).
Здравствуйте, Kolesiki, Вы писали:
K>И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
Вообще то микросервисы крутятся в каком то кластере. Корпоративном или облачном. Этот кластер уже есть, он уже сконфигурирован. И там уже есть независимые от задачи механизмы распределения нагрузки. Уже готовые, уже сконфигурированные, и на этом кластере гоняются десятки приложений. Если кто то под каждое приложение обслуживает отдельно, а не централизованно кластер — у кого то реально большие проблемы.
K>Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет.
Вот потому и появилась мода на фулстек. И на идиотизм, когда из за того, что фронтэндер хочет писать фронтэнд на JavaScript, на нем же и фигачат огроменную бекэнд логику. Ибо фронтэнд в современном мире будет по любому на JavaScript. Соответственно так как мы хотим, чтоб язык был один, этим языком будет JavaScript. Ибо от него не избавиться. И на нем все так или иначе умеют. Ибо фронтэндера современного хрен заставишь писать на статически типизированном языке, даже если бы инструменты были. Ибо ему пофиг, его задача отображение, там сложности обычно только с версткой и с приколами особенностей браузеров. И из за того, что так удобно фронтэндеру, многие додумываются проекты на миллионы строк писать на этом убожестве. Также советую попробовать пересадить математиков на что то, отличное от питона. В коде математиков один черт кроме них хрен кто разберет, там проблема не с языком. Кто будет писать кучу математических либ, которые существуют на питоне, под другие языки? Или мы будем всю систему фигачить на питоне, когда расчетная часть это весьма небольшая часть? Переписывать код математиков потом — это двойная работа. И пока ты переписываешь код математиков нормально, добиваясь чтоб то, что ты понаписал, считало аналогично, там уже к чертям требования черти как изменятся и код математиков уйдет далеко.
Здравствуйте, elmal, Вы писали:
E>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.
И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.
E> Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
Нет, не готова.
E>2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.
Зачем для этого создавать распределенную систему?
E>Естественно есть и недостатки у такой архитектуры. Ибо увеличение сложности на ровном месте, затраты на коммуникации, нужна облачная инфраструктура.
Ты про САР-теорему забыл, бессердечную суку, грозу всех хипстеров.
Здравствуйте, scf, Вы писали:
scf>И минусы: scf>- Сложность. Микросервисная архитектура требует огромных вложений в единую архитектуру системы, девопс, мониторинг, логгирование и аналитику. scf>- Еще раз сложность. Правильно разбить еще не написанное приложение на микросервисы — задача нетривиальная и при ошибке реализация каждой фичи затрагивает множество микросервисов, что серьезно стопорит разработку scf>- И еще раз сложность. Отказ от распределенных транзакций и сетевое взаимодействие требуют очень вдумчивого подхода к обработке ошибок.
А еще снижение стабильности и надежности системы в целом.
Здравствуйте, klopodav, Вы писали:
K>Если заложиться, что система будет построена на микросервисах — как минимум, можно начать варганить эту систему и потом относительно безболезненно пристегивать к ней новую функциональность по мере развития. (это , конечно, не единственный способ решения проблемы, но один из).
Ты путаешь логическую и инфраструктурную структуру. Для вышесказанного достаточно логического разбиения на изолированне контрактами модули. Физически резать инфраструктуру на куски нет нужды.
Проблема в том, что то, что вы называете microservices — это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:
Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Обычно в случае с микросервисным подходом нужно стремится к eventual consistency. Таким образом, чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.
Математики, с которыми я работал, писали исключительно на Фортране. Как их удалось пересадить на Питон?
