Как переход на микросервисы создает проблему во время выполнения?

104

Микросервисы переносят вашу организационную дисфункцию с проблемы времени компиляции на проблему времени выполнения.

Этот комментатор расширяет тему, говоря:

Функция не ошибка. Проблема времени выполнения => проблемы с продуктом => более сильная и быстрая обратная связь о дисфункции ответственным лицам

Теперь я получаю это с микросервисами вы:

потенциально увеличивает задержку вашего сквозного потока - это проблема производства и времени выполнения.
увеличьте количество «сетевых интерфейсов» в вашем коде, где могут возникнуть потенциальные ошибки синтаксического анализа во время выполнения.
потенциально может делать сине-зеленые развертывания. Они могут быть задержаны несоответствиями интерфейсов (см. Сетевые интерфейсы). Но если сине-зеленые развертывания работают, то это скорее проблема времени выполнения.

Мой вопрос: что это означает, что переход на микросервисы создает проблемы во время выполнения?

microservices runtime compile-time

— Hawkeye
источник

13

Если A говорит с B в монолите, то, по крайней мере, фактический интерфейс может быть доказан совместимым (посредством статической типизации), что делает его более вероятным, что это также правильно. Обычно микросервисы связываются друг с

— Ричард Тингл

Если вы изучаете проблемы, связанные с использованием микросервисов, обязательно прочитайте статью Фаулера. martinfowler.com/articles/microservices.html Я считаю, что это не просто случай компиляции против времени выполнения, как сказал @Richard Tingle. И не совсем согласен с тем, что проблема производства лучше, чем проблема в разработке. Но микросервисы могут помочь масштабировать большие проекты другими способами. (И это перебор для большинства небольших проектов)

— Borjab

2

Этот комментатор недальновиден. Проблема времени выполнения => проблемы с продуктом => недовольные пользователи => потерянные деньги.

— Филипп

@ Филипп: в этом все дело. Проблемы времени компиляции, вызванные организационной дисфункцией => никого не волнует. Потеря денег, вызванная организационной дисфункцией =>, наносит ущерб именно тем, кто несет ответственность за указанную организационную дисфункцию. Надежда: организационная дисфункция устраняется быстрее.

— Йорг Миттаг

194

У меня проблема. Давайте использовать микросервисы! Сейчас у меня 13 распределенных задач.

Разделение вашей системы на инкапсулированные, связные и разрозненные компоненты - хорошая идея. Это позволяет вам решать различные проблемы отдельно. Но вы можете сделать это на отлично в монолитном развертывании (см. Fowler: Microservice Premium ). В конце концов, это то, чему ООП учил много десятилетий! Если вы решите превратить свои компоненты в микросервисы, вы не получите никакого архитектурного преимущества. Вы получаете некоторую гибкость в отношении выбора технологии и, возможно, (но не обязательно!) Некоторую масштабируемость. Но вам гарантирована некоторая головная боль, обусловленная (а) распределенной природой системы и (б) коммуникацией между компонентами. Выбор микросервисов означает, что у вас есть другие проблемы, настолько острые, что вы готовы использовать микросервисы, несмотря на эти проблемы.

Если вы не можете спроектировать монолит, который четко разделен на компоненты, вы также не сможете спроектировать микросервисную систему. В монолитной кодовой базе боль будет довольно очевидной. В идеале код просто не будет компилироваться, если он ужасно сломан. Но с микросервисами каждый сервис может разрабатываться отдельно, возможно, даже на разных языках. Любые проблемы во взаимодействии компонентов не станут очевидными, пока вы не интегрируете свои компоненты, и в этот момент уже слишком поздно исправлять общую архитектуру.

Источник ошибок № 1 - несоответствие интерфейса. Могут быть явные ошибки, такие как отсутствующий параметр, или более тонкие примеры, такие как забывание проверять код ошибки или забывание проверять предварительное условие перед вызовом метода. Статическая типизация выявляет такие проблемы как можно раньше: в вашей IDE и в компиляторе, еще до того, как код запустится. Динамические системы не имеют такой роскоши. Он не взорвется, пока этот неисправный код не будет выполнен.

Последствия для микросервисов ужасны. Микросервисы по своей природе динамичны. Если вы не перейдете на официальный язык описания услуг, вы не сможете проверить правильность использования вашего интерфейса. Вы должны проверить, проверить, проверить! Но тесты дороги и обычно не являются исчерпывающими, что оставляет вероятность того, что проблемы могут все еще существовать в производстве. Когда эта проблема станет очевидной? Только когда этот ошибочный путь выбран во время выполнения в производстве. Понятие, что проблемы подталкивания приведут к более быстрой обратной связи,~~весело~~ опасно неправильно, если вы не удивлены возможностью потери данных.

— Амон
источник

13

@JacquesB Я уверен, что «организационная дисфункция» относится к неспособности разработать систему. Большая часть моего ответа является контекстом, иллюстрирующим, как можно прийти к такому выводу, но это мое профессиональное мнение, а не взятое из твита.

— Амон

10

«Монолит, который четко разделен на компоненты» - что, черт возьми, это значит?

10

И не говоря уже о версиях интерфейсов (интерфейсы меняются со временем).

— Питер Мортенсен

12

@mobileink Монолит здесь не идеальный термин, так как он предлагает «без архитектуры». Но я пытаюсь передать систему, которая разработана и развернута как единая система, в отличие от сервис-ориентированной архитектуры, в которой части системы могут быть развернуты независимо. Пожалуйста , измените пост , если вы знаете , лучший термин ...

— Амон

7

@amon Услышав слово «Монолит», не сразу возникает идея «без архитектуры». Большинство зданий - это монолиты, как и Великие пирамиды Египта, и многие другие предметы. Ясно, что они были спроектированы и доставлены в целом. Многим программным системам не хватает хорошей архитектуры; но отсутствие хорошей архитектуры, кажется, не зависит от того, как они развернуты. Вы можете позаимствовать некоторые леса другого проекта и назвать его архитектурой (3-уровневая, 2-уровневая, n-уровневая, микросервисная и т. Д.), Но это не гарантирует, что вы сделали это хорошо.

— Эдвин Бак

215

Первый твит был моим, поэтому я подробно остановлюсь на нем:

Предположим, у вас есть 100 разработчиков, работающих над монолитным приложением. Это слишком много людей, чтобы эффективно общаться друг с другом, поэтому компания должна усердно работать, чтобы разделить их на более мелкие команды и создать хорошие модели общения между ними. Когда организация "недееспособна", команды, вероятно, не разговаривают друг с другом, они не согласны с более крупной целью, они не согласны с приоритетами и т. Д. - в результате им нужно что-то отправлять навсегда. Это «проблема времени компиляции» в том смысле, что дисфункция очевидна до того, как программное обеспечение будет выпущено. Проект, вероятно, марш смерти или никогда не собирается отправлять («компилировать»).

Я думаю, что многих людей привлекают микроуслуги, и они переходят к ним не из-за присущих им технических / архитектурных преимуществ, а потому, что это позволяет им игнорировать организационную дисфункцию. Вместо того, чтобы пытаться объединить 100 разработчиков, они надеются, что у них могут быть крошечные команды, работающие в элеваторах, каждая из которых сосредоточена на своем собственном небольшом микро-сервисе. Если вы находитесь в такой неблагополучной организации, это настолько привлекательно: это дает вам гораздо больше возможностей избегать людей, которые вам не нравятся, не общаться.

К сожалению, это становится «проблемой времени выполнения», потому что после запуска программного обеспечения хорошее взаимодействие становится столь же важным. Проблемы с организацией - команды и то, как они выровнены и общаются - проявляются во время выполнения.

Суть моего твита была такова: если то, что у вас есть, это проблема людей , то новая архитектура не поможет. Это только задержит последствия проблемы. Я думаю, что привлекательность микроуслуг для многих людей - это надежда, что они волшебным образом решат проблемы этих людей.

— Пол Стовелл
источник

67

+1. Это гораздо лучше, чем ответ Stack Exchange, чем твит. :-)

— Руах

3

То же самое верно для любых динамических систем. Динамическая типизация очень полезна, но только если у вас есть нужные люди. «Базы данных свободной формы» очень полезны, но только если у вас есть нужные люди. Если у вас нет нужных людей, вы просто делегируете проблемы, а не решаете их.

— Луан

2

Я думаю, что это тавтология. Когда люди являются проблемой, проблемы могут проявляться везде. Я не могу представить решение, работающее в виде набора микросервисов, без надлежащих интеграционных тестов. В таком случае не существует способа доставки решения с поддерживаемым рабочим процессом. Если кто-то переходит на микросервисы без тестирования потока, особенно для того, чтобы скрыть проблемы, они являются проблемой. Также можно отправить непроверенные / сломанные двоичные файлы. Это поднимает проблему от программистов уровня солдата выше, где это принадлежит.

— luk32

10

@ luk32 Отчасти да, но суть микросервисов, которые делают его привлекательным для плохих команд, заключается в том, что вы заставляете свои навыки и дефицит общения оставаться незамеченными в течение более длительного периода времени. Дело не в том, иметь проблемы или нет, о том, когда они

— Т. Сар - Восстановить Монику

18

Очень хороший ответ. Спасибо за подтверждение моего мнения о Твиттере как совершенно бесполезного для всего, кроме возбуждения людей.

— Роберт Харви

43

Мой вопрос: что это означает, что переход на микросервисы создает проблемы во время выполнения?

Это не то, что говорят эти твиты! Они ничего не говорят о переходе на микросервисы и ничего не говорят о создании проблем. Они только говорят что-то о проблемах переноса .

И они накладывают контекстное ограничение на свои утверждения, а именно на то, что ваша организация не функционирует.

Итак, первый твит в основном говорит о двух вещах:

«если ваша организация сейчас не способна проектировать сложные системы без микросервисов, она волшебным образом не сможет проектировать сложные системы с микросервисами» и
«проблемы, вызванные этой неспособностью, которые теперь проявляются во время компиляции, то есть во время разработки, затем будут обнаруживаться во время выполнения, то есть в производстве» (технически они также могут появляться во время тестирования, но помните, цитата ограничивает себя неблагополучным организациям, которые, вероятно, имеют нестандартный режим тестирования)

Во втором твите говорится, что тот факт, что проблемы проявляются только на производстве, то есть там, где их видят клиенты, - это особенность, а не ошибка, потому что, когда клиенты жалуются, это, как правило, слышно в разных местах, а не при поломке сборки, а именно в местах, которые могут что-то сделать для организационной дисфункции (например, управление на высоком уровне). Поскольку организационная дисфункция обычно является ошибкой управления высокого уровня, это означает, что неудовлетворенные клиенты плохо отражаются на тех, кто в конечном счете несет ответственность за эту неудовлетворенность, в то время как низкое качество кода, вызванное ошибками управления более высокого уровня, обычно плохо сказывается на разработчиках, которые Однако не виноват и не может с этим что-то сделать.

Итак, в первом твите говорится, что микросервисы переносят проблемы, вызванные плохим управлением, со времени компиляции, где их видят только разработчики, во время выполнения, где их видят клиенты. Второй твит говорит, что это хорошо, потому что тогда проблемы наносят ущерб тем, кто за них отвечает.

— Йорг Миттаг
источник

6

@Michael Если вы не видите, как они влияют на качество кода, возможно, подумайте, какое влияние (если таковое имеется) оказывает руководство на какую-либо часть качества продуктов, которые создает их бизнес.

— 17

30

@ Майкл: Все в конечном счете вызвано управлением высшего уровня. Низкое качество кода вызвано невозможными сроками? Кто устанавливает эти сроки? Кто говорит тем, кто устанавливает эти сроки, чтобы установить эти сроки? Низкое качество кода вызвано некомпетентными разработчиками? Кто нанял этих некомпетентных разработчиков? Кто нанял тех, кто нанял этих некомпетентных разработчиков? Это вызвано неадекватной оснасткой? Кто покупает эти инструменты? Кто утверждает бюджет на покупку этих инструментов? Это вызвано глупой архитектурой? Кто нанял архитектора? Кто его возглавил? Эти твиты были конкретно в контексте ...

— Йорг Миттаг

13

… Организационная дисфункция. Ну, что делает функцию организации в значительной степени работу управления более высокого уровня. Это то, что управление является .

— Йорг Миттаг

4

Хотя это, вероятно, будет работать в долгосрочной перспективе, идея решения проблем вашей компании, оказывая влияние на клиентов, кажется неправильной.

— Стейн де Витт

1

@ JörgWMittag Я не считаю разумным утверждать, что плохой код, написанный плохими разработчиками, - это вина людей, которые наняли этих плохих разработчиков, а не самих плохих разработчиков. В конечном итоге это может быть обязанностью руководства, но это вызвано разработчиками.

— Майлз Рут

9

Это создает проблему времени выполнения, а не проблемы времени компиляции .

Монолитное приложение сложно и дорого компилировать. Но как только он скомпилируется, вы можете быть достаточно уверены, что между компонентами не существует каких-либо чрезвычайно глупых несовместимостей, потому что система типов может их перехватить. Та же самая ошибка в системе микросервисов может не проявиться, пока два конкретных компонента не будут взаимодействовать определенным образом.

— Килиан Фот
источник

9

Кажется, это предполагает, что «монолитные» приложения всегда статически типизированы. Как насчет динамически типизированных языков? А как насчет статически типизированных сервисных интерфейсов?

— JacquesB

1

@JacquesB OTOH, я могу представить себе ровно ноль динамически типизированных компилируемых языков.

— user253751

2

@JacquesB JavaScript и Python не скомпилированы. Если только вы не считаете внутренние структуры интерпретатора целью компиляции, в этом случае компилируется каждый язык .

— user253751

3

@immibis: каждая существующая в настоящее время реализация ECMAScript имеет как минимум один компилятор. Например, V8 имеет два компилятора и ровно нулевой интерпретатор, он никогда не интерпретирует, он всегда компилируется в двоичный машинный код. Я считаю, что у SpiderMonkey четыре компилятора и один интерпретатор, но этот интерпретатор не интерпретирует ECMAScript. SpiderMonkey никогда не интерпретирует ECMAScript, он всегда сначала компилирует его в байт-код SpiderMonkey, который затем может дополнительно скомпилировать в двоичный машинный код. Все существующие в настоящее время реализации Python, Ruby и PHP имеют компиляторы.

— Йорг Миттаг

12

@LieRyan Вы серьезно смущены, если считаете, что вывод типа совпадает с динамически типизированным и / или что Хаскель динамически типизирован.

— Дерек Элкинс

2

Как в монолитных системах, так и в микросервисах вы должны определять интерфейсы между подсистемами. Интерфейсы должны быть хорошо спроектированы, хорошо документированы и максимально стабильны. Это так же, как в ООП.

Если ваша организация не может этого сделать, микросервисы также не решат проблему. В микросервисах у вас есть общедоступные веб-интерфейсы. Так что вам даже придется потратить больше усилий на дизайн интерфейса.

Если интерфейс не разработан должным образом, вы получите два вида проблем во время выполнения:

Если интерфейс используется неправильно, вы получите ошибку во время выполнения, а не во время компиляции.
Вызов веб-интерфейса довольно медленный, поэтому вы можете столкнуться с проблемами производительности.

Я думаю, что создание проблем во время выполнения не является правильным способом связи организационных проблем с ответственными.

— Bernie
источник