Здравствуйте, gyraboo, Вы писали:
G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.
Это как раз не проблема. Указывать для какого юзера настройки необходимо все равно.
Гораздо серьезнее проблема что другие инстансы не сразу подхватывают изменение настроек сделанное на другом инстансе. А так как балансировщик обычно раскидывают клиентские подключения по случайным серверам начинаются проблемы пока кеш не обновится.
Здравствуйте, BlackEric, Вы писали:
G>>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.
BE>Это как раз не проблема. Указывать для какого юзера настройки необходимо все равно. BE>Гораздо серьезнее проблема что другие инстансы не сразу подхватывают изменение настроек сделанное на другом инстансе. А так как балансировщик обычно раскидывают клиентские подключения по случайным серверам начинаются проблемы пока кеш не обновится.
Ну да, у монолита обычно локальный кэш, так надо распределенный кэш прикручивать, hazelcast или gridgain из коробки такое умеют. А это тоже шаг в сторону микросервисов. Правда у распределенного кэша всё равно остается задержка или рассогласование, но это уже неизбежное следствие любой распределённой системы, по теореме CAP — "выбирайте два из трёх".
Здравствуйте, gyraboo, Вы писали:
G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.
Ну естественно при проектировании монолита, который потенциально может понадобиться масштабировать, подобные вопросы нужно как минимум держать в уме. Понятно, что если приложение рассчитано на один сервер, а его запустили на нескольких, будут нюансы.
Я просто не согласен с тем, что это первый шаг к микросервисам. Это первый шаг к распределённой системе и скорей всего для подавляющего большинства проектов этот шаг будет последним, т.к. больше ничего и не нужно.
Посмотрел я на картинки, и что-то от них 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.
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>Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.
В некоторых проектах такое норм. В некоторых не прохиляет. Смотри пример. В одном из проектов нужно было распознавать объекты с потокового видео.
Так, вот сервис этот был ресурсозатратным и дорогим, естественно, его масштабировали при достижении пиковых нагрузок, разворачивая довольно дорогие инстансы виртуалок в облаке.
А был ряд сервисов по-проще, у которых нагрузка была гораздо меньшей. И за чем эти сервисы хостить на дорогих инстансах?
И тут встает финансовый вопрос. Если у нас монолит, то при необходимости масштабировать сервисы, которые требуют минимальных ресурсов, придется их деплоить на более производительные инстансы.
Или задача автоматического масштабирования становится очень интересной.
vsb>Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.
Тут дело не только в масштабировании бд.
Для сущностей одного домена лучше подойдет реляционная бд, для сущностей другого домена лучше подойдет джокументная бд, для сущностей 3-го домена, лучше подойдет графовая бд.
Понятно, что все можно запилить на реляционной БД, но в некоторых случаях — это будет сложнее.
Здравствуйте, BlackEric, Вы писали:
BE>Один сервис — один докер контейнер или ВМ. Иначе смысла нет. Даже перезапуск веб-сервера перезапускает все сервисы сразу. Ничем не будет отличаться от монолита.
А если веб-сервисов несколько контейнеров, и они спрятаны за nGinx? Тогда можно ребутать каждый контейнер без особых потерь. А если используется какой-нибудь распределённый In-memory storage для хранения сессий и прочего состояния, то вообще нет проблем ребутать, главное чтоб число одновременных онлайн-узлов не опускалось ниже требований репликатора.
Здравствуйте, gyraboo, Вы писали:
G>И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.
Здравствуйте, white_znake, Вы писали:
_>А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах? _>Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет. _>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?
Фантазируя — а если понадобится какая-то статистика/анализ зависимостей по больным, лабораториям и моделями оборудования лабораторий?
Как быть?
Здравствуйте, white_znake, Вы писали:
_>А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах? _>Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет. _>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?
Ну, например, первое, что приходит в голову — врачу, работающему с мед.картой, (да и пациенту на руки распечатку) надо отобразить так:
1. Вверху диалога — ФИО пациента (домен "Мед.карта"?)
2. Под ФИО таблицу со столбцами:
Вид анализа (как минимум — это название из справочника, находящегося в домене "Лаборатория"?)
Фактический результат (то, что реально обнаружили в лаборатории)
Допустимые результаты (то, что считается нормой для данного людей данного пола/возраста и т.п.)
Вот уже в одной отчетной форме (в одном диалоге) имеем данные из двух доменов.
Можно, конечно, к справочнику "Видов анализа" обратиться через API сервиса "Лаборатория", а в таблице "Результаты_анализов_пациента" из сервиса "Мед.карта" хранить только ID вида анализа (GUID или некий строковый идентификатор).
Но ведь простой SQL-ный "INNER JOIN" будет проще.
Нет?
Красота — наивысшая степень целесообразности. (c) И. Ефремов
Здравствуйте, swimmers, Вы писали:
S>Здравствуйте, white_znake, Вы писали:
_>>А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах? _>>Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет. _>>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?
S>Фантазируя — а если понадобится какая-то статистика/анализ зависимостей по больным, лабораториям и моделями оборудования лабораторий? S>Как быть?
А как связаны больные с используемым оборудованием? Из мед.кабинета в лабораторию уходит пробирка со штрихкодом и показателями, которые нужно исследовать, в мед.карте больного добавляется направление на анализ со штрихкодом и требуемыми показателями.
Из лаборатории приходит отчет со штрихкодом и результатами. Ни какой зависимости между больным и лабораторным оборудованием — нет.
В лаборатории не знают ни чего о пациенте.
. Вот вы начинаете проект — по какому критерию будете отдельные сервисы выделять?
