GK
А где Governance, там и архитекторы))
Size: a a a
2019 August 15
GK
Sergey Baranov
Меня это натолкнуло на то, что эмерджентное поведение от взаимодействия сервисов в общем случае не детерминировано и может быть шире, чем изначальная потребность. И то, что выходит за рамки изначальной потребности будет находиться вне контроля (вне поля зрения).
Хорошая мысль. Тогда можно говорить о контроле в конечном итоге
RT
Неявные связи сервисов порождают неожиданные спецэфекты в большой системе
RT
Давай будем формулировать более аккуратно. Термин dependency hell https://ru.wikipedia.org/wiki/Dependency_hell относится к использованию общих пакетов. В этом смысле, вызывающие друг-друга микросервисы могут (и должны) быть полностью независимыми компонентами. Т.е. в микросервисах нет такой проблемы. А на страшных рисунках выше нарисованы не зависимости, а нечто иное
Не согласен:
программыне библиотеки тоже как-бы должны быть независимы друг от друга.
Но для сложных задач всегда встает вопрос повторного использования решений и появляются ссылки одних модулей на другие.
В MSA аналогично - никому к примеру не придет в голову в каждом приложении отдельно реализовывать скажем шлюз отправки SMS,
а значит всегда будут зависимости между сервисами.
Задача в том чтобы правильно организовать эти зависимости, например чтобы не было циклических связей.
программыне библиотеки тоже как-бы должны быть независимы друг от друга.
Но для сложных задач всегда встает вопрос повторного использования решений и появляются ссылки одних модулей на другие.
В MSA аналогично - никому к примеру не придет в голову в каждом приложении отдельно реализовывать скажем шлюз отправки SMS,
а значит всегда будут зависимости между сервисами.
Задача в том чтобы правильно организовать эти зависимости, например чтобы не было циклических связей.
SB
Неявные связи сервисов порождают неожиданные спецэфекты в большой системе
Причем если для технических характеристик мы учимся сейчас с этим жить через chaos engineering, а с точки зрения функционального поведения вообще непонятно.
SB
На ум только exploratory testing приходит
SB
А существует ли реально такая проблема (про функциональное поведение) или это фантазии?)
MS
Не согласен:
программыне библиотеки тоже как-бы должны быть независимы друг от друга.
Но для сложных задач всегда встает вопрос повторного использования решений и появляются ссылки одних модулей на другие.
В MSA аналогично - никому к примеру не придет в голову в каждом приложении отдельно реализовывать скажем шлюз отправки SMS,
а значит всегда будут зависимости между сервисами.
Задача в том чтобы правильно организовать эти зависимости, например чтобы не было циклических связей.
программыне библиотеки тоже как-бы должны быть независимы друг от друга.
Но для сложных задач всегда встает вопрос повторного использования решений и появляются ссылки одних модулей на другие.
В MSA аналогично - никому к примеру не придет в голову в каждом приложении отдельно реализовывать скажем шлюз отправки SMS,
а значит всегда будут зависимости между сервисами.
Задача в том чтобы правильно организовать эти зависимости, например чтобы не было циклических связей.
С чем не согласны то? Могут ли два разных микросервиса использовать одну и ту же библиотеку? Да, могут. Но никому не придет в голову заставлять разработчиков этих сервисов синхронизировать версии. Могут ли два микросервиса вызывать один и тот же сервис? Да, могут. Но это не является зависимостью, в используемых выше терминах. Никому в голову не придет рисовать картинку того, как, например, какой-нибудь поисковый запрос в гугле разойдется по разным модулям, повлияет на сервисы рекомендации, статистику посещений, результаты последующих выдач и пр. Если это (было бы возможно) проанализировать, то граф получился бы еще тот
GK
С чем не согласны то? Могут ли два разных микросервиса использовать одну и ту же библиотеку? Да, могут. Но никому не придет в голову заставлять разработчиков этих сервисов синхронизировать версии. Могут ли два микросервиса вызывать один и тот же сервис? Да, могут. Но это не является зависимостью, в используемых выше терминах. Никому в голову не придет рисовать картинку того, как, например, какой-нибудь поисковый запрос в гугле разойдется по разным модулям, повлияет на сервисы рекомендации, статистику посещений, результаты последующих выдач и пр. Если это (было бы возможно) проанализировать, то граф получился бы еще тот
Если сервис вызывает другой сервис и зависит от результата вызова, то это зависимость.
GK
Никому не придёт в голову, потому что все понимают, что это невозможно.
MS
Если сервис вызывает другой сервис и зависит от результата вызова, то это зависимость.
Такие "зависимости" не вызывают проблему, именуемую Dependency hell. Вот когда нам в один бинарник нужно влинковать две разные версии функции - это проблема, разные версии динамически подключаемых библиотек - это проблема, а то, что множество узлов в интернет постоянно вызывают друг-друга по http это, вообще, не проблема. Так сеть устроена. То, что новые вызовы зависят от результатов предшествующих - это, тем более не проблема, это называется бизнес-логика. Вложенные синхронные вызовы это проблема. Ну так со времен SOA прошло уже много лет и все успели понаделать асинхронных развязок. Некоторые, даже угадали где именно их надо сделать
GK
Такие "зависимости" не вызывают проблему, именуемую Dependency hell. Вот когда нам в один бинарник нужно влинковать две разные версии функции - это проблема, разные версии динамически подключаемых библиотек - это проблема, а то, что множество узлов в интернет постоянно вызывают друг-друга по http это, вообще, не проблема. Так сеть устроена. То, что новые вызовы зависят от результатов предшествующих - это, тем более не проблема, это называется бизнес-логика. Вложенные синхронные вызовы это проблема. Ну так со времен SOA прошло уже много лет и все успели понаделать асинхронных развязок. Некоторые, даже угадали где именно их надо сделать
Вызывают, если становятся неконтролируемыми
GK
Бизнес логика которая закодирована в виде макарон, это проблема. Распределённые макароны это тоже проблема
GK
Чтобы не было макарон нужен контроль
SB
Чтобы не было макарон нужен контроль
Событийна модель скорее на суп похожа :)
MS
circuit breaker нужен, а не контроль :-))
GK
circuit breaker нужен, а не контроль :-))
Как он поможет?))
GK
Sergey Baranov
Событийна модель скорее на суп похожа :)
Точно, кипящий котёл)
GK
Если у вас макароны, то изменения в одном сервисе могут вызвать неконтролируемые ошибки в других. Circuit breaker защищает от недоступности сервисов, но не от распространения ошибок
MS
Как он поможет?))
отключит компонент, который нам не нравится(лучше навсегда). вообще, в средах, где доступные внешним клиентам сервисы явно декларируются предпосылок для лапши существенно меньше, чем при традиционном развертывании, когда каждый сервер светится по десяткам портов как новогодняя ёлка, а админы об этом даже не задумываются