Comments 15
Вода и капитанство, извините.
Как надо: microservices.io
Как надо: microservices.io
Я вот прочитал статью и не понял, а причём тут микросервисы?
1) Планирование? В любой проекте.
2) Глобальные переменные и синглтоны для любого проекта актуальны. И нет, они не всегда вредны.
и т.д.
Ну и в целом статья больше про код и архитектуру приложения как такового. В микросервисах самая большая, как по мне, проблема — это взаимодействие компонентов. В монолите у вас всё в куче, главного только обеспечить доступность, отказоустойчивость и т.п.
Когда вы монолит распилите, то надо настроить взаимодействие: REST? RabbitMQ или Kafka? Через базу? Или ещё как-то. Как наши сервисы найдут друг друга? consul? Или что-то другое для сервис дискавери.
В случае монолита, как правило, всего 2 состояния: работает и не работает. В случае с микросервисами надо думать и разруливать ситуации, когда какой-то сервис лежит.
Плюс, желательно, чтобы все эти отдельные сервисы были максимально стейтлес. А это тоже та ещё морока при переходе от монолита.
Возможно вообще лучше использовать что-то вроде kubernetes или mesos, тогда очень много чего переписать придётся.
1) Планирование? В любой проекте.
2) Глобальные переменные и синглтоны для любого проекта актуальны. И нет, они не всегда вредны.
и т.д.
Ну и в целом статья больше про код и архитектуру приложения как такового. В микросервисах самая большая, как по мне, проблема — это взаимодействие компонентов. В монолите у вас всё в куче, главного только обеспечить доступность, отказоустойчивость и т.п.
Когда вы монолит распилите, то надо настроить взаимодействие: REST? RabbitMQ или Kafka? Через базу? Или ещё как-то. Как наши сервисы найдут друг друга? consul? Или что-то другое для сервис дискавери.
В случае монолита, как правило, всего 2 состояния: работает и не работает. В случае с микросервисами надо думать и разруливать ситуации, когда какой-то сервис лежит.
Плюс, желательно, чтобы все эти отдельные сервисы были максимально стейтлес. А это тоже та ещё морока при переходе от монолита.
Возможно вообще лучше использовать что-то вроде kubernetes или mesos, тогда очень много чего переписать придётся.
> В случае с микросервисами надо думать и разруливать ситуации, когда какой-то сервис лежит.
Это и есть одно из главных преимуществ, разработка микросервиса предполагает, что либо мы вообще ничего не знаем о других микросервисах (управление через посредника), либо считаем, что каждый из них, либо все могут перестать работать в любой момент времени.
Это не навязанная сложность, это то, с чего начинается определение микросервиса. А возможно это потому, что микросервисная архитектура предполагает композицию на основе бизнес-функций, а не техническое разделение.
Т.е. у нас не сервис для базы, сервис для шаблонизатора, сервис для генерации изображений. У нас сервис для оформления заказа, сервис для оформления доставки и т.д. И у каждого, в идеале, своя база, своя сеть, процесс или поток, или контейнер. И если у нас упала база сервиса по оформлению заказов, то сервису доставки все равно. В итоге > 95% бизнеса работает 100% времени (uptime), причем можно распределять надежность по критичности сервиса (например, сервису оплаты выделить 50 программистов, а сервису «Планирование корпоратива» — 1).
Это и есть одно из главных преимуществ, разработка микросервиса предполагает, что либо мы вообще ничего не знаем о других микросервисах (управление через посредника), либо считаем, что каждый из них, либо все могут перестать работать в любой момент времени.
Это не навязанная сложность, это то, с чего начинается определение микросервиса. А возможно это потому, что микросервисная архитектура предполагает композицию на основе бизнес-функций, а не техническое разделение.
Т.е. у нас не сервис для базы, сервис для шаблонизатора, сервис для генерации изображений. У нас сервис для оформления заказа, сервис для оформления доставки и т.д. И у каждого, в идеале, своя база, своя сеть, процесс или поток, или контейнер. И если у нас упала база сервиса по оформлению заказов, то сервису доставки все равно. В итоге > 95% бизнеса работает 100% времени (uptime), причем можно распределять надежность по критичности сервиса (например, сервису оплаты выделить 50 программистов, а сервису «Планирование корпоратива» — 1).
И если у нас упала база сервиса по оформлению заказов, то сервису доставки все равно.Как сервис по доставке будет работать, если база с заказами недоступна?
А если упал сервис по оформлению доставки, то сервису оформления заказов тоже всё равно?
Как сервис по доставке будет работать, если база с заказами недоступна?
Потому, что у него своя база, никак не связанная с базой сервиса заказов. Архитектура строится так, что если сервису доставки нужны данные из заказа, то они загружаются в его собственную базу через обмен сообщениями, и ни в коем случае не через прямой обмен между базами или пользование одной. Это несет определенную нагрузку на систему сообщений, но полностью оправдывается слабой связанностью.
А если упал сервис по оформлению доставки, то сервису оформления заказов тоже всё равно?
Если бизнес-логикой они напрямую не связаны, то они поэтому и находятся в разных микросервисах. Принимаем спокойно заказы, а сервис доставки оперативно (или не очень) чиним.
Потому, что у него своя база, никак не связанная с базой сервиса заказов. Архитектура строится так, что если сервису доставки нужны данные из заказа, то они загружаются в его собственную базу через обмен сообщениями, и ни в коем случае не через прямой обмен между базами или пользование одной. Это несет определенную нагрузку на систему сообщений, но полностью оправдывается слабой связанностью.
Ага. Вот пользователь пришел и обновил в заказе данные об адресе доставки. В какой базе они обновились?
Ага. Вот пользователь пришел и обновил в заказе данные об адресе доставки. В какой базе они обновились?
Нужно разделять вопросы UI и вопросы микросервисов. Пользователь не меняет ничего в заказе, он что-то сделал в UI, при этом возникло некое сообщение. Оно должно быть доставлено всем заинтересованым сервисам. Часто делают API-шлюз, выполняющий роль транспорта (не более). Но возможен вариант и работы из UI напрямую с нужным сервисом. Соответственно, в сервис заказа придут нужные ему данные, а в сервис доставки — нужные ему. Если изменился лишь адрес, и он никак не используется в сервисе заказов, то соответственно ему даже сообщение это не придет, а все изменения произойдут в базе сервиса доставки.
Понятия заказ в UI и сервис заказов не связаны в данном случае.
Пользователь не меняет ничего в заказе, он что-то сделал в UI, при этом возникло некое сообщение.
С точки зрения пользователя, он меняет именно в заказе, ему плевать на вашу декомпозицию и сообщения. И с точки зрения бизнеса тоже изменился именно адрес доставки заказа.
Соответственно, в сервис заказа придут нужные ему данные, а в сервис доставки — нужные ему.
Ага, так кто же отвечает за то, чтобы данные пришли и провалидировались (ну то есть чтобы мы не вбили адрес, который наша доставка не умеет)?
Если изменился лишь адрес, и он никак не используется в сервисе заказов, то соответственно ему даже сообщение это не придет, а все изменения произойдут в базе сервиса доставки.
Вот только "сервису заказов" адрес нужен, потому что история заказов должна содержать адреса доставки. Что делать в этом случае?
А возможно это потому, что микросервисная архитектура предполагает композицию на основе бизнес-функций
Я стесняюсь спросить, а чем это отличается от старой доброй SOA с оркестровкой?
Я думаю, что ничем, кроме масштабируемости отдельных сервисов.
Отличается размером сервисов, как следует даже из названия. А это повышает надежность всей системы, меньше единовременных точек отказа. Опять же, чем меньше кусок, чем проще повторное использование.
Ну и вокруг этого понятия уже сформировались некие принципы, почитайте любую литературу, ключевые слова, highly cohesive, loosely coupled.
Ну и вокруг этого понятия уже сформировались некие принципы, почитайте любую литературу, ключевые слова, highly cohesive, loosely coupled.
Отличается размером сервисов, как следует даже из названия.
В названии-то что угодно можно написать, но "что конкретно"? Если мы и там, и там компонуем бизнес-функции, то размер сервиса определяется размером бизнес-функции, и больше ничем. Так за счет чего в микросервисах размер сервиса меньше?
Опять же, чем меньше кусок, чем проще повторное использование.
Это, кстати, неправда.
Ну и вокруг этого понятия уже сформировались некие принципы, почитайте любую литературу, ключевые слова, highly cohesive, loosely coupled.
Вы меня извините, но принципы "high cohesion, loose coupling" есть еще у МакКоннела — и это наверняка не единственное место, мне просто искать лень. Это, прямо скажем, вообще одни из базовых принципов в дизайне ПО.
Микросервисы — частный случай SOA.
Вы абсолютно точно описали все, что происходит, например, сейчас в средне-большом проекте на yii2, где я участвую.
Где нас 5-6 программистов и изначально «было написано кем-то» 30% функционала, в виде «монолита с антипаттернами» а-ля «раздутый yii2 basic app», а теперь уже все 80% (и мы не везде избавились от этих анти, а еще и дополнили))), но вовсю идет попытка, не теряя темпов разработки, отрефить все проблемы и выделить какое-то (потенциально rest) api, капсуляция виджетов, решение проблем применения фреймворка для действительно чего-то большого и т.п… Ни о каких микросервисах речи не идет пока, но весь ваш текст, кроме этого конечного пункта рефа — идеально подходит)))
Где нас 5-6 программистов и изначально «было написано кем-то» 30% функционала, в виде «монолита с антипаттернами» а-ля «раздутый yii2 basic app», а теперь уже все 80% (и мы не везде избавились от этих анти, а еще и дополнили))), но вовсю идет попытка, не теряя темпов разработки, отрефить все проблемы и выделить какое-то (потенциально rest) api, капсуляция виджетов, решение проблем применения фреймворка для действительно чего-то большого и т.п… Ни о каких микросервисах речи не идет пока, но весь ваш текст, кроме этого конечного пункта рефа — идеально подходит)))
Sign up to leave a comment.
Пилим монолит