Спасибо за статью, добавила в закладки. Был опыт использования варианта 2, значение перцентиль выносила в переменные графаны, во время просмотра просто переключала значения перцентиль, на практике всегда хватало 90.
Все беды из-за линейной интерполяции и большого числа ваших данных. В сервисах в небольшим RPC, погрешность из-за линейной интерполяции наиболее высока. Условно: если из 10 запросов в бакете у вас 1 выброс, то его будет видно, но если туда влезла 1000, то этот выброс "слижется" в прямую. Делая бакеты максимально узкими, вы уменьшаете число запросов в бакете, а если сделать 1 бакет - 1 запрос то вообще не увидите интерполяции. Но вместе с этим и потеряете весь смысл: большое число бакетов просто повесит интерфейс вашей графаны и вы не сможете посмотреть статистику за месяц, неделю, год.
В связи с этим предлагаю оставить общие графики в покое, они показывают температуру по больнице.
А для мониторинга выбросов использовать:
логировать выбросы, ELK позволит посмотреть графики логов чтобы оценить число выбросов в моменте
писать запросы с высоким RT в тот же прометеус отдельной метрикой. В этом случае бакеты будут достаточно маленькими и никакая интерполяция их не "слижет"
простите за духоту, долго работала на проекте с gps отслеживанием и я тот человек, который писал все эти интерполяции с миллионами gps точек )
чтобы не путали сервис ориентированную архитектуру а микросервисной
по этому пункту признаю свое поражение)
Ну сами посудите, какой смысл заменить в монолите вызов методов через память, вызовом методов через какой-то транспорт и назвать это микросервисом.
Аааа возможно вас зупатал пункт "Все модули используют одну базу данных, а взаимодействие между ними представляет собой цепочку вызовов функций, а не сетевых запросов. " и вы думаете что здесь про RPC, а я то библиотечное апи имела ввиду. Нарочно там не хотела писать про вызов методов чтобы никто про апи методы не подумал, а вы про RPC подумали. Надо подумать как переформулировать. Все нормально с моим монолитом, он сам с собой общается, не переживайте )
Кстати, вот вам какие-то ребята дали сервис, который они написали на несусветном языке, использую несусветные знания, которые не смогли реализовать в рамках модуля в вашем монолите - что будет, если вы вызовите их сервис, а они в это время будут делать деплой новой версии?
Общение по HTTP. Ну деплоят, Polly подождет. Кстати, у меня есть апи-метод прокся для резолва таких сервисов, но я боюсь вызывать у людей паническую атаку. Хватит контроллеров в библиотеках на сегодня)
Тогда еще было модно говорить "если один микросервис упадет, остальные 9 будут продолжать работать, но с ограниченным функционалом". Когда встречаются сервисы, разработчики которых справились с этой задачей, это действительно приятно. Монолит все-таки падает целиком. Но с другой стороны, сейчас со всеми куберами, свормами, дублированием датацетров, автоскейлингом и прочим, даже уборщица шваброй в дц не сможет положить твой сервис. Понадобится кластер распределенных по датацентрам уборщиц
Прийти к выводу об отсутствии архитектуры на основании того что все микросервисы общались через RPC вызовы - сильно, но давайте разбираться:
Основное отличие микросервисной архитектуры - это общение между микросервисами через шину сообщений
Вы ошибаетесь. Взять определение того же Мартина Фаулера здесь:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
То, каким способом взаимодействует приложение, не определяет микросервис это или нет. Более того, основной тип взаимодействия микросервисов - протокол HTTP. Но конечно вы можете настроить общение через шину сообщений, микросервис от этого не станет более микросервисным.
А то что вы изобрели - уже как лет 15, если не больше, изобретено в Django.
Ничего не изобретала, архитектуре модульных монолитов уже десятки лет, у меня вариант реализации паттерна, а не изобретение нового. Джанга молодец)
Звучит так как будто вы меня упрекаете в том что я развернула монолит лишь потому что не справилась с микросервисами) Ну да ладно, мы же тут собрались просто болтать и душно проводить вечера
Да, если проделать все что вы описали, будет технически почти все то же самое что и у меня, только не в монорепе. Придет продакт, закажет "сервис, который поздравляет людей с днем рождения" и мы из шаблона создадим 16-тый сервис, который будет изолирован, масштабироваться, тащить Common библиотеку, выкладываться известным общим шаблоном ci/cd, а заодно выложим новый конфиг в апигейтвей. Еще попросим девопсов выпустить роль для нового приложения в хранилище секретов. А когда выйдет .net 10, пойдем дружно обновлять 16 сервисов. Или только 2 из них, остальные как-нибудь сами ) Кстати, иметь 16 сваггеров тоже довольно удобно. Надеюсь во всех сервисах будут использованы хотя бы одни библиотеки сериализаторов и логирования. И давайте будем честны, даже в самом идеальном мире со всеми рабочими шаблонами, создавать новую пачку API методов и новый сервис - не одно и то же. Я не против оверинжениринга, он дает мне работу. Но надо же когда-нибудь остановиться )
Написать хорошо можно используя любую архитектуру.
Из контекста имела ввиду и микросервисную, и монолитную архитектуры
мне кажется, вы путаете понятия модульного монолита и монорепа. В моем случае модульного монолита я имею один общий деплой, один общий хост с di контейнером и общий модуль Common, где хранится единое подключение к базе, брокеру сообщений и прочему, т.е. все сервисы причесаны к единому стандарту. Это не "микросервис в монолите", это монолит с одной точкой входа, куски которого притворяются микросервисами
И куда интереснее было бы послушать про процесс причесывание всего к единому виду, и как выжить в процессе.
проблема в том, что я не знаю как выжить в процессе) по-моему единственный вариант - это делегировать задачу на другого человека, чтобы помер не ты. Это путь из боли и страданий
если в рамках одного языка - единое соглашение по неймспейсам во всех микросервисах достаточно, при условии общих соглашений по конфигу.
не соглашусь, этого не достаточно. Как я написала в выводе, задачу через микросервисы решить можно, но придется попотеть: внедрять общие библиотеки, создавать шаблоны для выкладки, выделять отдельный микросервис для авторизации, автоматизировать обновление хостов через инструменты DevOps. Я даже изначально рассматривала этот вариант, но на мой вкус это слишком много действий для маленьких админок, возможно мы с вами в разных контекстах.
разделения уровней доступа
эту задачу я решила единой авторизацией и определением уровня доступа для каждого контроллера в модуле при помощи аттрибутов. Определяем на входе кто из сотрудников авторизовался, в какой он команде, рабочей группе и должности и решаем какие у него права на взаимодействие с модулем.
плохо организованные микросервисы не есть камень в огород микросервисов. это камень в огород их организации.
нет никаких камней в огородах, я не говорю что микросервисы это плохо. Написать хорошо можно используя любую архитектуру. У меня просто решение задачи одним способом, вы можете использовать любой другой
Честно, более красивым решением было бы вытащить нагруженный модуль в микросервис и масштабировать по общим принятым стандартам. Но если говорить о паттерне SUFA, то мы можем описать в сервисе все зависимости модуля и инициализировать при выкладке только их. Например, в ci/cd можно указать роль "users", зарегистрировать в DI контейнере только конкретные модули, сообщить в service-discovery свою роль и балансировать урлы с префиксом модуля только на монолиты с соответствующей ролью. Однако я настоятельно рекомендую так не делать :)
Спасибо за статью! Она мне близка во всем кроме пункта с бюрократией) Подскажите, ваши коллеги тоже следуют принципу "Постоянно улучшай" или это так и живет на уровне вашей собственной инициативы?
Спасибо за статью, повеселилась 👏 так вот почему все бесконечно заводят девопсам задачи на перекладывание сервисов с ноды на ноду. Чисто чтобы парням скучно не стало и они не придумали себя развлечь чем-то подобным))
У меня муж девопс, растим ребенка. Наверно это вообще идеальный мир. Когда дочь была карапузом, муж вставал в 8 утра с ребенком сидеть, я до 10 отсыпалась, потом он садился за комп в соседнюю комнату, а я оставалась с малышом.
Спина не устает попу мыть, почти всегда могу вытащить из-за компа на 5 минут и попросить помощи. Еще есть с кем ребенка оставить пока ходишь в туалет.
Няни немного в шоке от двух больших компов, по 2 монитора у каждого и обилия другой техники, но привыкают. Ах да, у девопсов есть деньги на няню, рекомендую )
Я не была отрезана от мира, дома всегда со мной был разумный человек, с которым можно поговорить. Плюс, если что случится, понимать, что ты не одна - бесценно.
Вечером ляля уснула - бежим гамать в комп. Да и вообще за декрет я отдохнула от работы и апнула даймонд в овервоче и апексе, так что грех жаловаться :)
Не хотела вгонять в краску, я хвалила не вас, а позицию, которая имеет место быть. Странно что вас удивил мой восторг, в статье же сказано, что я люблю дискуссии и конфликты )
Как по мне, то деньги - это вполне достаточная мотивация.
Да, для состоявшегося профессионала этого достаточно. Но часто я вижу как приходят люди, делают задачу по принципу "мне сказали сказали сделать, я сделал", а то что в проекте все пошло по одному месту, в общем-то все равно, ЗП я уже получил. 10 лет назад было "стремно перед пацанами" подкладывать говну своим коллегам, можно было кривые взгляды словить, да и подзатыльник от лида получить. Сейчас я не могу ничей код назвать говной, меня сочтут токсичным нарушителем экологичности коллектива. А человек просто пока не вырос как профессионал, нужно подождать, он подрастет, ага.
Что делать с такими людьми? Мотивировать повышением ЗП, если перестанет косячить? А он и не косячил - он сделал то, что вы просили. Ну да, не подумал о последствиях, но в задаче не было сказано думать о последствиях.
Добросовестность же - часть того самого профессионализма.
Хорошо сказано. Было бы хорошо если бы все добросовестно выполняли свою работу, пока в них кидают купюрами. Я как раз и говорю об утере профессионализма на фоне излишне мягкого менеджмента
Поправочка: в сервисах с большим RPC, погрешность из-за линейной интерполяции наиболее высока.
Спасибо за статью, добавила в закладки. Был опыт использования варианта 2, значение перцентиль выносила в переменные графаны, во время просмотра просто переключала значения перцентиль, на практике всегда хватало 90.
Все беды из-за линейной интерполяции и большого числа ваших данных. В сервисах в небольшим RPC, погрешность из-за линейной интерполяции наиболее высока. Условно: если из 10 запросов в бакете у вас 1 выброс, то его будет видно, но если туда влезла 1000, то этот выброс "слижется" в прямую. Делая бакеты максимально узкими, вы уменьшаете число запросов в бакете, а если сделать 1 бакет - 1 запрос то вообще не увидите интерполяции. Но вместе с этим и потеряете весь смысл: большое число бакетов просто повесит интерфейс вашей графаны и вы не сможете посмотреть статистику за месяц, неделю, год.
В связи с этим предлагаю оставить общие графики в покое, они показывают температуру по больнице.
А для мониторинга выбросов использовать:
логировать выбросы, ELK позволит посмотреть графики логов чтобы оценить число выбросов в моменте
писать запросы с высоким RT в тот же прометеус отдельной метрикой. В этом случае бакеты будут достаточно маленькими и никакая интерполяция их не "слижет"
простите за духоту, долго работала на проекте с gps отслеживанием и я тот человек, который писал все эти интерполяции с миллионами gps точек )
по этому пункту признаю свое поражение)
Аааа возможно вас зупатал пункт "Все модули используют одну базу данных, а взаимодействие между ними представляет собой цепочку вызовов функций, а не сетевых запросов. " и вы думаете что здесь про RPC, а я то библиотечное апи имела ввиду. Нарочно там не хотела писать про вызов методов чтобы никто про апи методы не подумал, а вы про RPC подумали. Надо подумать как переформулировать. Все нормально с моим монолитом, он сам с собой общается, не переживайте )
Общение по HTTP. Ну деплоят, Polly подождет. Кстати, у меня есть апи-метод прокся для резолва таких сервисов, но я боюсь вызывать у людей паническую атаку. Хватит контроллеров в библиотеках на сегодня)
Тогда еще было модно говорить "если один микросервис упадет, остальные 9 будут продолжать работать, но с ограниченным функционалом". Когда встречаются сервисы, разработчики которых справились с этой задачей, это действительно приятно. Монолит все-таки падает целиком. Но с другой стороны, сейчас со всеми куберами, свормами, дублированием датацетров, автоскейлингом и прочим, даже уборщица шваброй в дц не сможет положить твой сервис. Понадобится кластер распределенных по датацентрам уборщиц
Прийти к выводу об отсутствии архитектуры на основании того что все микросервисы общались через RPC вызовы - сильно, но давайте разбираться:
Вы ошибаетесь. Взять определение того же Мартина Фаулера здесь:
То, каким способом взаимодействует приложение, не определяет микросервис это или нет. Более того, основной тип взаимодействия микросервисов - протокол HTTP. Но конечно вы можете настроить общение через шину сообщений, микросервис от этого не станет более микросервисным.
Ничего не изобретала, архитектуре модульных монолитов уже десятки лет, у меня вариант реализации паттерна, а не изобретение нового. Джанга молодец)
Ну не прям фиг знает что, там картинки смешные есть!)
Поняла ваш посыл, я подумаю что интересного можно написать на тему рефакторинга и наведения порядков
Звучит так как будто вы меня упрекаете в том что я развернула монолит лишь потому что не справилась с микросервисами) Ну да ладно, мы же тут собрались просто болтать и душно проводить вечера
Да, если проделать все что вы описали, будет технически почти все то же самое что и у меня, только не в монорепе. Придет продакт, закажет "сервис, который поздравляет людей с днем рождения" и мы из шаблона создадим 16-тый сервис, который будет изолирован, масштабироваться, тащить Common библиотеку, выкладываться известным общим шаблоном ci/cd, а заодно выложим новый конфиг в апигейтвей. Еще попросим девопсов выпустить роль для нового приложения в хранилище секретов. А когда выйдет .net 10, пойдем дружно обновлять 16 сервисов. Или только 2 из них, остальные как-нибудь сами ) Кстати, иметь 16 сваггеров тоже довольно удобно. Надеюсь во всех сервисах будут использованы хотя бы одни библиотеки сериализаторов и логирования. И давайте будем честны, даже в самом идеальном мире со всеми рабочими шаблонами, создавать новую пачку API методов и новый сервис - не одно и то же. Я не против оверинжениринга, он дает мне работу. Но надо же когда-нибудь остановиться )
Из контекста имела ввиду и микросервисную, и монолитную архитектуры
Мне не знаком этот паттерн. В исходниках, что лежат в статье, нет ничего общего с модульными монолитами https://github.com/ardalis/OrganizingAspNetCore/tree/master
Пункты 1 и 2 имеются, 3 и 4 можно попробовать. Спасибо!
мне кажется, вы путаете понятия модульного монолита и монорепа. В моем случае модульного монолита я имею один общий деплой, один общий хост с di контейнером и общий модуль Common, где хранится единое подключение к базе, брокеру сообщений и прочему, т.е. все сервисы причесаны к единому стандарту. Это не "микросервис в монолите", это монолит с одной точкой входа, куски которого притворяются микросервисами
проблема в том, что я не знаю как выжить в процессе) по-моему единственный вариант - это делегировать задачу на другого человека, чтобы помер не ты. Это путь из боли и страданий
не соглашусь, этого не достаточно. Как я написала в выводе, задачу через микросервисы решить можно, но придется попотеть: внедрять общие библиотеки, создавать шаблоны для выкладки, выделять отдельный микросервис для авторизации, автоматизировать обновление хостов через инструменты DevOps. Я даже изначально рассматривала этот вариант, но на мой вкус это слишком много действий для маленьких админок, возможно мы с вами в разных контекстах.
эту задачу я решила единой авторизацией и определением уровня доступа для каждого контроллера в модуле при помощи аттрибутов. Определяем на входе кто из сотрудников авторизовался, в какой он команде, рабочей группе и должности и решаем какие у него права на взаимодействие с модулем.
нет никаких камней в огородах, я не говорю что микросервисы это плохо. Написать хорошо можно используя любую архитектуру. У меня просто решение задачи одним способом, вы можете использовать любой другой
Шаришь )
Честно, более красивым решением было бы вытащить нагруженный модуль в микросервис и масштабировать по общим принятым стандартам. Но если говорить о паттерне SUFA, то мы можем описать в сервисе все зависимости модуля и инициализировать при выкладке только их. Например, в ci/cd можно указать роль "users", зарегистрировать в DI контейнере только конкретные модули, сообщить в service-discovery свою роль и балансировать урлы с префиксом модуля только на монолиты с соответствующей ролью. Однако я настоятельно рекомендую так не делать :)
Спасибо за статью! Она мне близка во всем кроме пункта с бюрократией) Подскажите, ваши коллеги тоже следуют принципу "Постоянно улучшай" или это так и живет на уровне вашей собственной инициативы?
Сегодня на Хабре прям соревнование промтов
Спасибо за статью, повеселилась 👏 так вот почему все бесконечно заводят девопсам задачи на перекладывание сервисов с ноды на ноду. Чисто чтобы парням скучно не стало и они не придумали себя развлечь чем-то подобным))
То Хабр статьи из песочницы не выпускает из-за «недостаточной академичности», то разрешает подобные авторские развороты )
Спасибо. Сижу и думаю что за автор Мартерт, впервые слышу. Да и зовут его не Робин, а Роберт
Однажды моя коллега выдала: "Чтобы выйти замуж за девопса, надо начать встречаться с сисадмином" :)
У меня муж девопс, растим ребенка. Наверно это вообще идеальный мир. Когда дочь была карапузом, муж вставал в 8 утра с ребенком сидеть, я до 10 отсыпалась, потом он садился за комп в соседнюю комнату, а я оставалась с малышом.
Спина не устает попу мыть, почти всегда могу вытащить из-за компа на 5 минут и попросить помощи. Еще есть с кем ребенка оставить пока ходишь в туалет.
Няни немного в шоке от двух больших компов, по 2 монитора у каждого и обилия другой техники, но привыкают. Ах да, у девопсов есть деньги на няню, рекомендую )
Я не была отрезана от мира, дома всегда со мной был разумный человек, с которым можно поговорить. Плюс, если что случится, понимать, что ты не одна - бесценно.
Вечером ляля уснула - бежим гамать в комп. Да и вообще за декрет я отдохнула от работы и апнула даймонд в овервоче и апексе, так что грех жаловаться :)
Не хотела вгонять в краску, я хвалила не вас, а позицию, которая имеет место быть. Странно что вас удивил мой восторг, в статье же сказано, что я люблю дискуссии и конфликты )
Да, для состоявшегося профессионала этого достаточно. Но часто я вижу как приходят люди, делают задачу по принципу "мне сказали сказали сделать, я сделал", а то что в проекте все пошло по одному месту, в общем-то все равно, ЗП я уже получил. 10 лет назад было "стремно перед пацанами" подкладывать говну своим коллегам, можно было кривые взгляды словить, да и подзатыльник от лида получить. Сейчас я не могу ничей код назвать говной, меня сочтут токсичным нарушителем экологичности коллектива. А человек просто пока не вырос как профессионал, нужно подождать, он подрастет, ага.
Что делать с такими людьми? Мотивировать повышением ЗП, если перестанет косячить? А он и не косячил - он сделал то, что вы просили. Ну да, не подумал о последствиях, но в задаче не было сказано думать о последствиях.
Хорошо сказано. Было бы хорошо если бы все добросовестно выполняли свою работу, пока в них кидают купюрами. Я как раз и говорю об утере профессионализма на фоне излишне мягкого менеджмента