Комментарии 75
Как по мне, автор не объективен, а просто топит за схему, которая лично ему больше нравится. В реальности микросервисы не есть шаг вперёд по сравнению с модульным монолитом. Да, эволюционно они появились позже монолитов, но тем не менее, эта архитектура имеет рамки применения, где у неё есть преимущества:
Части вашего приложения разрабатываются независимыми командами
Нагрузка на разные компоненты вашего приложения имеет такой характер, что вы при его масштабировании получаете бОльшую выгоду от разнесения компонент на разные хосты, чем просто от увеличения количества экземпляров.
Пожалуй, это всё. В остальном модульный монолит либо имеет паритет с микросервисами
Возможность независимо разрабатывать компоненты приложения есть и там, и там
Грамотное проектирование модульного монолита по сложности примерно такое же, как и грамотное проектирование микросервисов
Возможность деплоить только изменённые компоненты у микросервисов нивелируется возможностью использовать слоты деплоя у монолита
...либо имеет преимущества, например
Существенно более высокую производительность приложения, т.к. вместо общения через хттп юзаются обычные внутренние вызовы
Упрощаются и ускоряются интеграционные тесты
В общем, как мне кажется, в большинстве случаев практичнее иметь модульный монолит, нежели набор микросервисов.
Да, эволюционно они появились позже монолитов
Для меня это спорный вопрос. Сами термины вполне возможно что появились одновременно, когда люди начали противопоставлять монолиты и микросервисы. Но какой из подходов более новый и прогрессивный... Прообразы микросервисной архитектуры на мой взгляд были и раньше.
Когда-то давно я работал в медицинском центре. Там для каждого подразделения, под каждую задачу была своя небольшая информационная система. Делались они на чём угодно - FoxPro, Delphi + Firebird, Access, C# + MS SQL, Java. Сами по себе эти системы были вполне норм, писались умными людьми и решали свою задачу. Но когда их количество достигло критической массы, то стали возникать вопросы: 1) а почему отчеты, построенные в разных системах не бьются между собой? 2) как вообще собрать эти отчеты без ручной работы? 3) можно ли как-то уменьшить дублирование работы операторов, потому что часто они вносят в разные системы пересекающиеся данные? 4) можно ли как-то в одной системе посмотреть данные из другой системы, чтобы не устанавливать себе десятки приложений?
Нужно было всё это как-то интегрировать. И было два пути:
1) Довести всё это до труЪ микросервисной архитектуры. Прикрутить туда интеграционную шину, ETL-процедуры и т.д., чтобы данные гонялись из одной системы в другую.
2) Разработать единую модель данных для всего предприятия и сделать одну монолитную систему.
Естественно, сначала мы попробовали пойти первым путем, это более логично, чем всё переписать, но быстро надсадились, потому что некоторые ИС использовались просто для распечатки документов, и разработчики не запаривались даже с первичными и внешними ключами. Плюс в принципе тянуть данные из FoxPro - тот ещё гемор. Причём сложно винить разработчиков этих отдельных ИС, ровно по заветам микросервисной архитектуры они выбрали удобные для себя технологии и не тратили время на согласование своей схемы данных со схемами данных других ИС, что позволяло им очень быстро выпускать свои системы в прод, независимо разворачивать их - короче пользоваться основными преимуществами микросервисной архитектуры, хотя тогда этого термина даже и не было.
В итоге мы даже сделали единое хранилище данных, которое наполнялось лютейшими ETL-скриптами, накрутили OLAP-кубы и одну частную задачу построения отчетов решили.
Но потом всё-таки решили, что, нет, нужна единая каноническая модель данных для всего предприятия и одно монолитное приложение. Естественно это существенно упростило и работу ИТ подразделения, и жизнь пользователей, и на порядок увеличило возможности по использованию данных.
Какой из этих двух подходов более правильный и прогрессивный, ну, хз. Конкретно в этом случае для меня микросервисная архитектура - это тот же зоопарк ИС на максималках, который только усугубил бы проблемы. А модульный монолит с единой канонической моделью данных для меня выглядит куда более осмысленным и целостным решением.
Я согласен насчет минусов монолита:
Сложно распределить части приложения между независимыми командами. Хотя, блин, сейчас задумался. А в чём сложность? Стартовый модуль, точка входа в приложение должна быть у всех одна. Но для работы им не нужны все модули. Например, если они разрабатывают модуль для регистратуры поликлиники, то им совершенно не нужен модуль для стационара или аптеки. Достаточно чтобы в приложении была возможность запускать только доступные модули и отключать ненужные.
Сложность масштабирования. Во-первых, на сколько часто эта проблема действительно есть? Во-вторых, разве не проще её решить на уровне СУБД? В том же примере с медицинским центром у нас было несколько распределенных подразделений. В каждом из них просто был развернут свой экземпляр СУБД и данные синхронизировались.
В общем для меня единственный осмысленный сценарий использования микросервисов - это только если каждый микросервис это тупо отдельное приложение, которое практически не пересекается с другими микросервисами. Если у микросервисов разные заказчики, которые планируют использовать данные только из своего микросервиса.
А что если в какой-то момент всё-таки понадобятся целостные данные? Наверное это решится добавлением ещё кучки микросервисов в виде DWH, ETL, ... А что если схема данных в микросервисах на столько разная, что данные фиг соберешь? Это решается с помощью DDD, но тогда это уже не труЪ микросервисы, потому что каждой команде придётся сверяться с единой схемой данных и так быстро фигачить релизы в прод уже не получится.
Короче, я потерял последние доводы в пользу микросервисов. Я реально не понимаю зачем они. Ок, последний довод - это отсутствие единого архитектора на проекте. Хотя, блин, и микросервисная архитектура без архитектора вряд ли обречена на успех. Но наверное этот архитектор должен быть очень ленивый или занятой, чтобы запариваться с единой моделью данных, выбором единых технологий разработки, единой СУБД и т.д. Типа, вот, вам микросервисная архитектура, фигачьте в своих сервисах что хотите, мне пофиг. Ааа, пожалуйста, убедите меня кто-нибудь что это не так и микросервисная архитектура реально решает больше проблем, чем добавляет.
Возможность деплоить только изменённые компоненты у микросервисов нивелируется возможностью использовать слоты деплоя у монолита
Так, а вот можно поподробнее про слоты деплоя? Впервые слышу такой термин.
Ещё, может быть, вы слышали "зелёная" и "синяя" среда, или как-то так. Это подход, когда у вас есть две (или больше) сред развёртывания с одинаковой конфигурацией, из которых одна активная в продакшене, остальные неактивны. Вы деплоите в неактивную среду, при этом процесс деплоя никак не влияет на продакшен, после этого единомоментно переключаетесь на новую среду, с новой версией вашего приложения. Если что-то пошло не так, вы точно так же можете единомоментно переключиться на предыдущую, исправную версию. Такой режим деплоя поддерживается облаками, Azure, AWS и т.д.
А что случается с базой, если там нужны какие то миграции, менятся схема и т.п.?
Там где база меняется - куда более глубокое обновление. Если мы представим какой-то большой проект с большой по объему и количеству хостов базой, то любое изменение структуры базы это не простой процесс
поэтому правила хорошего тона на больших проектах нанимать инженера который проектирует базу и разрабатывает схемы расширения. И если он проектирует так, что раз в год туда что-то добавляют нарушая фрагментацию…ну такой инженер и грустно будет всем на каждом обновлении, возможно даже с ночевкой в офисе
По мне - ужасная статья и перевод. Даже ниосилил, извините. По переводу: какие-то несогласованные части в предложениях (автоматизированный перевод?), частое использование цитат (выделить очень умные мысли?). По статье всё ещё хуже - её можно представить фабулой: давайте представим, что микросервисы лучше монолитов; теперь давайте из этих предпосылок докажем, что микросервисы лучше монолитов. Очевидно, что взяв за основу спорное утверждение, в результате получим тоже что-то спорное.
-
По теме сравнения микросервисов и монолитов:
Обычно читаю про рассуждения о параллельности разработки, наращивании производительности и куче других (вероятно, полезных) вещей.
Что обычно остаётся за обсуждением: если ваша система работает на внешнем объекте без доступа к интернету, то микросервисы (как бы) применять можно, только работать это будет недолго. И все микросервисы "превращаются в тыкву". И такие "затыки" могут быть не только с интернетом. Вместо этого у человечка:
Лично для меня абсолютно логично утверждение, что многие организации и люди, решительно отвергающие микросервисы, никогда не оказывались в успешных условиях
Хотя, наверное, доля правды есть: если работать в условном Гугле, то ты будешь работать с микросервисами и, возможно, ты окажешься в успешных условиях (что бы это ни было). Это такой сарказм.
Пожалуйста, поясните, как отсутствие интернета мешает работать микросервисам?
Всё же уточнюсь по ограничениям:
на внешнем объекте без доступа к интернету
-
Вся та информация, которую собрал по процессу поддержки микросервисов сводилась к тому, что мы много чего логируем, много чего мониторим. И всё это делаем в (почти) реальном времени. И если есть какие-то проблемы: требуется что-то перезапустить!!!, где-то подправить код - то включается "счётчик" и в течение минут/часов это всё исправляется, перезапускается, или на крайний случай откатывается к предыдущему варианту.
И теперь представьте: у вас стоит система на внешнем объекте. На объекте есть инженеры, и они могут тупо-глупо что-то перезапустить (после общения по телефону), логи выслать на почту или сфоткать скрин. И это всё.
Как результат: логов нет (инженеры на объекте сами читать логи не будут :), передавать их вам через почту: при явных проблемах - да, постоянно - нет), мониторинг инженеры могут смотреть, но очень высокоуровнево. Заменить ПО (т.е. вы отсылаете дистрибутивы или пакеты инженерам через почту/внешние хранилище) через инженеров объекта вы не захотите (ну, если вы не камикадзе, так как все шишки полетят в вас). Откатиться - ну технически это можно, но тоже "жим-жим". Из нормальных решений это перезапуск и замена оборудования из ЗИП (это если ЗИП настроится сам или по простой инструкции).
С моей точки зрения, микросервисная архитектура при этом
работать это будет недолго
В общем, до первого "глючка"/сбоя.
Прим.: физически до объекта ехать/лететь - это дни/недели.
-
Может, Вы расскажете Свой взгляд на работу микросервисов на внешнем объекте без доступа к интернету? Здравые предложения приветствуются.
В описанной вами ситуации я не вижу разницы с монолитом - там будут примерно те же трудности.
За исключением того, что в случае микросервисов, если сбоит не сильно критичный сервис, то можно его отключить и иметь больше времени на фикс, тест фикса и запуск обновления.
Кроме того, перед запуском релиза обычно все таки делается достаточно масштабное тестирование, да и резервная система с предыдущим стабильным релизом тоже не помешает.
Также я сомневаюсь в реальности серьезных трудностей от сценария, который вы описали - при любой реализации системы.
Все эти мониторинги микросервисов, перезапуски, манипуляции выделенными ресурсами и прочее - это последствия их запуска в облаке с постоянно изменяющейся нагрузкой. На изолированном объекте нагрузка тоже изолированная, а значит всё шаманство будет требоваться только во время пусконаладки. Разве что перезапустить что-нибудь упавшее понадобится - но, во-первых, нормальное ПО так просто не падает, а во-вторых, перезапуск можно и автоматический настроить.
Другое дело, возможность всего этого тюнинга в реальном времени - одно из преимущество микросервисов. Так что в условиях изолированного объекте, где местные ничего не умеют, микросервисы теряют свои преимущества. Но это не значит что они не работают, они всего лишь нафиг не нужны.
Тут тонкость в том, что
микросервисы теряют свои преимущества
и приобретают пачку минусов:
сетевые подключения, которых можно было бы избежать в условном "монолите", здесь могут стать точкой отказа. Да, можно автоматически перезапуститься, но надёжность от этого не возрастёт;
то, что могло запускаться на одном сервере, потребует 5+ серверов (а если с логами и другими плюшками, то и 10 - 20). Вряд ли это положительно скажется на устойчивости.
Плюс у нас всё получилось несколько глубже: начинают меняться используемые решения. Например, мы в своё время отказались от MS SqlServer: после пары ошибок как-то стало грустно. Всё это было несложно, но наш спец сказал, что одного скриншота с ошибкой маловато и нужно посмотреть ещё в пару-тройку мест; далее предложение съездить в командировку :) и посмотреть лично особого энтузиазма не встретило; ошибку купировали "по явным признакам" и сползли с этой темы. С другими "не лёгкими" технологиями - вот всё аналогично.
-
Согласен с комментирующими, что можно написать так, что оно будет работать и в изоляции. Опять же:
нормальное ПО так просто не падает
Однако качество ПО частенько снижается до необходимо-допустимого уровня (ну так бывает, опять же сроки давят). И тут получается, что:
либо всё пишешь с расчётом на возможный доступ для мониторинга и обслуживания. И вот тут микросервисы хорошо заходят. Опять же, если тебе не требуется обслуживание, это не значит, что используемому тобой серверу это тоже не нужно;
либо начинаешь "дуть на воду" и делать кучу защит от всего. В случае условного "монолита" это вполне нормально делается. В случае же с микросервисами, подозреваю, это будет сильно "овер-...".
-
В общем, по-моему, каждая архитектура приспособлена под свои условия. Забивать гвозди микроскопом или стрелять из пушки по воробьям - занятия эти такие ... ничего хорошего.
Тут я хочу по поводу сети добавить один нюанс. Почему-то многие кто любят микросервисы забывают о том что сетевая нагрузка (не утилизация полосы, а именно CPU) стремится к нулю. Но это далеко от правды. Так что помимо точки отказа, там еще дополнительная нагрузка на CPU трафиком, который как вы правильно заметили при монолите сводится к нулю.
и приобретают пачку минусов:
Эти минусы у микросервисов есть изначально, они не приобретаются дополнительно.
Вот не понимаю откуда берется такой рост серверов? Сервисы запускают в контейнерах - это по сути просто отдельные процессы и все. Вместо 1 сервера будет 2, от силы 3 - если прямо сильно все обложить мониторингом. Понятно, что расходы вырастают, но не на порядок.
Вы не на ту цифру смотрите! Нужно смотреть на пропорции: если сервисы запускаются в контейнерах (и это отдельные процессы) и у вас от силы 3 сервера, то в "монолитном" приложении у вас (очень вероятно) будет один сервер, загруженный процентов на 20 - 30.
Про возрастание расходов. Представьте:
На одной чаше весов: сложить/умножить два числа (например, посчитать стоимость покупки), сравнить пару чисел (например, проверить что пользователь аутентифицировался, есть авторизация на операции). Все числа давно лежат в памяти (+кэш). Далее данные в стэк + вызов функции.
На другой чаше весов: числа загнать в строку (под которую нужно дополнительно выделять память) потом строку превратить в число - операции на 2+ порядка (десятичных порядка!) и более затратные, чем простые операции (например, сложение) с числами в регистрах процессора (да и в памяти тоже). Полученные строки загнать в json (+ выделение памяти) и, самое главное, разбор этого json-а (вообще отжирает ресурсы). Почему про память упоминаю: при работе со строками требуемый размер заранее неизвестен (в отличие от бинарных чисел и структур) и работа со строками превращается в постоянное выделение/перевыделение+перекопирование блоков памяти. Например, иногда к существующему блоку 5 кБайт памяти можно добавить ещё 5 кБайт (строки очень любят непрерывность в блоке памяти). А иногда и нет: тогда приходится выделять 10 кБайт, туда всё копировать, изначальные 5 кБайт удалять. Ещё сеть: это вообще нагрузка из нагрузок: пакеты сформируй, заголовками обложи, в буфер положи - выдай в другой буфер (это если в пределах одного сервера; и считаем что соединения давно установлены). Пакет принялся - отправь ответ-подтверждение (tcp/ip - хе-хе-хе - он такой). Проконтролируй чек-суммы и порядок пакетов. Бывает и перезапроси пакет (например, приёмная сторона пока не может принять данные - и начинается цирк - это всё на одном сервере). И всё это память-память-память. Надеюсь, очевидно, что когда пакетики уходят в физическую сеть и принимаются на другой стороне - это ещё дополнительный ужас-ужас-капец? +Логирование на физическое устройство (так как памяти на логи не хватит) - это ещё нужно столько же расписать, +Мониторинг (и ещё расписать столько же).
-
Есть ощущение, что это разные по вычислительной мощности задачи? Разницы в один порядок достаточно для сравнения? Да тут просто перечисление производимых операций отличается на порядок!
В итоге это всё выливается в миллиарды лишних инструкций. Количество железа растёт, микро сервисов становится больше и проект превращается в спагетти архитектуру. Где уже не понятно, что от чего зависит.
Все так, но в реальной жизни бизнес-логика типичного метода сервиса - это не два числа сложить, а гораздо сложнее. Это один или несколько непростых запросов к БД, результат которых может занимать десятки-сотни килобайт, потом маппинг этого всего к нужному виду и на фоне всех этих операций сериализация/десериализация результата - это самое большее +1% работы, а к серверной БД обращаются также по сети, поэтому передача пакетов все равно будет. В общем нагрузка от удаленного вызова по сравнению с вызовом внутренней функции - это не на порядок тяжелее, а всего лишь на несколько процентов.
Удалённый вызов через сеть, не может быть физически медленнее на несколько процентов. Как минимум на порядок. Читать данные из озу или из озу удалённого ПК по сети? А если нужно сделать несколько чтений по сети к разным микросервисам может быть задержка и больше. Я без обвинений. Но вот с такими взглядами и пишут микро сервисы, не зная базы. Типа всё быстро на пару процентов. Но физике всё равно на убеждение или не знание.
Я чисто физически не понимаю, как вместо вызова метода, сериализация - передача по сети - десериализация, может быть эффективна. Так еще если возникнут проблему, нужно либо обращаться к другой команде либо смотреть не типичный для тебя код. Плюс, допустим у вас есть состояние в приложении, нужно как-то синхронизировать это состояние между несколькими микросервисами (или делать запрос каждый раз для получения этого состояния). Я вижу просто работу ради работы. Да можно писать на разных языках в одном проекте, но серьезно, оно вам надо? Больше всего раздражает, что теперь на любом собеседовании тебя спросят про микросервисы и ты с умным лицом должен рассказать об их плюсах.
Сдаётся мне, что автор троллит и изначально повышает концентрацию го*на и вентиляторов
Расскажу свою историю
Был проект который с самого начала писался мной, состоял он из *ярда микросервисов. Притом были микросервисы которые писал я, были те которые взяты с других проектов или сделаны другими людьми. Естественно, проект не обошло все то что любят сисадмины: много всяких разных виртуалок, кучу систем мониторинга каждого пука. Все выглядело как рождественская елка которую наряжали годами, там у тебя API с WS, там ZeroMQ...там еще что-то. И скажу честно, на тот момент я верил что система идеальна.
Но идеального нет и мир был прекрасен до того момента пока не появилась задача ускорить работу. И тут стоит отметить что сама задача имела четкое финансовое обоснование – быстрее, значит больше денег приносит.
Я начал поиски как же ускорить и то что лежало на поверхности – различные протоколы взаимодействия микросервисов. Во время теста зоопарка протоколов включая IPC и UDP даже дошел до варианта убить де/сериализацию с помощью байтового представления. Т.е пакет кидал прям в байтах чтобы избежать трату времени на разбор. Но результаты оказались скромные, если мне не изменяет память была 1мс, стало 0.4мс. Конечно, кому-то покажется что это результат-результат, но на самом деле это как раз ускорение на базе UDP протокола где использовался бинар и требовалось очень много переписывать. Т.е 0.6мс не стоят этого.
В итоге пришло все к думам на тему монолита. Мозг не хотел принимать эту схему, самые частые мысли – а если ошибка в коде, там же все рухнет. И привычка дело такое, что на первой стадии разработки мысли эти не покидали. Тогда мозг не хотел понимать, что если в одном из микросервисов ошибка – все и так не будет корректно работать
Год я переписывал это чудо. Помню что лишь через 2-3 месяца от начала разработки до меня стало доезжать насколько микросервисы – пережиток прошлого и некий рекламный булшит. Отчетливо помню, как при разработке отыгрывали старые привычки: "о тут надо же сделать мониторинг...а потом такой – а зачем тут мониторинг, оно и так имеет только два статуса: либо работает, либо все рухнуло сразу вместе с приложением"
И когда все было закончено и запущено в прод тогда-то и наступило осознание, что надо было делать это раньше. Не говорю о скорости взаимодействия, которое теперь измеряется в тысячах наносекунд, – все таки это специфическая задача конкретного проекта. Говорю о том что подход к коду стал "ответственнее", ушло кучу мусора в том числе различных мониторингов, виртуалок и тд...освободились ресурсы. Вот к примеру про ресурсы, с 8 серверов которые были загружены под 70% теперь все живет на одном. А эти 7 перепрофилировали на резерв и различные другие функции. Что освободится такое количество ресурсов даже в сказке представить никто не мог.
В заключение хочу сказать вот что. Безусловно, микросервисная архитектура имеет право на жизнь, где-то она действительно необходима (хотя после моего опыта придумать у меня не получается). Но если перевести в понятную математику, то получится что запустить условно приложение на микросервисах понадобится наверное на 20% времени меньше и это плюс...более быстрый запуск так сказать, но обслуживание потом будет тратить это время в геометрической прогрессии с увеличением самого проекта. И хорошо если это время чье-то чужое или оплачиваемое, а не ваше личное.
В своё время примеривался к идее микросервисов, обсматривал как в соседних компаниях сделано, считал оверхед. Получил примерный общий вывод:
Потребляемые мощности микросервисной архитектуры и монолитной относятся примерно как 10:1 - 20:1 (в зависимости от логирования, мониторинга и др.).
Как результат, микросервисы имеют смысл (в разрезе вычислительной мощности) если всё это будет нагружать 20+ серверов. Возможно это временная ситуация (на пиковых нагрузках), или с заделом на будущее. Понятно, что "сервер" - это расплывчатое понятие (у кого-то они слабее, у кого-то мощнее), но для оценки это подходит: граница в 20 шт. - она примерно там и остаётся.
Если же микросервисы стабильно потребляют мощности меньше 20 серверов, то лучше делать не-микросервисы. Прим.: не очень люблю слово "монолит", т.к. вариантов реализации там много и не всё совсем уж монолитное.
И в обратную сторону: если сильно не хватает мощности одного сервера, то пишем (переписываем под ...) микросервисы и сразу обкладываемся вычислительными мощностями на оверхед.
Тут я хотел бы отметить, и думаю вы тоже это понимаете если есть условный монолит который утилизирует вычислительную мощность 1 условного сервера, то при появлении запроса на расширение этой мощности – доработать монолит для "клонирования" не является сверхзадачей. Это субъективно мое мнение.
Вы довольно четко попали в мою математику по соотношению 1:10 (у меня 1:8 получилось). Если представить гипотетическую ситуацию что некий проект начат с микросервисов и растет как на грибах...допустим, он вырос до 100 серверов. Рано или поздно кто-то появится и займется оптимизацией. Оптимизировать такое – дорого (я даже не говорю о том чтобы переписать все на монолит, а просто уменьшить количество микросервисов для увеличения утилизации ресурсов) и при всем при этом это надо все поддерживать чтобы работало. Ну и конечно не забываем о самом оборудовании, чем больше количество – тем больше отказов
А если мы возьмем обратную ситуацию, написан изначально монолит и хочется зачем-то перевести его на микросервис – это довольно просто будет, считай дробишь одно на какие-то части и налаживаешь связку. Хотя я не особо представляю такой кейс.
Пока честно, я пытаюсь представить различные кейсы в голове при каких условиях надо начинать проект с микросервисов и не могу их придумать. Может кто-то придет и расскажет свое видение, с удовольствием почитаю
Интересно было бы увидеть расчеты. С учетом того, что сервисы запускаются в контейнерах и малонагруженные сервисы могут жить на одном сервере в большом количестве, вплоть до десятков штук, пропорция 1:8 вызывает сомнения.
Если монолит изначально был спроектирован плохо - без четкого разделения на модули, то дробить его на части - это серьезная работа, может быть даже настолько серьезная, что проще рядом новую систему разработать.
Начинают проект с микросервисов обычно тогда, когда система разрабатывается для продажи (это продукт), а не под единственного заказчика. А также когда четко видна модульность и понятно, что разным покупателям будут поставляться разные конфигурации модулей.
Также добавлю, что современные фреймворки помогают разрабатывать микросервисные решения с возможностью развертывания сервисов как в отдельных процессах, так и группировать несколько плотно взаимодействующих сервисов в одном процессе (тогда упрощается коммуникация - происходит просто вызов функции в одном адресном пространстве и сериализация/десериализация не выполняются).
В случае интерпретируемых ЯП, например, JS/TS для изменения конфигурации запуска можно даже не пересобирать приложения и контейнеры. Файлы конфигурации запуска сервисов могут использовать переменные среды и в итоге это все может конфигурироваться на уровне параметров запуска контейнеров.
То есть систему, спроектированную в микросервисной архитектуре можно запускать как монолитом - одним процессом, так и кластерами сервисов, вплоть до кластеров, состоящих из одного сервиса. И все это без изменения бизнес-логики. Просто исходя из необходимости - нагрузок, доступной инфраструктуры.
Это довольно типичная ошибка - излишне подробное дробление задачи на сервисы. Апогеем этого безумия является упомянутое в статье - Function as a Service, этот подход продвигают компании, которые продают условный "хостинг" - чем больше народ на это подсядет, тем больше они заработают.
Думаю, что всё намного проще. Если вы не авито, гугл, яндекс. То вам не нужны микросервисы. Если вы пиццерия, или леруа мерлен, они вам зачем?
Сейчас любой средний сервер, потянет все ваши данные. Если вдруг упретесь всегда есть шардинг. Пока разрабатывают микросервис, занимаются тестированием, согласованием API,. Вы просто ставите ещё один сервак на чтение и нагрузка на железо падает на 50%.
Нормальное решение, если у вас в системе преобладает чтение данных, а если 50 на 50 с записью, или запись преобладает, то выгода будет поменьше?
По крайней мере снизится нагрузка на чтение. И освободятся доп ресурсы. Ну и запись независима от чтения. Ускорение будет, но сказать насколько не берусь.
Я больше исхожу из практичности и просто ты. Если пиццерия как некая константа функционала требует 100 микросервисов, для работы. Явно, что то пошло не так.
Перевод тяжело читается. Но в целом он близок к тому, что хотел сказать автор. Я поддержу автора, очень многие концепции идут в пересечении с организацией людей и хорошего проектирования.
Закон Конвея. Для команды важна изолированность ее решений, чтоб снизить влияние других команд на ее код. Микросервисы и отдельный репозиторий помогает в этом. В любом монолите будет общий код и его изменение затрагивает все команды и придется много потратить времени на глобальный регресс.
Возрастающие сложности:
Проблемы при разработке. Я видел проекты, где монолит нельзя было поднять локально у разработчика, для каждого пришлось выделять отдельную виртуалку, с микросервисами и например микрофронтендами в такое очень сложно упереться.
БД в Монолите единая, в отличии от микросервисов, что создает проблемы например для zero-downtime изменений (пример нужно изменить формат поля). С легковесными микросервисами и отдельным схемами/базы данными это проще
Монолит обычно не может быстро деплоиться , обычно собирают кучу МР и выкатывают например раз в 30 минут. Каждый МР успешно прошел, но когда они сливаются вместе, вы получаете ошибку. И дальше начинаются проблемы, например найти нужный МР, который привел к ошибке.
Обновление внешних библиотек, отдельная боль. Никто не обещает обратной совместимости, вам придется потратить кучу сил на синхронизацию команд, такое обновление должно быть единомоментным. В отличии от микросервисов, где каждая команда в своем ритме может это сделать.
Производительность, это отдельная тема, чисто на бумаге да, микросервисы тратят дополнительное время. Но зачастую вся проблема не в общении между микросервисами, а где то еще. Если у вам много общения между микросервисами, то возможно вы плохо спроектировали их. Но тут да, еще раз повторюсь на бумаге, производительность ниже.
Как итог, я полностью поддерживаю автора в том ключе, что возрастающая сложность - это самая большая проблема. Как в примере с чистой архитектурой, приходится платить много рутинным и банальным кодом, чтоб изолировать доменную область, чтобы снизить эту сложность. Так и в микросервисах, приходится обвязывать многими банальным,а иногда нет, инфраструктурными вещами ,которые кстати ложатся не на плечи разработчиков, чтоб бы снизить эту сложность для разработки.
Спасибо за развернутый комментарий!
Разграничение интерфейсами и функциональными доменами.
1 Я видел проекты где разработчики пытались поднимать 100500 микросервисов, но ПК не тянул. Невозможно локально поднять все и сервисы. С монолитом проще.
2 Всё покрыто интерфейсами и обращение за данными через них. Если по коду разбросано select поле1, а нужно поле_2 это проблема не из за монолита.
Можно разворачивать несколько монолитов для теста. Одни пилят одну фичу тестируют на одном контуре, другие на другом. Потом уже есть финальная сборка.
Ага. У всех разные библиотеки. Допустим прилетает библиотека с исправлением, у одной команды всё ок. Несколько микросервисов при работе сломались. Идёт разбирательства кто виноват. Оказывается остальные которые не обновили библиотеку в своём микросервисе. Работает же.
Разделили на микросервисы. Архитектор доволен. Всё чувствуют себя Мега программистами. А потом микросервис доставок полез в микросервис юзеров, юзеры полезли в историю покупок. Заказы идут опять в юзеров и в итоге с опозданием когда отработал код распределённых транзакций мы получили две требуемы строчки пробившись через сеть. А что делает монолит, одним запросом забирает данные. Всё происходит быстро так как находится в едином адресном пространстве. А ещё по дороге что то посчитал, так как это быстрее чем считать на клиенте.
В итоге не всё так просто и в лоб не сравнить.
И как ты этим единый репозиторий кода разделишь?
Зачем мне разворачивать все микросервисы? я вряд ли буду вносить во все изменения. Мне нужен минимум чтоб сделать свою задачу.
Надеюсь ты знаешь как решается задача zero-downtime для изменения БД например типа одной колонки и в чем сложность
Я описал проблему именно когда сливают несколько фич в финальную сборку, они же могут влиять друг на друга? Может же ломаться?
Раздолбайство не лечится архитектурой.
Если ты почитаешь статью, то автор говорит о том что разработка должна быть без сложностей и "мегапрограммисты" обычно создают проблемы. И твой пример при распределенных транзакциях - это не к микросервисам, это уже ближе SOA, где распределнную транзакцию можно в оркестраторе бизнес процессов реализовать.
И как ты этим единый репозиторий кода разделишь?
Такая потребность, это очень-очень частный случай. Обычно вполне достаточно, если другая команда просто работает с отдельными модулями в рамках общей репы
Зачем мне разворачивать все микросервисы? я вряд ли буду вносить во все изменения. Мне нужен минимум чтоб сделать свою задачу.
А как ты узнаешь, затронули ли твои изменения работу других сервисов? Деплоем в тестовую среду и ожиданием, пока там интеграционные тесты отработают, и если что-то пошло не так, то повторением цикла изменений/тестов? Это долго и непродуктивно.
Надеюсь ты знаешь как решается задача zero-downtime для изменения
Deployment slots
Я описал проблему именно когда сливают несколько фич в финальную сборку, они же могут влиять друг на друга? Может же ломаться?
Могут, но в монолите-то они никак не окажутся внезапно вместе в финальной сборке. До этого они побудут все вместе в тестовой сборке, где возможные конфликты и должны выявляться.
Раздолбайство не лечится архитектурой.
Это факт :)
Такая потребность, это очень-очень частный случай. Обычно вполне достаточно, если другая команда просто работает с отдельными модулями в рамках общей репы
речь шла о кейсе, когда есть общий код для всех. Если он меняется, например тип какого то поля, удобно же что IDE тебе подсветит все места где надо изменить. Но данное поле еще сохраняется где то в БД, надо будет еще единую миграцию сделать по всем таким случаем. И если мы возьмем большую компанию 100+ разработчиков, я думаю это будет неприятным организационным моментом.
А как ты узнаешь, затронули ли твои изменения работу других сервисов? Деплоем в тестовую среду и ожиданием, пока там интеграционные тесты отработают, и если что-то пошло не так, то повторением цикла изменений/тестов? Это долго и непродуктивно.
Опять же речь шла о локальной разработке. Мне для решения хочется поднять локально код и проверить что он работает. Мне не нужно поднимать 100500 сервисов. Чтоб узнать о том что затронули или нет, всегда есть контрактные тесты. Понятно что в монолите можно написать больше дешевых тестов для отладки взаимодействия между командами. Но это уже другой вопрос. Тут конечно сложнее микросервисам, поэтому придумали контрактные тесты. Такой кейс кстати есть и в монолите - между фронтом и бэком.
Могут, но в монолите-то они никак не окажутся внезапно вместе в финальной сборке. До этого они побудут все вместе в тестовой сборке, где возможные конфликты и должны выявляться.
выше писали что в финальной сборке все окажуться вместе. я конечно за то чтоб как можно раньше выявить проблему. Вот у тебя 30 мров в тестовой сборке и она падает. И начинаются танцы поиска проблемы, особенно если тот кто закоммитил и ушел пить кофе по-ирландски. Понятно, что все решается, но просто из-за упавшей сборке, все должны отвлечься и посмотреть кто накосячил.
Мой довод в том что микросервисы лучше разграничивают зону ответственности команд, но конечно это небесплатно. И архитектура должна помогать не делать глупости. Как бы ты не хотел в микросервисах ты не сможешь вызывать методы другой команды мимо API или залезть в БД, в отличии монолита. Умники всегда найдутся "потому что сроки горят".
Но данное поле еще сохраняется где то в БД, надо будет еще единую миграцию сделать по всем таким случаем. И если мы возьмем большую компанию 100+ разработчиков, я думаю это будет неприятным организационным моментом.
Да, но это абсолютно то же самое, что поменять тип поля в микросервисе. В монолитах (дисклеймер: я не имею в виду откровенно жопную архитектуру, при желании испортить можно всё) тоже не бывает такого, что одно поле влияет на всё везде. За каждую сущность отвечает какой-то конкретный сервис, к которому обращаются другие сервисы. Если вы конкретно работаете с данным сервисом, вы и затронете только его же данные. Конечно, я имею в виду современный монолит. Если взять какое-нибудь легаси, где бизнес-логика вообще всунута в хранимые процедуры, как это было модно в 90-е, там точно будут нюансы :)
Опять же речь шла о локальной разработке. Мне для решения хочется поднять локально код и проверить что он работает
Ну я как бы и локально хочу сразу знать не просто, что код проходит юнит-тесты, а то, что он не ломает ничего вокруг. Не знаю, как у вас, а у меня во всех проектах ничего существенного юнит-тесты не находят, самые серьёзные ошибки всегда на интеграционных выскакивают.
Вот у тебя 30 мров в тестовой сборке и она падает. И начинаются танцы поиска проблемы, особенно если тот кто закоммитил и ушел пить кофе по-ирландски
Так с микросервисами будет всё то же самое, но вы об этом узнаете не локально, а уже после публикации :)
И архитектура должна помогать не делать глупости.
Да, такой момент есть: в монолите куда больше свободы выбора сделать кривую архитектуру
Да, но это абсолютно то же самое, что поменять тип поля в микросервисе.
Про поле не понял) всегда есть версионность api, есть конечно минусы, версий не напасешься на все случаи. второй момент, если из одного простого типа в другой тип, то куча возможностей при сериализации можно использовать. поэтому не соглашусь что таже проблема)
Ну я как бы и локально хочу сразу знать не просто, что код проходит юнит-тесты, а то, что он не ломает ничего вокруг. Не знаю, как у вас, а у меня во всех проектах ничего существенного юнит-тесты не находят, самые серьёзные ошибки всегда на интеграционных выскакивают.
ну вот у меня сейчас проект, монолит отдельно стоит на виртуалке, с отдельной БД. потому что локально это не поднять. с микросервисом иначе. да, можете поднять все необходимые микросервисы, и интеграционные прогнать на нужных вам отдельных модулях. вряд ли вам нужны прям все микросервисы
Так с микросервисами будет всё то же самое, но вы об этом узнаете не локально, а уже после публикации :)
не будет, у тебя отдельный микросервис у команды, она его деплоит когда хочет и никого не ждет. понятно что надо соблюсти все понятия обратносовместимости и версионнирования. но это полностью отвязывает от ожидания других команд.
не будет, у тебя отдельный микросервис у команды, она его деплоит когда хочет и никого не ждет. понятно что надо соблюсти все понятия обратносовместимости и версионнирования. но это полностью отвязывает от ожидания других команд.
Это при условии что микросервисы стоят не в цепочке. Т.е от отказа одного сервиса весь проект потеряет какую-то одну функцию. А если там все в цепочке, то истории: одна команда независимо разрабатывает и делает деплой – становится не более чем фантастикой.
И хорошо если при такой системе просто все остановится. Но бывают более комичные случаи, когда все продолжает работать. Но результат одного микросервиса влияет на конечный результат всей системы.
Я выше писал. Что не имеет смысла баловаться с микросервисами получая лишнюю сложность, так как при малом количестве данных, пользователей, вы не получите отдачу пропорционально технологии. Получите только сложность разработки, поддержки, выкатывания и тестирования. И зачем тогда всё это нужно. Технология ради технологии?
И как ты этим единый репозиторий кода разделишь?
Код стоит из модулей/пакетов, раскинул их по разным репозиторием...и все. В чем проблема?
Раздолбайство не лечится архитектурой.
Это правда. Только в случае монолита вероятность проблем со сборкой увеличивается. У нормальной команды проблемы со сборкой должны вызвать как минимум дополнительные тесты. Да и в целом, выше писал что монолит заставляет делать тестов больше и вероятности багов просто меньше.
Если ты почитаешь статью, то автор говорит о том что разработка должна быть без сложностей
Выше уже написали, что в любом случае помимо кода самого функционала нужно писать или использовать фреймвяорки для того чтобы микросервисы общались. Это ли не есть усложнение?
Код стоит из модулей/пакетов, раскинул их по разным репозиторием...и все. В чем проблема?
нигде такого не видел, как мне кажется ни одна команда с монолитом на такое не пойдет. теряется важное преимущество все в одном месте.
Это правда. Только в случае монолита вероятность проблем со сборкой увеличивается. У нормальной команды проблемы со сборкой должны вызвать как минимум дополнительные тесты. Да и в целом, выше писал что монолит заставляет делать тестов больше и вероятности багов просто меньше.
вероятность багов не меньше. зачастую если меньше кода, то его проще поддерживать и писать адекватные тесты.
Выше уже написали, что в любом случае помимо кода самого функционала нужно писать или использовать фреймвяорки для того чтобы микросервисы общались. Это ли не есть усложнение?
Очень много тут ложиться на девопсов для поддержки инфраструктуры, а не на разработку. все гарантированные доставки, предохранители (circuit breaker), балансировки). Разработчик вообще об этом не заботится. Для него все просто, есть API с контрактными тестами. Полная изоляция согласно SOLID/GRASP.
В итоге при микросервисном подход мы получаем.
Сетевые задержки.
Лишние синхронизации.
Обработка распределённых транзакций, что не быстро как минимум.
Дополнительные сложности на каждом уровне разработки, тестирования.
Более сложный код при обработке и откату изменений. См распределённые транзакции.
Выкатка всего этого в прод. Девопс эдишен.
Невозможность всё поднять локально.
А какие же плюсы у микро сервисов?
1. Каждый домен в своей репе.
Можно юзать разные языки программирования.
И в итоге. Зачем это всё? Ради чего мистер Андерсон?
Интересно тогда откуда берутся запросы у нанимающих менеджеров? Примерно на каждом втором собесе можно услышать - мы делаем систему уже 3+ года и она разрослась, теперь хотим распилить это все на микросервисы и ищем разработчиков с подобным опытом.
Возможно не желание рефакторить текущий монолит, пересмотреть функционал, разграничить обязанности, пересмотреть интерфейсы и т. д имеет смысл выносить определённые вещи в микросервисы. Но если этот функционал полностью реализуем в одном микросервисе. Не дёргает для своей работы 100500 других, а именно хранит и обрабатывает свои данные. Тогда производительность вырастет, так пользователь которому нужна именно эта фича не будет дёргать основной монолит. Это плюс. Но обычно делают микросервисы взаимосвязанные между собой очень многими нитями. Друг друга опрашивают, и в итоге запрос прошёл по всем сервисам собрал информацию, затратил много времени на синхронизацию и сеть и в итоге производительность запроса упала.
В первую очередь следует посмотреть на код и архитектуру, скорее всего проблема там.
Я не гуру. Пишу о том, что знаю и с чем сталкивался.
Я просто не люблю овер инжиниринг без необходимости.
Потому что менеджер стал жертвой маркетинга или такой вариант не рассматривается?
Расскажу свежую историю.
Приходит мой друг и говорит: "можешь зайти оценить проект системы бронирования. Мне надо понять что делать с ним дальше"
Он сразу сказал что её разрабатывал человек 5 лет назад который только учился программировать, сейчас его нет...а система тормозит. Надо что-то делать, клиенты жалуются.
Захожу на виртуалу мат.....много мата разного и красочного. Через пару часов я наконец понял как эта шайтан машина работает. Для человека который учился программировать он сделал невероятное, пусть и криво и выбрал технологии которые я бы никогда не выбрал.
Он использовал Nodejs и плохого в этом нет, смог подцепить всякие фреймворки и даже разобрался с многопоточностью из микросервисов. Краеугольным камнем стала база – Mongo DB. База выросла, стала тормозить. Более того там вопросы и к самой структуре базы. Лаги не только от того что она выросла, а и из-за того что в структуре допущены ошибки и Nodejs выполнял лишние действия.
После всей оценки мое заключение простое: Замена базы на более подходящую и переписывания всего проекта.Переписать все там проще, чем разбираться как это вообще работает чтобы производить какие-то модификации. Тем более проект реально не сложный с базовым функционалом без сложных функций.
На вот это заключение я от друга получил вопросы от которых сам удивился, не дословный диалог:
Д: А чем база тебя не устроила?
Я: А вы почему Mongo выбрали?
Д: Ну, я посмотрел везде про нее тогда писали. Решил выбрать её
Я: Надо использовать простую базу типа Mysql, без всяких свистелок и перделок. Специалистов на данную базу больше чем на Mongo. В случае вот таких проблем когда программист ушел надо искать специалиста по Mongo.
Д: Окей. А можно не переписывать? Тут пару фрилансеров смотрело, говорят можно просто микросервисов добавить и будет побыстрее
---
Я: Сколько они за это хотят? (в этот момент я уже выпал из реальности. Посмотреть на проект с Mongo DB и сказать что, а давайте его клонирумем и разрастемся еще больше. Хотя тормоз как в базе, так и в скриптовый части)
Д: один 250к, другой 300-400k
Я: Разработка с нуля за 3-4 недели будет стоить тебе у средней руки специалиста 400-500k рублей. Зато это будет красиво, будет работать быстро и надежно и на другой нормальной БД
Далее я объяснил что и как более подробно, все таки друг. Дал им знакомого который все сделал за 200к и за неделю. Писают кипятком
Конец.
И я надеюсь вы увидели контекст истории. И про то как модные-молодежные базы попадают в прод и про то как лихо можно сказать слово "микросервисы" и сразу бабок нарубить.
И думаю менеджеры коим является мой друг искал фрилансеров по принципу: где-то услышал
Я полагаю вы говорите о разработчиках, которые плохо понимают DDD и не знают как находить ограниченные контексты, чтоб сервисы были с низкой связанностью. Если так, то да, все эти проблемы будут убивать разработку. Про распределенные транзакции, повторюсь, для них делают зачастую другую архитектуру с оркестратором, и он уже этим всем заботиться.
И преимущество микросервисов в том что вы можете поднять только те, что вам нужны. Не видел я такие задачи, чтоб прям все 10+ микросевисов надо было поднять локально.
Кажется, никто из комментаторов не увидел самой ценной мысли в этой статье. А именно, что код - это отражение отношений внутри организации.
Монолит можно писать, когда у всех есть кристалльно чёткое понимание, что за продукт разрабатываем, нет изменений входящих данных, бизнес-процессы более-менее отстроены, и есть ресурсы нанимать команды примерно одинакового уровня.
Для большинства реальных организаций лучше всё-таки пилить микросервисы, так тупо надёжнее и гибче
Лично я вас не понимаю.
Возьмем Golang, есть условно блок математики находящийся в пакете math. Сейчас, данный пакет находится в одном репозитории с монолитом и вдруг мне понадобилось чтобы этот пакет разрабатывали отдельно от центрального.
Я открываю новый репозитория, кладу туда math. Добавляю разрабов которые будут им заниматься и делаю импорт из нового места
Монолит остается монолитом, т.к при сборке импортирует этот пакет просто с другого репозитория.
И так попилить можно весь проект на части. Но я бы делал кучу веток, которыми занимаются отдельные люди ответственные за модуль.
вероятность багов не меньше. зачастую если меньше кода, то его проще поддерживать и писать адекватные тесты.
Гениальную вещь пишите. В Монолите всегда кода меньше, потому что отсутствуют блоки соединения и мониторинга микросервисов
Разработчик вообще об этом не заботится.
Вы очень лихо как фокусник манипулируете словами. Это конечно замечательно, но пока что все ваши аргументы либо связаны с "плохими" разработчиками, либо у вас какие-то языки такие странные типа Nodejs и подобное где в принципе нормально монолит не сделать потому что они симулирую асинхронность и многопоточность.
Возьмем Golang, есть условно блок математики находящийся в пакете math.
Плохой пример, Выглядит как общая библиотека, если в ней что то поменять и не предупредить другие команды, я думаю многие много хороших слов скажут.
Гениальную вещь пишите. В Монолите всегда кода меньше, потому что отсутствуют блоки соединения и мониторинга микросервисов
вы видели микросервисы, знаете что означает "микро"?
Вы очень лихо как фокусник манипулируете словами. Это конечно замечательно, но пока что все ваши аргументы либо связаны с "плохими" разработчиками, либо у вас какие-то языки такие странные типа Nodejs и подобное где в принципе нормально монолит не сделать потому что они симулирую асинхронность и многопоточность.
Моя основной стек java/kotlin. Я хорошо знаю кубер, реакт. В данный момент я работаю с огромным монолитом на PHP. И я поработал и с микросервисами и монолитом достаточно много. В данный момент на монолите более 500+ разработчиков сидит и это очень больно, потому что изначально не сделали хорошее разделение между модулями, почему? потому что изначально не планировали так делить модули, так сказать произошла эволюция понимания как надо было делать правильно)
В данный момент я работаю с огромным монолитом на PHP.
В данный момент на монолите более 500+
Можно есть суп вилкой. Не пробовал, но говорят очень интересно.
Удивительно что человек со стека java/kotlin участвует в этом и я пожелаю вам удачи.
Плохой пример, Выглядит как общая библиотека, если в ней что то поменять и не предупредить другие команды, я думаю многие много хороших слов скажут.
Вы точно знаете как работают репозитории?
import в go работает совсем по другому принципу. Если я добавляю какой-то внешний импорт из репозитория, то я должен инициализировать его через go mod. Т.е go его скачивает в момент установки и в проекте go.mod добавляет ссылку на локальную папку (cache) с ВЕРСИЕЙ.
Вот для примера go.mod
require (
github.com/caarlos0/env/v6 v6.10.1
github.com/shopspring/decimal v1.3.1
github.com/sirupsen/logrus v1.4.2
gopkg.in/yaml.v3 v3.0.1
)И когда ты делаешь import github.com/shopspring/decimal то берется версия 1.3.1 которая находится локально на сервере разработки
Все тоже самое только в профиль и менее удобно на C++. Но вот так просто там кто-то поменял во внешнем пакете и у тебя нагнулась сборка – такого нет (уважаемые программисты на C++ не кидайте камни, я совсем чу-чуть знаю этот язык и местами его использую в стеке с Go. Возможно там есть какие-то другие варианты о которых я просто не знаю)
И когда к примеру мне надо сменить версию внешнего пакета я:
1. Создаю новую ветку
2. Обновляю один за другим пакеты
3. Тестирую
4. Если все хорошо, делаю merge (по-сути merge одного файла go.mod где меняет версия пакета из кэша на более новую)
И опять же – всегда есть ветки и пакеты могут находится внутри монолита. Каждым конкретным пакетом может заниматься команда и в конце делается merge. За счет строгой типизации ошибки сведены к минимуму.
И в заключение, если есть внешний пакет и нет защит от самого языка, то эту защиту должен предусмотреть тот кто руководит проектом. Если он этого не умеет – научить. Если не хочет...ну тут я не знаю какие бабки мне надо платить чтоб я согласился учавствовать в таком цирке шапито.
Можно есть суп вилкой. Не пробовал, но говорят очень интересно.Удивительно что человек со стека java/kotlin участвует в этом и я пожелаю вам удачи.
Если вам нравится, ешьте вилкой)
Вы точно знаете как работают репозитории?
Знаю, но вы плохо понимаете о чем я говорю.
Вы опять говорите про одну команду. Пусть будет 10 команд+, то у вас обязательно возникнет проблема, когда надо поднять версию для ВСЕХ одновременно. Каждая команда должна будет проверить, что у них ничего не сломалось. Коммит с поднятием версии этой библиотеки повлияет на всех и сразу, в отличии от микросервисов.
По-моему, это уже холивар. Пардонь-те, по минусу двум предыдущим.
Проверят тестам же. Что ничего не сломалось и работает ожидаемо.
Просто у всех в спринте будет блокирующая задача, обновить библиотеку. Всё решаемо.
Я вам описал полностью всю схему обновления. Если у вас есть критика этой схемы, то укажите шаг на котором кто-то может создать такую проблему что положит весь монолит и не даст собрать
Действительно, я плохо понимаю о чем вы говорите и создается впечатление что вы не понимаете что такое "монолит" и мы говорим о разном.
Как минимум потому что я могу только в страшном сне представить что такое монолит на php. Это хороший язык, но давайте не будет рожденного ходить заставлять летать. Краем глаза видел, добавили какую-то там ассинхронку через какие-то неведомые костыли.
Честно, я не видел монолитов на PHP и не хочу видеть
И если там реально существует проект с 500+ разработчиками которые пилят на PHP монолит....у меня много вопросов. ОЧЕНЬ МНОГО ВОПРОСОВ
Я как-то работал в Сбере, был монолит и три команды - Москва, Питер и Технополис. Каждое утро начиналось с того, что на общем созвоне пытались поднять систему после очередных экспериментов в Технополисе. 30-60 человек-часов каждый день, как с куста.
Но Сбер богатый, ему это как слону дробина
И добавлю. Микросервисы тормозят, так накладывают оверхед, на сеть, на распределённую транзакцию, на синхронизацию. В монолите на себя это всё берёт БД из коробки.
Практика критерий истины. Просто практика зависит от данных.
Подскажите, в чём именно у вас выражается торможение микросервисов? Как и какой оверхед они накладывают на сеть у вас? На сколько понимаю, даже простецкий хостер (сугубо для примера) сейчас гарантировано даёт 1 Гб/с между виртуалками. И если смотреть задержки распростанения пакета, то они в пределах милисекунды или даже долей милисекунды
Монолит, микросервисы... Тот самый случай когда телега бежит впереди лошади. Вы сначала напишите чтобы просто работало, потом из этого работающего выделите отдельную сущность которая может работать самостоятельно, потом сделайте это еще раз, если в этом есть польза. Оцените результат, учтя увеличившуюся нагрузку на девопсов, на координации, версионинг, тестирование кубернетисы и прочие. Есть польза - можно попробывать продолжать. Нет - есть повод остановиться. Возможно в итоге это окажется четыре больших сервиса, а возможно 25 средних, но все еще не микро. А возможно у вас родится настоящая микросервисная архитектура. И она будет замечательна, я уверен. Потому что родилась по потребности и исходя из полезности, а не потому что вы пытались впихнуть свои задачи в модный (или уже нет) тренд
Я увидел в статье только очень болезненную реакцию автора на тот факт, что не все такие умные и образованные как он и поэтому они просто не тянут микросервисы.
Вообще, это сплошь и рядом происходит: мастера поднимаются до высот познания и начинают мечтать о том, как с такими же будут создавать коллективные шедевры. В реальности шедевры (и в строительстве тоже) - удел одиночек или редких сплочённых групп, а действительно работающие большие системы могут строиться только на основе простых и понятных более-менее всем участникам процесса принципах.
Странно ожидать того, что в большом коллективе, который является необходимым для появления микросервисов (для одиночки монолит идеален, т.к. он полностью отражает "структуру" "компании") все будут грамотными, экстравертами и одновременно хорошими архитекторами (начал он ведь с отрицания отдельной роли архитектора - каждый инженер должен им быть), ну прямо как он (ну почти, он на самом деле - ваще бох). И он на полном серьёзе возмущается тем, что люди не боги и не тянут микросервисы!
Ну и также его ошибкой являтся то, что он напрочь забыл почему микросервисы могут являться лучшей архитектурой: кроме независимой разработки и развёртывания, также большую роль сыграла та форма, которую прогресс принял в нашем мире: мощность систем перестала расти вертикально и стала расти горизонтально: требуется множество серверов, масштабирование с некоторых размеров возможно только горизонтальное. И выход из строя частей системы стал обыденностью (раньше можно было резервировать весь монолит один раз и почти забыть про надёжность). Если масштабирования не нужно, если на каждом хосте один модуль монолита всегда будет справляться с нагрузкой, то это прекрасный компромисс между одним монолитом и микросервисами. И он работает в реальном мире, который не наполнен розовыми экстравертными пони со знанием и умением всего.
А, да, забыл самое главное написать! Автор путает монолит со спагетти кодом. Для него возможность физически расположить код в одном месте означает с необходимостью превращение его в спагетти. На самом деле монолитный модуль - не значит монолитный код. Все эти ваши Мартины и прочие Бучи формулировали свои принципы когда слова микросервис не существовало (ну может быть в академическом смысле где-то и было), кластер серверов был роскошью, а слово "опс" иногда для разнообразия говорили разве что вместо "упс". Начинать надо с хорошего слабосвзязанного кода (и такие системы в рамках монолитов существовали всегда). И когда и если придёт время разделять на микросервисы - это случится легко и естественно.
Статья великолепная, кладезь знаний, можно разбирать её месяц, читая ссылки и много думая.
Перевод ужасен
О сложности и монолитах