Подход в разработке, когда система развёртывается не одним большим exe, а множеством мелких.
Очень любим всякими сектантами-саентологами за возможность навертеть запутанное наукообразие на ровном месте, корпоративными паразитами за возможности затруднять работу коллегам-конкурентам в борьбе за милость начальства, и прочими врагами трудового народа https://habr.com/ru/post/709328/
— Видишь этих людей? — ответил он мне, показывая страничку одного из подчинённых ему отделов на staff, — здесь, например, их сейчас сто пятьдесят. Все они работают в одной парадигме — пишут микросервисы — причём значительную часть работы вообще делает кодогенератор.
Знаешь, в чём ценность подобного подхода?
— В чём? — переспросил я.
— Во-первых, я могу уволить половину или даже вообще всех, заместив их совершенно новыми людьми с улицы. От этого не случится никакого ущерба.
Во-вторых, никто из них, уйдя отсюда, не сможет сделать систему, аналогичную той, что мы имеем: большинство не то что не знает даже о половине бизнес-нюансов — не имеет представления, чем занимается сосед!
Здравствуйте, gyraboo, Вы писали:
G>Монолит лучше, безусловно. Причем чем больше организация, тем острее необходимость монолита.
Тут, главное, непременно выбрать крайность, и всячески противиться любому отступлению от выбранной парадигмы. По крайней мере, до тех пор, пока не придумают новый модный-стильный-молодежный подход; вот тогда можно будет выкинуть все наработки, и переписать все под него.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: Объясните на пальцах, что такое микросервисы
Очередной buzzword, призванный решить все проблемы. Помню времена, когда MVC считался таким словом, и все вокруг срочно переписывали свои приложения в этом стиле. Потом, правда, оказалось, что у этого подхода большие проблемы. И тогда придумали MVP, MVVM, а потом и вовсе перестали как-либо называть свои архитектуры.
Возвращаясь к сабжу. Микросервисная архитектура это когда отдельные функции приложения выделяют в независимый сервис, который принимает и отдаёт данные через какой-то обобщённый интерфейс, например Thrift-RPC или REST-HTTP. Такой подход позволяет распределить нагрузку, потому что разные сервисы могут распологаться на разных узлах, а запросы могут быть обработаны параллельно. Также микросервисы позволяют добиться независимости различных команд разработчиков друг от друга, пока API остаётся стабильным. Но это больше описание микросервисов здорового человека. А на практике всё выглядит примерно так.
O>>Очень любим всякими сектантами-саентологами за возможность навертеть запутанное наукообразие на ровном месте G>Монолит лучше, безусловно. Причем чем больше организация, тем острее необходимость монолита.
Я просто наблюдал, как мою подсистему молодые сеньоры "переписали на микросервисы". Попросили меня в итоге что-то в ней поотлаживать. Вместо 1 сервера теперь надо запустить штук 7 "микросервисов" на нескольких компах, причём сначала надо узнать на каких (потому что микросервисы ежедневно туда-сюда перекладывают как муравьи) и дождаться когда эти компы будут свободны, и всё перемещённое заново настроить. Для этого надо допросить 7 человек в 7 разных современных месенжерах (не все из них ясно выражаются на русском, некоторые только по-смартфонски, как тут на форуме). Каждый микросервис, разумеется, сделан в отдельном гигасолюшене (всё в 1 физически не влезает), так что будьте добры запустить одну за другой несколько студий. Солюшены с кучей нугет-пакетов, так что подхватывание исходника отладчиком работает далеко не всегда. Когда всё наконец через несколько дней было запущено и удалось выпасть ошибкой в отладчик, то можно было наблюдать сильно удлиннившийся stack trace (строк 50 превратилось в 500, это при включенном just my code), и там почти нетронутые мои старые методы бизнес-логики перемежались в 10 раз большим кол-вом добавленных вызовов одних инфраструктурных паттернов другими. Т. е. при том же функционале добавилось в 10 раз больше нового кода и лишней работы, чисто чтобы кому-то было удобно всё всем запутать — быть в этом бардаке единственным всезнающим — и на этом строить карьеру.
Здравствуйте, Mihal9, Вы писали: M>Сабж. M>Спасибо
микросервисы это что-то типа кубиков лего — закинул данные и получил результат обработки,
делают то что выполняется за относительно небольшое кол-во времени,
как правило такие сервисы доступны на облачных сервисах
ещё микросервисы в основе парадигмы software as a service (SaaS) — вебсервисы,
когда большие on-premise системы заменяются на облачные сервисы —
например не нужно самому реализовывать какой-нить edifact или покупать и внедрять систему учёта,
можно купить доступ на тематическое облако и подписаться на необходимые сервисы,
т.е. теперь необязательно закупать оборудование в стойки, failover, и небольшие орг-ии
получают доступ к качественному условно отказоустойчивому ПО,
микросервисы есть например в amazon web services, microsoft azure, google cloud, sap cloud
-
Re[4]: Объясните на пальцах, что такое микросервисы
Здравствуйте, Osaka, Вы писали:
O>>>Очень любим всякими сектантами-саентологами за возможность навертеть запутанное наукообразие на ровном месте G>>Монолит лучше, безусловно. Причем чем больше организация, тем острее необходимость монолита.
весьма спорно, есть и плюсы и минусы
O>Я просто наблюдал, как мою подсистему молодые сеньоры "переписали на микросервисы". Попросили меня в итоге что-то в ней поотлаживать. Вместо 1 сервера теперь надо запустить штук 7 "микросервисов" на нескольких компах, причём сначала надо узнать на каких (потому что микросервисы ежедневно туда-сюда перекладывают как муравьи) и дождаться когда эти компы будут свободны, и всё перемещённое заново настроить. Для этого надо допросить 7 человек в 7 разных современных месенжерах (не все из них ясно выражаются на русском, некоторые только по-смартфонски, как тут на форуме). Каждый микросервис, разумеется, сделан в отдельном гигасолюшене (всё в 1 физически не влезает), так что будьте добры запустить одну за другой несколько студий. Солюшены с кучей нугет-пакетов, так что подхватывание исходника отладчиком работает далеко не всегда. Когда всё наконец через несколько дней было запущено и удалось выпасть ошибкой в отладчик, то можно было наблюдать сильно удлиннившийся stack trace (строк 50 превратилось в 500, это при включенном just my code), и там почти нетронутые мои старые методы бизнес-логики перемежались в 10 раз большим кол-вом добавленных вызовов одних инфраструктурных паттернов другими. Т. е. при том же функционале добавилось в 10 раз больше нового кода и лишней работы, чисто чтобы кому-то было удобно всё всем запутать — быть в этом бардаке единственным всезнающим — и на этом строить карьеру.
Здравствуйте, Mihal9, Вы писали:
M>Сабж. M>Спасибо
Микросервисы это когда ты разбиваешь одно приложение, выполняющее N функций, на N приложений, выполняющих одну функцию. Например монолитное приложение интернет-магазина превращается в в микросервисы: каталога товаров, корзина и формирование заказа, управление складом и доставкой. У каждого свой api и свой бэкэнд, своя база. Фронтэнд остается общим, он дергает разные апи микросервисов.
Из определения очевидны недостатки:
— надо писать больше кода, количество функций остается постоянным, взаимодействие между приложениями требует написание дополнительного кода
— сильно медленнее работает, взаимодействие между разными приложениями дороже вызовов внутри приложений
— требует намного больше ресурсов
Преимущества:
— микросервисы могут быть написаны на разных языках разными командами
— раздельное обновление микросервисов, уменьшение "площади поражения" при обновлении
— раздельное масштабирование микросервисов
Многие всерьез рассматривают уменьшение связности как преимущество, но оно не компенсирует раздувание кода из-за необходимости кросспроцессного взаимодействия.
Но ключевое, что полюбили все управленцы и менеджеры: с помощью микросервисов можно простое приложение сделать очень сложным, привлечь больше ресурсов, повысить свой вес как менеджера.
Если тебе нечем занять команду программистов — перепиши систему на микросервисы, программисты будут заняты на 110%.
Re[5]: Объясните на пальцах, что такое микросервисы
T>а что за подсистема такая?
Да как обычно, получать xml, потрошить в таблицы, редактировать в гуе и в обработках, читать из таблиц, отправлять xml. И всё это между сотнями узлов.
Re[3]: Объясните на пальцах, что такое микросервисы
Здравствуйте, gyraboo, Вы писали:
O>>Очень любим всякими сектантами-саентологами за возможность навертеть запутанное наукообразие на ровном месте
G>Монолит лучше, безусловно. Причем чем больше организация, тем острее необходимость монолита.
В больших огранизациях монолит должен учитывать интересы самых различных подразделений, между которыми всегда возникают конфликты интересов. Чем больше организация, тем больше таких подразделений и как следствие конфликтов. Рано или поздно появляются взаимоисключающие требования, ограничения и тд.
В этом случае можно просто отпочковать зону конфликта в виде отдельного микросервиса.
В маленькой конторе такого хаоса нет, потому можно обеспечить гибкость именно за счет монолита.
Re[6]: Объясните на пальцах, что такое микросервисы
Здравствуйте, Osaka, Вы писали: T>>а что за подсистема такая? O>Да как обычно, получать xml, потрошить в таблицы, редактировать в гуе и в обработках, читать из таблиц, отправлять xml. И всё это между сотнями узлов.
интеграция чтоль?
-
Re[3]: Объясните на пальцах, что такое микросервисы
Здравствуйте, gyraboo, Вы писали:
O>>Очень любим всякими сектантами-саентологами за возможность навертеть запутанное наукообразие на ровном месте
G>Монолит лучше, безусловно. Причем чем больше организация, тем острее необходимость монолита.
Ну в .Net Framework есть домены, интерфейсы, dll, рефлекшин
Это ведь тоже монолит!
и солнце б утром не вставало, когда бы не было меня
Микросервисы — подход к разработке софта, когда приложение делится на несколько/много независимых, взаимодействующих по сети частей. Протокол обмена известен и является отдельной сущностью, объединяющей взаимодействующие сервисы.
Микросервисы решают 2 практических задачи:
масштабирование сервиса, который не может работать на одной физической машине (гугл, фейсбук, частично яндекс),
организация совместной работы организации, когда над проектом работают несколько команд/отделов (тут суть в том, чтобы ограничить эго каждого руководителя его подчиненными).
С первым пунктом все понятно. А второй устроен так: у каждой команды/отдела есть руководитель и если подчиненного можно чморить чтобы получить желаемый результат (быковать, разводить, компосировать мозги), то с руководителем соседнего отдела так не получится — нужно договариваться (тут подход "делай как я сказал, потому что я так хочу" или "ты подчиненный — должен подчиняться" не работает). Каждый управленец считает себя центром вселенной. Более того, именно такие люди в первую очередь и поднимаются наверх, потому что "кто умеет работать...". Однако, "я прав, я всегда прав, только я всегда прав, поэтому будет так, как я сказал" с другим всегдаправом договориться не сможет, а их точки зрения обязательно по какому-то вопросу разойдутся. И суть подхода в том, чтобы вселенную каждого всегдаправа ограничить. Поэтому каждый отдел пилит свой микросервис (так, как решит их всегдаправ) и договариваются они о протоколе обмена данными между их сервисами. В результате все терки сводятся к решению вопроса, какие данные и при каких условиях должны бегать по сети. Ну, а если кому-то понадобиться еще один сервис — он сам его и будет пилить (тебе надо — ты и делай) и взаимодействовать с другими он будет по существующим протоколам.
У этого подхода даже есть именное название (типа архитектура софта отражает архитектуру организации, если над компилятором работают 4 отдела — он будет 4-х проходной).
Здравствуйте, Mihal9, Вы писали:
M>Сабж. M>Спасибо
Это когда вместо leftpad, который, как известно, может все поломать, ты просто отправляешь эту задачу, через балансировщик, отдельному серверу, и уже он отдает тебе результат.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
