S>Вот уже в одной отчетной форме (в одном диалоге) имеем данные из двух доменов.
Нет не имеем
S>Можно, конечно, к справочнику "Видов анализа" обратиться через API сервиса "Лаборатория", а в таблице "Результаты_анализов_пациента" из сервиса "Мед.карта" хранить только ID вида анализа (GUID или некий строковый
идентификатор).
Совсем не так. Есть общий информационный сервис-правочник с кодами исследований и болезней, который используется и в мед.картах и в лаборатории. S>Но ведь простой SQL-ный "INNER JOIN" будет проще. S>Нет?
Конечно нет, потому что мед.карты в реляционной субд, а результаты лабораторных исследований в NoSql бд.
Здравствуйте, white_znake, Вы писали:
_>А как связаны больные с используемым оборудованием? Из мед.кабинета в лабораторию уходит пробирка со штрихкодом и показателями, которые нужно исследовать, в мед.карте больного добавляется направление на анализ со штрихкодом и требуемыми показателями. _>Из лаборатории приходит отчет со штрихкодом и результатами. Ни какой зависимости между больным и лабораторным оборудованием — нет. _>В лаборатории не знают ни чего о пациенте.
А я не знаю, как связаны.
Это задача не уровня лаборатории.
Вдруг есть уникальные люди, у которых стандартный анализ на А на оборудовании Б имеет какие-то особенности?
Как их найти?
Или как найти какие-то другие неочевидные зависимости?
S>Вдруг есть уникальные люди, у которых стандартный анализ на А на оборудовании Б имеет какие-то особенности? S>Как их найти? S>Или как найти какие-то другие неочевидные зависимости?
Какие прекрасные фантазии
Но в лабораторию данные поступают обезличенные.
Ну ладно. Предположим, что случлась какая-то аномалия и нужно для конкретного направления на анализы (по штрих коду) получить данные о том, на каком оборудовании и с какими параметрами производились анализцы.
Не проблема. Добавим метод в REST API сервиса лаборатории о получении таких данных. Но это реально будет редкоиспользуемой фичей. Думается, что не каждый врач разбирается в настройках оборудования.
Здравствуйте, swimmers, Вы писали:
S>Как их найти? S>Или как найти какие-то другие неочевидные зависимости?
Обычно подобное решается созданием специальных свалок данных, по которым можно безболезненно для production'а запускать аналитику.
Кроме того, с учётом защиты приватных данных, часто в принципе нельзя давать возможность просто взять и выполнить произвольный запрос. Так как нужно редактирование или анонимизирование.
Здравствуйте, white_znake, Вы писали:
S>>Вот уже в одной отчетной форме (в одном диалоге) имеем данные из двух доменов. _>Нет не имеем
_>Совсем не так. Есть общий информационный сервис-правочник с кодами исследований и болезней, который используется и в мед.картах и в лаборатории.
Отлично. То есть на самом деле тут три сервиса — справочник, лаборатория, и мед.карты. И простая штука "результат исследования" в PDF генерируется из данных трёх сервисов. Я правильно понял?
Кстати — какой из сервисов за этот PDF отвечает: медкарты, лаборатория, или справочник?
_>Конечно нет, потому что мед.карты в реляционной субд, а результаты лабораторных исследований в NoSql бд.
Стесняюсь спросить: а зачем? Что там у нас такого в лабораторных исследованиях, что не ложится в какой-нибудь банальный postgres?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, white_znake, Вы писали:
_>Из мед.кабинета в лабораторию уходит пробирка со штрихкодом и показателями, которые нужно исследовать, в мед.карте больного добавляется направление на анализ со штрихкодом и требуемыми показателями. _>Из лаборатории приходит отчет со штрихкодом и результатами. _>В лаборатории не знают ни чего о пациенте.
Это ты описал процесс, как он выглядит со стороны медиков (лечащий врач, передавший пробирку в лабораторию, и лаборант, проведший анализ содержимого пробирки).
А как это выглядит программно (для простоты считаем, что одна пробирка — один вид анализа)?
Предполагаю так (поправь меня): лаборант, получив пробирку с биоматериалом внутри и штрихкодом снаружи, сканирует этот штрихкод
по ID пробирки (полученном из штрих-кода) в домен "Мед.карта" уходит запрос типа "Какой анализ надо сделать для пробирки с таким-то ID?"
из домена "Мед.карта" приходит ID типа анализа
в домене "Лаборатория" создается некий объект типа "Проведение анализа" с указанием ID пробирки и ID типа анализа
из домена "Лаборатория" в домен "Справочники" уходит запрос типа "Что это за тип анализа с таким-то ID типа?"
из домена "Справочники" приходит ответ с описанием типа анализа
лаборант, прочитал задание, провел анализ, внес результаты (которые сразу улетели в домен "Мед.карта"), а в домене "Лаборатория" у добавленного выше объекта "Проведение анализа" выставляется статус "Выполнено, передано в Мед.карту".
в домене "Мед.карта" полученные результаты сохраняются и проставляется признак, что результаты анализов получены
Примерно так?
Ну тогда отвечая на твой изначальный вопрос: _>>>За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?
могу сказать, что как раз связь с доменом "Справочники" очень хочется сделать "INNER JOIN"-ом.
Но сделать так нельзя, потому, что справочник типов анализа должен быть доступен из обоих прикладных доменов: и для "Мед.карты", и для "Лаборатории".
Красота — наивысшая степень целесообразности. (c) И. Ефремов
Здравствуйте, 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 тянется из другого сервиса.
Красота — наивысшая степень целесообразности. (c) И. Ефремов
Здравствуйте, 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 на каждое изменение там — слишком накладно. И это вполне типичная ситуация.
Если это из "как можно делать" — может быть. А вот микросервисы не получаются — в описании нет замкнутыых контествов ("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 он вынесен в отдельный сервис "Справочники":
Именно! Сервисы, хоть микро, хоть макро, определяются тем, что они делают, а не тем какие данных они хранят. Проектирование от данных, а не от обязанностей, это вернейший способ превратить любой проект в алтарь поклонения макаронному монстру.
Взять сервис "Справочники", что полезного он делает? Ничего не делает. Как он будет обрабатывать ситуацию когда есть две лаборатории, у которых отличаются наборы анализов? Или если у лаборатории ограниченная пропускная способность по какому-то исследованию. Никак не будет, если его не связать жестко с лабораторией. Наличие обязательно жесткой связи это хороший такой звоночек что граница сервиса выбрана неудачно.
BE>Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].
BE>Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?
BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов. BE>Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему. BE>А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.
BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.
BE>Кто как делает?
BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
По мне собственное проблема не в этом. Разбить программу на модули не составляет труда, хоть через микросервисы, хоть как-то по другому. Проблема сделать что бы это все собиралось, обновлялось с учетом версий и по нажатию кнопки, а не через ковыряние простыней конфигов, запусков разных скриптов и других магических действий. Плюс нужно автоматизировать весь процесс разработки, что бы было удобно, а это в этом случае не так просто.
Здравствуйте, BlackEric, Вы писали:
BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки
Пока проект маленький — да, повышает трудоемкость, но когда монолит становится большим появляется "синдром завтрашнего утра",
когда на мерж изменений сделанный командой которая работает уходит каждый день по пол дня.
Когда ревьюверы не досмотрели и в коде образовываются зависимости, потому что не все знаю архитектуру этого монолита.
Или какая-то команда залила изменения, которые все сломали, а ты смержил этот код и тестируешь и понимаешь что, что-то не работает, но не знаешь что.
А смоук, интеграционные, юнит тест на твоей машине работают больше часа.
Микросервисная архитектура прежде всего позволяет разбить проект на независимые модули, и там где код не самый важный отдать на разработку менее опытным разработчикам(или на аутсорс).
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, 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>Если что интересно — спрашивайте. Расскажу подробнее.
Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена. Предполагаем, что сервис примитивный, например складывает два числа и разного рода мастер-бд отсутствуют?
.