Comments 10
или же падение одного из процессов ведет к неработоспособности другого — это не микросервис, а распределенный монолит
Если микросервис авторизации упадёт, что будет? А если это микросервис аутентификации?
«Как быть с данными?»
Я всё-таки не понял... Вот, мы разложили данные на несколько кучек (или, быть может, даже куч) в MongoDB, PostgreSQL и т.д. А потом нам понадобилось построить по этим данным какую-нибудь аналитику, например. Придётся создавать ещё одну распределенную команду, которая будет пилить ETL-процедуры, поминая недобрыми словами разработчиков микросервисов, которые не особо заморачивались с целостностью данных, дублированием, нормализацией, просто сваливали всё в NoSQL базу и т.д. Хотя нет, лучше сделать несколько таких команд, каждая из которых будет пилить ETL-процедуры под свои витрины. Вот, тогда наступит полное счастье и распределенность!
Извиняюсь за сарказм :) У меня стойкое ощущение, что подавляющее большинство разработчиков относятся к схеме данных как к внутренним техническим деталям реализации. И типа это личное дело разработчиков каждого отдельного микросервиса как структурировать данные, как называть таблицы и столбцы, какие технологии использовать, в какой момент взять и перефигачить полностью схему данных, потому что Agile и нужно срочно делать очередной релиз. Как будто эти данные нигде и никогда за пределами микросервиса использоваться не будут. Я лично насмотрелся на ужасы БД-строения и у меня посттравматический синдром стойкая убежденность, что схема данных на предприятии должна быть одна, за неё должен отвечать один человек или небольшая группа людей, они принимают решение о том как разложить её на несколько СУБД, если требуется. А разработчики микросервисов - это пользователи этой единой схемы данных.
Либо другой вариант. Каждый микросервис - это фактически отдельное приложение, на разработку которого нет возможности как-то влиять, ну, пилят они у себя там что-то и пилят. При этом невозможно понять что именно пилят и, уж, тем более как-то повлиять на это. От безысходности бытия приходится придумывать какие-то другие механизмы интеграции, шину какую-нибудь сделать, нафигачить тонны сложных ETL-процедур.
Вот, мы разложили данные на несколько кучек (или, быть может, даже куч) в MongoDB, PostgreSQL и т.д. А потом нам понадобилось построить по этим данным какую-нибудь аналитику, например.
В случае, если надо строить аналитику, применяется уже какое-либо OLAP-решение, в котором данные по сути дублируются. Откуда брать данные - вопрос очень дискуссионный, но есть несколько решение. Аналитический сервис либо может забирать интересующие данные из других сервисов и складировать у себя, либо, как вариант, если данные реально должны шариться между несколькими службами, можно использовать что-нибудь на подобие озера данных (т.е. первичные данные лежат где-то в необработанном виде, а разные сервисы затягивают их к себе и форматируют).
У меня стойкое ощущение, что подавляющее большинство разработчиков относятся к схеме данных как к внутренним техническим деталям реализации. И типа это личное дело разработчиков каждого отдельного микросервиса как структурировать данные
Если сервисы организованы, как черные ящики и взаимодействуют с внешним миром только через стройное АПИ, то это от части действительно так. Разработчики достаточно вольны в своих решениях. Но тут я с Вами тоже согласен, в любом случае в компании должен быть общий подход к организации данных и к определению контекста. Если в двух сервисах одна и та же сущность называется по-разному(userId и memberId, например), то даже банальная коммуникация между командами может превратиться в сущий ад.
Каждый микросервис - это фактически отдельное приложение, на разработку которого нет возможности как-то влиять, ну, пилят они у себя там что-то и пилят.
Хоть и не панацеей, но хорошим подспорьем в данном случае будет качественная техническая документация)
Да, конечно аналитику можно построить в любом случае, но это разные ситуации:
Есть единая схема данных, которая разрабатывалась ограниченным количеством людей в соответствии с едиными стандартами, данные нормализованы, обеспечена ссылочная целостность, всё это лежит в одной базе данных
То же самое, но уже разложено на несколько баз данных, есть дублирование данных, не везде есть внешние ключи
Вообще полный треш, куча баз данных сделанных как угодно
Для меня ближе всего 1-ый вариант. Чтобы согласиться на 2-ой нужны какие-то веские основания. Причём даже то, что эти микросервисы разрабатывают разные команды само по себе для меня не означает, что нужно сразу автоматически распиливать и базу данных. Ну, а 3-ий вариант в моём понимании это ужас-ужас. Да, конечно, можно сделать отдельное хранилище, или если не осилили хранилище, то озеро данных, нафигачить ETL-процедур, чтобы всё это наполнять. Но ради чего тратить на всё это кучу времени когда можно сразу сделать нормально?
У меня немного подгорает от того, что в подавляющем большинстве статей про микросервисы говорится о том, что распиливание базы данных по сервисам - это великое благо, каждый может использовать СУБД какие хочет, проектировать базу данных так как принято в этой отдельной команде, менять схему данных когда захочет. А в добавок ко всему ещё приводятся примеры, когда чуть ли не для каждой сущности (клиент, заказ, товар, ...) создаётся свой микросервис со своей базой данных. И типа это норма, на мой взгляд это вообще не норма. Схема данных и сами данные - это основа приложения. А то как в данный момент кому-то было удобно распилить приложение на микросервисы по командам - это что-то абсолютно второстепенное и временное, сегодня одни команды, через год - другие. А для работы с данными, на мой взгляд, горизонт планирования должен быть лет на десять вперед и они не могут быть разложены как попало по черным ящикам (микросервисам).
Что-то меня понесло :) У меня представление примерно такое. В ядре приложения слой хранения данных, по возможности единый для всей компании (если это корпоративная разработка) или для продукта (если продуктовая разработка) или для группы компаний, группы продуктов (если их несколько и они сильно пересекаются). А дальше можно добавить слой API, фронтенд, аналитические системы, ... И для меня лично совершенно не факт, что API, реализованные в виде микросервисов, будут основными потребителями данных, и что под них нужно эту схему данных подстраивать.
А разве каждый endpoint не выходит на микросервис в монолите? Или они должны быть в отдельных файлах?
Я подозреваю, что главное отличие в том, что монолит сидит на одном порте, а микросервесы на нескольких. Только так я могу понять как при падение одного, другое будет работать исправно.
Подскажите по вашему опыту как реализуете "Общие НСИ" в локальных микросервисах?
например, есть микросервис для ведения справочника "Контрагент"
На уровне другого "локального" микросервиса, возникает необходимость быстрой обработки данных с учетом полей данных из сервиса "Контрагент" (например, простейшее постраничное отображение заказов с сортировкой по наименованию "контрагент" заказов 10млн. контрагентов 1млн)
как поступаете? делаете синхронный кэш Контрагентов на уровне локального микросервиса?
Вариантов несколько:
Можно, как Вы и предложили, использовать локальный кэш. Основной проблемой в таком случае, как обычно является инвалидация оного.
Если данные +- статичные или зафиксированные в итории, можно хранить требуемую информацию непосредственно в базе микросервиса (для Вашего примера, в сервисе Заказов можно хранить не только id контрагента, но и его имя). Понятное дело, что в данном случае у нас возникают проблемы с обновлением данных (если бизнес разрешит, то лучше их вообще не трогать)
Если данные действительно НСИ, например, коды валют(в Вашем примере, Контрагенты не совсем подпадают под критерий, т.к. справочник меняется достаточно часто), то нет ничего плохого и в том, что бы банально захардкодить наименования.
Можно реализовать отдельностоящий сервис аналитики, который будет аккумулировать в себе всю необходимую информацию (т.е. отдельно сервис для оперативной информации, отдельно для аналитической). Данные придется синкать, что значительно усложнит инфраструктуру.
В общем, всё, как обычно, строится на компромиссах)
Когда и как переходить с монолита на микросервисы. Предпосылки и общие понятия