Много шуму поднято из-за публичного обсуждения "вхождения во власть" Илона Маска с его новоприобретённым Твиттером. Это действительно хороший повод для понимания того, что творится в современных информационных технологиях. Поэтому рассмотрим проблему со стороны оппонентов повсеместно распространённой излишней сложности, коллективно называемой "микросервисная архитектура".
Итак, на Хабре появилась статья защитников микросервисов. Очень кстати, теперь есть о чём говорить предметно. Общий посыл статьи такой - у каждого микросервиса есть крайне важная ниша и потому - всё сделано правильно. Но я думаю, что многим очевиден несколько натянутый характер заявления, не подкреплённого конкретикой. Конкретика - это цифры. Давайте попробуем оценить приведённые защитниками микросервисов аргументы именно в цифрах.
Традиционно микросервисы обосновываются в контексте бизнес-процессов, в которых эти сервисы выполняю какую-то важную роль. И потому логично, что автор "аргументов за" привёл список процессов. Пройдёмся по нему.
Процесс управления информационной безопасностью
Место микросервисов в процессе не указано, но попробуем "догадаться с трёх раз", используя опыт работы в аналогичных компаниях. Основной способ достижения целей ИБ (информационная безопасность) простой - ограничения. Это и пароли, и политика требований к местам пользователей, и всевозможные прокладки между серверами и остальным миром, и много чего другого. Но суть здесь простая - это администрирование. У админов тоже должна быть какая-то консоль, но для неё обычно не нужно писать микросервис, ибо есть привычная админам командная строка привычного им Unix-подобного софта. А там, где нужно работать с данными, вроде задачи администрирования пользователей, все соответствующие инструменты давно написаны и админы про них отлично знают. В целом получается, что для основных задач инструменты есть, а микросервисы здесь не особо нужны.
Но есть ещё задача мониторинга. Мониторинг плох тем, что должен быть плотно привязан к существующему набору сервисов, поэтому здесь можно допустить наличие специфического софта, который выполняет хоть и простые, но зависящие от наблюдаемых микросервисов функции. Таких функций немного. Обычно большая часть мониторинга заключается в получении информации - жив сервис, или упал. Это достигается простейшим запросом по указанному в настройках адресу и через указанный там же протокол. Такая задача решена давно и не требует никаких микросервисов, кроме одно сервиса (не микро, а вполне приличного по функционалу). Этот сервис опрашивает по кругу все сервисы, по которым есть данные в его списке. Задача опрашиваемых сервисов - вернуть хоть что-нибудь без ошибки. Это чаще всего достигается без разработки чего-то нового в самом сервисе, потому что мониторинг вызывает готовые для других задач обработчики с безопасным для такой ситуации набором входных данных. Отсюда вывод - один сервис закрывает большинство задач по мониторингу. Добавим к нему ещё один, который решает узко-специальные задачи, требующие проверки не просто "жив или мёртв", но чего-то более сложного, учитывающего бизнес-логику приложения. Таких задач обычно мало и с ними справится сервис, написанный начинающими студентами с курсов по вашему любимому языку программирования. Итого - нам нужно два сервиса.
Есть ещё задача анализа трафика. Это задача "междисциплинарная", то есть она нужна и в ИБ и в других местах. Поэтому добавим ещё 0.1 сервис, приходящийся на долю ИБ. Правда анализ может быть очень тяжёлый, потому что каждый день анализируется много гигабайт данных, значит здесь нам потребуются мощные сервера и распределение задачи на параллельную обработку по доступным серверам. Но сервис всё же один, хотя и можно выделять - эта долька для ежа, эта долька для ужа, и т.д.
Процесс борьбы с ботами
И это тоже информационная безопасность, правда с немного другой начинкой - она фильтрует. То есть здесь нужны алгоритмы, умеющие отличать бота от человека. Да, это отдельная задача. И она привязана к логике приложения, потому что именно логика приложения нужна человеку, а боту нужно лишь рекламу повесить - в этом отличие. Только зачем же здесь городить тысячу сервисов? Здесь две составляющие - простая, которая решается стандартными средствами вроде анализа адресов и интервалов между запросами, и сложная, которая работает вместе с приложением и фильтрует, основываясь на его логике. Первая давно реализована и требует одну прокладку между пользователями и приложением. Вторая, как часть приложения, работает вместе с ним и могла бы вообще не создавать ни одного дополнительного сервиса. Но что бы вынести сложность в отдельный компонент согласимся на парочку дополнительных служб. Но не на тысячу.
Процесс управления инфраструктурой
Нам нужно управлять нашими серверами. А с ними ещё и сетями. И туда же - группами администраторов. А потом ещё создать группу управления группами. А к ней совет директоров. А к нему аудиторскую палату... Но мы этого делать не будем, мы попробуем просто обрисовать задачи, а накручивание около них бюрократии оставим Илону Маску.
Итак, сервера. Их нужно учитывать. Учёту подлежит и всё остальное - сети, админы, их любимый софт, и все-все-все юзеры. Да, это отдельная задача. Но повторю старую истину - всё украдено до нас. Это означает, что все эти админы и юзеры давно записаны в какой-нибудь LDAP (учётную систему с приоритетом на права доступа и описание ресурсов). Это, разумеется, сервис. Но сколько нужно админов на пусть даже 100 000 серверов? По большому счёту это вопрос о частоте изменений, а не о количестве серверов, потому что сегодня изменения устанавливаются автоматически, и не важно, хоть на один сервер, хоть на 100 000. Хотя я верю, что команды Твиттера сумели собрать страшный зоопарк из серверов, а потому и автоматическая установка намордников на сотню видов животных потребует с десяток различных протоколов и прочих приседаний. Пусть в итоге на весь зоопарк будет пятнадцать сервисов - для жирафов, для рыбок из аквариума, и т.д. Пока, всё равно, сильно меньше тысячи.
Процесс управления тестированием и качеством
Здесь мы должны немного погрузиться в разработку софта. При нормальной его организации имеем несколько серверов для одной команды разработчиков. Но важно отметить, что сервера эти ничего общего с требованиями к промышленным серверам не имеют. То есть они могут упасть, они могут сломаться, на них забудут установить обновление, и даже пусть рухнет весь дом, где стоят эти сервера - пользователи Твиттера этого не заметят. Потому что им нет никакого дела до того, что творится на ноутбуке у разработчика. И у тестировщика. И у менеджера проектов. И даже у директора по качеству. И даже у самого, не побоюсь этого слова, Илона, который в Маске.
Хотя есть задача мониторинга на сбои, что бы разработчики, если сбой по их вине, эти проблемы устранили. Но выше мы уже говорили - есть сервис, который опрашивает систему про сбои, и есть аналитика, они-то всё разработчикам и доложат. Хотя можно добавить систему ведения журнала для разработчиков, то есть это расшифровка деталей, рассказывающих программистов в какой ситуации упал их любимый сервис. Количественно оценивать такую систему можно по разному, в зависимости от качества самих разработчиков и безжалостности их по отношению к товарищу Маску. Одним разработчикам хватает относительно краткого описания ошибки, а другим нужно на каждый запрос пользователя получить мегабайт дополнительной информации - отсюда разница в нагрузке. Но понятно, что при нормальной разработке запись в подобный журнал не должна нагружать систему больше, чем целевая функция. И желательно, что бы нагрузка от журнала была этак раз в сто поменьше. Поэтому выделим на журнал долю в 0.01 от общего количества серверов, обслуживающих компанию. При 100 000 серверах (что явно много) получим 1000 серверов под журнал. Но, особенно если разработчики грамотные и умеют уложить все записи в один сервис, логически вся эта 1000 серверов будет представлена одной службой. Но ладно, допустим, что в в Твиттере одни неумёхи и им нужно 20 разных служб под одну универсальную задачу журналирования. Но опять имеем много меньше 1000 сервисов.
Добавим сюда работу с отзывами пользователей и разного рода опросы, которые суть бизнес-логика. И сразу заметим, что пользователи в основном пользуются платформой, а не отвечают на вопросы из очередного опроса от департамента по работе с клиентами. Отсюда мораль - эта нагрузка опять никакая. Пусть это будет пять сервисов. Хотя при желании можно уложить их всех в один - сервис взаимодействия с клиентом. Но никак не в тысячу сервисов.
Процесс управления релизами и выкатками
Это опять продолжение разработки. А потому здесь многое опять зависит от вольностей наших славных программистов. Но суть происходящего простая - команды складывают новый код в некое хранилище, которое они называют "репозиторий", это событие обнаруживается следящим за репозиторием сервисом, после чего он пытается сделать так, что бы появившийся код заработал на серверах, обслуживающих пользователей. Детали внутри такой попытки могут быть разнообразные, но для нас важно одно - мы опять имеем дело с одним сервисом, а не с тысячей. Хотя опять же, если Твиттер собрал у себя тысячу команд, и каждая сочинила для себя своё собственное решение по передаче "в бой" своего кода, тогда, разумеется, Илону Маску нужно срочно доложить о том, что у него действительно есть тысяча сервисов. Но вот в нужности такого количества велосипедов на стороне разработчиков у меня есть огромные сомнения.
Процесс технической поддержки пользователей
Помимо падений сервисы бывают ещё и неудобными, а иногда делают не то, что от них ожидает пользователь. Для анализа и устранения таких ситуаций существует служба поддержки. Это довольно много людей. И они обслуживают многие тысячи заявок в день, если мы говорим о масштабах Твиттера. Но здесь стоит пояснить, что все эти заявки укладываются в единую базу данных, потому что если разбивать их на много баз, то потом возникает обратная задача - для работы с заявкой нужно снова свести информацию в одно место, что даёт нам размножение работы как на входе, так и на выходе - очевидно неэффективное решение. Поэтому смело предположим, что всё-таки Твиттер как-то справился со своими разработчиками или сторонними производителями системы по работе с заявками пользователей и всё же имеет один сервис для этой цели, а не тысячу. Ну ладно, пусть десять специализированных, но уже не очень понятно зачем. И мы видим - до тысячи опять далеко.
Процесс управления рекламой
Да, это важный процесс. Это те деньги, которые зарабатывает Твиттер. То есть именно ради этого процесса всё начиналось и продолжает цвести и пахнуть. Поэтому под такую задачу смело выделяют большие бюджеты и готовы оплачивать много команд разработки, которые дотачивают все эти нейросети и прочий дата-сайенс до нужной кондиции. Но глобально задач здесь опять немного. Сервис под нейросети, сервис под статистический анализ, сервис под дискретную математику на графах и тому подобное. Плюс к этому привычная аналитика и всяческие отчёты. То есть десяток сервисов вполне может набраться. И где здесь тысяча?
Процесс предоставления API для сторонних разработчиков
Опять речь идёт о работе разработчиков. Они должны выставлять наружу практически тот функционал, который используют сами. Но поскольку внутренняя среда отличается от внешней, например наличием большого количества угроз, на подобное расширение нужно вешать фильтрацию. То есть отдельную логику, специализированную именно под данную задачу. Архитектурно это может быть очередная прокладка между потребителями (в виде удалённых автоматически действующих устройств) и производителями (в виде внутренних частей приложения). На сколько частей делить прокладку - вопрос к разработчикам. Но мы видели выше, что делить можно и на одну часть, и на тысячу. Последнее, как и раньше, есть явное расточительство. Но мы ещё поговорим о нём позже.
Процесс цензурирования
И снова мы возвращаемся к разработчикам. Давайте вспомним старые добрые форумы. Там тоже есть модераторы. И они используют тот же самый форум. Но у них на странице появляется кнопка - забанить. Вот и всё отличие от страниц обычных пользователей. На форумах о таком функционале даже не задумываются - делают частью приложения и не требуют никаких сервисов. А вот последующий разбор жалоб пользователей действительно нужно выделять в отдельную (организационную) службу. Но про неё мы уже говорили выше - это служба поддержки. Так что здесь сервисов просто нет.
Процесс поддержки 100 OpenSource проектов в красивом состоянии
Задача интересная, но стоит уточнить её цель. Сильно подозреваю, что это способ привлечения разработчиков "интересными задачами", то есть они, в рабочее время, занимаются интересными делами, ну а потом Твиттер это дело оплачивает. Это, конечно, хорошо. Разработчики должны быть довольны. Как и доктора, полицейские, металлурги, и даже дворники из Таджикистана. А что, разве дворники не люди? Но почему-то дворникам не дают столько возможностей для самореализации. Ну ладно, речь ведь о количестве сервисов. Итак, что такое "OpenSource проект"? Очень просто - копируем на известный сайт свой код и пишем к нему вступительное слова, экранов на пять-шесть, если не сильно лень. И всё. Дальше - обычный процесс разработки. И всё это на стороннем сервисе. Но где же 1000 внутренних сервисов? Ну пусть будет сервис отчётов перед начальством за непонятно на что потраченное рабочее время. Один. Не тысяча.
Процесс совершенствования методологий разработки и правил оформления кодовой базы
Ну да, как только подсистема осознаёт свою значимость, тут же появляются адепты "совершенствования методологий" и "правил оформления". Ну куда же нам без ГОСТ-ов на код? Но я бы не стал под это дело заводить серьёзный сервис. Хотят ребята побаловаться - вот вам куча внутренних серверов для разработчиков, на них и поднимайте свой мега-сервис. Опять один.
Процесс управления документацией
Соглашусь, это важная задача. Хотя, если честно, никто в Твиттере (как и в других системах) документацию не читает. Ну почти никто. А вот документировать внешнее API нужно, и обязательно качественно. Но ведь мы уже выше рассмотрели эту задачу. Значит лишь для тех долей процента от пользователей, которые сумели найти ссылку "Помощь" и разобрались там в сложной навигации по содержимому, нам и нужно писать документацию. И это не "высоко нагруженная" система. Это доли процентов от миллионов в день общего количества пользователей. То есть это тысячи, ну пусть десятки тысяч запросов. Такую нагрузку держит самый дешёвый виртуальный сервер за 3 бакса в месяц. Можно ли его приравнять к тысяче микросервисов? Вопрос риторический. И всё же остаётся задача - организовать работу технических писателей и их взаимодействие с разработчиками. Но это же опять внутренняя кухня разработки. А у них свои независимые и ненагруженные сервера. И пусть их там хоть 1000 штук, и даже пусть разработчики поиграются и поставят на каждый по сервису для документирования, но для пользователей Твиттера-то это что меняет? Зачем здесь все эти провода? По прежнему вопрошает Илон наш, свет-Маск.
Самая главная правда
Да, раньше был лишь ответ на аргументы сторонников микросервисов, изложенные явно. А теперь скажем о том, о чём они сказать забыли.
Зачем нужны микросервисы? Коротко - они повышают гибкость. Да, они нужны. Но всегда есть вопрос о границах. Если где-то летает муха, то мы же не будем говорить, что видим слона? Поэтому далее мы поймём, почему нужны микросервисы и где же нам поставить пограничные столбы.
Как достигается гибкость? Просто - внесли изменение в часть приложения, теперь его нужно как-то отправить в бой. Но для этого чаще всего нужно что-то перезапустить. Если приложение монолитное, то перезапустить придётся всё приложение целиком. Это означает, что миллионы пользователей Твиттера начнут страдать. Да, они видят ответ на их запрос примерно такого содержания - этот сервер недоступен, позвоните Илону Маску, вот телефон. Илон Маск не справится с таким количеством звонков. Поэтому разработчики предложили "рубить хвост по частям". Они перезапускают один мкросервис, при этом его работу никто не выполняет, но все остальные части приложения, так же созданные как сервисы, знают, что если что-то недоступно, то есть алгоритм обработки такой ситуации. Например - можно немного подождать. Или можно отправить запрос на другой сервис. Или и то и другое, и можно без хлеба. В целом же получаем некоторую новую устойчивость всей системы в целом.
Но, как вы могли заметить, при таком подходе возникает ряд дополнительных требований. Первое - все должны стать ёжиками сервисами. Второе - все должны знать, что делать, если соседний ёжик не хочет работать. Третье - кто-то должен понимать, как это огромное стадо ежей пинать столь нежно, что бы они в итоге полетели, но не убились об ближайшее дерево. Одним словом это всё называется так - сложность. Да, сложность сильно возрастает. И с ней не всегда справляются даже очень умно выглядящие разработчики.
Ранее уже говорилось, что в Твиттере (и не только) всё сильно зависит от разработчиков. Значит нам нужно рассмотреть как поведут себя условно "плохие" разработчики и условно "хорошие". Для этого поймём общую картину боя.
Сначала количественная сложность. Когда есть сотня микросервисов, то взаимодействие между ними требует налаживания десяти тысяч связей (пропорционально квадрату от количества сервисов). Если взять и разбить приложение на сервисы, не вспоминая о количественной сложности, то очень вероятно, что именно так и выйдет - сложность увеличится пропорционально квадрату. Поэтому нужно хорошо подумать. И здесь становится незаменим персонаж под псевдонимом "архитектор". Если он сумеет разбить систему так, что бы количество связей не возрастало до безобразия, то в таком случае мы можем переходить на систему из взаимодействующих сервисов. Ну а если не сможет - товарищу Маску придётся что-то делать с его не самым эффективным наследием.
Но есть ещё и качественная сложность. Подняв тысячу микросервисов, мы сразу получим задачу на мониторинг этого зоопарка. А к ней и задачу установки отличающихся обновлений на каждый из тысячи сервисов. Вместе с задачей установки идёт задача преобразования кода в то, что сможет запуститься, что называют "сборкой приложения". А к ней прилагается команда, то есть те люди, которые ответственны за данный сервис. И эти команды склонны к размножению. Они находят для себя огромное количество задач, хотя бы даже из уже приведённого списка - им же нужно сделать мониторинг? Нужно. Им же нужно написать документацию? Нужно. И так по всем процессам, задействованным в разработке. И что интереснее, преимущество микросервисов в гибкости позволяет разработчикам писать на том языке, к которому они привыкли, что означает сильно разные подходы к разработке. Но тут всплывает ещё и задача запрячь вола и трепетную лань в одну крестьянскую телегу. А к ней - нанять на рынке всё это бесконечное количество разработчиков, тестировщиков, технических писателей, аналитиков, менеджеров проектов, админов, дизайнеров и к ним ещё отдел из секретарш, ежедневно разносящих смузи по столам для каждого участника команды (мы ведь ценим разработчиков!). И все эти люди должны быть наняты на работу с отличающимися инструментами, то есть они должны иметь опыт работы с точно такими же. Что же теперь делать отделу кадров? Правильно - раздувать штат.
Вот таким примерно образом, из хорошей в своей основе идеи повышения гибкости, Илон Маск получил на свою миллиардерскую шею налог в виде никуда не исчезающей сложности. Ну что-ж, я думаю страдать о судьбе Маска не стоит, он справится. А вот о грамотном построении архитектуры информационной системы мы вполне можем задуматься. У нас перед глазами вопиющий пример из тысяч сервисов, которые требуют десяток тысяч работников, а всё для чего? Что бы пользователь мог на странице Твиттера сделать всего лишь часть от того, что любой старый добрый форум выполнял в гораздо большем объёме, не требуя такого гигантского раздувания штатов и инфраструктуры.
И о производительности
Ещё один аргумент за микросервисы - у нас нагрузка! Миллионы пользователей! Пуленепробиваемая надёжность! И ещё time-to-market и все-все-все.
Добавим деталей. Нагрузка обрабатывается за счёт распараллеливания. Можно поднять 1000 дешёвых виртуальных серверов и каждый обслужит минимум 1000 пользователей в день. Вот вам и миллион пользователей. Но для этого нужно уметь сводить запросы на одном сервере с данными от другого. Это архитектурная задача. И, как мы видим, сотрудники Твиттера её решили просто - покупаем 100 000 серверов (не виртуальных), нанимаем 10 000 человек, и вуаля - у нас даже что-то работает. Но тут уместна поговорка - с деньгами бы и дурак смог, а ты вот без денег попробуй.
Вторая часть - отказоустойчивость. Это продолжение всё той же гибкости. В идеале, миллион независимых микро-сервисов легко переключится на другой адрес при падении одного из миллиона участников. Но это лишь в идеале. Хотя суть здесь простая - дублирование. И опять мы получаем задачу для архитектора. Сумеет он достичь приемлемого дублирования на 1000 виртуальных серверов - молодец. Но чаще всего получается как в Твиттере - 100 000 серверов и миллиарды в год на содержание бегемота.
Третья часть - скорость разработки. Здесь люди идут по проторенной дорожке, что означает - действие по шаблону. Они смотрят, а что там у соседа. Если у соседа что-то работает и по меркам индустрии затраты приемлемые, то вывод здесь простой - я хочу так же. Но дело в том, что сосед далеко не семи пядей во лбу и, как много проблем в его внутренней кухне, смотрящий снаружи просто не видит. Поэтому копируются не самые эффективные решения, а просто "понравившиеся", то есть внешне выглядящие как успешные. Но стоит заглянуть внутрь, как все мы видим - Твиттер был несколько переоценен. Решение здесь опять лежит в плоскости внимательного и грамотного анализа требований с последующей продуманной реализацией. Опять во всём виноват архитектор. Но мы его обвинять не будем, потому что на работу в Твиттеры нанимают не по непонятным качествам типа внимательный, грамотный, продуманный и т.д., а по субъективному критерию "от 5 лет на аналогичной должности в компании Top-500 рейтинга NASDAQ". И теперь бывший разработчик из Твиттера, который не смог объяснить Маску, зачем нужны тысячи сервисов, легко устроится на аналогичную должность в другую такую же компанию, ведь у него за плечами есть эти самые 5 лет на аналогичной должности. Но хорошо ли это для разработки информационных систем?
Вывод
Микросервисы не плохие и не хорошие. Они - инструмент. Если не умеешь - не трогай. Но ситуация на рынке такова, что умеющих отбирать сложно, а потому мы и дальше будем наблюдать перегиб в сторону расползания неэффективности во все стороны. Но если кто-то всё же заинтересовался возможностью уменьшения затрат на корпоративного монстра, то мой ему совет - не надо вам "5 лет на аналогичной должности", вам надо грамотного и способного. Да, это означает, что лично вам придётся сидеть и самому с ним изучать матчасть. Не всю, понятно, но вникать надо. Любишь экономию? Люби и архитекторов на саночках возить.
Комментарии (25)
xxxphilinxxx
27.11.2022 20:26+5Если приложение монолитное, то перезапустить придётся всё приложение целиком. Это означает, что миллионы пользователей Твиттера начнут страдать.
Они перезапускают один мкросервис, при этом его работу никто не выполняетВовсе нет. Что микросервис, что монолит можно поднять в нескольких инстансах и переключать - green/blue deployment, довольно простая штука. В больших системах желательно каждый сервис делать с оглядкой на горизонтальное масштабирование - обычно это несложно, если изначально заложить.
Второе - все должны знать, что делать, если соседний ёжик не хочет работать.
Что внутри монолита выполнение функции может прерваться с выбросом исключения, что при обращении к сервису запрос может вернуть ошибку. Обрабатывать нужно в любом случае, просто по-разному. А чем больше проект и больше пользователей, тем чаще случаются даже крайне маловероятные ситуации.
Когда есть сотня микросервисов, то взаимодействие между ними требует налаживания десяти тысяч связей (пропорционально квадрату от количества сервисов)
Как внутри монолита делили код на модули/пакеты/неймспейсы и старались ослаблять связи, так и с микросервисами. Каждый отдельный микросервис знает о считанных единицах других, а некоторые и вовсе могут никого не знать и общаться, например, исключительно через общую шину данных. И еще забываете, что один раз создав и описав входящий/исходящий интерфейсы сервиса, это будет переиспользовано другими сервисами, а не делаться каждый раз с нуля. Если, конечно, в проекте языков не перебор.
Подняв тысячу микросервисов, мы сразу получим задачу на мониторинг этого зоопарка.
Для монолита тоже мониторинг нужен по предметным областям и тут пофиг, это монолит или сервисы. А предметно-независимый, то бишь инфраструктурный мониторинг вообще-то шаблонный, его тоже достаточно один раз описать и переиспользовать.
И, как мы видим, сотрудники Твиттера её решили просто - покупаем 100 000 серверов (не виртуальных), нанимаем 10 000 человек, и вуаля - у нас даже что-то работает.
Вы хорошо знаете, какие проблемы возникали и как решались в Твиттере, или просто "да я это сделаю за ночь и бутылку водки"?
В идеале, миллион независимых микро-сервисов легко переключится на другой адрес при падении одного из миллиона участников. [...] Но чаще всего получается как в Твиттере - 100 000 серверов и миллиарды в год на содержание бегемота.
Опять голословное утверждение. И уже миллионы - курток замшевых уже минимум три, видимо. Неужели в Твиттере не знают о балансировщиках? Кстати, как кол-во серверов помогает сервисам переключаться при падениях? Не понял эту мысль. И еще, пожалуйста, подскажите хоть примерно, сколько примерно из этих 100 000 ушло на такое бездумное дублирование? Можно ограничиться двумя-тремя наиболее жирными микросервисами Твиттера. Я вот затрудняюсь сделать такую оценку на основе новостей.
Здесь люди идут по проторенной дорожке, что означает - действие по шаблону. Они смотрят, а что там у соседа. Если у соседа что-то работает и по меркам индустрии затраты приемлемые, то вывод здесь простой - я хочу так же.
Пожалуйста, не экстраполируйте плохие практики на всю индустрию, если не знаете наверняка. И опять-таки, подскажите, пожалуйста, какие конкретно шаблонные действия совершали разработчики Твиттера и какой у них был выбор? Я не уловил таких подробностей в информационных потоках.
murkin-kot Автор
27.11.2022 22:38-3Что микросервис, что монолит можно поднять в нескольких инстансах и переключать - green/blue deployment
Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
Что внутри монолита выполнение функции может прерваться с выбросом исключения, что при обращении к сервису запрос может вернуть ошибку. Обрабатывать нужно в любом случае
Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
Как внутри монолита делили код на модули/пакеты/неймспейсы и старались ослаблять связи, так и с микросервисами. Каждый отдельный микросервис знает о считанных единицах других, а некоторые и вовсе могут никого не знать и общаться, например, исключительно через общую шину данных
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
один раз создав и описав входящий/исходящий интерфейсы сервиса, это будет переиспользовано другими сервисами
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Для монолита тоже мониторинг нужен по предметным областям и тут пофиг, это монолит или сервисы
Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
А предметно-независимый, то бишь инфраструктурный мониторинг вообще-то шаблонный, его тоже достаточно один раз описать и переиспользовать
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
Вы хорошо знаете, какие проблемы возникали и как решались в Твиттере, или просто "да я это сделаю за ночь и бутылку водки"?
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Пожалуйста, не экстраполируйте плохие практики на всю индустрию, если не знаете наверняка
Кое-что знаю. Но да, о Твиттере - только из интернета. Оттуда же про 100 000 серверов, и про десяток тысяч работников, ну и про остальное. Остальное как раз сильно намекает на то, что видел сам лично.
xxxphilinxxx
28.11.2022 00:33+3Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
А что вы предлагаете в качестве решения? Оно имхо будет одинаковое что для монолита, что для микросервиса. Идеального и бесшовного я, кстати, вовсе не знаю... Не доводилось делать. Может, кто подскажет, как надо :)
Видится мне так: клиенты ж не напрямую к сервисам подключаются, а через балансировщики, так что клиентская сессия останется живой. Дальше варианты: если нет проброса постоянного коннекта, а общение идет в режиме запрос-ответ, то проблемы никакой нет: балансировщик будет выбирать один из оставшихся инстансов. Недошедшие запросы можно отправить другому инстансу (понадобится защита, если они не идемпотентные), ну или ответить клиенту ошибкой. С каким-нибудь сокетом сложнее - его может быть сложно полноценно переинициализировать непосредственно на балансировщике, но и тут достаточно отправить клиенту сообщение о необходимости переподключения и закрыть коннект. Клиент тут же создаст новый коннект через тот же балансировщик к другому инстансу, а для пользователя все пройдет как меньше-чем-секундный лаг.Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
Тоже повторю: по взаимодействию вызов высокоуровневой функции похож обращению к сервису. И там, и там есть входные/выходные данные, и там, и там есть какая-то скрытая логика и наверняка работа с чтением/сохранением данных, и там, и там есть вероятность неудачи: функция выбросит исключение, сервис вернет ошибку. Значит, у нас появляется ветвление: что делать, если что-то пошло не так. Если же предполагаемая функция принципиально не допускает неудачи и ветвления не было бы, как Вы говорите, то она, скорее всего, воплощает чистую логику без работы с другими сервисами и хранилищами данных и в сервис ее выносить попросту нет смысла. В свою очередь это значит, что ваш пример справедлив только для плохой архитектуры, а сравнивать обычные монолиты и плохие микросервисы несколько несправедливо...
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
Согласен, зависит в том числе и от архитектора. Можно действительно наворотить дурацкую систему с неимоверным количеством сетевых взаимодействий, да на разных протоколах, да разных версий. Но кол-во связей и трудоемкость их реализации все равно не будут настолько безумными, я лишь прошу не впадать в крайности.
Общая шина данных используется не только в микросервисной архитектуре - во многих фреймворках реализован observer и я во многих проектах видел использование внутри монолита.
Речь о проблемах микросервисов, да? Но ведь дурацкие связи - это и для монолита актуально, просто там последствия менее очевидны. Пустить поток данных через десятки классов, потом на внутренние события завернуть, плюс глобальными флагами приправить, да еще триггеров в базе данных понаписать - наверняка ж видели такое. И это тоже ненормально.
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Какая асинхронность? Речь же была о реализации и документировании API. Один раз описываем и реализуем driving интерфейс при создании сервиса - какой-нибудь REST API для примера. Для сервисов, которые будут его использовать, потребуется клиент: либо действительно в каждом пишем свою копию, либо создаем общий и переиспользуем. Тут здорово могут помочь какие-нибудь protobuf/gRPC. Один раз описываешь структуры и получаешь и документацию, и болванку сервера, и клиенты под кучу языков. Никакого бойлерплейта. А составление исходного описания сопоставимо по затратам с описанием интерфейса какого-нибудь фасада в монолите. Ну и один раз накладные расходы на регистрацию нового API в балансировщике - копипаст нескольких строк + деплой.
Если же Вам принципиально не нравится, что тут появляются сетевые задержки, то да, это недостаток. Но тут я напомню, что микросервисы обычно появляются тогда, когда вертикальное масштабирование становится невозможным, поэтому возможности избежать сетевых запросов в этом вопросе попросту не существует. Микросервисы на микроскопических проектах без перспектив большого роста, надеюсь, тут не рассматриваем :)Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
Выше уже расписал - они повторяют те же внутренние интерфейсы модулей монолита на свой лад, так что много времени и сил не отнимают, особенно при использовании удобных инструментов.
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
Не об интерфейсах речь, я имел в виду два типа мониторинга: бизнес-метрики и технические. Бизнес-метрики в любом случае нужно реализовывать что в монолите, что в сервисах: нужно знать активность пользователей, отслеживать платежи, контролировать воронки активаций, проводить А/Б-тесты и т.д. Это не зависит от архитектуры проекта. А технические метрики типа доступности сервиса, кол-ва ошибок, дисконнектов, состояния железок и виртуалок и т.д. мало зависят от реализации софтины и обычно являются шаблонными: вот шаблон метрик по железке, вот по nginx/apache, вот по MySQL/PostgreSQL/noSQL. И тут особо нет разницы, условный HTTP API один на 1000 методов в монолите или их 10 по 100 методов для фронта плюс еще 100 по 10 методов для внутреннего взаимодействия. Даже не копипаста, а массовое применение один раз написанного шаблона.
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Т.к. тут вы выходили за рамки подтверждаемых утверждений - туше.
murkin-kot Автор
28.11.2022 13:02Видится мне так: клиенты ж не напрямую к сервисам подключаются, а через балансировщики, так что клиентская сессия останется живой
Ну вот, вы уже торгуетесь.
Смысл в том, что придраться к отдельным, оторванным от контекста словам можно, но целом в тексте был несколько другой посыл. Посыл такой - нужно разумно подходить к выбору решений. И если нам нужны клиентские сессии, то мы вынуждены будем думать в сторону разбиения монолита. Но не на 1000 микросервисов, а для начала на два - первичная обработка запроса и всё остальное. Далее возможны ещё варианты, но если два сервиса справятся (а это реально работает), то зачем нам 1000?
В свою очередь это значит, что ваш пример справедлив только для плохой архитектуры, а сравнивать обычные монолиты и плохие микросервисы несколько несправедливо...
Скорее ваши слова справедливы лишь для ваших предположений. Микросервис может просто оставить сообщение в очереди, на диске, хоть на 1000 лет. Как вы предлагаете сделать такой финт в монолите? Ответ - добавив в монолит функционал очередей. Теперь следите за руками - очередь, это отдельный сервис? Немного по другому - очередь, это отдельный компонент? И ещё вариант - в микросервисном решении с самого начала были очереди, а в монолите не было, отсюда вопрос - мы всё же что-то добавили?
Поэтому не стоит много слов тратить на рассказ о том, что "в принципе оно всё похоже". Да, в принципе мы вообще тут ерундой занимаемся и перегружаем лишними разговорами свои распределённые микросервисы. Но это только в принципе. А конкретика несколько другая.
Общая шина данных используется не только в микросервисной архитектуре - во многих фреймворках реализован observer и я во многих проектах видел использование внутри монолита.
Вы опять не обратили внимания на причину использования шины.
Но ведь дурацкие связи - это и для монолита актуально, просто там последствия менее очевидны
Последствия более очевидны - нет или есть накладные расходы. Результат - вместо, скажем, 10 000 серверов твиттер имеет 100 000.
Какая асинхронность?
Пример - очереди.
Речь же была о реализации и документировании API
Про документирование вы не говорили, а про реализацию - она стала асинхронной.
Если же Вам принципиально не нравится, что тут появляются сетевые задержки, то да, это недостаток
Там ещё в 10 раз больше серверов появляется.
так что много времени и сил не отнимают, особенно при использовании удобных инструментов.
Конечно, 10 против 100 тысяч.
нужно знать активность пользователей, отслеживать платежи, контролировать воронки активаций, проводить А/Б-тесты и т.д
Про это написано в разделе про аналитику.
доступности сервиса, кол-ва ошибок, дисконнектов, состояния железок и виртуалок и т.д. ... условный HTTP API один на 1000 методов в монолите
Монолит падает один раз. Микросервисы - 1000. Разница 1000 раз вам ничего не говорит? Условный HTTP API один только для монолита. А для микросервисов протокол один, а параметров - 1000 наборов. И обычно под мониторинг в каждом сервисе выделяют отдельный вход - вот ещё 1000 задачек.
Siddthartha
28.11.2022 11:15+1А я согласен с автором. Он говорит, вроде бы, об очевидном факте -- разнесение компонентов кода (монолита) в отдельные микросервисы добавляет в процесс сетевой слой со всеми его издержками и асинхронность, а изоляция этих сервисов в отдельные машины -- добавляет, как минимум, проблему согласованности конфигураций окружений.
Все это вместе порождает очень существенные трудности для отладки, мониторинга и внесения изменений. Трудности эти, условно говоря, действительно растут квадратично, если не более. Сложность растет "драматически") Собственно именно поэтому существуют целые инструменты для борьбы с этой сложностью.
Поэтому вывод -- бездумное наращивание их количества (т.е. принцип "новая задача -- новый микросервис" столь удобный для бизнеса) приводит к огромному перерасходу, который, до поры до времени, может окупаться, если речь идет о корпорациях, но в итоге неизбежно превращается в бегемота а-ля фейсбук, твиттер, вотсап и т.п.
Решение тоже очевидное -- предлагается приоритет на минимизацию количества сервисов в системе, и реинжениринг с этой целью по мере роста функционала (а не просто причесывание кодестайла, как зачастую бывает или поверхностный рефакторинг).
Ну а архитектор, который просто будет добавлять их годами (в т.ч. используя шину и прочие правильные ухищрения), но боясь тронуть процесс -- "зп идет, все работает, трогать страшно" -- в итоге может быть уволен именно так, как мы наблюдали. С треском.Именно в этом, мне кажется, суть претензий Маска к их техлидам.
Mikhail1972
27.11.2022 23:06Маск, твиттер , разработка)) По- моему слово разработка здесь лишнее. Максимум поддержка. То что разработали 100 спецов в силе поддерживать двое.
neenik
28.11.2022 00:40+4Вы пишите серьёзную статью, не не похоже, что она основана на полноценном опыте в каждом из направлений.
Для примера, типовой стек простого мониторинга (берём готовое ПО): prometheus, node_exporter, victoriametrics (3 микросервиса), grafana, БД grafana (распределённая, 3 микросервиса), prometheus alert manager, любая система реагирования на инциденты (1-2 микросервиса), шиппер логов, хранилище логов (эластик [3 микросервиса], loki).
Примерно 15 микросервисов в самом простом варианте и это я наверняка что-то забыл.
murkin-kot Автор
28.11.2022 13:03Это не "готовое ПО", это готовое решение. В других решениях цифры могут быть другими.
DarthVictor
28.11.2022 01:48+1И это тоже информационная безопасность, правда с немного другой начинкой - она фильтрует. То есть здесь нужны алгоритмы, умеющие отличать бота от человека. Да, это отдельная задача. И она привязана к логике приложения, потому что именно логика приложения нужна человеку, а боту нужно лишь рекламу повесить - в этом отличие. Только зачем же здесь городить тысячу сервисов? Здесь две составляющие - простая, которая решается стандартными средствами вроде анализа адресов и интервалов между запросами, и сложная, которая работает вместе с приложением и фильтрует, основываясь на его логике. Первая давно реализована и требует одну прокладку между пользователями и приложением. Вторая, как часть приложения, работает вместе с ним и могла бы вообще не создавать ни одного дополнительного сервиса. Но что бы вынести сложность в отдельный компонент согласимся на парочку дополнительных служб. Но не на тысячу.
Не хочу вас огорчать, но боты указанными вами способами не работают с середины нулевых. Бот не будет публиковать рекламу, он будет иногда лайкать нужные посты и в остальное время будет лайкать тоже, что и все остальные. Он будет подписываться не только на нужных персон, но и на просто популярных. Можете не сомневаться, что бот будет это делать с таймингами ничем не отличающимися от простого пользователя. Ну то есть каких-нибудь скрипт-киди вы вашим способом отловите, но не более того. Бот будет возможно даже постить периодически что-то интересное.
Современные сети ботов выявляются на основе кучи факторов таких как связанности пользователей внутри сети, на основе уникальности контента, на основе отношения к ним доказанно живых пользователей. Знаете, что у этих показателей общего? Они требуют анализа больших объемов информации. Уже на обслуживании одной инфраструктуры вам потребуется немало людей. А ещё куча специалистов, которые пишут алгоритмы для вычленения информации из текста, изображений и видео.
murkin-kot Автор
28.11.2022 12:15Да, в такой работе есть сложная часть, и я на неё указывал, правда без подробностей.
В плане "куча специалистов" - да, какое-то количество потребуется, но это один отдел, вместе со всеми нейросетями и прочим для рекламы. Одни и те же люди. Одно и то же железо. Железо мощное, но не запредельно (не тысячи серверов).
Разумеется, если ставить цель тренировать какую-нибудь GPT-4, тогда вам потребуется домик метров сто длинной для одних только серверов, но я сильно сомневаюсь в необходимости такой задачи в случае с твиттером.
Politura
28.11.2022 09:29+2Просто - внесли изменение в часть приложения
С раздутым монолитом над которым работают сотни разработчиков это нифига не просто. Для начала сама разработка. Сборка по любому чиху десятки минут это натурально боль, потом его перезапуск, чтоб потестить - тоже небыстро. Ну ок, потерпели, сделали свою задачу, теперь надо выложить пул-реквест на ревью. Однако десятки, а то и сотни тысяч юнит тестов могут выполняться часами. И все эти часы пул-реквест, уже заапрувленный, нельзя будет замержить, однако другие, уже проверенные, пул-реквесты мержиться-то будут. И пока до твоего дойдет очередь есть нормальный шанс, что автомерж не пройдет и надо менять пул-реквест - мержиться вручную с аутуальной версией. Так простейшие изменения могут отнимать кучу времени на задачи, которые обычно занимают минуты. И это лишь одна из целого ряда причин, почему разработчики дозревают до того, чтоб распилить некий монолит на части. Одна из. И ни одной из них, ни одной реальной причины, почему люди принимают решение перейти от монолита к микросервисам вы в своем разделе "Самая главная правда", увы, так и не рассмотрели.
Если приложение монолитное, то перезапустить придётся всё приложение целиком. Это означает, что миллионы пользователей Твиттера начнут страдать.Они перезапускают один мкросервис, при этом его работу никто не выполняет
Эта задача решена уже миллион лет назад, с появлением первых 24/7 систем, решается одинаково, что для монолита, что для микросервисов, разница лишь в том, что при изменениях в структуре баз данных, с монолитом геморроя больше, как и шансов на ошибку, ибо данные у них как правило реляционные.
Решается очень просто - одновременно работают и старая и новая версии, новые сессии открываются на новых версиях серверов, старые работают до тех пор пока не будут завершены все старые сессии.
Когда есть сотня микросервисов, то взаимодействие между ними требует налаживания десяти тысяч связей (пропорционально квадрату от количества сервисов)
Простите, а у вас в монолите тоже каждый класс знает о всех остальных классах и взаимодействует с ними? Если нет, так почему вы от сервисов подобное ждете?
Идеал микросервисной архитектуры это когда сервисы настолько не связанны, что вообще друг с другом никак не разговаривают и дел не имеют. Обычно при проектировании стремятся к идеалу, отвязать сервисы друг от друга, хотя конечно идеал не достижим и всегда есть какие-то высоконагруженные сервисы которые используются большим количеством других сервисов, или даже почти всеми, как какая-нибудь аутентификация/авторизация.
murkin-kot Автор
28.11.2022 12:33С раздутым монолитом над которым работают сотни разработчиков это нифига не просто.
Я не говорил, что абсолютно всё следует держать в одном монолите. Этого никогда не требовалось, например в мире Java. Там уже больше 20 лет существует концепция сервера приложений, где условный единственный монолит организации давно разделён на отдельные приложения. Результат - два-три десятка приложений слабо зависимы. Но работают все на одном сервере. Сам сервер, разумеется, даёт нам кластеризацию и прочие способы масштабирования, но приложения об этом не задумываются (ну почти). Всё это - на основе опыта с приложением в организации с десятками миллионов клиентов.
В итоге - в такой ситуации нет ничего подобного описанному вами. Соответственно, организация, работавшая с серверами приложений, переходит на микросервисы уж точно не из-за того, о чём говорите вы.
одновременно работают и старая и новая версии, новые сессии открываются на новых версиях серверов, старые работают до тех пор пока не будут завершены все старые сессии
Правильно, но вы уже разбили монолит. Это означает, что претензии у вас не ко мне, а к вашему собственному пониманию.
Простите, а у вас в монолите тоже каждый класс знает о всех остальных классах и взаимодействует с ними?
Каждый класс "знает" о других. То есть при необходимости может и взаимодействовать. Лёгкость организации взаимодействия ведёт к повышению количества связей. Хотя да, можно не учитывать мои слова из текста о сильной зависимости количества связей от умений архитектора.
Идеал микросервисной архитектуры это когда сервисы настолько не связанны, что вообще друг с другом никак не разговаривают и дел не имеют
Это не идеал микросервисной архитектуры, это скорее ваши фантазии. В любой книжке по архитектуре вам скажут, что связность нужно сокращать, но ни в одной из них не скажут, что связность нужно уменьшить до нуля.
Politura
28.11.2022 19:43+1Соответственно, организация, работавшая с серверами приложений, переходит на микросервисы уж точно не из-за того, о чём говорите вы.
Это то, с чем я столкнулся лично, что на предыдущем месте работы, что на текущем. И это только одна из проблем, толкающая на распиливание прекрасного монолита, которым еще несколько лет назад люди гордились. Монолиты имеют тенденцию расти.
Правильно, но вы уже разбили монолит. Это означает, что претензии у вас не ко мне, а к вашему собственному пониманию.
Нет, не разбил. Разные сервера это разные инстансы одного и того-же сервиса (монолит это, или микросервис - не важно), это основа хай авайлабилити и горизонтального масштабирования. При переходе на новую версию одна часть будет старые версии серверов, другая часть - новые, и первая часть будет постепенно уменьшаться.
Каждый класс "знает" о других. То есть при необходимости может и взаимодействовать.
Ага, однако у конструкторов (или через что там ваш DI работает) ваших классов бизнес-логики от силы с десяток параметров, очень редко когда больше, вот и вся связность монолитов. Которую, тем не менее, с помощью микросервисов предлагаются уменьшать. Так что ни о какой квадратичной зависимости речи не идет.
Это не идеал микросервисной архитектуры, это скорее ваши фантазии. В любой книжке по архитектуре вам скажут, что связность нужно сокращать, но ни в одной из них не скажут, что связность нужно уменьшить до нуля.
Бога ради, пусть будут мои фантазии, однако в хороших книжках вам скажут, что если останется значительная связность, то это будет не микросервисная архитектура, а распределенный монолит и что это наихудшее архитектурное решение, которое можно предлопожить. Так что ни о какой квадратичной зависимости микросервисов речи не идет.
murkin-kot Автор
28.11.2022 20:36Нет, не разбил. Разные сервера это разные инстансы одного и того-же сервиса
Разбили, но не заметили. Кодовое слово - балансер.
Ага, однако у конструкторов (или через что там ваш DI работает) ваших классов бизнес-логики от силы с десяток параметров, очень редко когда больше, вот и вся связность монолитов
Компоненты приложения взаимодействуют через вызов методов, а не конструкторов. Методов может быть тысяча (гуглим god's class)
в хороших книжках вам скажут, что если останется значительная связность, то это будет не микросервисная архитектура, а распределенный монолит и что это наихудшее архитектурное решение, которое можно предлопожить. Так что ни о какой квадратичной зависимости микросервисов речи не идет.
Пример - слоёный сервис. И каждая веб-страница (через серверную часть) дёргает все возможности логики. Потому что так види художник (и на каждой странице хочет предложить пользователю). И одновременно уведомляет остальные страницы об изменениях через ненаблюдаемую им лично реактивность.
Квадратичность достижима легко, ну а неверие в силу "настоящих художников" проходит после личного знакомства с их творчеством.
Politura
28.11.2022 23:02+1Разбили, но не заметили. Кодовое слово - балансер.
А у вас значит балансеров нет, всегда один инстанс? Просто интересно. Впрочем, даже если и так, по вашей логике вы свой монолит все равно разбили, как минимум, на веб-сервер и сам монолит.
Компоненты приложения взаимодействуют через вызов методов, а не конструкторов.
Чтобы вызвать чей-то метод нужен инстанс класса. А инициализацией инстансов и добавлением их в инстансы классов бизнес логики занимается dependency injection. Через конструктор, или через поля, это уже дело десятое, однако именно этим набором инстансов можно оценить количество связей объектов бизнес-логики. И даже у монолитов не будет квадратичных прямых зависимостей.
Квадратичность достижима легко, ну а неверие в силу "настоящих художников"
Если где-то кто-то сумел сделать нечто непонятное и назвал свое творение микросервисной архитектурой, это не значит что он выбрал правильное название и следует ставить его в пример. Скорее всего у вашего художника получился распределённый монолит, или просто какой-то бред.
sgjurano
Мне кажется, что у вас немного некорректное представление о том, как устроена разработка в компаниях типа твиттера - там сотни команд инженеров, на каждой из которых лежит частичка общей ответственности за то, чтобы "сделать хорошо", а сами команды стремятся к тому, чтобы действовать максимально независимо друг от друга - именно это обеспечивает необходимый темп разработки.
Поэтому и стали популярными такие системы из сотен и тысяч микросервисов - они обеспечивают адекватное время замены одного маленького кусочка в случае необходимости, и возможность его условно независимой, от остальной системы, разработки. Это просто более высокоуровневый аналог ООП, если хотите.
Нет такого человека, который разработал бы текущую архитектуру твиттера с нуля. Это эволюционно развившаяся система, платить за это приходится всем тем, что является преимуществами консолидированной разработки - согласованной архитектурой, предсказуемой производительностью, понятностью системы в целом, стоимостью её эксплуатации.
Если что-то в получившейся системе, состоящей в основном из связей, не устраивает, то переделывают конкретный кусок, минимизируя область поражения, а не всё целиком - там тысячи человеко-лет закопаны, это просто невозможно без остановки развития.
DikSoft
Никто не понимает, как это всё совместно работает
Есть куча кода, про который толком не понять что реально именно он делает, и что сломается если его "немного переписать"
Выбросить всё целиком уже нельзя, ибо вложено очень много и как-то, но работает.
Производительность и отзывчивость стала непредсказуемой, и кроме "добавить больше серверов" ничего принципиально не помогает. И то не всегда. Где-то есть узкое место. Но где - непонятно.
А не возврат ли это к проблеме легаси, за который жутко ругали монолиты, но уже на новом витке и с ещё худшими последствиями?
sgjurano
Прелесть в том, что это и не требуется.
Как раз в каждом маленьком уголочке такие знания обычно есть, если не увольнять одним махом половину сотрудников, то знания вполне себе восстановимы, даже при отсутствии внятной документации.
Для решения проблем с производительностью применяются специальные инструменты для распределённого трейсинга и развитая система сбора метрик.
Монолиты чем плохи?
- Тяжёлый сервис кушает много железа
- В который много людей коммитит, значит постоянно есть конфликты
- Совокупная сложность очень большая
- Обычно у монолитов невысокая скорость релиза фич
А что микросервисы?
- Много маленьких кусочков кушают в сумме +- столько же ресурсов, скорее больше, чем меньше
- Коммиттеры распределены по кусочкам
- Совокупная сложность выше, но в каждом конкретном месте всегда меньше
- Скорость релизов очень высокая
То есть микросервисная архитектура - это просто подход, позволяющий максимально быстро пилить фичи.
DikSoft
Не, я как и автор статьи тоже понимаю плюсы микросервисов. Речь о том, что ими нынче пытаются закрывать вообще любые проблемы. Доводя до абсурда. При активной поддержке мифа о "золотой пуле" манагерами, да и разрабами, что греха таить, тоже.
Вот в этом месте и заложена причина. "Нам, разработчикам, так удобнее и легче", а сложный способ, который даст нормальный результат, теперь даже не рассматривается.
PS У монолитов тоже есть плюсы, как ни странно. Меньше дурной и непредсказуемой асинхронности, например.
sgjurano
Таков путь, что тут ещё скажешь :)
DikSoft
Так если он приводит к системам, поддержка которых сжирает всё больше и больше, пока не становится неподъемной, может лучше было не "пилить постоянно новые фичи по аджайлу", изначально не идти путём "фигак-фигак и продакшн", не отдаваться тупо моде, а использовать плюсы всех подходов, вместо выбранного одного?
sgjurano
Лучше так и делать конечно, лично я в работе стараюсь проводить линии раздела сервисов там, где это осмысленно с точки зрения data oriented подхода, но это далеко не всегда очевидно в момент принятия решения.
Ну и, да, квалификации для защиты таких решений требуется больше, чем при использовании общих практик, а ненаступившие последствия затем практически невозможно ставить себе в заслугу на ревью :)
Kanut
Можно конечно. И куча фирм так и делает. Только далеко не везде это работает. Например потому что если медленно пилишь новые фичи, то в отдельных нишах тебя обходят конкуренты которые делают это быстро.
murkin-kot Автор
Когда все независимы от других, получаем повышенную сложность движения к общей цели. Простейшая иллюстрация - представим, что на войне каждый солдат будет думать за генералов. Что тогда будет? Уж точно не "необходимый темп разработки".
Не совсем так. Скорее даже наоборот - сначала растолстели команды на монолитах, обросли наследственностью и притёрлись к организационным особенностям, что привело к сокращению их эффективности. Потом эту проблему идентифицировали и решили, что виноват инструмент - монолит. Ну и начались микросервисы, которые действительно в небольшом объёме позволяют быстро вносить изменения (нет традиционных для монолитов возражений, плюс ещё не так сильно растолстели).
Но проблема была не в монолите, а в особенностях организации разработки. И отчасти она решается эволюционно, вспомним тот же git вместо svn. Но качественно, революционным путём, эту проблему никто решать не собирается, потому что за такой постановкой стоит большой риск. Это означает, что и микросервисы никуда не денутся, им тоже придётся с этой проблемой столкнуться. И уже сталкиваются.
В целом опять как всегда - не инструмент виноват, а пользователь.
Это опять возвращает нас к проблеме множества генералов на поле боя.
Это применимо к любому варианту, проблема только в различии способов доставки изменений. Если доставку архитектурно сделать эффективной, то и монолит вполне позволит "минимизировать область поражения".