На хабре есть перевод довольно интересной статьи: Распутывание микросервисов или балансировка сложности в распределенных системах.

Где наконец-то говорится, что микросервисы это не так уж хорошо и не всегда применимо. В конце статьи очень интересный список ссылок.

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему.
А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.

Несколько бд было только в том случае, если одна реляционная, а другая — нет.

Кто как делает?

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

Здравствуйте, BlackEric, Вы писали:
BE>Кто как делает?
не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов.
в отличии от нативных ЯП. Я и сам удивлялся сколько гласфишу нужно памяти для пары крохотных веб-приложений.
сишарп кушает поменьше но тоже нехило. плюс эта вечная отмазка про компиляцию первого вызова. пробовал ngen но прикола так и не понял.
а всякие джанго и питоны еще и медленные.

Здравствуйте, BlackEric, Вы писали:

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.

Здравствуйте, vaa, Вы писали:

vaa>не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов.

А разве не возможность делать изи горизонтальное масштабирование?

Здравствуйте, BlackEric, Вы писали:

BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
BE>Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему.
BE>А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.

BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.

BE>Кто как делает?

На новой работе сделали несколько сервисов. Каждый сервис с отдельной БД. Не сказал бы, что они микро. Мне не нравится. Любители копипаста. Нужен новый схожий проект — создают новый репозиторий в гитлабе, склонированный из старого, копируют базу и поехали менять. Надеюсь всё это выбросить и переделать в один универсальный сервис с единой БД. Хотя не факт, что дадут.

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

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

Вот, кстати, "идея для стартапа" — надёжная и быстрая синхронизация некоторого подмножества БД между разными базами.

Здравствуйте, vaa, Вы писали:

BE>>Кто как делает?
vaa>не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов.
vaa>в отличии от нативных ЯП. Я и сам удивлялся сколько гласфишу нужно памяти для пары крохотных веб-приложений.

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

Здравствуйте, rosencrantz, Вы писали:

R>Здравствуйте, BlackEric, Вы писали:

BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.

Команда в 10 человек — это уже толпа. И она вполне способна сделать большой проект.
А на практике команды в 4-5 человек начинают плодить сервисы с кубернетисом, кучей нод и потом думаю как же все это поддерживать.

Здравствуйте, vsb, Вы писали:

vsb>На новой работе сделали несколько сервисов. Каждый сервис с отдельной БД. Не сказал бы, что они микро. Мне не нравится. Любители копипаста. Нужен новый схожий проект — создают новый репозиторий в гитлабе, склонированный из старого, копируют базу и поехали менять. Надеюсь всё это выбросить и переделать в один универсальный сервис с единой БД. Хотя не факт, что дадут.

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

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, vaa, Вы писали:

BE>>>Кто как делает?
vaa>>не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов.
vaa>>в отличии от нативных ЯП. Я и сам удивлялся сколько гласфишу нужно памяти для пары крохотных веб-приложений.

vsb>Тут можно схитрить и не запускать отдельный сервер приложений для каждого микросервиса. Тогда накладные расходы на каждый микросервис будут небольшими. Правда там свои проблемы появляются, но в целом решаемые. Хотя это старые и не модные технологии нынче. Поэтому да, по факту жава жрёт память дико, если жалко гигабайта на каждый микросервис, лучше от жавы сразу отказываться в пользу го, ноды или пайтона.

Один сервис — один докер контейнер или ВМ. Иначе смысла нет. Даже перезапуск веб-сервера перезапускает все сервисы сразу. Ничем не будет отличаться от монолита.

Здравствуйте, BlackEric, Вы писали:

BE>Один сервис — один докер контейнер или ВМ. Иначе смысла нет.

Почему?

BE>Даже перезапуск веб-сервера перезапускает все сервисы сразу.

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

BE>Ничем не будет отличаться от монолита.

Почему? Для меня отличие монолита от микросервиса в "толщине" границ. А что там используется для запуска — докер, процесс ОС или сервер приложений — это уже детали реализации.

Здравствуйте, gyraboo, Вы писали:


G>А разве не возможность делать изи горизонтальное масштабирование?
ну да. и вообще тут вопрос выбора должен определятся тем действительно ли будет перегружено приложение? или в итоге все усилия будут потрачены впустую.
опять вспомнил доклад рича хикки от 2012 "значение значений".
там он предлагает уходит от "программирования на месте" к иммутабельному ФП аргументируя это тем что уже 5-10 лет железо не проблема. хватит мол экономить на байтах.
странно конечно слышать такое от сишника.
вот александреску так не считает. нам все еще нужны быстрые программы с малым потреблением ресурсов.
у раста в этом смысле есть будущее. если учесть что он на достаточно медленном llvm работает дебианбенчмарки впечатляют.

Здравствуйте, BlackEric, Вы писали:

vsb>>Тут можно схитрить и не запускать отдельный сервер приложений для каждого микросервиса. Тогда накладные расходы на каждый микросервис будут небольшими. Правда там свои проблемы появляются, но в целом решаемые. Хотя это старые и не модные технологии нынче. Поэтому да, по факту жава жрёт память дико, если жалко гигабайта на каждый микросервис, лучше от жавы сразу отказываться в пользу го, ноды или пайтона.

BE>Один сервис — один докер контейнер или ВМ. Иначе смысла нет. Даже перезапуск веб-сервера перезапускает все сервисы сразу. Ничем не будет отличаться от монолита.

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

Здравствуйте, rosencrantz, Вы писали:

BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.

Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.

Здравствуйте, vaa, Вы писали:

vaa>там он предлагает уходит от "программирования на месте" к иммутабельному ФП аргументируя это тем что уже 5-10 лет железо не проблема. хватит мол экономить на байтах.

Я в этом не эксперт. Но моё понимание такое: иммубательное ФП хорошо для процессоров с огромным числом ядер. Там работает модель с акторами, передачей сообщений. Чтобы было минимум синхронизаций через общую память. В идеале общей памяти вообще не должно быть. В 2012 году вероятно было представление, что число ядер будет расти. Правда расти оно начало лишь спустя 8 лет. В общем, имхо, когда у нас в ноутбуках будут тысячеядерные процессоры, в этом будет смысл.

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

А ещё в последние годы всё актуальней встаёт вопрос безопасности со всех сторон.

Здравствуйте, gyraboo, Вы писали:

BE>>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

R>>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.

G>Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.

Ничего не мешает монолиту быть масштабируемым.

Здравствуйте, vsb, Вы писали:

G>>Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.

vsb>Ничего не мешает монолиту быть масштабируемым.

Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.

Здравствуйте, BlackEric, Вы писали:

BE>На хабре есть перевод довольно интересной статьи: Распутывание микросервисов или балансировка сложности в распределенных системах.

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

То что сервисы (микросервисов не бывает) должны быть крайним средством — это факт. Но вот монолиты тоже не вариант, так как их сложно поддерживать.

BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
Я встречал. В Амазоне это сделано наиболее правильно из всего, что я видел. Границы сервисов — это границы команд. И публичный интерфейс сервисов — это то, о чём договорились на берегу.

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

Здравствуйте, Cyberax, Вы писали:

BE>>На хабре есть перевод довольно интересной статьи: Распутывание микросервисов или балансировка сложности в распределенных системах.

C>

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

C>То что сервисы (микросервисов не бывает) должны быть крайним средством — это факт. Но вот монолиты тоже не вариант, так как их сложно поддерживать.

BE>>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
C>Я встречал. В Амазоне это сделано наиболее правильно из всего, что я видел. Границы сервисов — это границы команд. И публичный интерфейс сервисов — это то, о чём договорились на берегу.

BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
C>При масштабах, на которых нужны сервисы, обычно данные одним запросом вытащить уже вообще нельзя.

Будущее за в меру упитанными и воспитанными микросервисами.

Здравствуйте, gyraboo, Вы писали:

G>Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.

Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.

Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.

Здравствуйте, vsb, Вы писали:

G>>Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.

vsb>Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.

vsb>Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.

Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.

Здравствуйте, gyraboo, Вы писали:

G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.

Это как раз не проблема. Указывать для какого юзера настройки необходимо все равно.
Гораздо серьезнее проблема что другие инстансы не сразу подхватывают изменение настроек сделанное на другом инстансе. А так как балансировщик обычно раскидывают клиентские подключения по случайным серверам начинаются проблемы пока кеш не обновится.

Здравствуйте, BlackEric, Вы писали:

G>>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.

BE>Это как раз не проблема. Указывать для какого юзера настройки необходимо все равно.
BE>Гораздо серьезнее проблема что другие инстансы не сразу подхватывают изменение настроек сделанное на другом инстансе. А так как балансировщик обычно раскидывают клиентские подключения по случайным серверам начинаются проблемы пока кеш не обновится.

Ну да, у монолита обычно локальный кэш, так надо распределенный кэш прикручивать, hazelcast или gridgain из коробки такое умеют. А это тоже шаг в сторону микросервисов. Правда у распределенного кэша всё равно остается задержка или рассогласование, но это уже неизбежное следствие любой распределённой системы, по теореме CAP — "выбирайте два из трёх".

Здравствуйте, gyraboo, Вы писали:

G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.

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

Я просто не согласен с тем, что это первый шаг к микросервисам. Это первый шаг к распределённой системе и скорей всего для подавляющего большинства проектов этот шаг будет последним, т.к. больше ничего и не нужно.

Здравствуйте, BlackEric, Вы писали:

BE>На хабре есть перевод довольно интересной статьи: Распутывание микросервисов или балансировка сложности в распределенных системах.

Посмотрел я на картинки, и что-то от них SOA пахнуло. Потом почитал немного — не ошибся. Их определение сервиса взято из Service Oriented Architecture. Вообще определения архитектур варьируются. Я дальше приведу те, которые использую сам (это enterprise integration patterns). Они дают очень четкое различие между SOA & Microservices.

Собственно, сервис на каждый бизнес-процесс — это один из характерных атрибутов SOA. Еще там обычно наблюдаются еще два уровня сервисов (инфраструктура — логи и т.п., и "бизнес-ядро" — всякие пользователи и прочие общие понятия). SOA идеально подходит для случаев, когда бизнес-сценарии включают множество шагов (потенциально — много ручных шагов). Например, "одобрить квартиру в ипотеку" — очень хороший кандидат на SOA. Там много внешних интеграций, процесс может включать осмотр квартиры специалистом и т.п. К сожалению, SOA вроде больше никуда не подходит.

BE>Где наконец-то говорится, что микросервисы это не так уж хорошо и не всегда применимо. В конце статьи очень интересный список ссылок.

Серебрянной пули нет, это известно было и до этого автора. Характерным критерием microservices architecture, которую учил я, является построение сервисов вокруг замкнутых контекстов (Bounded Context). Т.е. каждый сервис описывается в рамках "своей личной" модели. Микросервисы не допускают в API полей вида "userId — id пользователя в central user-management system", а SOA как раз допускает и даже приветствует. Условно, Backlog в статье имеет своих team и user (могут создаваться из других систем). Эти сущности могут иметь поля вроде externalId, но внутри самого сервиса эти поля не используются! Если выкинуть из первой картинки Backlog непонятную функцию "show item", получится неплохой микросервис.

Микросервисы устраняют проблемы (churn) вокруг широкоиспользуемых классов (вроде пользователя, базовых документов и т.п.) куда в монолите будут периодически пытаться писать много команд. Но зато создает проблемы синхронизации/репликации данных между сервисами и контекстами. Также усложняет UI/фасад, так как нет единого понятия "пользователь". Интерфейсным частям часто приходится ходить во много сервисов и собирать "полное" представление по частям. В общем, компромиссы.

BE>Кто как делает?

Я делаю микросервисы в моем определении (замкнутый контекст). Из артефактов реализации:

• База логически у каждого своя (физически — может быть один экземпляр db engine).
  
• Общение (push, в направлении зависимостей) в основном REST Level 2. Т.е. общение в терминах состояний а не операций.
  
• Передача данных "в обратном направлении" — обычно через message queues. Люблю rabbit, где клиенты могут _сами_ подписаться на нужные обмены (exchange). Наличие exchange и форматы сообщений — часть контракта сервиса.
  
• Есть разница между развертыванием (deployment) и сервисами (bounded context, роль в рамках большей системы). Один микросервис может иметь несколько различных компонент (т.е. несколько различных deployment unit). Эти компоненты могут ходить в базу и общаться по внутреннему протоколу. С точки зрения внешнего зрителя — это один среднего размера сервис.

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов.

Да, микросервисы делать сложнее по многим причинам. В какой-то книжке это прекрасно сформулированно было: если ваши разработчики не могут нормально сделать модульность в рамках одного монолита, то почему вы решили, что они смогут сделать нормальную модульность в рамках распределенной системы? Именно в дизайне модулей, разбиении на компоненты и начинаются проблемы. Всякие там зацепление и связность (coupling & cohesion). Почему-то не любят разработчики эти понятия. Разбивают систему на куски чисто механически. А в распределенной системе этот бардак становится заметен очень рано.

BE>В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

Так а это две стороны одной и той же медали. В микросервисах вам нужно согласовывать API между компонентами. В одной базе — согласовывать форматы данных хранения. Вот представьте, что моя команда сделала рефакторинг и переколбасила с десяток таблиц. Ваши sql запросы по вытаскиванию данных придется пересматривать. При определенной зрелости команды меньше согласований именно в микросервисах. Одна команда выкатила обратно-совместимый API (новые поля, новые content type, в крайнем случае — новые /api/vX). Затем туда переползают все пользователи сервиса, старый API отключается. Иногда так сделать нельзя, но очень часто все-же можно. Только это нужно уметь, а это задача вроде сложнее сортировки гномиков.

Здравствуйте, maxkar, Вы писали:.

M>Микросервисы устраняют проблемы (churn) вокруг широкоиспользуемых классов (вроде пользователя, базовых документов и т.п.) куда в монолите будут периодически пытаться писать много команд. Но зато создает проблемы синхронизации/репликации данных между сервисами и контекстами. Также усложняет UI/фасад, так как нет единого понятия "пользователь". Интерфейсным частям часто приходится ходить во много сервисов и собирать "полное" представление по частям. В общем, компромиссы.

Не по этой ли причине монолитный UI сейчас тоже пытаются разбить на микро? Фронтэндеры Тинькова вроде статью на Хабре об этом писали.

Здравствуйте, gyraboo, Вы писали:

G>Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования.

Согласен кроме слова "дешевого". Микросервисы требуют специфической экосистемы и рабочих процессов. Например там где в монолите можно обойтись локальным инт тестом, в микросервисной архитектуре нужно будет поднимать эту самую распределённую систему и тестировать её "снаружи". Там где в монолите у вас интерфейсы между модулями — на уровне ЯП, в распределённой системе нужна технология для удалённого взаимодействия. Да куча примеров.

G>Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.

Это только так кажется. Если бы вы изначально делали микросервисы, с большой вероятностью вообще до рынка не дошли бы — застряли бы на обслуживании самой этой микросервисности (без обид: либо у команды не было опыта с микросервисами, и поэтому стали делать монолит, либо был негативный опыт и _поэтому_ стали делать монолит . Вот вы начинаете проект — по какому критерию будете отдельные сервисы выделять?

Здравствуйте, gyraboo, Вы писали:

G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита.

Да ну. Крутить 3+ инстансов одного сервиса — это такой минимальный бест пректиз, который позволяет деплоить новые версии аппликейшна без даунтайма. Писать код в рассчёте на 1 инстанс — это по-моему 100% индикатор профнепригодности.

Здравствуйте, gyraboo, Вы писали:

G>Ну да, у монолита обычно локальный кэш

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

1. одна кодовая база
2. один деплоймент юнит
3. всё

Перестаёт ли монолит быть монолитом, если запустить его 5 инстансов? Нет, не перестаёт. Перестаёт ли монолит быть монолитом, если у него не локальный кэш, а несколько нодов редиса? Нет, не перестаёт. И т.д.

Здравствуйте, gyraboo, Вы писали:

G>Не по этой ли причине монолитный UI сейчас тоже пытаются разбить на микро? Фронтэндеры Тинькова вроде статью на Хабре об этом писали.

Причины те же, что и у микросервисов на бэкенде. Фронтэнд пилит не одна команда, а десяток. Команды появляются, исчезают, какие-то раньше, какие-то позже. Команды — разные. По квалификации, по предпочтениям, по темпераменту, по частоте релизов, и т.д. "Микрофронтэнды" позволяют этим командам действовать максимально независимо. Эти вон хотят писать на AngularJS, окей, нет проблем. Эти хотят на React — да ради бога. У вон тех по 4 релиза в день, на здоровье.

G>Не по этой ли причине монолитный UI сейчас тоже пытаются разбить на микро? Фронтэндеры Тинькова вроде статью на Хабре об этом писали.

Именно это и есть одна из реально важных причин, по которым микросервисы вообще пользуются популярностью. Чтобы разделить зоны ответственности команд. Наиболее надежным методом является необходимость общаться по сети. Там хошь не хошь, но придется продумать API.

В "монолите" же проблема в том, что если есть много команд, очень часто народ "прокручивает дырочки" в обход слоев разных API. Если это невозможно по чисто техническим причинам (нужно чтоб через сеть пролезало, однако), становится куда проще все это менеджить.

R>Да ну. Крутить 3+ инстансов одного сервиса — это такой минимальный бест пректиз, который позволяет деплоить новые версии аппликейшна без даунтайма. Писать код в рассчёте на 1 инстанс — это по-моему 100% индикатор профнепригодности.

Вы еще скажите, что отсутствие, скажем, staging environment, или test-only database является показателем профнепригодности. И очень много людей из FAANG почувствуют грусть, ибо очень часто сервисы (особенно внутренние) попросту не имеют инстансов. Есть только production, где с помощью разных ACL разделяются use-cases.

Здравствуйте, maxkar, Вы писали:


BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов.
M>Да, микросервисы делать сложнее по многим причинам. В какой-то книжке это прекрасно сформулированно было: если ваши разработчики не могут нормально сделать модульность в рамках одного монолита, то почему вы решили, что они смогут сделать нормальную модульность в рамках распределенной системы? Именно в дизайне модулей, разбиении на компоненты и начинаются проблемы. Всякие там зацепление и связность (coupling & cohesion). Почему-то не любят разработчики эти понятия. Разбивают систему на куски чисто механически. А в распределенной системе этот бардак становится заметен очень рано.
Так всетаки микросервисы проще монолитов или сложнее? Я везде вижу один аргумент в пользу микросервисов, что они проще и масштабировать их легче. А вы пишите что нет.


BE>>В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

M>Так а это две стороны одной и той же медали. В микросервисах вам нужно согласовывать API между компонентами. В одной базе — согласовывать форматы данных хранения. Вот представьте, что моя команда сделала рефакторинг и переколбасила с десяток таблиц. Ваши sql запросы по вытаскиванию данных придется пересматривать. При определенной зрелости команды меньше согласований именно в микросервисах. Одна команда выкатила обратно-совместимый API (новые поля, новые content type, в крайнем случае — новые /api/vX). Затем туда переползают все пользователи сервиса, старый API отключается. Иногда так сделать нельзя, но очень часто все-же можно. Только это нужно уметь, а это задача вроде сложнее сортировки гномиков.
При использовании правильных средств в монолитном приложении запросы проверяются при компиляции.

Здравствуйте, SkyDance, Вы писали:

R>>Да ну. Крутить 3+ инстансов одного сервиса — это такой минимальный бест пректиз, который позволяет деплоить новые версии аппликейшна без даунтайма. Писать код в рассчёте на 1 инстанс — это по-моему 100% индикатор профнепригодности.

SD>Вы еще скажите, что отсутствие, скажем, staging environment, или test-only database является показателем профнепригодности. И очень много людей из FAANG почувствуют грусть, ибо очень часто сервисы (особенно внутренние) попросту не имеют инстансов. Есть только production, где с помощью разных ACL разделяются use-cases.

Фаанг так делает не из-за того, что это охрененное решение, а из-за кучи ограничений с которыми ему нужно жить (легаси, развесистая экосистема, дохрена народу, и главное — желание максимально сократить время поставки правок в продакшн). Что они там делают — это совершенно точно не решение по умолчанию для всех, и не эталон к которому нужно стремиться.

Но я вообще не про энвайронменты писал. Я высказывал несогласие с заявлением коллеги:

монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита

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

BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.
А кто мешает в одной СУБД иметь несколько разных бд, или в одной бд иметь разные схемы для каждого сервиса?

BE>Кто как делает?
Несколько лет тому назад делал проект для сети местных больничек.
Так, вот был реализованы следущие сервисы: "Расписание врачей", "Лаборатория", "Мед.Карта" и ряд вспомогательных сервисов.
Так же разрабатывал архитектуру сервисов для энерегетической западной компании.

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
Я так не считаю.
А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах?
Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет.
За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?

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

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

P.S. Пример с распиливанием сервиса Backlog — на 8 раздельных сервисов — это крайне тупая вещь, и через эту крайне тупую вещь, заставляют принять мысль, что вся идея микросервисов — тупая.

Здравствуйте, vsb, Вы писали:


vsb>Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.

В некоторых проектах такое норм. В некоторых не прохиляет. Смотри пример. В одном из проектов нужно было распознавать объекты с потокового видео.
Так, вот сервис этот был ресурсозатратным и дорогим, естественно, его масштабировали при достижении пиковых нагрузок, разворачивая довольно дорогие инстансы виртуалок в облаке.
А был ряд сервисов по-проще, у которых нагрузка была гораздо меньшей. И за чем эти сервисы хостить на дорогих инстансах?
И тут встает финансовый вопрос. Если у нас монолит, то при необходимости масштабировать сервисы, которые требуют минимальных ресурсов, придется их деплоить на более производительные инстансы.
Или задача автоматического масштабирования становится очень интересной.

vsb>Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.
Тут дело не только в масштабировании бд.
Для сущностей одного домена лучше подойдет реляционная бд, для сущностей другого домена лучше подойдет джокументная бд, для сущностей 3-го домена, лучше подойдет графовая бд.
Понятно, что все можно запилить на реляционной БД, но в некоторых случаях — это будет сложнее.

P.S. В общем, все зависит от задачи.

Здравствуйте, BlackEric, Вы писали:

BE>Один сервис — один докер контейнер или ВМ. Иначе смысла нет. Даже перезапуск веб-сервера перезапускает все сервисы сразу. Ничем не будет отличаться от монолита.

А если веб-сервисов несколько контейнеров, и они спрятаны за nGinx? Тогда можно ребутать каждый контейнер без особых потерь. А если используется какой-нибудь распределённый In-memory storage для хранения сессий и прочего состояния, то вообще нет проблем ребутать, главное чтоб число одновременных онлайн-узлов не опускалось ниже требований репликатора.

Здравствуйте, gyraboo, Вы писали:

G>И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.

Я бы для начала в транзакции все завернул.

Здравствуйте, white_znake, Вы писали:

_>А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах?
_>Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет.
_>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?

Фантазируя — а если понадобится какая-то статистика/анализ зависимостей по больным, лабораториям и моделями оборудования лабораторий?
Как быть?

Здравствуйте, white_znake, Вы писали:

_>А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах?
_>Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет.
_>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?
Ну, например, первое, что приходит в голову — врачу, работающему с мед.картой, (да и пациенту на руки распечатку) надо отобразить так:
1. Вверху диалога — ФИО пациента (домен "Мед.карта"?)
2. Под ФИО таблицу со столбцами:

• Вид анализа (как минимум — это название из справочника, находящегося в домене "Лаборатория"?)
  
• Фактический результат (то, что реально обнаружили в лаборатории)
  
• Допустимые результаты (то, что считается нормой для данного людей данного пола/возраста и т.п.)

Вот уже в одной отчетной форме (в одном диалоге) имеем данные из двух доменов.
Можно, конечно, к справочнику "Видов анализа" обратиться через API сервиса "Лаборатория", а в таблице "Результаты_анализов_пациента" из сервиса "Мед.карта" хранить только ID вида анализа (GUID или некий строковый идентификатор).
Но ведь простой SQL-ный "INNER JOIN" будет проще.
Нет?

Здравствуйте, swimmers, Вы писали:

S>Здравствуйте, white_znake, Вы писали:

_>>А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах?
_>>Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет.
_>>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?

S>Фантазируя — а если понадобится какая-то статистика/анализ зависимостей по больным, лабораториям и моделями оборудования лабораторий?
S>Как быть?

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

Здравствуйте, stomsky, Вы писали:


S>Вот уже в одной отчетной форме (в одном диалоге) имеем данные из двух доменов.
Нет не имеем

S>Можно, конечно, к справочнику "Видов анализа" обратиться через API сервиса "Лаборатория", а в таблице "Результаты_анализов_пациента" из сервиса "Мед.карта" хранить только ID вида анализа (GUID или некий строковый
идентификатор).
Совсем не так. Есть общий информационный сервис-правочник с кодами исследований и болезней, который используется и в мед.картах и в лаборатории.
S>Но ведь простой SQL-ный "INNER JOIN" будет проще.
S>Нет?
Конечно нет, потому что мед.карты в реляционной субд, а результаты лабораторных исследований в NoSql бд.

Здравствуйте, white_znake, Вы писали:

_>А как связаны больные с используемым оборудованием? Из мед.кабинета в лабораторию уходит пробирка со штрихкодом и показателями, которые нужно исследовать, в мед.карте больного добавляется направление на анализ со штрихкодом и требуемыми показателями.
_>Из лаборатории приходит отчет со штрихкодом и результатами. Ни какой зависимости между больным и лабораторным оборудованием — нет.
_>В лаборатории не знают ни чего о пациенте.

А я не знаю, как связаны.
Это задача не уровня лаборатории.
Вдруг есть уникальные люди, у которых стандартный анализ на А на оборудовании Б имеет какие-то особенности?
Как их найти?
Или как найти какие-то другие неочевидные зависимости?

Здравствуйте, swimmers, Вы писали:


S>Вдруг есть уникальные люди, у которых стандартный анализ на А на оборудовании Б имеет какие-то особенности?
S>Как их найти?
S>Или как найти какие-то другие неочевидные зависимости?
Какие прекрасные фантазии
Но в лабораторию данные поступают обезличенные.

Ну ладно. Предположим, что случлась какая-то аномалия и нужно для конкретного направления на анализы (по штрих коду) получить данные о том, на каком оборудовании и с какими параметрами производились анализцы.
Не проблема. Добавим метод в REST API сервиса лаборатории о получении таких данных. Но это реально будет редкоиспользуемой фичей. Думается, что не каждый врач разбирается в настройках оборудования.

Здравствуйте, swimmers, Вы писали:

S>Как их найти?
S>Или как найти какие-то другие неочевидные зависимости?
Обычно подобное решается созданием специальных свалок данных, по которым можно безболезненно для production'а запускать аналитику.

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

Здравствуйте, white_znake, Вы писали:

S>>Вот уже в одной отчетной форме (в одном диалоге) имеем данные из двух доменов.
_>Нет не имеем


_>Совсем не так. Есть общий информационный сервис-правочник с кодами исследований и болезней, который используется и в мед.картах и в лаборатории.
Отлично. То есть на самом деле тут три сервиса — справочник, лаборатория, и мед.карты. И простая штука "результат исследования" в PDF генерируется из данных трёх сервисов. Я правильно понял?
Кстати — какой из сервисов за этот PDF отвечает: медкарты, лаборатория, или справочник?

_>Конечно нет, потому что мед.карты в реляционной субд, а результаты лабораторных исследований в NoSql бд.
Стесняюсь спросить: а зачем? Что там у нас такого в лабораторных исследованиях, что не ложится в какой-нибудь банальный postgres?

Здравствуйте, white_znake, Вы писали:

_>Из мед.кабинета в лабораторию уходит пробирка со штрихкодом и показателями, которые нужно исследовать, в мед.карте больного добавляется направление на анализ со штрихкодом и требуемыми показателями.
_>Из лаборатории приходит отчет со штрихкодом и результатами.
_>В лаборатории не знают ни чего о пациенте.
Это ты описал процесс, как он выглядит со стороны медиков (лечащий врач, передавший пробирку в лабораторию, и лаборант, проведший анализ содержимого пробирки).
А как это выглядит программно (для простоты считаем, что одна пробирка — один вид анализа)?
Предполагаю так (поправь меня):

1. лаборант, получив пробирку с биоматериалом внутри и штрихкодом снаружи, сканирует этот штрихкод
   
2. по ID пробирки (полученном из штрих-кода) в домен "Мед.карта" уходит запрос типа "Какой анализ надо сделать для пробирки с таким-то ID?"
   
3. из домена "Мед.карта" приходит ID типа анализа
   
4. в домене "Лаборатория" создается некий объект типа "Проведение анализа" с указанием ID пробирки и ID типа анализа
   
5. из домена "Лаборатория" в домен "Справочники" уходит запрос типа "Что это за тип анализа с таким-то ID типа?"
   
6. из домена "Справочники" приходит ответ с описанием типа анализа
   
7. лаборант, прочитал задание, провел анализ, внес результаты (которые сразу улетели в домен "Мед.карта"), а в домене "Лаборатория" у добавленного выше объекта "Проведение анализа" выставляется статус "Выполнено, передано в Мед.карту".
   
8. в домене "Мед.карта" полученные результаты сохраняются и проставляется признак, что результаты анализов получены

Примерно так?
Ну тогда отвечая на твой изначальный вопрос:
_>>>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?
могу сказать, что как раз связь с доменом "Справочники" очень хочется сделать "INNER JOIN"-ом.
Но сделать так нельзя, потому, что справочник типов анализа должен быть доступен из обоих прикладных доменов: и для "Мед.карты", и для "Лаборатории".

Здравствуйте, Sinclair, Вы писали:

_>>Совсем не так. Есть общий информационный сервис-правочник с кодами исследований и болезней, который используется и в мед.картах и в лаборатории.
S>Отлично. То есть на самом деле тут три сервиса — справочник, лаборатория, и мед.карты. И простая штука "результат исследования" в PDF генерируется из данных трёх сервисов. Я правильно понял?
S>Кстати — какой из сервисов за этот PDF отвечает: медкарты, лаборатория, или справочник?

Вокрфлоу здорового человека:
1. "лаборатория" подключаясь к системе отдает capabilities, что она умеет измерять и как она это делает.
2. "клиника" направляет биоматериал пациента (в том числе в виде целикового человка) в "лабораторию". На этом этапе биоматериал анонимизируется, ибо закон о медицинских данных.
3. "лаборатория" присылает результат исследования обогащенный метаданными о том что, как и с какими погрешностями измерялось. Однажды сделанные исследования уже нельзя поправлять задним числом.
4. "клиника" включает результаты исследований в медицинскую карту и ставит диагноз. Опять же, однажды поставленный диагноз уже нельзя просто так убрать.

Если завтра в capabilities лаборатории изменятся, это никак не должно повлиять на уже сделанные анализы. Если завтра примут МКБ-12, то и это никак не должно повлиять на уже сделанные анализы и назначения.

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

S>Стесняюсь спросить: а зачем? Что там у нас такого в лабораторных исследованиях, что не ложится в какой-нибудь банальный postgres?

Например, там может быть какой-нибудь DICOM сервер, в том числе и физически встроенный в томограф. Кроме того, результат исследования это достаточно сложная штука. Пациенту показывается только финальный результат, когда в реальности лаборатория может оперировать на несколько порядков большим объемом промежуточных данных часть из которых имеет смысл хранить. Включая, например, физические "стекла" по которым смотрели гистологию.

Здравствуйте, Sinclair, Вы писали:

_>>Конечно нет, потому что мед.карты в реляционной субд, а результаты лабораторных исследований в NoSql бд.
S>Стесняюсь спросить: а зачем? Что там у нас такого в лабораторных исследованиях, что не ложится в какой-нибудь банальный postgres?
Рентгеновские или МРТ-снимки, аннотированные результаты ДНК-тестов, например.

Здравствуйте, Miroff, Вы писали:

M>1. "лаборатория" подключаясь к системе отдает capabilities, что она умеет измерять и как она это делает.
Ну ты немного другую архитектуру описал. У тебя справочник видов анализов (capabilities) хранится в "Лаборатории", а у white_znake он вынесен в отдельный сервис "Справочники":
_>>>Совсем не так. Есть общий информационный сервис-правочник с кодами исследований и болезней, который используется и в мед.картах и в лаборатории.
Т.е., если я правильно понимаю, у него "Мед.карта" и "Лаборатория" хранят только ID видов анализов. А детализация этих ID тянется из другого сервиса.

Здравствуйте, Miroff, Вы писали:

S>>Кстати — какой из сервисов за этот PDF отвечает: медкарты, лаборатория, или справочник?
M>Вокрфлоу здорового человека:
А теперь как это работает в РЕАЛЬНОЙ системе (LabCorp) по состоянию на примерно 3 года назад.

M>1. "лаборатория" подключаясь к системе отдает capabilities, что она умеет измерять и как она это делает.
Подключение к лаборатории пишется отдельной интеграцией, со своим кодом и отдельными ужимками. Тесты пишутся в контракте и имеют стандартные коды (из общегосударственного справочника), специальные тесты имеют коды из приватного диапазона.

M>2. "клиника" направляет биоматериал пациента (в том числе в виде целикового человка) в "лабораторию". На этом этапе биоматериал анонимизируется, ибо закон о медицинских данных.
Клиника отправляет в лабораторию запрос. Путём отсылки файла через FTP. Файл зашифрован с помощью PGP публичным ключом, который напечатали внутри контракта.

Файл — это XML специальной схемы. В нём данные пациента, включая идентификационные и биллинговые. Это, в частности, нужно для того, чтобы в лаборатории можно было подтвердить имя и дату рождения пациента.

M>3. "лаборатория" присылает результат исследования обогащенный метаданными о том что, как и с какими погрешностями измерялось. Однажды сделанные исследования уже нельзя поправлять задним числом.
Статус исследований и результаты раз в несколько часов выкладываются на FTP, откуда их клиника может забрать.

Альтернативный вариант — это лаборатория их посылает по факсу на указанный в заявке номер. Кстати, заявку прислать можно тоже по факсу.

M>4. "клиника" включает результаты исследований в медицинскую карту и ставит диагноз. Опять же, однажды поставленный диагноз уже нельзя просто так убрать.
Это примерно так. Хотя медицинские записи можно редактировать (исправлять ошибки, например), в том числе по требованию пациента.

Потом ещё есть пункт 5. — биллинг. С workflow, который похож на Ктулху. Так как заявку должна одобрить страховая, которая может выставить претензию доктору, и так до бесконечности.

M>Если завтра в capabilities лаборатории изменятся, это никак не должно повлиять на уже сделанные анализы. Если завтра примут МКБ-12, то и это никак не должно повлиять на уже сделанные анализы и назначения.
Ха. В США переключение на новую систему кодов заняло всего-ничего 20 лет.

Вот так выглядят сервисы в реальной жизни, когда они работают с реальными данными.

Здравствуйте, gandjustas, Вы писали:

G>Так всетаки микросервисы проще монолитов или сложнее?

Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.

На архитектурном уровне вместе с микросервисами приходит eventual consistency. В монолите можно сделать большую транзакцию, в микросервисах — в целом нет. Распределенные транзакции идее микросервисов противоречат и технически вряд ли возможны (у каждого сервиса может быть свой стек технологий). Эта неконсистентность сразу вызывает вопросы надежности (reliability). Очень часто нужно уметь надежно доставлять состояние между сервисами. Или надежно знать, что данные не доставлены. А в HTTP есть состояние неопределенности. Запрос отправили, ответ не получили. И вот что это значит? Сервер запрос вообще не получил? Или получил, обработал, но ответ отправить не сумел? Поэтому практически в каждом с сервисе с зависимостями возникает необходимость повторов (retry) и соответствующих внутренних состояний. Кроме того, в сервисах с зависимостями есть проблема устойчивости (robustness). Например, сервис A вызывает сервис Б. Сервис Б обычно отвечал за 10 миллисекунд, а стал — за 10 секунд. Вопрос — что будет с сервисом A? Я видел ситуацию, когда пул HTTP-соединений между A->Б был установлен в настройки по умолчанию (и это было четыре соединения). Поэтому все операции выстраивались в длинную очередь и латентность ответов от А взлетала до небес.

Выше — это архитектурные и технические вопросы. Есть еще операционные: мониторинг (и не "как попало", а чтобы было удобно и более-менее понятно, что происходит с конкретным сервисом), CI, развертывание. Каждая команда должна уметь делать QA, performance и security на неплохом уровне. При большом количестве команд тестировать "в среде/environment" становится сложно — нужно согласовывать тестовые данные, расписания работы сервисов (а вдруг мы задеплоили и что-то сломали?), нагрузку (параллельные perf test имеют много шансов упасть). Это решается эмуляторами зависимостей, но их же кто-то должен писать. А это — время и силы.

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

На самом деле после некоторой практики все из вышеописанного совершенно не сложно. Но вот стартовать без наработок долго. Обучать команду всем аспектам — тоже.

G> Я везде вижу один аргумент в пользу микросервисов, что они проще и масштабировать их легче. А вы пишите что нет.

Масштабировать сервисы — в целом да, проще. Микросервисы стартуют быстрее, да и масштабироваться будут только те части, на которые приходится нагрузка. Но во многих случаях узким местом является база данных. А там сервисы особо масштабировать не приходится. Если использовать асинхронность, несколько инстансов сервиса запросто упрутся именно в базу. При масштабируемом хранилище (что нужно закладывать при разработке!) — да, все чуть лучше.

А "проще" — это из-за некорректного сравнения происходит. Монолит и "микросервисы" имеют несравнимый возраст и историю. Смотрите, что происходит. Есть начальная команда, которая разрабатывает продукт. Это монолит, со внутренней модульюностью и более-менее успешной архитектурой. В течение 5 лет половина команды уходит на новые проекты. Другую половину эффективные менеджеры заменяют на более дешевых и управляемых сговорчивых разработчиков. Это поколение немножко забивает на границы между модулями и вводит ненужную связность. В коде образуется лишний coupling, но зато тикеты закрываются легко и весело. Приложение постепенно превращается в макаронного монстра (spaghetti monster). За следующие 5 лет половина разработчиков успешно фрустрирует и уходит. Другую половину эффективные менеджеры увольняют из-за снизившейся производительности (tech debt мешает, да) и нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами. Система может разиваться еще какое-то время. Еще через 5 лет организация получает уже распределенного макаронного монстра. И здесь вариантов уже совсем мало. Либо вообще закрыть продукт (через 15 лет много шансов, что он будет и так не нужен), либо нанимать специалистов за много денег приводить все это в порядок.

Т.е. "проще" — это обычно в условиях, когда монолит уже запущен и там скорее "совсем никак" с теми ресурсами, которые имеются в наличии. Еще на "проще" влияет первое впечатление. Пока сервисов мало (меньше 10) нефункциональные требования (reliability & co) не особо влияют. "Один" сервис в серднем скорее работает, чем нет. А вот когда сервисов много, начинаются отказы (просто статистически, когда сервисов много, больше шансов, что в каждый момент хоть что-то не работает). Так как про устойчивость (robustness) на начальных этапах "забывают", вся система регулярно рушится с громким грохотом.

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

G>При использовании правильных средств в монолитном приложении запросы проверяются при компиляции.

Дело не в ошибках. Дело в количестве и (очень часто) черезмерной связанности (coupling). Там запросто правки вида "здесь всего в 5 местах поменять" преврашаются в приключение "оказалось, оно используется в 25 местах!". А потом через две недели вы внезапно узнаете, что этим рефакторингом еще и сорвали сроки релиза. Потому что другая команда тоже делала рефакторинг где-то в другом месте. Но несколько из этих 25 мест попали в затронутый ими код. И теперь им нужно еще несколько дней на все исправить, проверить и смержиться. Почему раньше не узнали? Да потому, что до них только сейчас дошла очередь мержится. А мержить master в рабочую ветку и гонять CI на каждое изменение там — слишком накладно. И это вполне типичная ситуация.

Здравствуйте, stomsky, Вы писали:

S>Примерно так?

Если это из "как можно делать" — может быть. А вот микросервисы не получаются — в описании нет замкнутыых контествов ("bounded context") у сервисов. Тут Miroff и Cyberax прекрасно описали, как оно может быть и как бывает на практики. Даже в случае с FTP домены у клиники и лаборатории свои! Стороны общаются по протоколу. Часть вещей используют общие идентификаторы (например, стандартный классификатор анализов). То, что там FTP и опросы (polling) концептуально ничего не меняет.

S>могу сказать, что как раз связь с доменом "Справочники" очень хочется сделать "INNER JOIN"-ом.
S>Но сделать так нельзя, потому, что справочник типов анализа должен быть доступен из обоих прикладных доменов: и для "Мед.карты", и для "Лаборатории".

Нет! Вы очень хотите сделать большой объект "справочник", который содержит кучу полей, используемых только в специальных ситуация. А на самом деле у вас разные домены и разные справочники. Для "мед карты" вам нужен вообще стандартный классификатор. Для больницы/терапии вам нужен терапевтический справочник. Т.е. какие диагнозы подтверждает анализ, границы нормы, плюсы/минусы данного типа анализов, альтернативы и дополнительные исследования. Справочник больницы может иметь ссылки на лаборатории (или поддерживаемые интеграции). А лаборатории нужен операционный справочник. Там написано, как проводить анализ, на каком оборудовании, сроки хранения материала, правила утилизации и т.п. Ее справочник может содержать (или включать) справочники на конкретные типы оборудования. Т.е. "используйте аппарат АБС, следуйте инструкции производителя здесь". И вот зачем вам в карте информация о том, какие коды нужно вводить на панели автоматизированного анализатора?

Что вам нужно, это некоторое согласование между доменами (карта — просто текст, больница — терапевтические данные, лаборатория — операционные). Для этого как раз используются стандартные коды и согласование справочников (по коду из внутреннего справочника можно получить коды во внешних). В крайнем случае — протаскивание кодов из мноих источников (т.е. в карте может быть текст, внутренний код лаборатори и отдельно код терапии). И join будет уже делаться с конкретной копией справочника в правильном домене.

Здравствуйте, rosencrantz, Вы писали:

R>Микросервисность — это в первую очередь про изоляцию команд друг от друга.

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

Микросервисы и команды это перпендикулярные понятия. Всё что нужно для разделения на команды — это чётко очерченые скоупы функциональности и чёткие программные интерфейсы. Да, микросервисы форсят появление чётких скоупов функциональности и уж точно форсят появление чётких программных интерфейсов, но всё это возможно и без микросервисов. Windows, Linux, Microsoft Office, 1C, и прочие гроамадные продукты делают тысячи, десятки тысяч человек, а это самые что ни на есть монолиты. Поэтому не надо ставить телегу впереди лошади, пожалуйста. Микросервисы это про горизонтальное масштабирование и resilience, изоляция команд здесь глубоко вторична.

Здравствуйте, Умака Кумакаки, Вы писали:

УК>Здравствуйте, rosencrantz, Вы писали:

R>>Микросервисность — это в первую очередь про изоляцию команд друг от друга.

УК>найти бы того дурачка который это написал изначально, а то в каждом первом топике про микросервисы слышу. Видимо нулевой идиот был менеджером.

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

УК>Микросервисы и команды это перпендикулярные понятия. Всё что нужно для разделения на команды — это чётко очерченые скоупы функциональности и чёткие программные интерфейсы. Да, микросервисы форсят появление чётких скоупов функциональности и уж точно форсят появление чётких программных интерфейсов, но всё это возможно и без микросервисов.

В ваших суждениях вы упускаете важную деталь: система это не только "начинка" (функциональность, интерфейсы — о чём вы пишете), но ещё и её жизненный цикл (о чём вы не пишете): как система появляется, как сопровождается, как ретайрится. Монолитный подход предлагает "систему, состоящую из подсистем" (жизненный цикл подсистем "подчиняется" жизненному циклу системы). Микросервисный подход предлагает "систему систем" (жизненный цикл у каждой системы — свой). Именно из этого отличия вытекает идея "изоляции команд" — у команд появляется возможность самостоятельно решить что, как и когда они будут делать. А так вы правы, да, если жизненные циклы игнорировать, один хрен.

УК>Windows, Linux, Microsoft Office, 1C, и прочие гроамадные продукты делают тысячи, десятки тысяч человек, а это самые что ни на есть монолиты. Поэтому не надо ставить телегу впереди лошади, пожалуйста.

Вот вы когда говорите Windows — вы что конкретно имеете в виду? Если смотреть с точки зрения продукта для конечного пользователя, Windows — это не монолит. Грубо одна команда делает ОС и выпускает когда хочет, другая команда делает Офис и выпускает когда хочет, параллельно с этим есть ещё маленькие команды, которые пилят улучшенный терминал и прочее такое. Люди — разные. Инструменты у них разные. Каденс релизов разный. Слово "микросервисный" тут конечно выглядит несколько нелепо, но вообще чем не микросервисы?

Здравствуйте, stomsky, Вы писали:

S>Здравствуйте, Miroff, Вы писали:

S>Ну ты немного другую архитектуру описал. У тебя справочник видов анализов (capabilities) хранится в "Лаборатории", а у white_znake он вынесен в отдельный сервис "Справочники":

Именно! Сервисы, хоть микро, хоть макро, определяются тем, что они делают, а не тем какие данных они хранят. Проектирование от данных, а не от обязанностей, это вернейший способ превратить любой проект в алтарь поклонения макаронному монстру.


Взять сервис "Справочники", что полезного он делает? Ничего не делает. Как он будет обрабатывать ситуацию когда есть две лаборатории, у которых отличаются наборы анализов? Или если у лаборатории ограниченная пропускная способность по какому-то исследованию. Никак не будет, если его не связать жестко с лабораторией. Наличие обязательно жесткой связи это хороший такой звоночек что граница сервиса выбрана неудачно.

Здравствуйте, BlackEric, Вы писали:

BE>На хабре есть перевод довольно интересной статьи: Распутывание микросервисов или балансировка сложности в распределенных системах.

BE>Где наконец-то говорится, что микросервисы это не так уж хорошо и не всегда применимо. В конце статьи очень интересный список ссылок.

BE>

BE>Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

BE>Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
BE>Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему.
BE>А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.

BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.

BE>Кто как делает?

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.

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

Здравствуйте, BlackEric, Вы писали:

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки

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

Здравствуйте, maxkar, Вы писали:

M>Это решается эмуляторами зависимостей, но их же кто-то должен писать. А это — время и силы.

Это что за зверь такой, на каком уровне он работает? На уровне api? Где про это почитать?

Здравствуйте, Sharov, Вы писали:

S>Это что за зверь такой, на каком уровне он работает? На уровне api? Где про это почитать?

Да, это такой мок, но уже для целого внешнего приложения. Взаимодействие — через API. Точно так же, как с реальной системой. Обычно эмулируются внешние http-сервисы, но можно еще и всякие очереди сообщений обрабатывать. В зависимости от того, как именно у вас процесс построен, симулятор может запускаться отдельным приложением или изнутри теста (поднимать временный веб-сервис, опускать после завершения теста). Где почитать — не знаю, мы независимо это изобрели в рамках велосипедостроения .

Собственно, история. Мы первые симуляторы начали делать для проверки/тестирования нетривиальных настроек http-клиентов (у нас с десяток сервисов, использующих разные библиотеки). Если с базами данных более-менее все понятно (там соединений единицы, большинство пулов имеют какой-то разумный таймаут), то с http-клиентами беда. В них совершенно детское количество одновременных соединений (2-4 на целевой хост) по-умолчанию. В добавое еще огромные таймауты на все запросы и ожидание соединения из пула. Так что хотелось иметь возможность видеть, что оно не работает, а после изменения — работает. Поэтому на коленке были собраны простенькие симуляторы под каждое приложение. Почти все нужное (вроде асинхронных http-серверов на монадах) у нас было. Нужно было дописать только асинхронный sleep. Симуляторы были без логики, ответы — это подстановка одного-двух параметров в хардкоженый шаблон ответа. Ну и вообще работа с ними была плюс-минус ручная на первом этапе. Дописал метод, заменил вызов в маршрутизации на новый — и готово.

Следующим этапом было внедрение этих технологий в CI в новые сервисы (уже не для настройки пулов). Разработчикам было лень писать симулятор под каждый проект. Поэтому они написали один универсальный. Ему передается список URL, ответы и задержки для них. Конфигурация на отдельном порту. Поэтому в симуляторе можно вообще что угодно делать. Интеграционные тесты по необходимости конфигурируют ответы и гоняют сервис. И еще. Для CI есть обвязка, которая деплоит симулятор в кубернетес и настраивает приложение на его использование. Потом тесты деплоят приложение (с правильными лимитами) и все тестируется. Если поднимать сервер внутри тестового кода, в CI будет очень сложно передать правильный адрес (тест работает где-нибудь на worker node в совершенно другом пуле).

Эти симуляторы очень хорошо легли на нашу концепцию тестирования. У нас основные тесты — интеграционные. В коде много ручных частей, включая sql-запросы в базу и ручная же сериализация/парсинг в dto и внутренние структуры (зачем — отдельный большой разговор). И если парсинг еще можно проверить в юнит-тесте, то sql-запросы — нет. Поэтому автоматически нужна база и тесты становятся интеграционными. С эмуляторами можно проверить все уровни обработки сразу. Также можно эмулировать отказы (коды ошибок, таймауты и т.п.). Инфраструктура у нас со свободными лицензиями, поэтому можно все необходимое поднять локально. Разработчик может хоть в лесу сервис запускать и тестировать. А еще у нас build tool умеет запускать только "изменившиеся или упавшие тесты" в приложении. Поэтому в типичных сценариях разработки/отладки запускаются только релевантные сценарии. В общем, это все здорово уменьшает время обратной связи. Позволяет делать простые регрессии (можно взять реальный ответ сервера и сделать из него тестовый сценарий). Все это можно запускать на всех этапах начиная с локальной разработки и заканчивая CI. Вся эта схема еще и достаточно стабильна — тесты не падают из-за того, что что-то происходит с другой системой.

Сейчас у нас в коде идут сервис и симулятор его зависимостей. В планах переделать на "сервис и симулятор этого же сервиса". Симулятор публиковать в репозиторий. В этом случае CI может выкачивать симуляторы зависимостей и гонять тесты на них. Цель — чтобы симулятор был к коду основного приложения (он может и какую-то часть кода использовать). В этом случае при изменении API/поведения больше шансов сразу получить и обновленный симулятор. И следующий CI у пользователей уже будет тестировать код с использованием новой версии. Т.е. интеграционные ошибки будут находиться еще раньше. Но это пока мечты

Если что интересно — спрашивайте. Расскажу подробнее.

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, Sharov, Вы писали:

M>Если что интересно — спрашивайте. Расскажу подробнее.

Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена. Предполагаем, что сервис примитивный, например складывает два числа и разного рода мастер-бд отсутствуют?

Здравствуйте, Qulac, Вы писали:

Q>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.

Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для нового сервиса есть некоторая специфика. Процесс примерно следующий:

1. Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете . Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час.
   
2. Залить в source control, сделать MR.
   
3. Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее).
   
4. Дождаться аппрува на MR
   
5. Смержить
   
6. Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке.
   
7. Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно.
   
8. Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут.
   
9. Проверить, что логи видны.
   
10. Подумать про alerts. Сделать их или решить, что не нужно.

Вот это то, что у нас считается production приложением. И все из этого входит в норматив.

Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, Qulac, Вы писали:

Q>>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.

M>Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для нового сервиса есть некоторая специфика. Процесс примерно следующий:
M>

M>
1. Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете . Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час.
   M>
2. Залить в source control, сделать MR.
   M>
3. Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее).
   M>
4. Дождаться аппрува на MR
   M>
5. Смержить
   M>
6. Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке.
   M>
7. Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно.
   M>
8. Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут.
   M>
9. Проверить, что логи видны.
   M>
10. Подумать про alerts. Сделать их или решить, что не нужно.
    M>

M>Вот это то, что у нас считается production приложением. И все из этого входит в норматив.

M>Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.

Спасибо. Но по моему это очень долго.

Здравствуйте, Qulac, Вы писали:

Q>Спасибо. Но по моему это очень долго.
Расскажите про ваш процесс. Лично я — очень впечатлён.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>Спасибо. Но по моему это очень долго.
S>Расскажите про ваш процесс. Лично я — очень впечатлён.

У нас все "на коленке".

"Любая организация, которая строит системы... неизбежно произведет дизайн, структура которого является копией коммуникационной структуры организации". (с) Мелвин Конвей.

Конечно вместо статей на хабре я бы рекомендовал прочитать книгу от Сэма Ньюмена: "От монолита к микросервисам". Если еще не читали. Есть перевод на русском языке.

Там на эту тему идет более предметный разговор. С аргументами и доводами за и против.

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

Сделать микросервисы сложнее. Причем сделать правильно. И тут вопрос даже не в технических способностях. Посмотрите на цитату, с которой я начал этот пост. Вопрос, ни много ни мало, в организации разработки.
Это ничуть ни меньше про менеджмент разработки, чем про архитектуру. И это все более ни менее понимают. Поэтому так престижно говорить на конференции "А у нас микросервисы ...", остальные менеджеры/управленцы "Вау... да вы круты... Смогли организовать процесс!" Конечно, внутрь компании никто лезть не будет. Никто не будет выяснять есть ли там Entity Service в качестве антипаттерна.
Просто пойдет слух, что вот есть организация РосароконсалтТаргетинг у которой микросервисы и они передовые в плане выстраивания процессов.
Отсюда и беруться через пару лет все эти разочарования.

Но в самих микросервисах идея крайне простая и давным давно известная. Нужно сложную систему разбить на части и получить несколько слабо связанных между собой систем. У каждой системы своя команда. Свой деплой. Это известно уже тысячу лет... просто появился buzzword ну и некоторая систематизация практик и паттернов для этого.
И один из главных паттернов — если система не разбивается, то не разбивайте ее. Гемора получите больше выгод. Разве что где-то на конференции скажите "А у нас микросервисы..."

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, Qulac, Вы писали:

Q>>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.

M>Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для нового сервиса есть некоторая специфика. Процесс примерно следующий:
M>

M>
1. Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете . Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час.
   M>
2. Залить в source control, сделать MR.
   M>
3. Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее).
   M>
4. Дождаться аппрува на MR
   M>
5. Смержить
   M>
6. Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке.
   M>
7. Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно.
   M>
8. Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут.
   M>
9. Проверить, что логи видны.
   M>
10. Подумать про alerts. Сделать их или решить, что не нужно.
    M>

M>Вот это то, что у нас считается production приложением. И все из этого входит в норматив.
M>Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.

А какая предментая область, если не секрет? И кто придумал этот пайплайн -- скопипастили у кого-то или продиктовано бизнес
потребностями?

Здравствуйте, Sharov, Вы писали:

S>А какая предментая область, если не секрет?

B2B2C. Если совсем упрощенно, мы делаем некоторые сервисы для интернет-магазинов. Т.е. наши клиенты — интернет-магазины. Но наши (условно) плагины видны посетителям интернет-магазинов. Моя команада отвечает за платежи и все, что с ними связано.

S>И кто придумал этот пайплайн -- скопипастили у кого-то или продиктовано бизнес потребностями?

Скорее так исторически сложилось на основе организационной структуры. Когда-то давно, может, и скопировали. Но с тех пор практически все уже поменялось. Например, изначально CI разрабатывался вообще отдельной командой без какой-либо связи с продуктовыми командами. Разработчикам спускались инструкции "пишите так и только так" (в виде огромного boilerplate для каждого проекта). Сейчас ситуация меняется, появляется обратная связь и больше свободы. Promotion approval — по большей части исторические. Зависят от уровня паранойи у руководства. При этом считаюстся по худшей команде. Т.е. косячит одна команда, а репрессии устраивают всем. Тоже есть подвижки в сторону упрощения. Хотя конкретно у нас какая-то часть будет идти строго из-за специфики платежей. Мы вообще PCI-certified, для этого нужно немного бюрократии. Логи/алерты — смесь "глобальных технических инициатив" и конкретно нашей команды.

Многие части процесса или особенности наши (определяются внутри команды). Они нам подходят и какого-то особого недовольства не доставляют.

Boilerplate/skeleton — это заготовка с основными аспектами (каркас web-обработчиков, логи, мониторинг, деплоймент, база), принадлежит нашей команде. Вообще у нас в команде достаточно радикальная политика по отношению к фреймворкам и библиотекам: "Если библиотека/фреймворк не устраивает — можно (и даже рекомендуется) велосипедить так, чтобы было удобно". Я не хочу, чтобы мы тратили время только потому, что когда-то приняли формальное решение. Это повышает требования к качеству библиотек. И особенно — к их модульности. Так что, с одной стороны, мы на конкретном проекте можем изменить конкретный выбор. Например, не нравится веб-уровень — можно сделать другой (бюрократии нет, но причины нужно где-нибудь записать). Или решить отдавать метрики в другом формате. Или, например, использовать какой-то специфический слой для базы. Но это же значит, что мы не можем просто "включить фреймворк" в котором есть все (потому что в нем со временем может оказаться куча ненужного). Так и появляесят полуфабрикат — все вроде есть, но можно открутить (сейчас или потом) что угодно. Стандартный набор велосипедов и деталей у нас удачный. Так что "взять базу и выпилить лишнее" работает хорошо и в краткосрочной, и в долгой перспективах.

Merge request — это правила хорошего тона уже практически везде. Плюс по нашим процессам я почти во всех outages участвую в группе поддержки. Поэтому мне лично интересно, чтобы если что-то падало, то падало в одном месте и заметно. А не отдавалось фантомными болями где-то далеко-далеко. И у меня обычно есть возможность быстро переключиться с текущей задачи и сделать ревью. CI у нас делает pre-merge. Проходит оно быстро (меньше 10 минут обычно), типичное ревью занимает больше времени. Так что merge check нас не замедляет. Иногда он даже падает (иначе бы упало после мержа), так что некоторая польза есть. А еще у нас члены команды имеют разные интересы (кому-то интереснее технические детали, кому-то — бизнес) и ревью дает разносторонние отзывы.

Так как мы платежи, тестироваться интеграционно с реальными системами нам сложно. А тестирование в pre-merge еще и не ложится в environments. Здесь нам очень помогают различные эмуляторы. Заодно мы можем эмулировать "особенности" наших поставщиков услуг. Заодно упрощается и локальная разработка. Честные "интеграционные" тесты мы тоже делаем вручную, но это долго, сложно и не автоматизируется.

Promotion я уже сказал. Частично — исторически-бюрократические, частично — для PCI и прочего legal.

Метрики — фишка нашей команды. Я лично считаю, что найти что-то в логах на хоть какой-то интересной нагрузке (допустим, мизерные 100 запросов в минуту) становится практически не реально. Если добавить несколько экземпляров сервиса и несколько других систем, все становится очень печально. В метриках можно делать почти все то же, что в логах (вместе с записью исключения можно и счетчик увеличить). Потом мы можем сначала посмотреть на дашборды а потом прогнать какие-нибудь ручные запросы по метрикам. Т.е. тормозит "все" или конкретные типы запросов? Привязано это к отдельной машине или медленно везде? Что у нас с вызовами persistence и внешних сервисов? И все это в динамике (сейчас, час назад, "обычно").

Логи в нашей организации — отдельная грустная история. Чтобы логи были полезны, они должны содержать достаточно информации. Поэтму они становятся "большими". Бизнес жалуется, что все дорого и просит логи почикать. А почиканные логи становятся бесполезными. В рамках "дорого" мы еще и несколько миграций logging system сделали. Поэтому "проверить, что логи видны" — суровая необходимость. Мало-ли что отвалится. А конкретные exception traces все же бывают полезны. Обычно уже после того, как что-то нашли в метриках. Или для новой функциональности, когда у нас все работает с тестовой средой вендора, а в production все ну совсем по-другому. Поэтому полностью отказаться от логов мы тоже не можем.

Alerts — это еще сверху к логам и метрикам. Мы 24/7 работаем и вроде как в надежности хотим минимум 99.9% доступности. Поэтому нужны alerts. Желательно — до того, как наши клиенты начали жаловаться (это добавляет необходимость успокаивать нашу команду поддержки). Обычно все сводится к "вендор упал — звоните им и спрашивайте", но иногда бывает и интереснее.

Лично мне процесс в целом нравится. Команде — тоже. Некоторые вещи можно сделать лучше, но не все зависит от нас. Alerts происходят напрямую из бизнес-требований. Часть — была задолго до меня (и вообще до нашей команды). Почти половину мы сделали сами в команде для себя. Если переводить на язык бизнеса — уменьшает время на разработку (boilerplate — локально и "сейчас", принципы — для того, чтобы в будущем не застопориться на каких-нибудь несовершенствах). Еще мы повышаем надежность в ревью/тестировании (вклад в количество девяток). Также имеем хороший observability (т.е. меньше времени требуется на обнаружение и исправление проблем, тоже в девятки идет).

Здравствуйте, BlackEric, Вы писали:

BE>Где наконец-то говорится

Наконец-то? Типа ты раньше об этом никогда не слышал?

BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.

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

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

Ну и? Чем это не микросервисно?

BE>А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.

Это тоже вполне себе microservices way.

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

Т.е. тебя только РСУБД пугают?

Здравствуйте, Nikita Lyapin, Вы писали:

NL>"Любая организация, которая строит системы... неизбежно произведет дизайн, структура которого является копией коммуникационной структуры организации". (с) Мелвин Конвей.

Хрень полная.

NL>Во-первых никто и не призывает везде лепить микросервисы.

Вот прям уж так и никто?

NL>Сделать микросервисы сложнее. Причем сделать правильно.

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

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

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

NL>И один из главных паттернов — если система не разбивается, то не разбивайте ее.

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

Здравствуйте, vaa, Вы писали:

vaa>там он предлагает уходит от "программирования на месте" к иммутабельному ФП аргументируя это тем что уже 5-10 лет железо не проблема. хватит мол экономить на байтах.

Ну да, в 2012 для некоторых может оно так и было. А в 2021 каждый сэкономленный байт выливается во вполне конкретные деньги, не потраченные на лишнюю ВМ.

Здравствуйте, Умака Кумакаки, Вы писали:

УК>Микросервисы и команды это перпендикулярные понятия.

Это прямо противоречит определению микросервисов.

A microservice architecture – a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely-coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The goal is that teams can bring their services to life independent of others.

Если кто то делает микросервисы, но при этом они перпендикулярны командам — это карго культ в чистом виде.

Здравствуйте, gyraboo, Вы писали:

G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита.

Здесь нет никакой связи с монолитной архитектурой. Либо приложение проектируется под один инстанс (что нынче редкость, потому что, помимо масштабируемости естиь еще и high availability), либо под несколько. А попытка притянуть сюда микросервисы похоже на необходимость придумать хоть что то, что оправдывает лишние телодвижения в разработке.

Здравствуйте, gyraboo, Вы писали:

G>А разве не возможность делать изи горизонтальное масштабирование?

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

Представь, что у тебя система из 30 сервисов, у каждого своя база/монга/редис/memcached все они связаны кафкой/кроликом и дергают друг-друга внутри. Здесь хотя бы начальные ресурсы на все расчитать, не говоря уже о том, что их потом надо научиться масштабировать от нагрузки.

Здравствуйте, Ziaw, Вы писали:

G>>А разве не возможность делать изи горизонтальное масштабирование?

Z>Масштабирование становится совсем не изи, одна попытка определить, какие микросервисы в системе из нескольких десятков нужно масштабировать и по каким метрикам — отдельная работа тянущая минимум на десятки часов.

Z>Представь, что у тебя система из 30 сервисов, у каждого своя база/монга/редис/memcached все они связаны кафкой/кроликом и дергают друг-друга внутри. Здесь хотя бы начальные ресурсы на все расчитать, не говоря уже о том, что их потом надо научиться масштабировать от нагрузки.

Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Здравствуйте, gyraboo, Вы писали:

G>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Так изи или нужен немалый труд нескольких команд специалистов? Про зрелость технологии дискутировать не буду, а вот то, что простые и дешевые решения на ней становятся дорогими и сложными это факт. Ну и цена ошибки просто зашкаливает, аналитики выдали что-то типа — сервис должен выдерживать работу 20к посетителей в час, а потом выясняется, что эти посетители приходят на событие в час в одно и то же время и логин 20к в течении минуты кладет все. Да и без этих ошибок, вывод состоит в том, что мы провели НТ и система не выдержала, надо увеличивать мощности или оптимизировть код. Потом начинается работа по апроксимации этого вывода в дорогие и неоднозначные решения, посколько сказать заранее сколько потребуется мощности в пике нагрузки или насколько мы сможем что-то оптимизировать можно с очень небольшой точностью, так как стоимость железа в RPS превращается очень опосредовано, а уж время программистов на оптимизацию и эффект от нее часто оценивается либо интуитивно, либо программисты говорят что-то типа "да, мы знаем, что здесь O(N!) и это превращается в O(log N) парой строк, но тогда не стали заморачиваться premature optimization".

У меня лично складывается такое впечатление от МС архитектуры
1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто.
2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт
3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.

Здравствуйте, gyraboo, Вы писали:

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

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

G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так). В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы. Бизнес месяц провел в совещаниях по планируемой нагрузке и пришел с конкретными цифрами: говорит, что система должна выдерживать миллион пользователей в день, что бы они не захотели делать на платформе.

На одном сценарии вебморда стейджа у нас ложится по таймаутам на 5к RPS, на втором на 3К, не третьем не держит и 500RPS. Какие решения нам предложит достаточно зрелая технология, как считаешь? Как найти узкие места и что именно улучшать?

Это я еще не учел всякие сюрпризы типа cache hit ratio и зависимости от конкретных данных.

Здравствуйте, Ziaw, Вы писали:

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

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

Ну так трейсинг же из коробки делается, библиотеками типа sleuth, zipkin, там тебе даже фронт готовый есть для анализа трейсов. Просто юзай трейсы и наслаждайся. Как и многие другие вещи, в экосистеме Spring Cloud, скажем обнаружение сервисов или их конфигурирование (я про проект Spring Cloud Config Server), для всего в спринге есть решения, пусть не всегда идеальные, но они идут в единой связке.

G>>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Z>А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так). В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы. Бизнес месяц провел в совещаниях по планируемой нагрузке и пришел с конкретными цифрами: говорит, что система должна выдерживать миллион пользователей в день, что бы они не захотели делать на платформе.

>А где же про эти решения можно почитать? — например в книгах и статьях про Spring Cloud, про реактивный подход или про современные паттерны отказоустойчивости. Также есть статьи и блоги про стек нетфликса, нетфликс как раз одна из компаний, которая многие такие вещи придумала и внедрила, т.к. столкнулась с большой нагрузкой на микросервисы.

Z>На одном сценарии вебморда стейджа у нас ложится по таймаутам на 5к RPS, на втором на 3К, не третьем не держит и 500RPS. Какие решения нам предложит достаточно зрелая технология, как считаешь? Как найти узкие места и что именно улучшать?

Какая технология? Ну так реактивщину придумал и для этих задач (повышение перформанса) + паттерны отказоустойчивости (например, из библиотеки resilience). В частности, если у вас кто-то ложится по таймаутам, реализуйте паттерны Circuit Breaker и Bulkhead (https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/). Это позволит проблемному микросервису обслуживать больший спектр запросов, а не ложиться от нагрузки на однотипных запросах. Спектр можно распределить по разным параметрам, например по конкретным эндпоинтам.
Как найти узкие места — анализ метрик, прогон микросервиса с профайлером. Тут уже всё упирается к компетенции разрабов. С монолитом точно так же приходится анализировать перформанс, только вот в монолите бывает тяжело провести оптимизацию, если она упирается в монолитную природу. Не раз с этим сталкивался, т.е. проводим анализ перформанса профалингом, находим узкие места в монолите, но понимаем, что проще вынести точки нагрузки в отдельные микросервисы на физические узлы, чем заниматься миллионом микро-оптимизаций монолита, которые все равно не гарантируют что узкое место будет устранено. А при выносе точки нагрузки в микросервис можно просто написать код без этих оптимизационных заморочек, что выйдет дешевле и быстрее.

Z>Это я еще не учел всякие сюрпризы типа cache hit ratio и зависимости от конкретных данных.

Я не спорю, что задачи при разработке микросервисов непростые. Но моё мнение, что с монолитом эти задачи решать намного тяжелее.

Здравствуйте, Ziaw, Вы писали:

G>>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
G>>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Z>Так изи или нужен немалый труд нескольких команд специалистов? Про зрелость технологии дискутировать не буду, а вот то, что простые и дешевые решения на ней становятся дорогими и сложными это факт. Ну и цена ошибки просто зашкаливает, аналитики выдали что-то типа — сервис должен выдерживать работу 20к посетителей в час, а потом выясняется, что эти посетители приходят на событие в час в одно и то же время и логин 20к в течении минуты кладет все. Да и без этих ошибок, вывод состоит в том, что мы провели НТ и система не выдержала, надо увеличивать мощности или оптимизировть код. Потом начинается работа по апроксимации этого вывода в дорогие и неоднозначные решения, посколько сказать заранее сколько потребуется мощности в пике нагрузки или насколько мы сможем что-то оптимизировать можно с очень небольшой точностью, так как стоимость железа в RPS превращается очень опосредовано, а уж время программистов на оптимизацию и эффект от нее часто оценивается либо интуитивно, либо программисты говорят что-то типа "да, мы знаем, что здесь O(N!) и это превращается в O(log N) парой строк, но тогда не стали заморачиваться premature optimization".

Z>У меня лично складывается такое впечатление от МС архитектуры
Z>1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто.
Z>2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт
Z>3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.

Мне кажется, ты смешал в одну кучу бюрократические корпоративные проблемы процесса разработки и технологии МС. В крупных компаниях или банках и раньше, по монолитам, были миллион совещаний и утверждений, и целая толпа непонятных людей — возможно потому, что цена ошибки в крупной компании слишком высока, на каждое изменение в коде нужно найти ответственного, разделить все обязанности и т.д. и т.п.. А в мелких конторах микросервисы пиляться быстро и споро, особенно если используется экосистема типа Spring Cloud. Выкатили баг на прод — ниче страшного, ща исправим, "компания у нас мелкая, никто из клиентов сильно не пострадает, зато быстро всё выкатываем".

Здравствуйте, gyraboo, Вы писали:

G>Ну так трейсинг же из коробки делается, библиотеками типа sleuth, zipkin, там тебе даже фронт готовый есть для анализа трейсов. Просто юзай трейсы и наслаждайся. Как и многие другие вещи, в экосистеме Spring Cloud, скажем обнаружение сервисов или их конфигурирование (я про проект Spring Cloud Config Server), для всего в спринге есть решения, пусть не всегда идеальные, но они идут в единой связке.

Ты прав, не только трейсинг, еще и обнаружение сервисов.

G>Какая технология?

Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Какие стандартные отработанные решения в зрелой технологии позволяют прогнозировать SLA? Вот я привел тебе гипотетический пример SLA и результатов НТ. Как тебе может помочь здесь микросервисная технология?

G>Я не спорю, что задачи при разработке микросервисов непростые. Но моё мнение, что с монолитом эти задачи решать намного тяжелее.

Я как раз хочу понять, что они такого предлагают, что вдруг стало легче? Куда делать объективная сложность, если ее помножили на сложность взаимодействия множества микросервисов? Пока получаю ответы в стиле — теперь легко делать трейсинг и сервис локаторы. Такой себе профит, по сравнению с отсутствием необходимости их делать.

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

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

Здравствуйте, gyraboo, Вы писали:

G>Какая технология? Ну так реактивщину придумал и для этих задач (повышение перформанса) + паттерны отказоустойчивости (например, из библиотеки resilience). В частности, если у вас кто-то ложится по таймаутам, реализуйте паттерны Circuit Breaker и Bulkhead (https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/).
Почитал.

Ведь известно, что на каждый запрос выделяется отдельный тред. Запрос /animals/any заставляет тред веб-сервера Zoo висеть в ожидании ответа от Random Animal — то есть не дает треду быстро освободиться. А пул тредов на веб-сервере ограничен и един: он обслуживает и запросы /animals/any, и запросы /ticket и любые другие.

Уах-хах-хаа!
Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны

Здравствуйте, gyraboo, Вы писали:

G>монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе

теперь все понятно

Здравствуйте, white_znake, Вы писали:

_>В некоторых проектах такое норм. В некоторых не прохиляет. Смотри пример. В одном из проектов нужно было распознавать объекты с потокового видео.
_>Так, вот сервис этот был ресурсозатратным и дорогим, естественно, его масштабировали при достижении пиковых нагрузок, разворачивая довольно дорогие инстансы виртуалок в облаке.
_>А был ряд сервисов по-проще, у которых нагрузка была гораздо меньшей. И за чем эти сервисы хостить на дорогих инстансах?
_>И тут встает финансовый вопрос. Если у нас монолит, то при необходимости масштабировать сервисы, которые требуют минимальных ресурсов, придется их деплоить на более производительные инстансы.
_>Или задача автоматического масштабирования становится очень интересной.

Монолит не подразумевает отсутствие сервисов. Более того, все, что можно вынести в сервисы — выносится. Распознавание отличный пример.

_>Тут дело не только в масштабировании бд.
_>Для сущностей одного домена лучше подойдет реляционная бд, для сущностей другого домена лучше подойдет джокументная бд, для сущностей 3-го домена, лучше подойдет графовая бд.
_>Понятно, что все можно запилить на реляционной БД, но в некоторых случаях — это будет сложнее.

Монолит может спокойно юзать все эти разные БД. Можно сделать монолит на домен. Для этого не обязательно переходить на микросервисы.

_>P.S. В общем, все зависит от задачи.

Это верно.

Здравствуйте, Ziaw, Вы писали:

Z>Какие стандартные отработанные решения в зрелой технологии позволяют прогнозировать SLA? Вот я привел тебе гипотетический пример SLA и результатов НТ. Как тебе может помочь здесь микросервисная технология?

Да ровно те же что и в монолите. Берешь сценарии, которые составляют SLA, определяешь сервисы, которые в них задействованы, тестируешь, снимаешь метрики, анализируешь. Плюс именно микросервисов в грануляции метрик. В монолите ты получаешь ответ "приложение делает 100RPS на стенде" и делай с таким ответом что хочешь, ни в чем себе не отказывай. Можешь профайлер запустить, если не встраивает. В микросервисах ты получаешь ответ "сервис А делает 20k RPS, Сервис Б делает 100k RPS, сервис В делает 100RPS и упирается в CPU" и тебе понятно что и как нужно масштабировать. Более того, ты эти же метрики получаешь и из продакшена и имеешь относительно адекватные профили нагрузки именно для твоего сервиса, без необходимости извлекать их из зашумленных профилей всего приложения.

Z>Я как раз хочу понять, что они такого предлагают, что вдруг стало легче? Куда делать объективная сложность, если ее помножили на сложность взаимодействия множества микросервисов? Пока получаю ответы в стиле — теперь легко делать трейсинг и сервис локаторы. Такой себе профит, по сравнению с отсутствием необходимости их делать.

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

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

2 человека и даже 20 человек это вообще не про микросервисы. Ну т.е. можно поиграться, но профита не будет. Вот 200 человек это про микросервисы. Представь себе монолит с командой в 200 человек. Да плевать уже на переиспользование алгоритмов, у них даже мердж веток в мастер будет требовать отдельного протокола и занимать недели. С микросервисами ты делишь эти 200 человек на ~20 команд которые пилят собственные модули, версионируют и документируют API, независимо деплоятся и взаимодействуют друг с другом очень ограниченно. Не особо важно что они не могут переиспользовать алгоритмы, когда одна команда пишет на python и tensorflow, а другая на Java и SQL.

Здравствуйте, Sinclair, Вы писали:

S>Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны

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

Здравствуйте, Ziaw, Вы писали:

Z>Монолит не подразумевает отсутствие сервисов. Более того, все, что можно вынести в сервисы — выносится. Распознавание отличный пример.

И в чем же тогда разница между микросервисами и монолитом?

Здравствуйте, Miroff, Вы писали:

M>И в чем же тогда разница между микросервисами и монолитом?

В микросервисной архитектуре сервис выполняет одну простую функцию и крайне рекомендуется не шарить одно хранилище между несколькими микросервисами. Нет какого-то главного микросервиса.

У монолита есть крупное основное приложение с основных хранилищем, возможно какие-то изолированные сервисы развернуты отдельно.

Здравствуйте, Miroff, Вы писали:

M>Да ровно те же что и в монолите. Берешь сценарии, которые составляют SLA, определяешь сервисы, которые в них задействованы, тестируешь, снимаешь метрики, анализируешь. Плюс именно микросервисов в грануляции метрик. В монолите ты получаешь ответ "приложение делает 100RPS на стенде" и делай с таким ответом что хочешь, ни в чем себе не отказывай. Можешь профайлер запустить, если не встраивает. В микросервисах ты получаешь ответ "сервис А делает 20k RPS, Сервис Б делает 100k RPS, сервис В делает 100RPS и упирается в CPU" и тебе понятно что и как нужно масштабировать. Более того, ты эти же метрики получаешь и из продакшена и имеешь относительно адекватные профили нагрузки именно для твоего сервиса, без необходимости извлекать их из зашумленных профилей всего приложения.

Чтобы было ровно то же, метрик должно быть столько же, а это не так, метрик на порядок больше и 100% CPU на одном сервисе в НТ на стейдже нам говорит только о том, что дав этому сервису больше CPU мы возможно что-то ускорим. Это собственно все, остальное исследуем на проде.

M>Сложность, как метрика неоднородности, естественно никуда не делась. Микросервисная архитектура упрощает лишь организацию разработки путем навязывания нормальных инструментов для формализации API, мониторинга, тестирования и деплоя. Без таких инструментов микросервисы не взлетают. В отличие от монолита, где все это внедряется по остаточному принципу когда уже зад начинает пригорать. Микросервисная архитектура упрощает взаимодействие между командами благодаря тому, что у них остается меньше точек взаимодействия.

Формализация API, мониторинг, тестирование и деплой маст хев в любом случае.

M>2 человека и даже 20 человек это вообще не про микросервисы.

Это как пример перехода.

M>Ну т.е. можно поиграться, но профита не будет. Вот 200 человек это про микросервисы. Представь себе монолит с командой в 200 человек. Да плевать уже на переиспользование алгоритмов, у них даже мердж веток в мастер будет требовать отдельного протокола и занимать недели. С микросервисами ты делишь эти 200 человек на ~20 команд которые пилят собственные модули, версионируют и документируют API, независимо деплоятся и взаимодействуют друг с другом очень ограниченно. Не особо важно что они не могут переиспользовать алгоритмы, когда одна команда пишет на python и tensorflow, а другая на Java и SQL.

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

Здравствуйте, Sinclair, Вы писали:

S>Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны

Но в этом случае отвалится вся видимость (observability)! И с доступом к базе данных могут быть забавные эффекты. В Spring и вообще большинстве java-инструментом много чего завязано на потоковые переменные (ThreadLocal). Например, идентификаторы запроса (для distributed tracing) будут в этих переменных.

У нас как-то добавили мониторинг из серии "просто добавь агента". Самое заметное — трассы запросов вида "мы ответили за 1 секунду, из которой 1.5 секунды заняло обращение к внешнему сервису". Диалог с их продажниками:
— А что у вас мониторинг чушь показывает?
— Вы многопоточность используете?
— Ну да, а как еще?
— А мы такое не поддерживаем.

Через какое-то время. Тот же сервис, тот же мониторинг. Прибегает высокое начальство.
— А что у вас все тормозит???
По трейсам — среднее время больше 5 секунд. Какие-то запросы вообще нарисованы по 30 секунд. Я смотрю в альтернативный мониторинг (у нас свой рукопашный, который умеет все, что нужно):
— А в чем проблема? Большинство запросов выполняются меньше 3 секунд (там вызовы других сервисов, которые всегда были медленные). Больше 5 секунд вообще не вижу запросов. И вообще мы же выяснили, что многопоточность ваш мониторинг не поддерживают .
— Ну как же? Раз графики фигню показывают, нужно чинить! Как вы там вообще без статистики?
— (Зло, так как систему без нас выбирали). Кому надо? У меня свои метрики, там все видно и нормально. Вам надо? Бэклог вот там. И он вашими хотелками забит. Приоритизируете ваши графики — с удовольствием сделаю. (в бэклоге лежит огромный compliance, который много времени занимает в том числе из-за того, что нам не давали времени на рефакторинг).

Ну ладно, там Akka. Может там сложности с инструментацией какие. Все-таки не стандарт. Но у нас есть и совершенно станартное JEE-приложение с использованием внедренной (embedded) Jetty. Так там мониторинг вообще стабильно показывает несколько миллисекунд на запрос (при фактическом времени 1-3 секунды). А все почему? Да потому что стандартные асинхронные сервлеты выглядят в духе

public void doRequest(HttpRequest request, HttpResponse response) {
  AsyncContext ctx = request.startAsync();
  // send context to the pool, complete on ctx later.
}

И вот их "инструментирование" вызов doRequest измеряет! А вот более сложно подменять (и измерять) request им было лень. Видимо, не нужно это никому

Здрав ствуйте, gyraboo, Вы писали:

G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

Это все красивая теория. На практике с "современными технологиями" можно прекрасно наблюдать эффекты интерференции между приложениями.

У нас тоже есть прекрасно обстрелянное нагрузкой приложение. С реальными k8s cpu constraints и симуляторами внешних сервисов (с необходимой задержкой "обработки"). И вот в какой-то момент выясняется, что один экземпляр приложения тормозит в боевой системе на нагрузке заметно ниже рассчетной. Я иду наезжать на наших опсов и архитекторов, отвечающих за k8s. Какого, мол, у вас среда такая? В perf были нормальные машины, а на проде вы закупили каких-то pentium pro. Дайте мне на perf самое худшее, что вообще бывает! Я тогда пропишу самые пессимистичные лимиты и все будет хорошо. Ну они поразбирались, все оказалось еще интереснее.

Наш экземпляр (который тормозит), попал на машину с тяжелой нагрузкой (для сравнения — у нас лимит в 1CPU, у них что-то вроде 4CPU). Вроде как эта нагрузка привела к троттлингу CPU. Планировщик считает CPU Time (не такты), так что зацепило вообще все приложения на хосте. И тут что тестируй, что не тестируй — все равно тормоза. В теории есть еше эффекты на CPU Cache (больше проявляются если много мелких приложений). Как-то вроде разрулили. Дали тяжелым задачам отдельный пул. Но осадочек остался.

Конкретно у k8s в его стандартных настройках есть и еще один замечательный эффект. При планировании исполнения k8s считает, что есть 150% CPU от того, что на хосте. Это хорошо подоходит Гуглу. У них много разноплановых приложений, какие-то работают близко к пределу, другие — используют минимум ресурсов. А у нас не так! У нас основное бизнес-приложение одно. Когда увеличивается входящая нагрузка, она разливается и по остальным зависимостям. Т.е. большинство сервисов приближаются к верхней границе потребностей одновременно. В результате на одном хосте потребность (demand) превышает 100% CPU, все начинает тормозить. И приводит к каскадным эффектам, замедляет обработку запросов выше, повышает требования по памяти. Ну и да, CPU опять греется и троттлится (или просто кончается burst capacity).

Здравствуйте, Sinclair, Вы писали:

S>

S>Ведь известно, что на каждый запрос выделяется отдельный тред. Запрос /animals/any заставляет тред веб-сервера Zoo висеть в ожидании ответа от Random Animal — то есть не дает треду быстро освободиться. А пул тредов на веб-сервере ограничен и един: он обслуживает и запросы /animals/any, и запросы /ticket и любые другие.

S>Уах-хах-хаа!
S>Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны
Поток-на-запрос — это единственный нормальный метод. Всё остальное — удаление гландов через задницу.

Просто нужны легковесные потоки, как в Go или будущей Java Project Loom (когда их оракловские жопорукие программисты допилят таки).

M>Есть начальная команда, которая разрабатывает продукт. Это монолит, со внутренней модульюностью и более-менее успешной архитектурой. В течение 5 лет половина команды уходит на новые проекты. Другую половину эффективные менеджеры заменяют на более дешевых и управляемых сговорчивых разработчиков. Это поколение немножко забивает на границы между модулями и вводит ненужную связность. В коде образуется лишний coupling, но зато тикеты закрываются легко и весело. Приложение постепенно превращается в макаронного монстра (spaghetti monster). За следующие 5 лет половина разработчиков успешно фрустрирует и уходит. Другую половину эффективные менеджеры увольняют из-за снизившейся производительности (tech debt мешает, да) и нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами. Система может разиваться еще какое-то время. Еще через 5 лет организация получает уже распределенного макаронного монстра.

Уже за один лишь этот абзац ставлю "Спасибо".
Все остальное, впрочем, тоже верно.

C>Просто нужны легковесные потоки, как в Go или будущей Java Project Loom (когда их оракловские жопорукие программисты допилят таки).

Уже скоро 25 лет как это одно из ключевых преимуществ Erlang'a, странно, что до других только сейчас доходит.

S>Расскажите про ваш процесс. Лично я — очень впечатлён.

Я сначала было тоже, а потом сообразил, что до основной-то работы этот процесс еще не дошел.
Работа начинается в тот момент, когда поднятный сервис требуется использовать по назначению (production rollout). Вот там уже все может быть довольно долго, типа "выкатываем на внутренних юзеров и ждем жалоб неделю", "выкатываем на бета-юзеров", "выкатываем на % юзеров" и так далее.

Так-то поднять endpoint по готовому шаблону можно за пару часов. Какой-нибудь gigalixir или его аналоги где-нибудь в digitalocean так и вовсе за час.

Здравствуйте, Ziaw, Вы писали:

Z>1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто.
Z>2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт
Z>3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.

Все круто, но при чем тут микросервисы? Вероятность таких проблем в монолитах точно такая же. Ты, случаем, не путаешь монолитную архитектуру и полное отсутствие масштабирования и HA?

Здравствуйте, Ziaw, Вы писали:

Z>А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так).

Включаешь трейсинг и смотришь в каком нибудь егере где мы утыкаемся. И 50 сервисов схлопываются до одного.

Z> В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы.

Значит снимаешь трейсинг для разных сценариев. Тебе продакты придут и скажут какой именно сценарий не удовлетворяет SLA. И микросервисы тут, опять же, совершенно не причем.

Здравствуйте, Ziaw, Вы писали:

Z>В микросервисной архитектуре сервис выполняет одну простую функцию и крайне рекомендуется не шарить одно хранилище между несколькими микросервисами. Нет какого-то главного микросервиса.
Z>У монолита есть крупное основное приложение с основных хранилищем, возможно какие-то изолированные сервисы развернуты отдельно.

Микросервисы это, во главе угла, прежде всего про процессы разработки. А архитектура это уже следствие.
Основное ради чего весь этот сыр-бор — максимальная изоляция компетенций по единицам деплоймента. Т.е. каждая конкретная команда решает свою узкую задачу независимо. Максимально независимо. И изменения деплоятся тоже независимо. А вот чтобы это обеспечить как раз и придумана та туча микросервисных технологий.
Монолит же, это когда у нас есть одна большая суперкоманда (пусть и состоящая внутри из нескольких команд), которая и обладает всеми необходимыми компетенциями. Характерный признак монолита — большие релизы, когда несколько разных сервисов, пусть и написанных разными командами, в итоге где то собираются в единое целое, и это целое сперва тестируется именно как целое, а затем и деплоится целиком. А сколько там физических сервисов и как расшарена БД — совершенно пофигу.

Здравствуйте, Ziaw, Вы писали:

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

Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.
О да, это какой-то пинцет.
С другой стороны, микросервисы — тоже не всегда панацея. Там начинаются какие-то адские цепочки зависимостей, которые рано или поздно упираются в компонент с самым медленным релизным циклом.
Но это в любом случае не хуже, чем расписание релизов монолита.

Здравствуйте, Sinclair, Вы писали:

S>С другой стороны, микросервисы — тоже не всегда панацея.

Микросервисы это необходимое, но не достаточное условие.

S> Там начинаются какие-то адские цепочки зависимостей, которые рано или поздно упираются в компонент с самым медленным релизным циклом.

Наоборот же. Проблемы вызывают быстро меняющиеся с потерей обратной совместимости компоненты. Что при этом дают микросервисы?
1) Локальность. Т.е. ты вполне можешь проапгрейдить компонент только в одном сервисе, а в остальных оставить старый.
2) REST API на границах микросервисов значительно гибче и слабее, чем интерфейсы дотнета. Т.е. оно намного чаще и проще позволяет сохранять обратную совместимость.
Все это, разумеется, небесплатно, и проблемы тоже привносятся. Основные:
1) Сильно усложняется разработка, когда история требует согласованного изменения нескольких компонентов и сервисов. Вместо одного релиза приходится делать несколько, причем в строго определенном порядке. И каждый шаг несет ровно тот же риск, сколько и одиночный накат релиза монолита. Тестерам, разумеется, требуется прогонять полный цикл тестирования для каждого шага цепочки.
2) Сильно усложняется обеспечение совместимости в сквозной функциональности. Т.е. если у тебя, скажем, есть некий общий трейсинг, то тебе нужно при внесении изменений держать в голове возможность одновременной работы нескольких его версий. И если вдруг такое обеспечить нельзя — мы приходим к монолит-лайк релизу, с даунтаймов, осложненному существенно большим количеством независимых деплойментов.

Здравствуйте, Sinclair, Вы писали:

НС>>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.
S>О да, это какой-то пинцет.
S>С другой стороны, микросервисы — тоже не всегда панацея. Там начинаются какие-то адские цепочки зависимостей, которые рано или поздно упираются в компонент с самым медленным релизным циклом.
Тогда на практике в больших компаниях просто этот компонент переписывают, причём независимо от старой команды.

Здравствуйте, Cyberax, Вы писали:
C>Тогда на практике в больших компаниях просто этот компонент переписывают, причём независимо от старой команды.
Не понял, это как? То есть в понедельник приходит команда, которая отвечает за микросервис "верификация телефонного номера", а им говорят: "посоны, теперь у нас две реализации этого микросервиса — ваша, и та, которая с воскресенья в проде" — так что ли?

Здравствуйте, Sinclair, Вы писали:

C>>Тогда на практике в больших компаниях просто этот компонент переписывают, причём независимо от старой команды.
S>Не понял, это как? То есть в понедельник приходит команда, которая отвечает за микросервис "верификация телефонного номера", а им говорят: "посоны, теперь у нас две реализации этого микросервиса — ваша, и та, которая с воскресенья в проде" — так что ли?
Примерно.

Реальный сценарий, который у меня был на практике:

1. Есть сервис (будем считать, что для верификации номеров), который написан и поддерживается Равшаном и Джамшутом из отдела "А". Все вызовы сервиса — синхронные, и могут висеть по 5 минут до получения ответа.
2. Многие клиентские библиотеки от такого немного фигеют, и требуют специально крутить таймауты. Всех это достаёт, и отдел "Б" делает обёртку, которая скрывает синхронный интерфейс за асинхронным фасадом, с поддержкой нотификаций через местную систему сообщений.
3. Обёртка заворачивается в REST-интерфейс и начинает использоваться внутри проектов отдела "Б".
4. Отдел "В", которой тоже осточертели те же проблемы сервиса, замечает этот фасад и просит отдел "Б" дать им доступ к сервису-фасаду. Отдел "Б" соглашается (а чего бы не помочь хорошим людям?).
5. Шаг 4 повторяется несколько раз.
6. Менеджер отдела "Б" замечает, что REST-обёртка сервиса верификации — это уже неплохой внутренний продукт, и нанимает под него менеджера и программистов.
7. Выделенный менеджер и программисты замечают, что вообще-то самим реализовать верификацию не так уж и сложно, и тогда можно избавиться от вызовов к сервису "А" совсем.

Усё. Имеем два сервиса с одинаковой функциональностью. Причём достаточно разнесённые по иерархии менеджмента, так что "дефрагментировать" их никого особо не тянет. Исходный сервис после этого может постепенно умереть своей смертью.

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

Здравствуйте, maxkar, Вы писали:

G>>Так всетаки микросервисы проще монолитов или сложнее?
M>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.

Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.

it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.

https://en.wikipedia.org/wiki/Microservices

Вобщем, ты явно что то путаешь.

M>На архитектурном уровне вместе с микросервисами приходит eventual consistency. В монолите можно сделать большую транзакцию, в микросервисах — в целом нет.

Распределенная транзакция с попыткой обеспечить ACID сложнее и требует более высокой квалификации, нежели eventual consistency. Аргумент твой доказывает обратное заявленному.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.
НС>

НС>it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.

НС>https://en.wikipedia.org/wiki/Microservices

НС>Вобщем, ты явно что то путаешь.
Я не путаю. В приведенной цитате да и вообще в статье нет ничего про стоимость и квалификацию. Более того, вводный параграф вообще функциональность приложения обходит стороной. Противоречия здесь никакого нет. Можно нанять много разработчиков, они все будут очень-очень заняты. А на выходе — прямо как в анекдоте: "Я могу печатать 600 символов в минуту но получается какая-то фигня". Для того, чтобы все более-менее работало (и работало 24/7) нужна будет квалификация. В другую сторону тоже работает — если получится найти сильных разработчиков в качестве лидеров команд, законченный продукт можно получить быстро.

Да и вообще вообще вся статья писалась по "вражеским" материалам. Например:

A microservice architecture – a variant of the service-oriented architecture (SOA) structural style

Я учил архитектурные стили по Neal Ford и Mark Richards. У них микросеврисы стоят рядом с SOA и не являются её разновидностью (bounded contexts — microservices, infrastructure services & service per business function — SOA). Микросервисы в разновидность SOA очень любят записывать консультанты вроде IBM. Это им нужно, чтобы продавать infrastructure services (общие пользователи и т.п.), которые в микросервисы не вписываются. Еще консультантам очень интересно продать как можно больше консультантов (organization grow fast). В большинстве случаев оплата идет по time & materials, и становится выгодно, чтобы проекты не заканчивались в срок. Если переборщить с communications are less, как раз получится мифический человекомесяц, когда все сервисы есть но не интегрируются друг с другом.

M>>На архитектурном уровне вместе с микросервисами приходит eventual consistency. В монолите можно сделать большую транзакцию, в микросервисах — в целом нет.
НС>Распределенная транзакция с попыткой обеспечить ACID сложнее и требует более высокой квалификации, нежели eventual consistency. Аргумент твой доказывает обратное заявленному.
Так в монолите же нет распределения через границы сервисов. А для транзакций внутри монолита (но через разные хранилища) решения разработаны уже давным давно. В JEE/JTA стандартные интерфейсы (javax.transaction.xa) для координатора транзакций были уже 17 лет назад. Поэтому "сложность разработки" сводится к использованию аннотации @Transactional по поводу и без. Настраивается это все один раз в начале проекта знающими людьми. А вот в микросеврисах такая магия не работает. Я вот часто вижу (и на rsdn темы периодически поднимаются), что делают rpc over http вместо rest. Об обработке ошибок даже не задумываются. Ты думаешь, с этими разработчиками можно конструктивно говорить про eventual consistency? А вот в монолите local procedure call прекрасно работает. Инфраструктура с транзакцией разберется если что-то пойдет не так.

Здравствуйте, maxkar, Вы писали:

M>Я не путаю. В приведенной цитате да и вообще в статье нет ничего про стоимость и квалификацию.

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

M>А на выходе — прямо как в анекдоте: "Я могу печатать 600 символов в минуту но получается какая-то фигня".

Именно. И микросервисы позволяют вот эту фигню изолировать в маленьком кусочке и остальным от нее не так сильно страдать, как в монолите.

M>Я учил архитектурные стили по Neal Ford и Mark Richards. У них микросеврисы стоят рядом с SOA

Микросервисы и SOA, при внешней похожести, все таки сильно не одно и тоже. SOA породили архитекты-теоретики, пытаясь пропихнуть некий концепт. А микросервисы наоборот, родились "от сохи". Когда адепты SOA начали ощущая загибание этой самой SOA со всеми причиндалами типа SOAP и WCF, вот тогда они и начали усиленно натягивать SOA на микросервисы.

M>Микросервисы в разновидность SOA очень любят записывать консультанты вроде IBM.

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

M>Еще консультантам очень интересно продать как можно больше консультантов (organization grow fast).

Ты неверно интерпретировал фразу. organization grow fast это когда мы покупаем за внезапно полученные от инвесторов бабки кучу индусов, и после этого начинаем думать как же нам со всей этой сомнительной толпой наконец начинать что то делать. Микросервисы — отличный подход. Пилим систему на кучу почти несвязанных кусков, а потом отдаем индусам всю эту тряхомудию. А микросервисы позволяют этому хоть как то взлететь.

НС>>Распределенная транзакция с попыткой обеспечить ACID сложнее и требует более высокой квалификации, нежели eventual consistency. Аргумент твой доказывает обратное заявленному.
M>Так в монолите же нет распределения через границы сервисов.

Это чего вдруг? Эра односерверных решений ушла в прошлое, они не годятся для high load, и даже монолитам надо уметь как минимум HA, а лучше все таки уметь в скейлинг.

Здравствуйте, Ночной Смотрящий, Вы писали:

M>>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.
НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.
НС>

НС>it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.

НС>https://en.wikipedia.org/wiki/Microservices
НС>Вобщем, ты явно что то путаешь.

Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,
теоретики типа. У Нетфликса получилось, давайте все делать как Нетфликс. Зачастую это либо реально сложно из-за предметной
области, либо просто не нужно. На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном
сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования.
Требования к программисту микросервисов -- тоже самое + знание распределенных систем, ну хотя бы
на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна,
пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно
работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать
свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо
изучать и инвестировать не мало своего времени на это. Те же, по сути, требования что и к монолоиту+еще куча всего.

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

C>Усё. Имеем два сервиса с одинаковой функциональностью. Причём достаточно разнесённые по иерархии менеджмента, так что "дефрагментировать" их никого особо не тянет. [Исходный сервис после этого может постепенно умереть своей смертью.

Проблема в том, что выделенное обычно попросту не происходит. Две (а по факту много больше) инфраструктуры существуют параллельно. Так что разработчикам приходится еще и мучаться с "интеграцией" этого добра, а также учить свои сервисы поддерживать оба варианта.

C>Разные вариации на эту тему видел лично несколько раз. Вариант "вот это, но с перламутровыми крылышками" даже сам писал из-за того, что другая команда по идеологическим причинам не хотела добавлять нужный функционал.

Мне неоднократно доводилось стоять с другой стороны баррикад. В большинстве случаев вовсе не Равшан и Джамшут сделали сервис А. Чаще все наоборот. Процитирую:

Есть начальная команда, <...> эффективные менеджеры заменяют на более дешевых и управляемых <...> нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами.

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

А далее по накатанной: параллельная реализация "с перламутром" оригинальными разработчиками с гордым видом сдается куда-нибудь в инфра-команду, с выражением "смотрите, вот мы сделали новую классную штуку, а поддерживать — это нам не с руки, мучайтесь сами, делайте что хотите, но сохраните вот этот вот API". И там, конечно, жуть и кошмар, сплошные макароны, обычно с минимумом тестов, в лучшем случае покрывающем нужды только оригинального разработчика. Почти всегда с текущими абстракциями, настолько затрудняющими рефакторинг (и сведение двух параллельных систем к одной).


Так вот, возвращаясь к "сам писал, потому что другая команда по идеологическим причинам не хотела". Причины очень часто не "идеологические", а банальная сложность поддержки костылей, которые просят натыкать, или абстракций, которые могут протечь, если продырявить "перламутровую пуговицу" где не надо. Монолит, конечно, упрощает такое, но и в случае с микросервисами выставить кишки наружу (и тем самым считай что запретить рефакторинг) — очень частая забава в "быстро растущем продукте".

Здравствуйте, SkyDance, Вы писали:

C>>Усё. Имеем два сервиса с одинаковой функциональностью. Причём достаточно разнесённые по иерархии менеджмента, так что "дефрагментировать" их никого особо не тянет. [Исходный сервис после этого может постепенно умереть своей смертью.
SD>Проблема в том, что выделенное обычно попросту не происходит. Две (а по факту много больше) инфраструктуры существуют параллельно. Так что разработчикам приходится еще и мучаться с "интеграцией" этого добра,
Пусть существуют. Компания большая, выдержит.

Это куда лучше, чем борьба внутри "монолита" по поводу того, как развивать его.

SD>а также учить свои сервисы поддерживать оба варианта.
Тут не очень понятно зачем. Потребители будут просто выбирать один из сервисов. Поддерживать все варианты нужно будет только в каких-то очень специфических случаях.

SD>

SD>Есть начальная команда, <...> эффективные менеджеры заменяют на более дешевых и управляемых <...> нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами.

И причём тут микросервисы? В монолите будет всё так же, но ещё хуже.

SD>А далее по накатанной: параллельная реализация "с перламутром" оригинальными разработчиками с гордым видом сдается куда-нибудь в инфра-команду, с выражением "смотрите, вот мы сделали новую классную штуку, а поддерживать — это нам не с руки, мучайтесь сами, делайте что хотите, но сохраните вот этот вот API". И там, конечно, жуть и кошмар, сплошные макароны, обычно с минимумом тестов, в лучшем случае покрывающем нужды только оригинального разработчика. Почти всегда с текущими абстракциями, настолько затрудняющими рефакторинг (и сведение двух параллельных систем к одной).
Это решается удалением такого понятия как "инрфа-команды". Те кто пишет сервис — поддерживают его во время его жизни.

SD>Так вот, возвращаясь к "сам писал, потому что другая команда по идеологическим причинам не хотела". Причины очень часто не "идеологические", а банальная сложность поддержки костылей, которые просят натыкать, или абстракций, которые могут протечь, если продырявить "перламутровую пуговицу" где не надо.
Там была чистая идеология, реализация с нуля с нужным функционалом заняла несколько недель.

SD>Монолит, конечно, упрощает такое, но и в случае с микросервисами выставить кишки наружу (и тем самым считай что запретить рефакторинг) — очень частая забава в "быстро растущем продукте".
Как раз наоборот. В монолите будет препятствие в виде идеологии. Причём непреодолимое.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Ночной Смотрящий, Вы писали:

M>>>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.
НС>>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.
НС>>

НС>>it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.

НС>>https://en.wikipedia.org/wiki/Microservices
НС>>Вобщем, ты явно что то путаешь.

S>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,
S>теоретики типа. У Нетфликса получилось, давайте все делать как Нетфликс. Зачастую это либо реально сложно из-за предметной
S>области, либо просто не нужно. На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном
S>сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования.
S>Требования к программисту микросервисов -- тоже самое + знание распределенных систем, ну хотя бы
S>на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна,
S>пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно
S>работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать
S>свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо
S>изучать и инвестировать не мало своего времени на это. Те же, по сути, требования что и к монолоиту+еще куча всего.

S>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой, соотв. про требования я взял из описания вакансий+
S>мое понимание работы и устройства микросервисных систем и архитектур. Я не очень понимаю, за счет чего требования к
S>квалификации программистов должны снизится, если наоборот, должны вырасти?

Микросервисы меньше размерами, удержать к голове архитектуру гораздо проще, проще сам процесс разработки, отладки, тестирования.
Размер в общем имеет значение. Я как-то работал с довольно большим, мягко говоря, монолитом, из несколько сотен Java модулей,
где разные части написаны как попало и как попало синтегрированы. Новому разработчику чтобы войти в курс дела и что-то начать
продуктивное писать не наломав дров сразу же, требуется где-то 3 месяца. Практически никто не видит полной картины, как вся система
работает, поэтому регулярно случались истории типа, что-то переместил в одном месте, отвалилось совсем в другом (и это удача если
это другое место было покрыто тестами. тестов там было много, но покрыть прямо все нереально).

По сравнению с этим, сложности микросервисов которые были упомянуты, они есть, но ими как правило занимаются специальные люди,
то есть при грамотной архитектуре, разработчик прикладной части микросервисов с ними не так много сталкивается.
Хотя сталкивается конечно, но это просто специфика, которая есть в каждом проекте. Я бы не сказал что нужна большая
квалификация разработчикам микросервисов. Но и что меньшая — тоже. Вообще здесь нет какого-то общего случая, может быть и так и эдак.
Однозначный плюс микросервисов — это размер, как я уже упомянул пару раз. Из-за него существенная часть сложности уходит.
Людей буквально заставляют делить большой проект на части физически, что в какой-то степени уменьшает степень макаронности кода.
Можно конечно и с микросервисами спагетти написать мама не горюй если архитектурой не занимаются вообще, но это все-таки
не так распространено как в монолитах.

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>Так всетаки микросервисы проще монолитов или сложнее?

M>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.

M>Как SkyDance здесь уже отметил, микросервисы на раннем этапе всего-лишь позволяют предотвратить излишнюю связность. Особенно на нижнем уровне вроде базы данных. Это можно делать и в монолите, но нужна определенная политическая воля.

Это "всего-лишь" довольно дорогого стоит на самом деле.
Если мы говорим про длительный отрезок времени (10-15-20 лет), это (политическая воля и все такое) 99.9% нереально. Ну то есть политическая воля нужна на самом-самом верху, да и это может не помочь, потому что CEO приходят и уходят, да и основатели компании могут уже уйти к тому времени.
А типичный и всеми используемый процесс разработки оперирует краткосрочными целями (квартал, ну максимум год), долгосрочный tech debt всем пофигу по большому счету, на всех уровнях менеджмента.
То есть превращение монолита в макаронного монстра просто-напросто неизбежно, можно сказать заложено силами природы . Ну или корпоративной практики, что в данном случае одно и то же.
С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.

Здравствуйте, VladiCh, Вы писали:

VC>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.

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

Здравствуйте, Sharov, Вы писали:

S>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,

Или нет.

S>У Нетфликса получилось, давайте все делать как Нетфликс.

А как надо?

S> Зачастую это либо реально сложно из-за предметной области, либо просто не нужно.

Зачастую? У тебя есть статистика?

S>На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном
S>сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования.

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

S>тоже самое + знание распределенных систем, ну хотя бы на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна,
S>пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно
S>работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать
S>свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо
S>изучать и инвестировать не мало своего времени на это.

Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?

S>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой

А опыт работы над современными монолитами есть?

Здравствуйте, Ночной Смотрящий, Вы писали:


S>>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,
НС>Или нет.

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

S>>У Нетфликса получилось, давайте все делать как Нетфликс.
НС>А как надо?

Прежде как, а оно вообще надо? Т.е. на эти вопросы надо сначала ответить.

S>> Зачастую это либо реально сложно из-за предметной области, либо просто не нужно.
НС>Зачастую? У тебя есть статистика?

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

S>>На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном
S>>сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования.
НС>Нужно умение хорошо структурировать код. И чем больше размер монолита, тем важнее это умение.
НС>Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API.

Допустим, а если разработчики монолита будут думать в терминах api, а не интерфейсов? В чем тогда выгода микросервисов?

S>>тоже самое + знание распределенных систем, ну хотя бы на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна,
S>>пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно
S>>работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать
S>>свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо
S>>изучать и инвестировать не мало своего времени на это.
НС>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?

В целом сравниваю. Ну не одно систему, а 2-3 пилят на 10 мелких. Опять же, надо определиться под тем, что называется
монолит. Много кода в едином адресном пространстве -- это оно?


S>>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой
НС>А опыт работы над современными монолитами есть?


Опыт работы над небольшими проектами, группой 2-3 человек, на 1-2 года работы. Иногда группы из 4-5 человек.
Взгляд со стороны, а не изнутри.

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

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

Куда логичнее было бы применить какой-нибудь message passing interface. Чтобы у сервисо-писателей даже не возникало чесотки сделать очередные RPC тут и там. Но вот же беда, пресловутых 100.000 индусов научить мыслить в терминах распределенной (и по определению асинхронной) системы куда сложнее, чем дать возможность совершать [local] blocking calls. В итоге практика показывает, что микросервисы попросту превращаются в еще более страшный кошмар архитектора — распределенный монолит. Когда на вид там микросервисы, но протекшие абстракциями отовсюду. И везде сплошные crawler'ы, постоянно шерстящие систему в поисках разных там tombstones, orphan entities и прочего забытого добра. А потом, конечно, скандалы, "компания G годами не удаляла данные пользователей, которые хотели удалить эти данные в соответствии с GDPR, ах эти G, злые они, так и хотят украсть что-то, нельзя им верить".

VC>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.

Рефакторинг одного микросервиса и в самом деле становится дешевле. Но их же много, причем, как уже было отмечено выше, вдобавок еще и есть варианты того же "с перламутровыми крылышками". Поэтому сравнивать нужно сравнимое. Рефакторинг монолита правильно сравнивать с рефакторингом всех микросервисов сразу.

Плюс еще тонкий момент с тестированием. Как уже было указано выше, чтобы иметь возможность хоть как-то тестировать "свой" сервис, нужно иметь возможность запустить либо тестовые экземпляры, либо моки всех зависимостей (хотя для e2e этот вариант может и не подойти). Как правило поднять экземпляр монолита проще, чем все зависимости "перламутровых пуговиц" микросервисов, где каждый кто во что горазд.

Короче говоря, серебряной пули нет. И так и этак нужна железная воля руководства, чтобы держать возникающую на пустом месте сложность в узде. А это, однако, редко встречается, ибо, как тоже уже было указано, горизонты планирования большинства контор сейчас от силы год, а реально еще короче. Это пару веков назад можно было себе представить проект на всю жизнь, где можно было держать марку качества. А сейчас если продукт не скатился в <...> за двадцать лет — это, однако, круто!

C>Пусть существуют. Компания большая, выдержит.

И то правда. В самом деле, так даже лучше, headcount больше, можно назваться "менеджером 3 команд". Это ничего, что там 3 дубликата одного и того же, зато 15 человек вместо 5. Более важный начальник, уже не просто менеджер, а менеджер менеджеров.

C>Там была чистая идеология, реализация с нуля с нужным функционалом заняла несколько недель.
C>Как раз наоборот. В монолите будет препятствие в виде идеологии. Причём непреодолимое.

Конкретно ваш случай обсуждать не стану, ибо конкретики не знаю. Но подобных ситуаций я наблюдал очень много. Обычно заявления "вон та команда по идеологическим причинам не делает то, что я хочу" возникают при низкой квалификации требующего, который не в состоянии понять, почему отказ "вытащить вот те данные" является не идеологическим. В самом деле, вот почему бы не вытащить кишки sk_buff через какие-нибудь sysctl, так удобно было б по-быстрому подсмотреть всякие кастомные битики в заголовках IP, или еще что такое.

Также встречаются банальные провалы менеджмента. Когда команде "А" неповезло, и ее менеджер не в состоянии выбить headcount. Поэтому у команды постоянно аврал, вечно растущие backlog'и, постоянная дерготня от смены приоритетов (сегодня пришли из payments, давайте спешно их требования удовлетворять, а завтра пришли из кернел, ну надо значит им теперь помочь). У команды "Б" же, наоборот, людям заняться нечем (начальник у них оказался пронырливый, headcount выбил, но чем теперь людей занять, не знает). Вот тогда "Б" и начинают городить параллельную инфраструктуру. Иногда от нечего делать, иногда "to unblock ourselves". И нет бы им разобраться да помочь "А", написать тесты, сделать нужные pull request. Нет, что вы, это ж надо в чужом коде разобраться. Но команда "Б" пришла не для этого, им свое хочется.

Заканчивается подобное тем, что рано или позно для команды "Б" таки находится чем заняться, и начинается какой-то проект. А параллельная инфраструктура, поскольку уж очень она похожа на продукт команды "А", как раз и сваливается на "поддержку" (стало быть, merge & deprecate) в ту самую команду "А". Чем вызывает вполне законную злость представителей "А" на товарищей из "Б", последними принимаемыми за "идеологическое препятствие". Однако ж никакой там идеологии нет, просто уровень знаний повыше.

PS: если что, мой сын тоже ведь считает, что я ему исключительно по идеологическим причинам не даю круглосуточно сидеть в онлайн-играх, жрать чипсы и прочую дрянь. Ужасная идеология! А, вот еще, зубы чистить — ну просто высшее проявление идеологии. Он ведь уже несколько раз проверял, не почистил — ничего не случилось. Зачем вообще чистить, кроме как по идеологическим причинам.

Здравствуйте, Sharov, Вы писали:

S>>>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,
НС>>Или нет.
S>Или да.

Т.е. аргументов у тебя нет. ЧТД.

S>>>У Нетфликса получилось, давайте все делать как Нетфликс.
НС>>А как надо?
S>Прежде как, а оно вообще надо?

Что вообще надо? Архитектуру какую то? Обычно надо.

S>Допустим, а если разработчики монолита будут думать в терминах api, а не интерфейсов?

И как ты это проконтролируешь?

S>В чем тогда выгода микросервисов?

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

НС>>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?
S>В целом сравниваю.

Тогда не вижу предмета для разговора.

S>Ну не одно систему, а 2-3 пилят на 10 мелких.

Пилят на микросервисы систему, которая изначально на одном сервере работает, я верно тебя понял?

S> Опять же, надо определиться под тем, что называется монолит. Много кода в едином адресном пространстве -- это оно?

Нет. https://whatis.techtarget.com/definition/monolithic-architecture

S>>>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой
НС>>А опыт работы над современными монолитами есть?
S>Опыт работы над небольшими проектами, группой 2-3 человек, на 1-2 года работы. Иногда группы из 4-5 человек.
S>Взгляд со стороны, а не изнутри.

Ну то есть все сервисы исключительно single instance?

Здравствуйте, SkyDance, Вы писали:

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

SD>Если уж на то пошло, REST API далеко не единственный и уж точно не лучший вариант для формализации общения между сервисами. Низкая эффективность, высокие накладные расходы и куча не совсем осмысленных ограничений.

В контексте разговора эффективность не принципиальна. Главное что не очередная разновидность OORPC.

SD>Но вот же беда, пресловутых 100.000 индусов научить мыслить в терминах распределенной (и по определению асинхронной) системы куда сложнее, чем дать возможность совершать [local] blocking calls.

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

НС>А им и не нужно мыслить. Их задача обычно диктуется уже спроектированным API и наложенными на них ограничениями в виде лимитов пода и SLA. Как это все будет натягиваться на реальную инфраструктуру — задача уже других людей.
НС>При этом, конечно, если забить на нормальных девопсов и посадить все это натягивать на инфраструктуру таких же индусов — фейл неизбежен и никакие микросервисы не спасут.

Я правильно понимаю, что если раньше тем самым "другим людям" (и "нормальным девопсам") достаточно было просто диктовать архитектуру и не давать руководству заменять дешевых разработчиков на дорогих, то сейчас вдогонку к тому нужно еще успеть уследить на 100.000 индусов, чтобы те не проторчали кишки во все стороны? Не, эт дохлый номер, оно так не сработает. Просто теперь расходы на такой проект вырастут на те самые 100.000 индусов и их менеджеров, плюс потребуется еще больше грамотных людей. Понимаю, что линейным менеджерам это только на руку, но с точки зрения компании выигрыш неочевиден.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации.
НС>

НС>it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.

НС>https://en.wikipedia.org/wiki/Microservices
НС>Вобщем, ты явно что то путаешь.

Это не maxkar, похоже, путает -- вот тут, по ссылке из ссылки выше, пишут в cons для микросервисов:

But the switch to microservices comes with its fair share of costs, particularly when it comes to app monitoring and the toll it can take on developers. Adopters will have to consider factors such as:

Team expertise: The benefits of microservices are moot without a prepared staff. You should assess the skills of your team members before moving forward with a microservices architecture.
Testing and monitoring: Once you break apps into components, you'll have more moving parts to track and eventually fix. Without the right testing and monitoring tools in place, things could quickly spin out of control.

Можно сказать, что design goal не удался.

Здравствуйте, SkyDance, Вы писали:

SD>Я правильно понимаю, что если раньше тем самым "другим людям" (и "нормальным девопсам") достаточно было просто диктовать архитектуру и не давать руководству заменять дешевых разработчиков на дорогих, то сейчас вдогонку к тому нужно еще успеть уследить на 100.000 индусов, чтобы те не проторчали кишки во все стороны?

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

SD>Понимаю, что линейным менеджерам это только на руку, но с точки зрения компании выигрыш неочевиден.

Тем не менее аутсорс в Индию продолжает цвести буйным цветом.

Здравствуйте, SkyDance, Вы писали:

VC>>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.

SD>Рефакторинг одного микросервиса и в самом деле становится дешевле. Но их же много, причем, как уже было отмечено выше, вдобавок еще и есть варианты того же "с перламутровыми крылышками". Поэтому сравнивать нужно сравнимое. Рефакторинг монолита правильно сравнивать с рефакторингом всех микросервисов сразу.

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

SD>Короче говоря, серебряной пули нет. И так и этак нужна железная воля руководства, чтобы держать возникающую на пустом месте сложность в узде. А это, однако, редко встречается, ибо, как тоже уже было указано, горизонты планирования большинства контор сейчас от силы год, а реально еще короче. Это пару веков назад можно было себе представить проект на всю жизнь, где можно было держать марку качества. А сейчас если продукт не скатился в <...> за двадцать лет — это, однако, круто!

Рефакторинг всех микросервисов сразу требуется куда реже (если их границы были выбраны правильно изначально). Может быть, да, в случае когда какая-то глобальная система меняется, что-нибудь типа авторизации / аутентификации, затрагивающее все микросервисы.
Или там переезд на другой сторидж, или другую систему очередей. Это вообще не рефакторинг уже, а редизайн, a редизайн любой большой системы это сильно дорогостоящая операция.
Я кстати совсем не уверен что в случае микросервисов это обойдется дороже — там чаще всего будет возможен вариант редизайна по частям, что в случае с монолитом обычно нереально.
Если же говорить про типовой рефакторинг для уменьшения tech debt, то это то что в монолите довольно часто просто нереально.
Просто потому что там с какого-то момента невозможно рефакторить "по частям", а глобальный рефакторинг такой же дорогостоящий как и редизайн.
Тестирование микросервисов более сложное, тут вопросов нет. То есть и в том и в другом подходе есть слабые стороны. Но, если развитие системы планируется надолго, монолит — это все-таки рискованная штука на длительном промежутке времени.
Я пока не видел ни одного крупного монолита, который бы развивался > 10 лет и не скатился в УГ. Правда, если честно, микросервисов которые столько бы прожили, тоже пока не видел .
Это все-таки более новые веяния, пока тому что я видел нет столько лет.

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, VladiCh, Вы писали:

VC>>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.

M>Зато рефакторить интерфейсы между сервисами становится практически невозможно поскольку для этого надо распинать кучу соседних команд. А у них у всех лапки и они ничего не хотят делать.

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