Следующий комментатор пишет :
Микросервисы переносят вашу организационную дисфункцию с проблемы времени компиляции на проблему времени выполнения.
Этот комментатор расширяет тему, говоря:
Функция не ошибка. Проблема времени выполнения => проблемы с продуктом => более сильная и быстрая обратная связь о дисфункции ответственным лицам
Теперь я получаю это с микросервисами вы:
- потенциально увеличивает задержку вашего сквозного потока - это проблема производства и времени выполнения.
- увеличьте количество «сетевых интерфейсов» в вашем коде, где могут возникнуть потенциальные ошибки синтаксического анализа во время выполнения.
- потенциально может делать сине-зеленые развертывания. Они могут быть задержаны несоответствиями интерфейсов (см. Сетевые интерфейсы). Но если сине-зеленые развертывания работают, то это скорее проблема времени выполнения.
Мой вопрос: что это означает, что переход на микросервисы создает проблемы во время выполнения?
microservices
runtime
compile-time
Hawkeye
источник
источник
Ответы:
У меня проблема. Давайте использовать микросервисы! Сейчас у меня 13 распределенных задач.
Разделение вашей системы на инкапсулированные, связные и разрозненные компоненты - хорошая идея. Это позволяет вам решать различные проблемы отдельно. Но вы можете сделать это на отлично в монолитном развертывании (см. Fowler: Microservice Premium ). В конце концов, это то, чему ООП учил много десятилетий! Если вы решите превратить свои компоненты в микросервисы, вы не получите никакого архитектурного преимущества. Вы получаете некоторую гибкость в отношении выбора технологии и, возможно, (но не обязательно!) Некоторую масштабируемость. Но вам гарантирована некоторая головная боль, обусловленная (а) распределенной природой системы и (б) коммуникацией между компонентами. Выбор микросервисов означает, что у вас есть другие проблемы, настолько острые, что вы готовы использовать микросервисы, несмотря на эти проблемы.
Если вы не можете спроектировать монолит, который четко разделен на компоненты, вы также не сможете спроектировать микросервисную систему. В монолитной кодовой базе боль будет довольно очевидной. В идеале код просто не будет компилироваться, если он ужасно сломан. Но с микросервисами каждый сервис может разрабатываться отдельно, возможно, даже на разных языках. Любые проблемы во взаимодействии компонентов не станут очевидными, пока вы не интегрируете свои компоненты, и в этот момент уже слишком поздно исправлять общую архитектуру.
Источник ошибок № 1 - несоответствие интерфейса. Могут быть явные ошибки, такие как отсутствующий параметр, или более тонкие примеры, такие как забывание проверять код ошибки или забывание проверять предварительное условие перед вызовом метода. Статическая типизация выявляет такие проблемы как можно раньше: в вашей IDE и в компиляторе, еще до того, как код запустится. Динамические системы не имеют такой роскоши. Он не взорвется, пока этот неисправный код не будет выполнен.
Последствия для микросервисов ужасны. Микросервисы по своей природе динамичны. Если вы не перейдете на официальный язык описания услуг, вы не сможете проверить правильность использования вашего интерфейса. Вы должны проверить, проверить, проверить! Но тесты дороги и обычно не являются исчерпывающими, что оставляет вероятность того, что проблемы могут все еще существовать в производстве. Когда эта проблема станет очевидной? Только когда этот ошибочный путь выбран во время выполнения в производстве. Понятие, что проблемы подталкивания приведут к более быстрой обратной связи,
веселоопасно неправильно, если вы не удивлены возможностью потери данных.источник
Первый твит был моим, поэтому я подробно остановлюсь на нем:
Предположим, у вас есть 100 разработчиков, работающих над монолитным приложением. Это слишком много людей, чтобы эффективно общаться друг с другом, поэтому компания должна усердно работать, чтобы разделить их на более мелкие команды и создать хорошие модели общения между ними. Когда организация "недееспособна", команды, вероятно, не разговаривают друг с другом, они не согласны с более крупной целью, они не согласны с приоритетами и т. Д. - в результате им нужно что-то отправлять навсегда. Это «проблема времени компиляции» в том смысле, что дисфункция очевидна до того, как программное обеспечение будет выпущено. Проект, вероятно, марш смерти или никогда не собирается отправлять («компилировать»).
Я думаю, что многих людей привлекают микроуслуги, и они переходят к ним не из-за присущих им технических / архитектурных преимуществ, а потому, что это позволяет им игнорировать организационную дисфункцию. Вместо того, чтобы пытаться объединить 100 разработчиков, они надеются, что у них могут быть крошечные команды, работающие в элеваторах, каждая из которых сосредоточена на своем собственном небольшом микро-сервисе. Если вы находитесь в такой неблагополучной организации, это настолько привлекательно: это дает вам гораздо больше возможностей избегать людей, которые вам не нравятся, не общаться.
К сожалению, это становится «проблемой времени выполнения», потому что после запуска программного обеспечения хорошее взаимодействие становится столь же важным. Проблемы с организацией - команды и то, как они выровнены и общаются - проявляются во время выполнения.
Суть моего твита была такова: если то, что у вас есть, это проблема людей , то новая архитектура не поможет. Это только задержит последствия проблемы. Я думаю, что привлекательность микроуслуг для многих людей - это надежда, что они волшебным образом решат проблемы этих людей.
источник
Это не то, что говорят эти твиты! Они ничего не говорят о переходе на микросервисы и ничего не говорят о создании проблем. Они только говорят что-то о проблемах переноса .
И они накладывают контекстное ограничение на свои утверждения, а именно на то, что ваша организация не функционирует.
Итак, первый твит в основном говорит о двух вещах:
Во втором твите говорится, что тот факт, что проблемы проявляются только на производстве, то есть там, где их видят клиенты, - это особенность, а не ошибка, потому что, когда клиенты жалуются, это, как правило, слышно в разных местах, а не при поломке сборки, а именно в местах, которые могут что-то сделать для организационной дисфункции (например, управление на высоком уровне). Поскольку организационная дисфункция обычно является ошибкой управления высокого уровня, это означает, что неудовлетворенные клиенты плохо отражаются на тех, кто в конечном счете несет ответственность за эту неудовлетворенность, в то время как низкое качество кода, вызванное ошибками управления более высокого уровня, обычно плохо сказывается на разработчиках, которые Однако не виноват и не может с этим что-то сделать.
Итак, в первом твите говорится, что микросервисы переносят проблемы, вызванные плохим управлением, со времени компиляции, где их видят только разработчики, во время выполнения, где их видят клиенты. Второй твит говорит, что это хорошо, потому что тогда проблемы наносят ущерб тем, кто за них отвечает.
источник
Это создает проблему времени выполнения, а не проблемы времени компиляции .
Монолитное приложение сложно и дорого компилировать. Но как только он скомпилируется, вы можете быть достаточно уверены, что между компонентами не существует каких-либо чрезвычайно глупых несовместимостей, потому что система типов может их перехватить. Та же самая ошибка в системе микросервисов может не проявиться, пока два конкретных компонента не будут взаимодействовать определенным образом.
источник
Как в монолитных системах, так и в микросервисах вы должны определять интерфейсы между подсистемами. Интерфейсы должны быть хорошо спроектированы, хорошо документированы и максимально стабильны. Это так же, как в ООП.
Если ваша организация не может этого сделать, микросервисы также не решат проблему. В микросервисах у вас есть общедоступные веб-интерфейсы. Так что вам даже придется потратить больше усилий на дизайн интерфейса.
Если интерфейс не разработан должным образом, вы получите два вида проблем во время выполнения:
Я думаю, что создание проблем во время выполнения не является правильным способом связи организационных проблем с ответственными.
источник