Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 10
Дорого! Очень дорого!
Я правильно понимаю, что если у нас нет RPC, а есть только обмен сообщениями, то каждый сервис должен иметь свою копию необходимых для ответа данных? Что-то нереальное.
Не обязательно прям копию, можно дать доступ к вью в отдельной интеграционной схеме в бд сервиса источника данных. Тащить всё через события может быть накладно. Но давайте будем честны: как много проектов, где данных столько, что микросервису нужно дублировать пару терабайт данных? Микросервисы то сами по себе не то, что бы для всех.
И это уже зависимость. Под зависимостью я понимаю, что сервис не может выполнять свою основную функцию без другого сервиса.
Т.е. если вью лег, то наш сервис тоже лёг.
микросервису нужно дублировать пару терабайт данных
Я понял автора довольно радикально: если есть зависимость от другого сервиса, тащи данные к себе. Скажем вы авито, вам нужно что-то из заказа - тащи все заказы к себе.
На моей практике делают по всякому: где-то дублируют модель чтения (а потом бьются за качество данных), где-то ходят за данными в другие сервисы. Есть некоторое количество сервисов, которые если полягут, поляжет многое.
Я таки считаю, что нет запрета ходить в другие сервисы, убер так делает, значит и нам можно :)
https://habr.com/ru/companies/flant/articles/514830/
Сервис-клиент должен иметь некоторое описание интерфейса сервиса-поставщика, оно включает схемы (структуры) данных для понимания, что допустимо отправлять и как разбирать ответ. На основе этого описания можно писать как тесты, так и моки сервиса-поставщика. Это справедливо и для RPC (обычно используется спецификация Swagger/OpenAPI, или определение сервиса gRPC, или что-то подобное), и для обмена сообщениями. Можно, конечно, эти описания схем вынести в специализированный репозиторий схем, но бывает проще иметь копии описаний.
Всмысле "Как не получить распределённый монолит", это же гомогенные распределенные системы, вполне желаемая многими архитектура, зачем ее избегать. Гораздо проще в разработке и эксплуатации чем микросервисы. СУБД например ее реализуют.
"Распределённым монолитом" обычно называют часто возникающий архитектурный антипаттерн, когда "обычную" (монолитную) систему преобразовывают в микросервисную путём замены простых вызовов функций на RPC. Из-за природы сетевых взаимодействий система начинает работать медленно и нестабильно, из-за распределённой структуры усложняются добавление фич, отладка, развертывание, поддержка - т.е. получившаяся система сочетает недостатки и микросервисного, и монолитного стиля, и теряет их преимущества. На самом деле это не монолит. Это скорее гетерогенная распределённая система, если пытаться классифицировать, имеющая свойства монолитной при деплое и комплексной при отладке (когда надо наоборот), выглядящая как плохо работающая куча сервисов, в которой тяжело разобраться.
Вы так говорите как будто это что-то плохое. Вот вам сходу преимущества распределенного монолита над микросервисами:
Нет дублирования данных, а значит нет и проблемы рассинхронизации и как следствие синхронизыции
Значительно проще разрабатывать т.к. полный контроль над API, стартом системы и вообще всем
Значительно проще тестировать - полный контроль над версиями
Проще деплоить - одна версия на все. Процесс деплоя локализован во времени
И еще у меня подозрение что то, что вы описываете как микросервисы на самом деле и сами являются монолитами. Это где слыхано чтоб 10 человек занималось одним микросервисом? Они скорее десятком-другим заведовать будут. А тут прямая дорога в распределенный монолит :)
Странно, что свойства "распределённого монолита" , что обычно преподносятся как недостатки, у вас инвертированы и являются преимуществами. Такая разница в терминологии?
Полагаю, что монолит, который вы имеете в виду, не распределённый, потому что он не делает внутренних сетевых вызовов между своими частями (исключая запросы к БД). Тогда он имеет те свойства, что вы перечислили. Если же части работают через сетевые вызовы, как минимум могут возникать некоторые проблемы синхронизации.
И еще у меня подозрение что то, что вы описываете как микросервисы на самом деле и сами являются монолитами.
Естественно, сами микросервисы атомарны. Под "монолитом" имеется в виду вся система, а не её часть.
Это где слыхано чтоб 10 человек занималось одним микросервисом? Они скорее десятком-другим заведовать будут.
Это в общем верно, в зависимости от размера микросервисов 1 команда может потянуть и несколько их,и десятки, однако когнитивная нагрузка возрастает. Насколько нужно дробить сервисы - холиварный вопрос.
Под монолитом я подразумеваю единую кодовую базу. Из нее может создаваться много исполняемых модулей (микросервисов если хотите). Между собой они разумеется общаются сетевыми вызовами - иначе какой-же он распределенный.
В такой структуре у команды полный контроль над API и не надо вообще заботиться об обратной совместимости (если конечно к этой точке не обращаются извне). При этом сильно упрощается разработка и тестирование. Как это недостаток - я не понимаю.
Отсутствие дублирования данных - плюс. Особенно когда нужна транзакционность. Распределенные транзакции - это ну... такое. Кеширование данных внутри сервисов вызывает просто кучу проблем. Начиная от "я только что вот это вот ввел, а его вот тут нет" и заканчивая отказом платежа по причине старых маркетных данных. Как такое не считать преимуществом?
Проблемы синхронизации при монолите ничто по сравнению с проблемами микросервисов :) Когда есть "золотой источник" можно в конце концов все сбросить и загрузить заново. Но когда таких источников как микросервисов - пойти разберись что есть "сейчас". Т.е. в каком состоянии система находится в данный момент и вон то событие должно уже произойти или нет еще?
Конечно если вы Нетфликс и можно 10% пользователей в 1 из 100 случаев отказать (страницу перегрузят да и все), то конечно. Но если вы работаете с финансовой информацией или пользователь настолько привередлевый (а их у вас всего 10, но зато КАКИХ!), то надежность прежде всего.
Про дейплоймент тоже весело. Хорошо когда ты захотел и задеплоил. Не пошло - передеплоил. А то и А/В тестирование на живых юзерах устроил. А если вы релизить можете только один раз в неделю да и то в ночь с Субботы на Воскресенье и промахнуться не можете в принципе (ибо единственное разрешенное действие - откат), вот тогда и достоинства стабильной версии появляются во всей красе.
Энтерпрайз он такой - чтоб зарелизить надо 10 подписей (половина групп по Индийскому времени, половина по Нью Йоркскому, а еще 3 человека в отпуске), лид тайм в 3 дня (это когда вы вообще ничего не можете для этого релиза делать) и документации вагон. И все это только для того чтоб одну строчку поменять (иногда в конфиге).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не получить распределённый монолит