Микросервисы и точки отказа.

разворачивай на нескольких серверах /thread

у тебя прод гарантированно должен смотреть на прод-сервер, протестированный и точно обновлённый, любой перевод на другой сервер вызывает боль и страдание у РП и выше, даже если всё нормально.

для этого придумали докеры, кубернетесы и прочие абсолютно ненужные для настоящих одминов вещи. чтобы как раз решать вышеописанную проблему. и в том числе чтобы запускать реплики микросервисов на разных нодах и не было необходимости «в проде гарантированно должно смотрящим на прод-сервер»

а с развитием микросервисов мне кажется что точек отказа просто писец как больше становиться

Ну, не писец, но больше.

Но смищно когда все микросервисы разворачивают на одном сервере

Так это «монолит» получается, только такой в котором точку отказа найти намного проще, чем если бы это и правда было монолитное приложение.

ться ться ться. айти которое мы заслужили…

Микросервисы придумали не ради надёжности или ещё чего-нибудь эдакого технического, а чтобы тысяча программистов не наступали друг другу на пятки при работе над проектом. Каждой команде (10-12 человек) по микросервису, все довольны, никто друг другу не мешает.

Проблема возникла тогда, когда в организациях, в которых одна команда (те же 10-12 человек), решили что микросервисы это путь к успеху, не разобравшись, что для работы в таком стиле нужно иметь <число микросервисов>*12 людей в штате.

микросервис - это кейворд-детектор.

- Здравствуйте, приветствуем вас на собеседовании на системного программиста. Скажите, вы используете микросервисы ?

- Да.

- Извините, на данный момент мы не готовы взять вас на должность системного программиста.

Микросервисы придумали не ради надёжности или ещё чего-нибудь эдакого технического, а чтобы тысяча программистов не наступали друг другу на пятки при работе над проектом. Каждой команде (10-12 человек) по микросервису, все довольны, никто друг другу не мешает.

Для этого придумали модули. А микросервисы, чтобы потом проще было на много серверов программу распараллеливать.

Притом админ при каждом обновлении фронта и бэка ставиться бешенной собакой.

Зачем быть админом?

А разве погромист не должен использовать то, что сказал ему архитектор?

Модули, запускаемые в едином монолите в меньшей степени чем микросервисы упрощают анализ причины в случае проблем.

Для монолита разработчик любого модуля чтоб понять проблема у него или пришли некорретные данные из другог модуля - вынужден тем или иным способом уметь ислледовать/отлаживать работу своего модуля в составе монолита. Такая деятельность может быть затруднена по группе причин. Например не получится через час после старта работы всех модулей, заменить один из них на сборку с тонной медленного логирования по гигабайту в секунду.

С микросервисами это проще, даже если они все крутятся на одной машине. Разработчику модуля не надо при иследовании/отладке учитывать что в рамках исследуемого процесса выполняется код про который он мало знает.

Да, для монолита можно придумать те или иные упрощения этих проблем, помодкльное включение логгирования на ходу и т.п., но такая проблема динамита имеет место быть

Для этого придумали модули. А микросервисы, чтобы потом проще было на много серверов программу распараллеливать.

Можно и монолит в нескольких экземплярах запускать на разных серверах. Накрайняк отделить http-сервер от background task воркеров, их на практике по-разному масштабировать приходится. И то, это всё можно сделать в рамках одного проекта, на одном языке, в одном репозитории, просто с двумя разными точками входа.

А то что я видел на практике когда говорят «у нас микросервисы», например иметь отдельно сервис аутентификации от сервиса пользовательских профилей, это не про много серверов, это про кота, которому нечего делать. Бонусные очки если каждый ещё на своём стеке.

И ещё не удивлюсь, если в значительном числе случаев «много серверов» нужно из-за того, что и без того неторопливую скриптоту разделили на микросервисы, которые друг в друга по тормозному (по сравнению с вызовом локальной функции) http что-то кидают.

Разработчику модуля не надо при иследовании/отладке учитывать что в рамках исследуемого процесса выполняется код про который он мало знает.

Это если за каждый микросервис отвечают разные люди/команды. А порой микросервисную архитектуру чуть ли не в одиночку делают. Мол сработало для нетфликса, сработает и для петпроджекта.

И тогда процесс отладки усложняется, потому что отладчик прикручивать к каждому запущенному сервису отдельно. А любой нетривиальный глюк вообще превращается в криминальную драму.

Я скажу странную вещь, но... В большинстве случаев современной разработки микросервисных систем эта разработка не похожа и никогда не будет похожа на «как у гугла», не имеет целью масштабирование ресурсов (даже если формально такая цель есть), эффективное их использование (использование чудовищно неэффективное в 99% случаев), отказоустойчивость (у нас не упала половина сервисов — мы просто экономим ресурсы в условиях пиковой нагрузки).

В подавляющем большинстве случаев истинная причина организационная, и описать ее можно как «у нас есть стадо мартышек со всех точек земного шара, без тимлида, без архитектора, они едва понимают ломанный английский друг друга, и в этих условиях нам нужно показать заказчику хотя бы подобие работающей системы». Естественно, в таких условиях «на моей машине работает» становится непререкаемым правилом, теперь после этого применяется не «бить кодера палками по рукам до просветления», а «этим займется девопс».

На момент создания докера проблема распространения софта, действительно, стояла остро. Сейчас есть стабильный интерфейс ядра линя, статическая линковка, pip, yarn, и прочие инструменты для создания идеально воспроизводимого окружения без необходимости помещать приложение в тюрьму, из которой его потом придется доставать. По этой причине нынче проблема распространения одного сервиса уже не так актуальна.

Потому да, разворачивание микросервисов на одной машине — это наиболее логичное развитие данной модели, поскольку распределенные системы разрабатывать, отлаживать, тестировать, поддерживать намного, НАМНОГО сложнее, чем централизованные. Потому мы экономим, мы разрабатываем микросервисы вместо распределенной архитектуры. Именно так, в большинстве случаев микросервисы скатываются в жесткую централизацию и единственную точку отказа — просто в качестве единственной точки отказа стараются брать что-то энтерпрайзно-отказоустойчивое (аля MongoDB), чтобы эта единственная точка отказа как можно меньше проявляла свою суть.

когда я рос в ИТ, я помню постулат «Всегда снижай точки отказа», а с развитием микросервисов мне кажется что точек отказа просто писец как больше становиться

Кстати, да, единственная точка отказа — это очень даже благоприятный исход, поскольку зачастую в типовой микросервисной архитектуре есть сразу несколько точек отказа, любая из которых ложит систему целиком.

в типовой микросервисной архитектуре есть сразу несколько точек отказа, любая из которых ложит систему целиком

Какой смысл в «живом монолите», если из-за внутренних проблем он не реализует свои функции?

А разве погромист не должен использовать то, что сказал ему архитектор?

А разве архитектор - не погромист ?

приветствуем вас на собеседовании на системного программиста

Посыл был в том, что программист должен делать что скажут.

Да кстати я тоже видел забавные ситуации, как «микросервисы» друг с другом взаимодействуют по тормозному http через не менее тормознутые маршруты с лагом в 50 мс.

Но оно же «разгружает серверы», лол. Ну а то, что их условный curl тратит 20мс на резолвинг доменного имени - это уже такое, неважное.

Обыкновенный карго-культ, ИМХО.

Посыл был в том, что программист должен делать что скажут.

Это всё легенды из жизни на галере.

В реальности, перед проектированием архитектуры, архитектор, если уж он совсем гуманитарий - собирает митинг, на котором расспрашивает сотрудников как это можно сделать, и можно ли сделать вообще. И если программист скажет что «нельзя», или что «ЯП не позволяет такое сделать» - архитектор ничего не сможет возразить.

Если же он, архитектор, скажет сделать то, что невозможно сделать априори, программист не сможет, и около дедлайна об этом узнает высший менеджмент - архитектор вылетит, как дурак.

Какой смысл в «живом монолите», если из-за внутренних проблем он не реализует свои функции?

Вот и я спрашиваю «какой смысл?». Но до сих пор не смог добиться ответа. Всё, что я до сих пор слышал, было либо про какую-то свободу/равенство/любовь, либо про «наша распределенная команда высрала двадцать кусков дерьма, и теперь поддерживать его удобнее на общепринятом инструменте, чтобы можно было нанимать с рынка спецов, а не зависеть от одного васяна». Причем, обычно в обсуждении никогда не затрагивается ключевая сторона отказоустойчивых систем — организация данных в гетерогенной системе, то есть, координация доступа к ним, миграция между версиями, поддержка согласованности между удаленными узлами, разрешение конфликтов доступа.

В подавляющем большинстве случаев истинная причина организационная

Две тонны орешков этой белке-истеричке.

Например не получится через час после старта работы всех модулей, заменить один из них на сборку с тонной медленного логирования по гигабайту в секунду.

На лиспе или ерланге легко. Причём с сохранением контекста (что в случае микросервиса почти невозможно). И сохранение состояния всего приложения проще сделать.

И ещё не удивлюсь, если в значительном числе случаев «много серверов» нужно из-за того, что и без того неторопливую скриптоту разделили на микросервисы, которые друг в друга по тормозному (по сравнению с вызовом локальной функции) http что-то кидают.

Когда-то такое же отторжение вызывала идея UNIX с программами-утилитами и демонами. Это же, чтобы прочитать строки из двух файлов, вывести десять строк по условию, надо три программы запускать. И они будут кидать по тормозному (по сравнению с вызовом локальной функции) конвейеру. А потом привыкли.

Микросервисы придумали не ради надёжности или ещё чего-нибудь эдакого технического, а чтобы тысяча программистов не наступали друг другу на пятки при работе над проектом. Каждой команде (10-12 человек) по микросервису, все довольны, никто друг другу не мешает

Давай зайдем с другой стороны: назови мне проект, на который нужно более 10-12 человек, и я скажу тебе, как он был реализован командой <10 человек.

Если в задаче применимы микросервисы, и в кокнетрном модуле лисп/ерланг удачный выбор - ничего не мешает использовать их для микросервиса.

Также если говорить о выборе языка/среды исполнения и т.п. - в монолите ещё одна проблема - все новые модули приходится писать так, чтоб они линковались с ранее написанными.

И например залинковать питон+numpy в многопоточное приложение выполняющее параллельную обработку задач - проблема. И тысячи других. Почти все комбо кроме «1 нативный язык + 1 скриптовый ил другой нативный» - нежизнеспособны в рамках одного процесса.

С другой стороны конечно слишком большой зоопарк технологий по разным микросервисам - тоже плохо с точки зрения поддержки.

Когда-то такое же отторжение вызывала идея UNIX с программами-утилитами и демонами. Это же, чтобы прочитать строки из двух файлов, вывести десять строк по условию, надо три программы запускать. И они будут кидать по тормозному (по сравнению с вызовом локальной функции) конвейеру. А потом привыкли.

Разница в том, что на юниксах cat и прочие grep уже написаны за тебя, в принципе отлажены и особо не глючат. И типично возникающие пайплайны все научились читать.

А с микросервисным подходом каждый раз вселенная изобретается с нуля, и формат сообщений между каждыми двумя конкретными микросервисами часто прибит гвоздями именно к этой конкретной паре микросервисов у этой конкретной конторы.

Это как если у тебя есть grep, вывод которого можно направить только в awk, а если нужно в sed, то нужен другой grep или же какой-нибудь awk_to_sed_adapter.

И сюда же вдогонку. Юникс изобретали как среду более-менее общего назначения, с неизвестными заранее задачами. Кому-то книги набирать, кому-то программировать, кому-то поиграть. А очередное поделие крудостроения должно показывать каталог товаров, корзину, кнопку купить и ничего принципиально другого в обозримом будущем для того чтобы всё переиграть из уже имеющихся частей не случится.

Также если говорить о выборе языка/среды исполнения и т.п. - в монолите ещё одна проблема - все новые модули приходится писать так, чтоб они линковались с ранее написанными.

Именно так. То есть это не про команды программистов или отладку, а про компоненты на разных языках (а иногда и аппаратных архитектурах).

Модули, запускаемые в едином монолите в меньшей степени чем микросервисы упрощают анализ причины в случае проблем

Фундаментальное отсутствие гарантий модульности, то есть, что рандомный код не насрет твоему коду на голову — это проблема C/C++, которую он унаследовал от кобола-фортрана, и от этого всего, в меньшей степени, но всё же унаследовались другие языки.

Если на минутку допустить, что во всех командах работают ответственные кодеры, которые контролируются взаимно и направляются лидом, то фактор «кто насрал в моем модуле» удается минимизировать. А вот теперь скажи мне, как ты собрался искать причину проблемы, проявившейся при интеграции сервисов?

Для монолита разработчик любого модуля чтоб понять проблема у него или пришли некорретные данные из другог модуля - вынужден тем или иным способом уметь ислледовать/отлаживать работу своего модуля в составе монолита

Вот у нас сейчас проблема наоборот: есть черные ящики макросервисов в контейнерах, и хер его знает, как с ними работать, потому что разработка их в процессе и ведется другой командой, часть фичей нет, часть фичей плохо работает, доки минимальные.

Например не получится через час после старта работы всех модулей, заменить один из них на сборку с тонной медленного логирования по гигабайту в секунду

Вообще не вижу такой проблемы.

Это как если у тебя есть grep, вывод которого можно направить только в awk, а если нужно в sed, то нужен другой grep или же какой-нибудь awk_to_sed_adapter.

Не сказал бы. Всё-таки для микросервисов есть набор стандартов HTTP+REST+JSON/grpc/hprose/capnp/… В рамках одного стандарта из любого можно в любой.

А с микросервисным подходом каждый раз вселенная изобретается с нуля, и формат сообщений между каждыми двумя конкретными микросервисами часто прибит гвоздями именно к этой конкретной паре микросервисов у этой конкретной конторы.

В конвейерах тоже так бывает. troff | grops, например. Но, в целом, это нетипично.

И сюда же вдогонку. Юникс изобретали как среду более-менее общего назначения, с неизвестными заранее задачами. Кому-то книги набирать, кому-то программировать, кому-то поиграть. А очередное поделие крудостроения должно показывать каталог товаров, корзину, кнопку купить и ничего принципиально другого в обозримом будущем для того чтобы всё переиграть из уже имеющихся частей не случится.

Когда делают микросервисы именно предполагают, что случится. Вдруг на базе каталога товаров будет добавлена социальная сеть, онлайн игры и облачное выполнение блокчейновых контрактов.

И почти любой стандарт микросервисов быстро вырастает во что-то вроде AWS или https://sandstorm.io/.

В подавляющем большинстве случаев истинная причина организационная

Две тонны орешков этой белке-истеричке

Ты можешь смеяться над тем, что это якобы очевидно, но я не вижу, чтобы это было очевидно, зато вижу кучу людей, которые на полном серьезе рассказывают, что микросервисы имеют какое-то отношение к масштабированию системы и к сокращению сроков разработки. ИЧСХ, им никто не возражает. Я возражаю, мне отвечают «да тебе не понять».

Например не получится через час после старта работы всех модулей, заменить один из них на сборку с тонной медленного логирования по гигабайту в секунду

На лиспе или ерланге легко. Причём с сохранением контекста (что в случае микросервиса почти невозможно). И сохранение состояния всего приложения проще сделать

Это можно сделать еще как минимум на питоне и JS.

Когда делают микросервисы именно предполагают, что случится.

Это в теории. А на деле не могут доделать то, что планировали в базовом варианте, потому что при организации кода в виде «10 микросервисов на разработчика» продуктивность работы падает в разы.

А кто будет выбирать, если вариантов реализации больше одного?

Когда-то такое же отторжение вызывала идея UNIX с программами-утилитами и демонами. Это же, чтобы прочитать строки из двух файлов, вывести десять строк по условию, надо три программы запускать. И они будут кидать по тормозному (по сравнению с вызовом локальной функции) конвейеру

От того, что к этому привыкли, оно не перестало быть неуклюжим дерьмищем, которая загнило до такой степени, что даже MS выпустил свой павершел, который на голову превосходит баш, поскольку по уровню семантике ближе к питону, чем к башу. Например, расскажи мне, как ты обычно обрабатываешь переводы строк в именах файлов при написании башескриптов?

А потом привыкли

Кто-то привык, а кто-то — нет.

Я именно про теорию. Про то, что на практике в 99% случаев выбирали не по техническим, а по организационным причинам byko3y уже написал.

Также как часто разбивают программу на сотню классов на случай произвольного изменения в любой из этих частей алгоритма. Даже когда программа пишется под конкретного заказчика и известно, что меняться не будет.

С другой стороны конечно слишком большой зоопарк технологий по разным микросервисам - тоже плохо с точки зрения поддержки

Да, лучше было начать с ответа на вопрос «на кой черт ты суешь питоновый скрипт в нативное приложение?». Аналогичный вопрос к любому другому животному, которое решило взять $языкнейм для разработки $фичанейма вместо уже принятого языка. Эта ситуация особенно удивительна мне, как человеку, который пишет на C/C++, питоне, паскале, JS, и даже немножко хаскеле, поскольку у меня никогда не было желания «о, выпишите проект на JS — давайте засунем сюда питон». Хотя знаю чела, который засунул дотнет в паскаль.

как ты обычно обрабатываешь переводы строк в именах файлов

Я не использую переводы строк в именах файлов. И не видел никого, кто бы использовал.

А зачем их как-то отдельно обрабатывать? Сейчас сделал for i in * нормально обработались как файлы с пробелами, так и с переносами. Если вопрос про find, то там -print0 есть

Аналогичный вопрос к любому другому животному, которое решило взять $языкнейм для разработки $фичанейма вместо уже принятого языка.

Например, если $фичанейм в $языкнейм уже готовый, а в принятом языке его писать намного дольше, чем FFI к $языкнейм.

даже MS выпустил свой павершел, который на голову превосходит баш

павершелл пошёл на замену цмд, а не башу.

Если бы павершелл превосходил баш, скрипты в init.d были бы уже на нём. Но пока, увы.

Разница в том, что на юниксах cat и прочие grep уже написаны за тебя, в принципе отлажены и особо не глючат. И типично возникающие пайплайны все научились читать

Разрешите не согласиться. Все никсовые утилиты написаны в разнобой, несмотря на то, что некоторые более-менее универсальные гайдлайны для параметров запуска имеются, как то аргументы через дефис. Более того, cat почти ничего не делает, это вообще бесполезный инструмент, он тупо подпирает интерфейс межутилитного взаимодействия. А межутилитное взаимодействие не умеет толком обрабатывать пробелы и переводы строк в данных.

А с микросервисным подходом каждый раз вселенная изобретается с нуля, и формат сообщений между каждыми двумя конкретными микросервисами часто прибит гвоздями именно к этой конкретной паре микросервисов у этой конкретной конторы

Неужели это правда? Мне казалось, что есть JSON, JSONB, protobuf — вот и всё, по большей части.

Если бы павершелл превосходил баш, скрипты в init.d были бы уже на нём. Но пока, увы

Проснись, System V init сдох, всех уже давно съел systemd. А вот если бы был павершел, то и не факт. Но ретроградов-юниксоидов попробуй переубеди — они бы до гроба собирали проекты автотулзами.

Мне казалось, что есть JSON, JSONB, protobuf — вот и всё, по большей части.

JSON это формат сообщений. А я про их, собственно сообщений, структуру. Которая в микросервисах либо органично перерастает в «давайте возвращать вообще все поля, потому что вдруг пригодится», либо во всякие причудливые изобретения вроде graphql.

Хотя знаю чела, который засунул дотнет в паскаль.

Во-первых, это красиво.

А так основная причина «давайте засунем язык Х в проект преимущественно на Y» это либо «программисты на X дешевле, а у менеджмента постоянно хотелки поиграть цветами на этой части проекта», либо «язык модный, надо бы дописать строчку в резюме».

Именно так. То есть это не про команды программистов или отладку, а про компоненты на разных языках (а иногда и аппаратных архитектурах)

Справедливости ради многие языки умеют друг с другом взаимодействовать, особенно если речь идет про взаимодействие высокоуровневого ЯП с низкоуровневым, так что разные ЯП не являются поводом лепить взаимодействие по HTTP. Вот с разными аппаратными архитектурами уже выбора нету.

А зачем их как-то отдельно обрабатывать? Сейчас сделал for i in * нормально обработались как файлы с пробелами, так и с переносами. Если вопрос про find, то там -print0 есть

Во-о-от, один костыль там, другой костыль тут... И первым лесом отправляются sed и awk.

Проснись, System V init сдох, всех уже давно съел systemd.

Но /etc/init.d в наличии. Можешь попробовать убрать /bin/sh в любом линуксе (заменив логин шелл на tcsh или zsh например) и посмотреть сколько всего отвалится.

Например, если $фичанейм в $языкнейм уже готовый, а в принятом языке его писать намного дольше, чем FFI к $языкнейм

С каждым годом существования $языкнейм этот фактор всё больше сходит на нет, кроме очень специфичных случаев, которые часто заранее известны.

А я про их, собственно сообщений, структуру. Которая в микросервисах либо органично перерастает в «давайте возвращать вообще все поля, потому что вдруг пригодится», либо во всякие причудливые изобретения вроде graphql

И что, ты хочешь сказать, что в никсах не так, в никсах заранее известная структура сообщений? Байты текста — это еще менее структурированный формат, чем JSON.

JSON это формат сообщений. А я про их, собственно сообщений, структуру.

Так структура у данных, возвращаемых утилитами UNIX такая же разнообразная. Только в UNIX «все есть текст», а у микросервисов «все есть JSON».

Но /etc/init.d в наличии. Можешь попробовать убрать /bin/sh в любом линуксе (заменив логин шелл на tcsh или zsh например) и посмотреть сколько всего отвалится

Совместимость же ж, наследие. Но по большей части в системных службах всех съел systemd.